Indy Plenum - 系统概要

原文地址：https://hyperledger-indy.readthedocs.io/projects/plenum/en/latest/main.html

• The system maintains a replicated ordered log of transactions called the ledger.
  系统维护了一个有序的交易 log 副本，这个副本被称为账本。
• Participants of the system which maintain this log are called the nodes. The nodes run a consensus protocol (RBFT) to agree on the order of transactions. For simplicity it can be assumed that one of the node is the leader (primary) which determines the order of transactions and communicates it to the rest of the nodes (followers).
  系统中这些维护账本的参与者被称为节点。这些节点运行着一个共识协议(RBFT) 来对交易的排序达成一致。简单来说，我们可以假设有一个节点是 leader (primary) 节点，它决定了交易的排序，并且会将它沟通给剩余的节点 (followers)。
• Each run (3 phase commit) of the consensus protocol orders a batch (collection) of transactions.
  每个节点运行着 (3 阶段提交) 共识协议将交易的一个 batch (集合) 进行排序。
• Nodes maintain several ledgers, each for a distinct purpose. It has a pool ledger for node membership transactions like addition of new node, suspension of a node, change of IP/port or keys of a node, a ledger for identity transactions, etc
  这些节点维护者不同目的的多个账本。其中包括节点成员交易的一个 pool 账本，里边存储的像添加新的节点，暂停一个节点，改变一个节点的 IP/port 或者密钥，还有 identity 交易的账本，等等。
• Apart for the ledger, nodes maintain state (for each ledger) which is 它是一个 Merkle Patricia Trie. It might maintain several other projections of the ledger. For more on storage, refer the storage 文档.
  除了账本，节点还维护着 state (每个账本的)，它是一个 Merkle Patricia Trie。它可能也在维护其他的有关账本的投影。对于 storage 的更多信息，参考 storage 文档。
• Clients with appropriate permissions can send write requests (transactions) to the nodes but any client can send read requests to the nodes.
  具有一定权限的客户端能够像节点发送写的请求 (交易)，但是所有的客户端都可以向节点发送读的请求。
• Client-to-node and node-to-node communication happens on CurveZMQ. The codebase has an abstraction called Stack that manages communication. It has several variants which offer different features.
  客户端到节点，以及节点到节点的沟通是在 CurveZMQ 上发生的。这个代码含有一个被称为 Stack 消息沟通的抽象方法。它含有不同的变形，以提供不同的方法。
• On receiving transactions nodes perform some basic validation and broadcast the request to other nodes. This is called request propagation, more details in RBFT paper. Once the nodes realise that enough nodes have got the request, they consider the request ready for processing. The primary node initiates a new round of consensus through a 3 phase commit process at the end of which all nodes add the transaction to their ledger and corresponding storages. More details on 3 phase commit in RBFT paper. Different kinds of requests update different ledgers and storage layers. A detailed explanation of request handling is present 这里
  当收到交易的时候，节点会进行一些基本的校验，然后将这个请求广播给其他节点。这被称为请求传播，，更详细的内容，请参考 RBFT 文档。一旦节点发现，有足够的节点已经拿到了这个请求，他们会认为这个请求已经可以被处理了。Primary 节点会初始新一轮的一个要通过 3 个阶段提交的共识，每个阶段的最后所有节点都会将交易添加到他们的账本以及对应的 storages 里。关于 3 阶段提交的详细信息，请参考 RBFT 文档。不同类型的请求会更新不同的账本以及 storage 层。这里 是关于请求处理的详细解释。
• During the life of the system, nodes might crash and restart, get disconnected/re-connected, new nodes might join the network. Thus nodes need a mechanism to get the transactions they have missed or never had (new node). They do this by a process called catchup. Here the nodes communicate their state and learn other node’s states and then if the nodes realise that they are behind, they run a protocol to get the missing transactions. More on this in the catchup document
  在系统的生命中，节点可能会崩溃或者重启，断开/重新连接，还有新的节点可能会加入。因此节点需要有一种机制来得到他们错过的或者从来都没有的 (新节点) 交易信息。它们通过一种叫做 catchup 的过程来实现这个。在这里，节点会交流它们的 state，并且了解其他节点的 states，如果节点意识到它们的信息是落后的话，它们会运行一个协议来获得错过的交易信息。更多的信息可以查看 catchup document。
• The nodes can request various protocol-specific messages from other nodes by a MESSAGE_REQUEST message.
  节点可以通过 MESSAGE_REQUEST 从其他节点那里请求不同的特定协议的消息。
• When the primary node crashes (or becomes non functional in any way), or it misbehaves by sending bad messages or it slows down then the follower nodes initiate a protocol to change the leader, this protocol is called view change. View change involves selecting a new leader, which is done in a round robin fashion and communication (and catchup if needed) of state so before the new leader starts, every node has the same state.
  当 primary 节点崩溃 (或者任何方式变得不工作) 的时候，或者它通过发送坏的消息而产生的不正常的行为，或者变得很慢的时候，follower 节点会初始一个协议来改变 leader 节点，这个协议叫 view change。View change 涉及到选择一个新的 leader，这个是以 round robin 的形式来进行的，然后会进行 state 的交流 (如果需要的话还会 catchup)，所以在新的 leader 开始工作之前，每个节点都会有相同的 state。
• The consensus round (3 phase commit) has some differences with the RBFT paper:
  同 RBFT 文档相比，这里的共识 (3 阶段提交) 有一些不同：
  1. RBFT describes a distinct 3 phase commit for each request, but in plenum, a 3 phase commit happens on batch of requests; this makes it more efficient since 3 phase commit involves n-squared communication (n being the number of nodes).
     RBFT 为每一个请求都描述一个 3 阶段提交，但是在 plenum 中，这个 3 阶段提交是发生在多个请求的 batch 上的，这个会更有效率，因为 3 阶段的提交会涉及到 n 次方的沟通 (n 是节点的数量)。
  2. PRE-PREPARE and PREPARE contain merkle tree roots and state trie roots which are used to confirm that each node on executing the batch of requests has the same ledger and state.
     PRE-PREPARE 和 PREPARE 包含了 merkle tree 的根以及 state trie 的根，它们被用来确认执行这个 batch 请求的每个节点都拥有相同的账本和 state。
  3. PRE-PREPARE contains a timestamp for the batch; the follower nodes check validate the timestamp and if valid, acknowledge with a PREPARE. The timestamp is stored in the ledger for each of the transaction.
     PRE-PREPARE 包含了 batch 的一个时间戳，follower 节点会检查验证这个时间戳，如果这个时间戳是有效的，那么就会带着一个 PREPARE 来接收。每个交易的时间戳都会存储在账本中。
  4. The 3 phase commit also includes a signature aggregation protocol where all nodes submit their signature on the state trie root and those signatures are aggregated and stored. Later when a client needs to query the state, the client is given a poof over the state value and the signed (aggregated signature) root. Thus the client does not have to rely on response from multiple nodes. The signature scheme used is BLS
     这个 3 阶段提交含包含一个聚合签名协议，所有的节点会在 state trie 根上提交它们的签名，这些签名会被聚合并存储。稍后当一个客户端需要查询 state 的时候，该客户端会被提供一个基于 state 的值以及被签过名 (聚合签名) 的根的证明。所以，客户端就不需要依赖于来自多个节点的反馈了。签名的 scheme 使用的是 BLS。