超级账本Fabric-0.6的PBFT共识算法

在超级账本 Fabric 的0.6版中主要使用经典的PBFT共识算法。一次完整的共识需要经历 Request，Pre-Prepare、Prepare、Commit、Reply五个阶段。

而在1.0版中是由排序者（Orderer）完成共识功能，其文档中定义了Solo、Kafka和PBFT三个排序者。但从1.0的代码来看，其使用的却是SBFT共识算法，还是类似PBFT的三阶段提交方式。

Fabric-1.0架构

超级账本Fabric-1.0的SBFT共识算法

我的理解：SBFT中S不是Simple，而是Speculative，其目的是实现Zyzzyva共识。【参考】Zyzzyva: Speculative Byzantine Fault Tolerance

Zyzzyva: Speculative Byzantine Fault Tolerance

其他：HQ Replication共识算法

【参考】HQ Replication: A Hybrid Quorum Protocol for Byzantine Fault Tolerance https://www.usenix.org/legacy/event/osdi06/tech/full_papers/cowling/cowling.pdf

Chain.com的SBFT

Consensus Mechanism: Simplified Byzantine Fault Tolerance (SBFT)

In SBFT, one designated block generator collects and validates proposed transactions, periodically batching them together into a new-block proposal. Consensus is provided by a Generator that applies rules (validates) agreed to by the nodes (chain cores) to the block and designated block signors. Other (multiple) designated block signers ratify the proposed block with their signatures. All network members know the identities of the block signers (permissioned blockchain) and accept blocks only if signed by a sufficient number of signers. A Block Signer validates all transactions in each block and adds a signature. Only blocks with sufficient signatures are accepted into the chain. This attempts to prevent the double spending problem by attempting to ensure competing transactions gets resolved.

By using 1 generator (master replicator) in a trusted, private environment this effectively allows for kind of scale and speed needed for transactions and for the signors to validate transactions. These signors are configurable meaning they can be added/removed from the system at any time. The same goes for the nodes (chain cores) in the network. They can be added/deleted since it is a private network and this adds an extra layer of security particularly when dealing with what could be a malicious actor.

As a result of using 1 generator instead of multiple, synchronization does not occur. Synchronization is a process that establishes consistency of data between 2 or more entities. This feature allows for scalability and speed to not be affected for the enterprise grade solution. Since the blockchain is private and the entities are known multiple generators could be seen as a redundancy. Not all nodes need to be online for this platform to function at a minimum 1 generator and 1 signor are needed. However, typically it allows 100 participants to interact, only needs 5 signors, 1 generator and 1 issuer (some regulatory body). The Fault Tolerance in this setup allows for 3 out of 4 or 4 out of 5 signors.

The Privacy section will go into the details of how the Chain Open Standard tackles the problem of Confidentiality of information for the platform participants. Open, permissionless blockchains like Bitcoin are transparency machines in that all participants can view information on the network. Chain has built a solution for those who need privacy as a main feature. Without the need for complete transparency and all nodes (chain cores) receiving transactional information, scalability does not get sacrificed, but transparency does. All systems have trade-offs. In this system, the nodes (chain cores) would only get block proofs by node platform.

The node (core) itself, could store all the blockchain data or only a snapshot (balance sheet) and a limited history of activity from the Account Manager (described below).

Stages

The Asset Issuer (presumably a node on the platform) creates what can be an unlimited number of cryptographically unique Asset ID's. (Creation Phase)
Units of these assets are issued on a blockchain. (Submission Phase)
An Asset ID is associated with an Asset Definition. (Asset Definitions can be self enforcing rules to meet specific conditions depending on the use case. These can have an unlimited amount of reference data) (Validation Phase)
Once issued, units of an asset ID can be stored in and transferred between accounts, programmatically transacted via smart contracts, or retired from circulation. (Signing Phase and Pulling into Nodes Phase)
After the Signing Phase the transaction goes live.

One of the interesting features of this system is the Account Manager which serves many key roles. It stores assets in secure accounts. This is where transaction data gets stored. These accounts can contain any combination of assets and created for many different types of users. These accounts can be thought of as digitally secure wallets. In addition to storing assets, the Account Manager enables the transferability of assets in to and out of accounts via blockchain transactions (within the same Core or between different Cores in the network). The Account Manager builds the smart contracts for all different types of transactions (See Smart Contract Section). Each transaction is a smart contract.

Ownership of the assets flows through the system by using a push model. The addresses are provided by other parties and the unique Asset ID's and accounts that get created are used to designate ownership of the assets. The smart contract (transaction) defines what actions a designated party can take.

阿尔山金融科技的SBFT

杨杰（Jeffrey Yang）在『区块链的技术细节』一文中也有一段关于SBFT的描述。

SBFT（Simplified Byzantine Fault Tolerance，简化拜占庭容错)

首先一个block Generator提交一个加入block的交易请求；
其他 block Signers认可（ratify），并且签名；
其他的networkmembers在有足够signers数量的条件下，接受block的交易请求；
生成新的block；
交易结束。交易历史不可篡改。

In SBFT, one designated block generator collects and validates proposed transactions, periodically batching them together into a new-block proposal. Other designated block signers ratify the proposed block with their signatures. All network members know the identities of the block signers and accept blocks only if signed by a sufficient number of signers. This ensures that competing transactions will be resolved, transactions will be final, and history cannot be rewritten.

小结

Talk is cheap, Show me the code.

BFT共识（Byzantine Consensus）

默认配置 PBFT (practical byzantine fault tolerance)

PBFT tolerates up to t<n/3 Byzantine validators (验证节点).
根据拜占庭容错机制，只要2/3验证节点确认的账本，即可成为标准账本。

Company	Consensus Management
Cachin/IBM PBFT	https://www.zurich.ibm.com/~cca/papers/pax.pdf
Microsoft PBFT	http://research.microsoft.com/en-us/um/people/mcastro/publications/p398-castro-bft-tocs.pdf
Redundant BFT	http://pakupaku.me/plaublin/rbft/report.pdf
Stellar Consensus	https://www.stellar.org/papers/stellar-consensus-protocol.pdf
Tendermint Consensus	http://tendermint.com/docs/tendermint.pdf