超级账本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的SBFT共识算法
我的理解：SBFT中S不是Simple，而是Speculative，其目的是实现Zyzzyva共识。【参考】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
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 |
共识算法可以根据不同的业务需求调整，生产中可以同时灵活应用多个共识机制！
参考索引
- （范捷 易乐天 舒继武）拜占庭系统技术研究综述，软件学报.2013-06 下载PDF
- （Chain.com）Simplified Byzantine Fault Tolerance (SBFT)
- 超级账本官方网站 http://www.hyperledger.org/
- 超级账本官方社区 https://jira.hyperledger.org/projects/FAB/issues/
- 超级账本开源地址 https://github.com/hyperledger/fabric
- Fabric下一代共识架构提案
- 超级账本Fabric官方文档
- （季宙栋）Fabric V1.0– 开发者快速入门
- （季宙栋）Fabric多通道和下一代账本设计
- （季宙栋）Fabric 1.0 账本设计（1）
- （季宙栋）Fabric 1.0 alpha快速部署和CouchDB使用 【关注】
- （闫洪坤）Fabric1.0 架构概览
- （庄鹏）Hyperledger Fabric 1.0 架构解读
- 2017-07-02 （张海宁）超级账本Fabric 1.0 多节点集群的部署【1、2、3】
- 2015-10-16（初夏虎）拜占庭将军问题深入探讨