系统概述
1、系统维护一个被复制的有序的交易记录，称为帐本；
2、维护这个记录的系统参与者称为节点。节点运行共识协议（RBFT），以商定交易的顺序。为简单起见，可以假设其中一个节点是领导者（主），它决定交易的顺序，并将其与节点的其余部分（追随者）进行通信；
3、共识协议的每次运行（3阶段提交）都会对一批交易集合进行调整；
4、节点维护几个账本，每一个都有一个明确的目的。它有一个用于节点成员交易的账本池，如添加新节点、暂停节点、改变ip/端口或节点的键、身份交易的帐本等等；
5、除了帐本，节点还保持每个账本状态，即Merkle Patricia Trie。它可能还会保留其他一些对账的预测。有关存储的更多信息，请参考存储文档
6、拥有适当权限的客户端可以向节点发送写交易请求，但是任何客户端都可以将读请求发送给节点；
7、客户端到节点和节点到节点的通信发生在CurveZMQ上。代码库抽象一个“Stack”来管理通信。它有几个变体，提供不同的特性；
8、在接收交易节点上执行一些基本验证，并将请求广播到其他节点。这被称为请求传播，在RBFT论文中有更多的细节。一旦节点意识到有足够多的节点得到了请求，它们就会认为这个请求已经准备好处理了。主节点通过一个3阶段提交过程发起新一轮的共识，在此过程中，所有节点将交易添加到他们的帐本和相应的存储中。更多关于RBFT论文3阶段提交的详细信息。不同类型的请求会更新不同的账簿和存储层。这里有一个关于请求处理的详细解释
9、在系统的生命周期中，节点可能崩溃和重新启动，断开连接/重新连接，新的节点可能加入网络。因此，节点需要一种机制来获得他们错过或从未有过的交易（新节点）。他们通过一个叫做“catchup”的处理来做到这一点。在这里，节点通信它们的状态并学习其他节点的状态，然后如果节点意识到它们已经落后了，它们就会运行一个协议来获取丢失的交易。更多的是在“ catchup document”中；
10、通过MESSAGE_REQUEST消息，节点可以请求来自其他节点的各种特定协议的消息；
11、当主节点崩溃时（或以任何方式变得不可用），或者它通过发送坏消息或减慢它的速度，那时跟随节点启动一个协议来改变领导者，这个协议被称为view change。view change涉及到选择一个新的领导者，这是在循环的方式和通信（如果需要的话）的情况下进行的，所以在新领导者启动之前，每个节点都有相同的状态。
12、共识回合（3阶段提交）与RBFT的论文有一些不同之处：
1）RBFT介绍了每个请求都是独立的3个阶段提交，但是在plenum上，在批量请求中执行3个阶段提交;这使它更有效率，因为3阶段提交涉及到n平方的通信（n是节点的数量）；
2）PRE-PREPARE和PRE-PREPARE包含merkle树根state trie根，用来确认执行成批请求的每个节点都有相同的账本和状态；
3）PRE-PREPARE包含批次的时间戳;追随者节点在PREPARE时检查验证时间戳是否有效、认可。时间戳储存在每一个交易的账本中；
4）3阶段提交还包括一个签名聚合协议，其中所有节点都在state trie根上提交签名，并且这些签名被聚合和存储。稍后，稍后，当客户端需要查询状态时，客户端将被给予一个state trie根上的状态值和已签名（聚合签名）根的结果。因此，客户端不需要依赖来自多个节点的响应。使用的签名方案是BLS
欢迎大家一起加入讨论！！！