Where is the alliance chain heading?

特邀专栏作者

2020-01-03 10:42 (UTC+8)

This article is about 10518 words, reading the full article takes about 16 minutes

Which alliance chain technology is strong? Open source architecture Fabric, FISCO BCOS (hereinafter referred to as "BCOS"), and CITA technology comparison.

AI Summary

Expand

Which alliance chain technology is strong? Open source architecture Fabric, FISCO BCOS (hereinafter referred to as "BCOS"), and CITA technology comparison.

Editor's Note: This article comes fromCarbon chain value (ID: cc-value), Author: Carbon Chain Value Research Institute, reprinted by Odaily with authorization.

Summary

secondary title

Summary

The 46th World Economic Forum Davos Annual Conference included blockchain, artificial intelligence, and autonomous driving in the "Fourth Industrial Revolution". "The Economist" once introduced blockchain in the cover article "Trust Machine" in October 2015 - "The technology behind Bitcoin has the potential to change the way the economy works".

The reason why the blockchain is called a trusted machine comes from its two core characteristics of distribution and non-tampering, which are also the core characteristics of the blockchain that are different from traditional databases. Distributed here contains two meanings: one is traditional distributed storage, and the other is the collaboration brought by the underlying protocol of the blockchain. Here it refers more to its distributed collaboration capability.

In the blockchain, its "credible collaboration" is mainly realized through consensus algorithms, smart contracts, governance, cross-chain, privacy, etc., so this article will analyze the differences in the underlying technologies from these aspects and combine enterprise application scenarios, Help business users make better choices. At the same time, it will also analyze and compare traditional enterprise software in terms of maintainability, performance, development tools, scalability, and software protocols.

As far as the history of the consortium chain and the difference between it and the public chain are concerned, there is not much difference in the early stage, but now as the market segment continues to deepen, the difference between the public chain and the consortium chain is becoming more and more obvious.

First of all, the public chain is facing an uncontrollable scenario, and it is necessary to find a balance between security, performance and decentralization. In the consortium chain enterprise service scenario, the number of participants is relatively more controllable, and the consortium chain is more likely to make breakthroughs in terms of performance and security. But precisely because of the controllability of the participants (nodes), decentralization has its own more unique design. In addition, in the public chain, all information is open and transparent and can be checked, and each participant is relatively equal. But in the industrial world, this is unacceptable. There is a large amount of public-to-public data privacy that needs to be dealt with, and there are also multiple organizational models in the enterprise that need to set permissions.

Based on these characteristics, the development of alliance chains includes node management, consensus selection, authority control, and contract design paradigms. At the same time, different frameworks have different understandings of contract design paradigms. In addition, the blockchain can be divided into open source and closed source, but the trust created by the blockchain is based on the open source code. Without open source, it is not a blockchain system in the true sense. Therefore, for the objectivity of the research, this article mainly focuses on the open source framework. Currently, the widely used open source architectures in the domestic market are Fabric, FISCO BCOS and CITA.

Hyperledger Fabric is a platform for distributed ledger solutions that is based on a modular architecture that provides a high degree of confidentiality, flexibility and scalability. It is designed to support pluggable implementations of different components and adapt to the complexities that exist throughout the economic ecosystem. Fabric was originally designed and developed by IBM, and its source code was dedicated to the Linux Foundation's Hyperledger project in 2015.

FISCO BCOS was born in 2017 and launched by the Golden Chain Alliance. It is a standard domestic bottom layer. Golden Chain Alliance is a non-profit organization jointly initiated and established on May 31, 2016 by more than 20 financial institutions and technology companies including Shenzhen Financial Technology Association, Shenzhen Qianhai WeBank, and Shenzhen Securities Express.

CITA is an open source blockchain operating system kernel designed with high stability, high performance, and high scalability. The CITA open source project was initiated by Cryptape in 2016. Currently, it is jointly maintained by CITAHub community enterprises such as Xita Technology. CITA adopts a micro-service architecture design and provides a rich set of development tools and flexible blockchain governance tools. Developers can perform secondary development or configuration for different types of blockchain networks.

In order to distinguish different implementations and design ideas of blockchain, we can first clarify the definition of blockchain itself. Usually the definition of blockchain itself is a decentralized and distributed ledger, and it is also an immutable ledger that records events and transactions. In this ledger, the immutable property is guaranteed by the consensus algorithm. From this point of view, the existing consortium chains can be divided into two categories: distributed database technology dominated by traditional databases, represented by Fabric; and FISCO BCOS and CITA, which are more in line with the "blockchain spirit".

Fabric features: IBM Fabric guarantees the two points of distributed and non-tamperable modification in the blockchain, omitting the decentralized consensus mechanism, and IBM Fabric does not have a real decentralized consensus mechanism in the framework. In the Fabric architecture, the participants (nodes) are divided into three roles: ordering nodes, endorsement nodes and submission nodes. For each transaction: the consensus state process is completed by the client, the endorsement node, and the submitting node; the ordering node is only responsible for the consensus of the transaction order, not the state consensus. strategy. The consensus method in the sorting node is Kafka or Raft, which is actually consistent with the existing distributed database consensus method and is not fault-tolerant.

Characteristics of CITA and FISCO BCOS: For FISCO BCOS and CITA, all the characteristics of the above-mentioned blockchain are guaranteed, but the design paradigm will be quite different from traditional projects when used. As a distributed ledger, it can ensure that the data cannot be tampered with and can also use the decentralized consensus mechanism Byzantine fault tolerance, which ensures a 1/3 fault tolerance rate. In these two frameworks, the participants of the chain are divided into consensus nodes and read-only nodes. Consensus nodes are participants with bookkeeping rights, and read-only nodes are participants with access to all data.

If Ethereum represents the spirit of the blockchain, CITA and FISCO BCOS inherit from the public chain. Although CITA and FISCO BCOS are completely different from the public chain in terms of scenarios and usage, they can still see the inheritance of the public chain in some underlying logic. Technically speaking, inheriting the virtual machine of Ethereum means inheriting the huge ecology of Ethereum. Next, this article will compare the differences between the three from the perspective of technical implementation.

secondary title

Consensus and transaction flow

Consensus mechanism is the soul of the blockchain. Whether it is a public chain or an alliance chain, the consensus mechanism fundamentally limits the transaction processing capability and scalability of the blockchain, and is also the basis of its distributed collaboration capabilities. Consensus is an agreement reached by nodes in a distributed system on the final state of data or the network. Due to the uncontrollable network environment and node status, the consensus mechanism needs to consider performance, reliability, security and other issues at the same time. From a broad perspective, the consensus mechanism can be divided into two categories: Nakamoto Consensus and other consensus mechanisms that do not require access, and PBFT and other consensus mechanisms that require access.

Nakamoto consensus is widely used in public chains, but its probability model sacrifices efficiency while providing high reliability. In a specific commercial application environment, the licensing mechanism has guaranteed a certain degree of node credibility. Under such a premise, users are more concerned about execution efficiency and finality. This is the reason why BFT consensus is popular in alliance chains.

Next, this article will first introduce the implementation of FISCO BCOS, CITA, and Fabirc consensus technologies, and then conduct a comparative analysis in terms of performance, application scenarios, scalability, and security.

Technical realization

The efficiency of the BCOS consensus mechanism is relatively traditional

The consensus mechanism of FISCO BCOS adopts the traditional PBFT consensus, and its consensus process mainly includes three stages: Pre-prepare, Prepare and Commit:

1. Pre-prepare: The Leader node executes the block, generates a signature, and broadcasts the Proposal to other consensus nodes;

2. Prepare: The consensus node verifies the Proposal and broadcasts the signature, and collects the signatures of other nodes at the same time. After the node collects the signature of 2f + 1, it starts to broadcast the Commit package;

3. Commit: The Leader node collects Commit packets. After the node collects 2*f + 1 Commit packets, it updates the local database and broadcasts it to other nodes, and other nodes update the local database after receiving it.

The following figure shows a standard PBFT process:

In the blockchain, because consensus nodes need to unify votes in the Commit phase, the final Commit phase is slightly different: after the Leader node receives the 2*f+1 Commit package, it will broadcast the final Commit package to other consensus nodes. Unified vote.

In the entire consensus process, the transaction is executed once in the Pre-prepare phase and verified once in the Prepare phase. The traditional PBFT process used in FISCO BCOS is a mode of execution first and then verification, which includes two time lengths for executing transactions.

CITA adopts self-developed consensus protocol

CITA implements CITA-BFT optimized according to the characteristics of continuous consensus of blockchain. Blockchain is a continuous consensus process. CITA splits transaction execution and consensus to avoid the problem of double execution. According to the principle of replicating the state machine: the initial state is consistent, the order of executing transactions is consistent, and the execution process is deterministic. When all three conditions are met, the final result can be guaranteed to be consistent. In the blockchain, the initial state is guaranteed to be consistent by the genesis block, and the virtual machine is completely deterministic, so as long as the order of transactions is consistent, the final result can be guaranteed to be consistent. In the blockchain, the preHash of Block already contains the world state information after the transaction processing of the last block. CITA-BFT agrees on the transaction sequence of the current block and the execution result of the previous block. In this way, there is no need to execute transactions during the consensus process, but only one transaction processing after the consensus is completed, which greatly improves the throughput of the entire chain. CITA-BFT is optimized for the characteristics of the continuous consensus of the blockchain. It adopts the method of consensus first and then processing, so that the consensus process does not need to execute transactions, but only needs to execute a transaction after the consensus is completed. After verification, in the simplest certificate deposit transaction, the consensus performance has been improved by about 35%.

CITA-BFT avoids the process of the last round of Leader broadcast in the consensus protocol. In the final Commit stage in traditional PBFT, the Leader needs to receive enough Commit packets and broadcast them to other nodes. The blockchain is a continuous consensus process. In CITA-BFT, the consensus vote in the Block is the vote of the previous block, so the process of the Leader broadcasting the final block in the Commit phase and the Proposal phase of the next height are combined, which saves After a round of broadcasting process, Commit voting information is unified through the next highly Proposal process.

CITA-BFT uses Proposal preprocessing technology to enable consensus and execution to proceed in parallel, improving system performance. Since in most cases, the network condition of the consortium chain is good and the consensus can be completed in a round of consensus process, CITA introduces the technology of Proposal preprocessing: in the Pre-prepare stage, the nodes can directly process the transaction after receiving the Proposal without having to Wait until the consensus process is completed, and then notify the transaction processor of the consensus result after the consensus process is completed. In the traditional PBFT process, transaction processing and consensus are serial. After the introduction of Proposal preprocessing, the Prepare phase of the consensus and the Commit phase can be performed in parallel with transaction processing, which greatly improves the throughput of the entire system. After testing, for simple transaction processing, there is a performance improvement of about 10% to 20%.

The CompactBlock technology is used in CITA to compress the size of consensus blocks and improve network bandwidth utilization. The transactions in the block have been broadcasted once alone, so only the transaction ID needs to be included in the consensus block, which can greatly reduce the size of the block message. It has been tested that in the case of good network conditions, there is a 5% to 10% performance improvement for simple transaction processing.

Fabric consensus mechanism limits business efficiency improvement

Fabric divides its node roles into: sorting node, endorsement node, and submission node. The client first sends the transaction request to the endorsement node. After the endorsement node executes, it returns the read/write set and its signature to the client. After the client collects enough identical results, it composes the read/writeset, multiple sets of signatures and the transaction request The signed transaction is sent to the sorting node. After the sorting node forms a block, it broadcasts to the submitting node. The submitting node verifies whether the read/write set and the number of signatures are satisfied, marks the result and saves the legal result to its respective ledger.

In Fabric, the execution of transactions is non-deterministic, which is different from the design concepts of FISCO BCOS and CITA. Therefore, the endorsement node needs to execute the transaction first, and the client will compare the results according to the endorsement policy, and then send it to the sorting node, and finally the submitting node will verify and update their respective databases. It can be understood as: the process of consensus status is completed by the joint participation of clients, endorsement nodes, and submission nodes; ordering nodes are only responsible for the consensus of transaction order, not the state consensus. Different strategies can be adopted for transaction status consensus and ordering. For example, the transaction state can adopt more than 3/4 of the same state, and the consensus of the ordering nodes uses the traditional Raft or Solo consensus, and the traditional CFT consensus can meet most scenarios. The problem here is that the transaction needs to include the user's signature, the signatures of multiple endorsement nodes, and the read/write set, which makes the transaction very large.

When Fabric has conflicts in transaction status, such as frequent transfers between A and B, because each transaction will modify the balance of AB's account, it will cause transaction conflicts. Conflicting transactions Only one transaction per block can be processed at most, which will greatly limit the scenarios of business contracts.

FISCO BCOS：

performance comparison
CITA consensus performance is good

CITA：

Traditional PBFT
During the consensus process, transactions will be executed repeatedly, and the consensus efficiency is average
First consensus and then execution, only one transaction is executed, the overall efficiency is higher
Optimize the Leader broadcast process in the Commit phase to reduce the consensus time

Fabric：

Proposal pre-execution technology makes consensus and execution parallel and improves overall performance
CompactBlock technology improves bandwidth utilization

Transactions require multiple endorsement node signatures and read/write sets, resulting in very large transactions

Application Scenario

It can be seen from the comparison that FISCO BCOS adopts traditional PBFT, and the consensus efficiency is average; CITA adopts the self-developed CITA-BFT, and the performance of consensus and transaction processing has been improved by more than 50%; Fabric splits the entire process into execution, sorting, verification, and increases flexibility, but the separation of verification and execution results in very large transactions.

Application Scenario

Fabric: Split the consensus process into execution, sorting and verification, which has better flexibility, but the resulting transaction structure is very large, and each block of conflicting transactions can only upload one transaction to the chain, which greatly limits business contracts scene. For example, for a statistical voting contract, there are N voters, each voter votes by sending a transaction, because the total voting result is a shared state, in this case each block can only process one transaction. For example, for the Randao project, it is necessary to collect all the submitted information of the participants. At this time, a set variable is needed to store the information. Since each participant's transaction will modify this set variable, each block can only process one submitted transaction , and the collection variable will cause the read/write set to be very large.

Scalability

safety

Scalability

For Fabric, due to the separation of execution, sorting, and submission node functions, and execution (verification) and sorting can adopt different consensus strategies, the security strategy can be freely grasped by the user, and the client participates in the consensus of status and execution.

smart contract

secondary title

smart contract

The term "smart contract" is somewhat misleading. Intelligence often brings a certain degree of mystery to people, and there is no "intelligence" in terms of its contract function itself. Before the emergence of the blockchain, all systems adopted a centralized architecture. Regulators and users could not verify and guarantee the correctness of the system functions, could not ensure that the data had not been maliciously modified, and could not guarantee the security of the data. Due to the emergence of blockchain, transactions can be credibly conducted without relying on a third party, and transactions can be traced and cannot be reversed. The core meaning of smart contracts is to realize trusted computing on the basis of blockchain, and the traceability and irreversibility guaranteed by the blockchain protocol.

Transactions in Bitcoin are mainly used for peer-to-peer cash payments, and Ethereum is called Blockchain 2.0 due to the introduction of Turing-complete smart contracts. Although theoretically the smart contracts on Ethereum are Turing complete, due to the limitations of transaction fees, contract instructions, block Gas upper limit, node credibility, etc., public chain smart contracts are not suitable for existing enterprise development .

Consortium chains are more suitable for enterprise development due to the limited number of nodes, and node operators can use high-performance hardware devices and underlying protocol support. First, this article introduces the technical implementation of the three smart contracts, and then conducts a comparative analysis from three aspects: security, ease of use, and usability.

Technical realization

Both BCOS and CITA support EVM and precompiled contracts. With the help of the complete ecosystem of Ethereum smart contracts, both of them have been customized on the basis of it, and there are rich contract writing and testing tools.

The contract of Fabric is installed offline in the form of Docker through ChainCode, and then activated through transactions. The deployment of the ChainCode contract is relatively heavy, but it supports multiple languages (Go, Javascript, etc.). The deployment and update of the contract are updated offline. There is no consensus on the contract code. Its input and output are correct, and it does not care about the specific implementation of its internal logic.

safety

Since Fabric uses a traditional language for contract writing, although developers do not need to learn new languages, due to the uncertainty of virtual machines, the ChainCode method is only suitable for Fabric's consensus method of execution first, consensus and verification, and does not have Versatility.

safety

Security is the main feature that distinguishes smart contracts from other programs. The security here includes features such as certainty, verifiability, auditability, and traceability.

From the comparison, it can be seen that since BCOS/CITA transactions are executed on the chain, the smart contracts of BCOS/CITA are more deterministic, verifiable, auditable, irreversible, and traceable.

ease of use

The contract code of Fabric is deployed and upgraded by the endorsement nodes respectively, and the verifiability, auditability, and traceability cannot be guaranteed. However, in the design concept of Fabric, the client will verify the contract after execution. This article can consider that the final result of the contract is determined by the client and the endorsement node. As long as the transaction result conforms to the endorsement policy and meets the user's expectations, the Code verification requirements are relatively less important.

BCOS/CITA is slightly better than Fabric in contract ease of use

availability

BCOS/CITA/Fabric can cope with the complex business logic of enterprises and support more complex contract calculation and processing, while CITA supports timing tasks on the chain.

performance

secondary title

performance

After the development of the underlying technology of the blockchain in recent years, the performance of the alliance chain is no longer its main bottleneck.

BCOS official documents do not provide performance data. This article can only be judged based on data provided by third parties. We have found two relatively reliable sources of information. The latest evaluation of China Academy of Information and Communications Technology's trusted blockchain (November-19, 2019), BCOS single-chain TPS exceeds 20,000. [A press release at the end of July 2019"](undefined) When the test team said that the blockchain performance reached 10,000TPS, Zhang Kaixiang sent the team the biggest red envelope in his life in the WeChat group.". Because the two test data did not provide the test environment, number of nodes, consensus protocol used (BCOS supports Raft), etc., it is speculated that different consensus methods and number of nodes were used for testing.https://arxiv.org/pdf/1801.10228.pdfThe transaction performance of the latest version of CITA in the official document can reach 15,000+ TPS. The data comes from CITA version 0.16 (May 15, 2018). Four nodes are deployed on four 32-core, 64G cloud servers. Each server Configure 100M bandwidth.

At this stage, the performance of the alliance has made great progress. Compared with the landing scenario, performance is no longer the main bottleneck. At the same time, the domestic alliance chain has not lost to the big foreign brands in terms of performance, and has even been ahead of foreign countries.

storage

secondary title

storage

In terms of content, blockchain storage mainly includes two aspects: block and transaction storage, and world state storage. This article first introduces their respective implementation methods, and then conducts a comparative analysis in terms of supported database types, storage efficiency, scalability, and data maintenance.

Method to realize

The state storage of BCOS supports two storage modes

For the storage of blocks, the BCOS transaction list, transaction receipt, etc. are all stored in the traditional MPT method. For the world state, BCOS adopts two storage modes: storage state and MPT state. MPT state supports RocksDB and External storage. MPT storage minimizes the storage data while saving the historical state. Storage State supports RocksDB, MySQL, and External. When using storage state storage, part of the traceability is sacrificed, but it brings performance improvement, and it can support SQL statement query and statistics. Because the state of the world can always be restored through transactions, it is acceptable to sacrifice some traceability in exchange for performance improvements and state queries.

CITA supports RocksDB and External storage. Use MPT to save the state, and use Simple Merkle Tree to save transactions and transaction receipts. For the state storage, CITA chose the classic MPT storage, which saves the historical state and minimizes the storage data at the same time. For transactions and transaction receipts, using Simple Merkle Tree storage can optimize the amount of stored data and reduce Hash calculations.

Fabric's block storage is also stored in the MPT method. The storage of the world state supports KV and CouchDB storage. When storing the world state, Fabric does not support the preservation of the historical state. At the same time, it has performance improvements and supports rich conditional queries and statistics.

Comparative analysis

For comparison:

This paper believes that in terms of transaction storage, nodes must keep historical records, and for the historical storage of the world state, it can be restored through transactions. In this case, BCOS/Fabric provides users with better query functions and higher performance. A nice trade off.

governance

secondary title

governance

The biggest difference between the alliance chain and the public chain lies in its different governance methods. For the public chain, because it is an open system, it needs certain economic incentives to coordinate the relationship between different roles, and the alliance chain is because the nodes are access mechanism, so its governance method is very different from the public chain. For the alliance chain, its governance mainly includes: node management, account authority, and economic model.

node management

For BCOS and CITA, nodes are mainly divided into two categories: consensus nodes and ordinary nodes. Consensus nodes are responsible for consensus block generation, and ordinary nodes can only synchronize data and verify data without the power to package transactions.

For Fabric, nodes are divided into endorsement nodes, ordering nodes, and submission nodes. The endorsement node is responsible for executing the transaction and returning the result, the sorting node is responsible for sorting the transaction and packaging it into blocks, and the submitting node is responsible for verifying the transaction and updating the status.

For the consensus node BCOS/CITA, the system contract is used for management, and the addition and deletion of nodes requires the consensus of the consensus node. The addition and deletion of Fabric nodes can be modified by the node administrator without consensus, but activating a new configuration file requires sending transactions and consensus.

This article believes that managing node identities through whitelist/blacklist or CA can satisfy most scenarios of alliance chains, and CA is more strict in verifying node identities.

User rights management

For the consortium chain, each role in the consortium and within the consortium require more complex authority management, so that different roles can only access resources that are authorized by them.

Fabric manages user permissions through configuration files (Policy).

economic model

BCOS/CITA rights management is managed through transactions, which is more blockchain-based than Fabric modified through configuration files, and governance operations will retain traces.

economic model

CITA supports two different economic models

BCOS, CITA and Fabric all support the model of providing free services to users. At the same time, BCOS/CITA will control the use of system resources in a single block of users through system contracts to prevent abuse of the system.

And CITA can support the charging mode, the node accurately bills the user's transaction and charges the Token handling fee. The Token can be allocated to users for free by nodes, or it can be used by users for a fee, so that users can more finely control the use of system resources.

secondary title

Cross-chain and privacy

Cross-chain and privacy solutions, there is still room for optimization from the production environment

BCOS introduces the group method, so that a node can belong to different groups, and the group's messages, transactions, storage, execution, etc. are completely isolated.

The group concept of Fabric is similar to that of BCOS. A node can belong to different groups, and different groups can use different endorsement policies.

In BCOS and Fabric, the data and communication of the group are isolated, and different consensus strategies can be used, so it can be regarded as a multi-chain. At present, the biggest problem for multi-chain is inter-chain communication, and neither of them has a very mature solution in this regard.

In CITA, the side chain technology is introduced, the side chain and the main chain can communicate with each other, and the side chain technology still has room for optimization from the production environment.

CITA has open-sourced its implementation of zero-knowledge proofs and SGX.

Homomorphic encryption, zero-knowledge proof, SGX, etc. are all in the development stage, and there is still room for optimization from the production environment.

secondary title

CITA is more comprehensive in cryptography support

By comparison, we can see that both BCOS/CITA support national secrets and are more friendly to domestic regulatory needs; CITA is more comprehensive in terms of cryptographic algorithm support. In addition to supporting the common Keccak/Secp256k1, it also supports Keccak/Secp256k1, which is more secure and better .

secondary title

system structure

Both BCOS and Fabric adopt a single system architecture, which requires nodes to be on a single physical machine.

CITA adopts a microservice architecture, and CITA is also the world's first open source blockchain using a microservice architecture. Using the microservice architecture, the nodes can not only be limited to a single physical machine, so that enterprise users can use better hardware devices to support the nodes and have better scalability. Since microservices communicate through message subscriptions, enterprise users can easily replace or add customized services to facilitate functional expansion.

secondary title

open source agreement

The open source protocol of BCOS is not friendly enough for commercial applications

Here is a brief introduction to the relevant open source agreements.

Apache License is also a license that is friendly to commercial applications. Users can also modify the code when needed to meet their needs and release/sell it as an open source or commercial product.