存储空间开销大

对于哈希表来说，需要遍历整个表，时间效率为O(n)

说句实话，工程上来说，和hash比起来，trie就是没有用的东西。这个可以说很深刻地表现出了一个学生和一个软件工程师的思维差异。你可能很清楚，hash类的算法都有可能因为碰撞而退化，而trie是稳定的复杂度，简直太招人喜欢了。但是工程师99.9%的情况下都会用hash。因为，hash函数、map、set，都有内置库，所有语言都有。这意味着一个功能用hash就是五行代码，甚至体现不出用了hash，而用trie，你要么先交一份trie开源库的分析选型比较报告来，要么自己撸一个，附带着先写一千行的单元测试用例，再跑个压测。万一将来换个语言，请从头再来。是的，就是这么简单，工程师才不会考虑碰撞，他们甚至不关心rehash、hash实现这些细节，许多语言内置的hash实现已经考虑了防止恶意碰撞了，而随机碰撞，没有那么巧的事情。写出简单可用能快速上线的代码要更重要。你看出来了，学术关心理论最优，工程关心实践最优。你可能愤愤不平，为啥标准库不把trie加进去？那你有没有想过这些问题呢？1. 如果字符串不是常见的英文小写字母，而是unicode呢？2. 如果这些字符串超级长，甚至有傻子拿来了一千个文本文件，每个有100KB呢？3. 字符串现在多得不能忍了，需要分布式处理，你要怎么设计一个分布式的trie（要记得trie的节点分布可能是高度不均衡的）？所以，工程看重什么也是有道理的。当然trie自然不是真的没用，它支持前缀匹配，支持范围查找，这些都有独特的应用，比如数据库里字符串类型的索引就经常实现为前缀树（另一种常见实现自然就是hash）。但说实话，不会有工程师认为这是两种可以相互竞争的技术。

从创世区块开始，无尽的交易不断的刷新着系统当前状态，每产生一个区块就对当前状态做一次快照（patricia trie根）存入区块头中。

我们选取了Snappy来实现数据包压缩和解压功能

支持监管

账本里包含的基本内容有区块，交易，账户，世界状态

智能合约执行过程产生的状态数据，经过共识机制确认，分布式的保存在各节点上，数据全局一致，可验证难篡改，所以称为“世界状态”。

支持采用C++编写合约

世界状态的存储从原来的MPT存储结构转为分布式存储，避免了世界状态急剧膨胀导致性能下降的问题；

各群组独立执行共识流程，由群组内参与者决定如何进行共识，一个群组内的共识不受其他群组影响，各群组拥有独立的账本

可支持监管和审计机构作为观察节点加入

同态加密、零知识证明、群签名、环签名

预编译合约框架

分布式存储定义了标准的数据访问CRUD接口，可以适配多种存储系统，同时支持SQL和NoSQL两种数据管理方式

实现群组架构，在多个节点组成的一个全局网络中，可以存在多个节点子集组成的子网络，这些子网络维护一个独立的账本。

Indeed, the ordering service nodes operate a mini-blockchain, connected via the system channel we mentioned earlier. Using the system channel ordering service nodes distribute network configuration transactions. These transactions are used to co-operatively maintain a consistent copy of the network configuration at each ordering service node. In a similar way, peer nodes in an application channel can distribute channel configuration transactions. Likewise, these transactions are used to maintain a consistent copy of the channel configuration at each peer node.

Both network and channel configurations are kept consistent using the same blockchain technology that is used for user transactions – but for configuration transactions. To change a network or channel configuration, an administrator must submit a configuration transaction to change the network or channel configuration. It must be signed by the organizations identified in the appropriate policy as being responsible for configuration change. This policy is called the mod_policy and we’ll discuss it later.

It means that although ordering service node O4 is the actor that created consortia X1 and X2 and channels C1 and C2, the intelligence of the network is contained in the network configuration NC4 that O4 is obeying. As long as O4 behaves as a good actor, and correctly implements the policies defined in NC4 whenever it is dealing with network resources, our network will behave as all organizations have agreed. In many ways NC4 can be considered more important than O4 because, ultimately, it controls network access.

We can see that network and channel configurations are logically singular – there is one for the network, and one for each channel. This is important; every component that accesses the network or the channel must have a shared understanding of the permissions granted to different organizations.

It is managed exclusively by R2 and R3; R1 and R4 have no power in channel C2.

A new channel can only be created by those organizations specifically identified in the network configuration policy, NC4, as having the appropriate rights to do so, i.e. R1 or R4.

It all means that it is possible to configure sophisticated topologies which support a variety of operational goals – there is no theoretical limit to how big a network can get. Moreover, the technical mechanism by which peers within an individual organization efficiently discover and communicate with each other – the gossip protocol – will accommodate a large number of peer nodes in support of such topologies.

We can see that the careful addition of peers to the network can help support increased throughput, stability, and resilience. For example, more peers in a network will allow more applications to connect to it; and multiple peers in an organization will provide extra resilience in the case of planned or unplanned outages.

Copies of smart contract S5 will usually be identically implemented using the same programming language, but if not, they must be semantically equivalent.

However, if R2 wanted to change the chaincode definition, both R1 and R2 would need to approve a new definition for their organization, and then one of the organizations would need to commit the definition to the channel.

A new organization can use the chaincode as soon as they approve the chaincode parameters agreed to by other members of the channel.

It’s more the case that peer nodes with smart contracts have a special power – to help generate transactions. Note that all peer nodes can validate and subsequently accept or reject transactions onto their copy of the ledger L1.

A peer can only run a smart contract if it is installed on it, but it can know about the interface of a smart contract by being connected to a channel.

Note that a peer can be a committing peer, endorsing peer, leader peer and anchor peer all at the same time! Only the anchor peer is optional – for all practical purposes there will always be a leader peer and at least one endorsing peer and at least one committing peer.

If a peer needs to communicate with a peer in another organization, then it can use one of the anchor peers defined in the channel configuration for that organization.

For the static set, zero or more peers can be configured as leaders. For the dynamic set, one peer will be elected leader by the set. Moreover, in the dynamic set, if a leader peer fails, then the remaining peers will re-elect a leader.

When an organization has multiple peers in a channel, a leader peer is a node which takes responsibility for distributing transactions from the orderer to the other committing peers in the organization.

Client applications do this by sending transaction proposals to peers owned by the organizations specified by the smart contract endorsement policy. The transaction proposal serves as input to the smart contract, which uses it to generate an endorsed transaction response, which is returned by the peer node to the client application.

It describes which organizations must approve transactions before they will be accepted by other organizations onto their copy of the ledger.

A sufficient number of organizations need to approve a chaincode definition (A majority, by default) before the chaincode definition can be committed to the channel and used to interact with the channel ledger.

When an organization has multiple peers in a channel, it can choose the peers upon which it installs smart contracts;

an administrator in organization R1 must create a chaincode package and install it onto peer node P1

client application A1 has to go through smart contract S5 to get to ledger L1!

note that R4 cannot add itself to the channel C1 – it must, and can only, be authorized by R1 or R2.

Ordering services are usually multi-node, and can be configured to have different nodes in different organizations.

R4 users administrative

though in practice, organizations will choose to use their own CA.

a specific user ID could be permitted to invoke a chaincode application, but be blocked from deploying new chaincode

To improve upon its privacy and confidentiality capabilities, Fabric has added support for private data and is working on zero knowledge proofs (ZKP) available in the future. More on this as it becomes available.

This design departs radically from the order-execute paradigm in that Fabric executes transactions before reaching final agreement on their order.

execute-order-validate

One of the most important of the platform’s differentiators is its support for pluggable consensus protocols that enable the platform to be more effectively customized to fit particular use cases and trust models.

application code should be treated as untrusted, potentially even malicious.

in such a permissioned context, the risk of a participant intentionally introducing malicious code through a smart contract is diminished