在⼀个通道上，区块是⼀组有序交易的集合。在通道中经过加密（哈希加密）
后与前序区块连接。
Zhu Jiang:账本的链是⼀个交易区块经过“哈希连接”结构化的交易⽇志。对等
节点从排序服务收到交易区块，基于背书策略和并发冲突来标注区块的交易为
有效或者⽆效状态，并且将区块追加到对等节点⽂件系统的哈希链中。
1.0 架构中⼀种 peer 节点⻆⾊，负责维护区块链和账本结构。对 orderer 排序
后的交易进⾏检查（包括交易消息结构、签名完整性、是否重复、读写集合版
本是否匹配等），检查完成后选择合法的交易执⾏并写⼊存储。
同⼀个物理节点可以仅作为Committer⻆⾊运⾏，也可以同时担任Endorser和
Committer这两种⻆⾊。
1.0 架构中⼀种 peer 节点⻆⾊，负责检验某个交易是否合法，是否愿意为之背
书、签名。
收到来⾃客户端的交易提案后，⾸先进⾏合法性和ACL权限检查，检查通过则
模拟运⾏交易，对交易导致的状态变化（以读写集形式记录，包括所读状态的
键和版本，所写状态的键值）进⾏背书并返回结果给客户端。注意⽹络中可以
只有部分节点担任Endorser⻆⾊。
1.0 架构中的共识服务⻆⾊，为⽹络中所有合法交易进⾏全局排序，并将⼀批
排序后的交易组合⽣成区块结构。
⽬前Orderer⽀持Solo（单节点共识）、kafka（分布式队列）、PBFT（拜占庭
容错）三种模式。
order-solo模式作为单节点通信模式，所有从peer收到的消息都在本节点进⾏
排序与⽣成数据块，因此不需要“共识”；对应的也就失去了⾼可⽤性与拓展
性。Solo使得开发与测试⾮常的简便易于使⽤，这种模式主要是为了⾮⽣产环
境⽽存在的。
此模式需要加⼊⼀个kafka集群统⼀分配处理所有Orderer的数据。Orderer服务
从kafka集群⾥获取相应topic，即在kafka队列中隔离出来不同的作⽤域供
Orderer使⽤。kafka的分布式⼀致机制确保了我们的交易数据是有序的。
虽然引⼊了kafka带来了较⾼的吞吐量以及可⽤性，但是却没有拜占庭容错。
⼀个⽹络实体，维护账本并运⾏链码容器来对账本执⾏读写操作。peer由
Member拥有和维护。
每⼀个Member在其订阅的channel上可以拥有多个peer，其中⼀个peer会作为
channel的leading peer代表该Member与ordering service通信。ordering
service将block传递给leading peer，该peer再将此block分发给同⼀member下
的其他peer。
即智能合约，是⼀个运⾏在账本上的⼀段代码，⽤来实现不同的业务逻辑，可
以实现对StateDB的增删改查。
⽀持golang等开发语⾔，运⾏在独⽴的Docker环境中。从Fabric1.0开始
Chaincode⽀持更新部署。
通道是构建在“Fabric”⽹络上的私有区块链，实现了数据的隔离和保密。通道
特定的账本在通道中是与所有对等节点共享的，并且交易⽅必须通过该通道的
正确验证才能与账本进⾏交互。通道是由⼀个“配置块”来定义的。