Abstract ： This article focuses on Fabric The core business , Build a test model , Native to the community Fabric And Huawei cloud blockchain （ be based on Fabric） Carry out the actual measurement , Identify community natives Fabric Performance bottlenecks , And try to use the dynamic scaling provided by Huawei blockchain 、 Fast PBFT The algorithm is optimized , Improve several key metrics .
1、Fabric Performance testing status
In layman's terms , Blockchain is a kind of chained data structure that combines data blocks in chronological order and connects them in order , Distributed ledger guaranteed by cryptography . The currency （Bitcoin）、 The etheric fang （Ethereum）、 Super ledger （Hyperledger） They are all typical blockchain systems . among Hyperledger Fabric Is the most popular enterprise blockchain framework ,Fabric A loosely coupled design , The consensus mechanism 、 Authentication and other components are modular , In the application process, it is convenient to select the corresponding module according to the application scenario .
Fabric Performance is one of the most concerned issues for users , However , At present, there is no authority neutral agency , According to accepted rules , Yes Fabric Carry out performance test and give test report , There are probably several reasons ：
(1)Fabric Still in rapid development , Detailed neutral and accepted test rules have not been given ;
(2)Fabric Network structure ( network bandwidth 、 disk IO、 Computing resources, etc ), Configuration parameters ( Such as block size 、 Endorsement strategy 、 Number of channels 、 State database, etc ), Consensus algorithm （solo,kafka,pbft etc. ） Will affect the evaluation results , It's hard to build a reflection fabric The whole picture of the test model ;
(3)Fabric The transaction process is complicated , There are many differences between traditional databases , It also doesn't apply to traditional testing programs and tools ;
This article focuses on Fabric The core business , Build a test model , Native to the community Fabric And Huawei cloud blockchain （ be based on Fabric） Carry out the actual measurement , Identify community natives Fabric Performance bottlenecks , And try to use the dynamic scaling provided by Huawei blockchain 、 Fast PBFT The algorithm is optimized , Improve several key metrics .
2、Fabric Transaction process analysis
stay Fabric During the transaction , Involving different roles , Each role has a different function , node （Peer） It can be subdivided into endorsement nodes （Endorser peer） And submit nodes （Committer peer）, Consensus is sorted by （Orderer） Role completion . The transaction process is as follows ：
chart 1：fabric Transaction flow chart
(1)： Application client through SDK Launch a transaction proposal to the blockchain network （Proposal）, The transaction proposal identifies the contract to be called in this transaction 、 The contract method, parameter information and client signature information are sent to the endorsement node （Endorser）.
(2)： An endorsement node （Endorser） Received a deal proposal （Proposal） after , Verify the signature and determine if the submitter is authorized to perform the action , Execute the smart contract after the validation is passed , The result is signed and sent back to the application client .
(3)： The application client receives the endorsement node （Endorser） After the information returned , Judge whether the proposal results are consistent , And whether to refer to the specified endorsement policy , If there is not enough endorsement , Then suspend processing ; otherwise , The application client packs the data together into a transaction and signs it , Send to Orderers.
(4)：Orderers Sort the received transactions by consensus , Then according to the block generation strategy , Pack a bunch of deals together , Generate new blocks , Send to the submission node （Committer）;
(5)： Submit node （Committer） After receiving the block , Each transaction in the block will be verified , Check whether the input and output relied on by the transaction match the status of the current blockchain , After completion, append the block to the local blockchain , And modify the state of the world .
Client pass Fabric Close the deal , There are three steps to perception （ Collect endorsements , Submit sort and confirm results ）, And the traditional database reading and writing , Just make a request , Wait for confirmation . If you use classic testing tools such as JMeter, Need to put fabric sdk For packaging RESTFul Interface , Increased the complexity of the evaluation . Fortunately, ,2017 year 5 Monthly super ledger community launched Caliper, Allows users to test specific blockchain technology implementations through a series of preset use cases .Caliper The generated report will contain a series of blockchain performance indicators , Such as TPS（ The average number of transactions per second ）, Time delay , System resource occupancy, etc . The evaluation results of this paper are Caliper Tools to test the build .
3、Fabric Test model building
Build a performance test model , It mainly includes two parts ： One is to extract evaluation indicators according to business characteristics ; The second is to establish a stable and measurable business model .
3.1 Evaluation indicators
Fabric It's a typical distributed system ,Fabric In the network Peer Independent deployment , Maintain your own books separately （ Support endorsement query ）, Through internal Gossip Synchronization of communication completion status .Fabric Comply with partition tolerance , According to the distributed system CAP Theorem ,Fabric Under the premise of ensuring availability , There is no way to ensure consistency .Fabric It's through ultimate consistency （ A kind of weak consistency ） To ensure that all nodes finally agree on the state of the world , This process is Orderer Consensus and Peer The process of validation . So in our test model , The following indicators are mainly investigated ：
Query throughput （Query Throughput）： Number of query requests processed per second
Consensus throughput （Consensus Throughput）： The number of consensus requests processed per second
Consistent throughput rate （Consistency Throughput）： The number of synchronization services completed per second
Average delay （Avg Latency）： The average time taken to complete a transaction
Failure rate （Fail Rate）： There was a business failure （ Including overtime ） The proportion of
3.2 business model
In the choice of business scenarios , We think about mainstream scenarios as much as possible , Get rid of options that are bottlenecks in themselves , Focus on the core business of blockchain .
Infrastructure ,Orderer and Peer Node we choose mainstream 8vCPU16G Specifications of virtual machine ,Client Choose one 32vCPU64G Virtual machine of . The whole test is done in a stable subnet .Orderer Node we configure 4 individual , Satisfy 3f+1 The minimum requirement for fault tolerance .Peer Node we configure 1, Expand as much as you need to 5 individual .
In terms of configuration parameters , We use a single channel , Single organization endorsement , State database selection goleveldb. The drop block strategy uses the default policy （2s/4M/500T）.
Consensus algorithm , Can choose solo、pbft、kafka.solo The mode is test mode , It can't be used in production .Kafka Pattern a kind of support CFT Fault tolerant consensus algorithm , Performance mainly depends on the plug-in kafka Cluster performance . and pbft Can guard against Byzantine nodes , More extensive application scenarios , It also requires higher performance . thus , This test chooses pbft As a consensus algorithm .
Chain code , We choose what the community offers chaincode_example02 Example , The percentage of business data is very low , At the same time, it can cover the basic use cases of account book reading and writing .
4 、 Measurement and tuning
4.1 Query performance and dynamic scaling
Fabric Query performance is actually an endorsement request .Peer The end mainly contains 3 A process .
(1) check Proposal Signature ;
(2) Check to see if Channel ACL;
(3) Simulate the execution of the transaction and sign the result ;
Code can refer to the community chaincode_example02.
chart 2： Single organization list Peer Query performance of
You can see , A single node （8vCPU,16G） The reading performance of 2500tps about . Observe the monitoring indicators and find ,CPU Usage rate in 70% about , Close to full load , And the memory utilization rate is only 25% about [z(3] . It's not hard to understand , The endorsement process involves a lot of validation 、 Signature work , These are all computationally intensive operations . According to the blockchain CAP The partition tolerance of the theorem , We can scale horizontally within the organization Peer To improve performance . Huawei blockchain has provided this scalability feature , We will peer The number of 5 individual .
chart 3： Huawei BCS The dynamic scaling properties of
Run the test script again , give the result as follows ：
|Avg Latency||Query Throughput|
chart 4： Huawei BCS Single organization 5Peer Query performance of
You can see , In constant service , Without sacrificing stability , Through the single Peer Dynamic extension is 5Peer. Performance can be improved 4 More than double , The overall throughput exceeds 10000tps, The average delay is only 0.06s.
4.2 Consensus performance and consensus algorithm
Consensus algorithm is the key to improve the performance of consensus . Community fabric v1.0.0-alpha2 Version provides PBFT Consensus is a practical Byzantine algorithm . The practical Byzantine algorithm mainly improves the inefficiency of Byzantine algorithm , The algorithm complexity is reduced from exponential level to polynomial level , It makes Byzantine fault-tolerant algorithm feasible in practical system application .
Let's start with community PBFT Under the consensus test ：
chart 5： Community origin PBFT Consensus performance
You can see , Community native PBFT Consensus , Whether it's throughput , Or average delay , They're all poor . Huawei PBFT The algorithm has Early-Stopping nature , That is, when there is no Byzantine node , The whole network will soon reach a consensus , So the speed should be very fast . We switch to Huawei fast PBFT Consensus algorithm , Let's measure it again :
chart 6： Huawei BCS Fast PBFT Consensus performance
Switch to Huawei PBFT After algorithm , Consensus throughput can reach 10000tps, Consistent throughput is also close to 1800tps. meanwhile , Relative to the community native version , The average delay is also greatly reduced . This write performance is comparable to the traditional single node relational database , It can satisfy most business scenarios .
4.3 About final consistency
In the process of testing consensus performance , We find that when consensus throughput exceeds 2000 when ,Peer There is a backlog when synchronizing blocks , This leads to an increase in the average delay . To understand in detail why , You can refer to Fabric Key source code (gossip/state/state.go) To get to know Peer The process of falling blocks ：
chart 7：gossip Synchronous block flow chart
stay fabric in , The book data is mainly made up of GossipStateProvider adopt Gossip Protocol to synchronize , Only the key process can be given here .
(1) Start a process deliverPayloads from orderer Or other Peer obtain “ Blank pieces ”, call LegerResources.StoreBlock;
(2) LegerResources call Validator Verify that the transaction complies with the endorsement strategy , Check whether the version in the read set is consistent with the ledger ;
(3)LedgerCommittor Execute legitimate transactions in blocks , Update ledger status ;
(4)ServiceMediator Update channel metadata ;
The author modified the source code , Added 4 Time consuming statistics of the steps , Results show 40000 Transaction generation 200 In the case of blocks , step 2（ check ） Time consuming 17s, And steps 3（ Write a piece , Update index ） Time consuming 40s. Both occupy deliverPayloads 80% Time consuming , Guess is the bottleneck of consistent throughput . Turn on Profile After the model , Monitor stack calls , This conjecture is further verified .[z4]
chart 8：gossip Synchronization block Profile Flame chart
The optimization scheme that the author can think of ：
(1) Use a high-speed read-write disk （SSD）, Improve the reading and writing efficiency of block files ;
(2)Validator Verification is computationally intensive , Can we use the combination of hardware and software , Greatly improve the verification efficiency ;
(3) at present Gossip Get Payload After the data , It can only be processed one by one in series . Whether it can be partitioned according to the read-write set of the block , Give it to different threads , Finally, merge them and put them on the plate , To improve performance （ The reference multichannel performance is times that of a single channel ）;
I learned through the media that , Huawei blockchain and other product teams , People have been invested in this field for preliminary research , Looking forward to the early release of commercially available products , Give back to the community .
Fabric As the most popular enterprise blockchain solution , It has been successfully applied in many fields . In this test tuning , Discover community Nativity Fabric There are many limitations , If it is not easy to expand , Poor performance , It is not recommended to be used directly in the production environment .
The scalability and speed of Huawei blockchain PBFT Algorithm , It can improve quickly Fabric Trading performance . Among them, the retraction characteristic , You can take it all the time , Improve query performance to 10000tps above （ single peer Of 4 More than double ）. And fast PBFT Algorithm , Consensus throughput can be increased to 10000tps above （ Community native 20 times ）, It can satisfy most business scenarios .
Simultaneous discovery , In the case of high concurrency , Finally, the average delay of consistency will increase , The main reason is that the current block check and drop disk are executed in sequence , Unable to make full use of multi-core resources . If a community successor or a commercial company , It can be combined with hardware and software , The idea of partition merging , Improve consistent throughput , Reduce delay ,Fabric Will be more successful in the business world .
6、 Reference material
Performance Benchmarking and Optimizing Hyperledger Fabric.pdf