The alliance chain based on the ether square? Preliminary study on the mechanism of Quorum (middle) __ Block chain

Guide : JPMorgan's quorum platform is a hot spot in the block chain industry (Quorum is a block-chain network based on the Etheric square that JPMorgan first unveiled last autumn), and JPMorgan's recent contact with the 0-currency electronic currency Company (Zerocoin Electronic Coin Company) 's cooperation is the cause of hot discussion. Some experts say that the combination of 0 knowledge cryptography and quorum is a major step forward in the block chain industry, as it will build a more suitable enterprise-class solution and push the enterprise application of the block chain. JPMorgan Chase will also expand its market share and ensure its position in the forefront.

Author: Uni Zhu the consensus mechanism of quorum

As of today (December 5, 2017), quorum has used two sets of consensus algorithms:quorumchain Consensus and raft-based Consensus. Quorumchain is a consensus algorithm based on voting mechanism, which uses the intelligent contract of the Ethernet square to realize voting and consensus. Raft-based is based on the Raft Consensus algorithm for Quorum correction. Release versions prior to Quorum 1.2 were used in Quorumchain. Starting with version 2.0, Quorum abandoned quorumchain to support raft-based Consensus instead. Here we will also introduce the Quorumchain consensus, so as to facilitate understanding and comparison. Quorumchain Consensus

Quorumchain Consensus is a consensus algorithm based on voting. Its main features are: to achieve and manage the consensus through the intelligent contract. In the form of Tai Fang transaction to complete the voting on the Internet. The signature verification mechanism used to validate the signatures from maker and voter nodes.

In Quorumchain, there are three kinds of identities Maker, voter, Observer. A node with a Maker identity has the right to package transactions and generate chunks. When the other node receives the block, it looks at the Maker signature in the block header and verifies that the node that generated the block has Maker identity. A node that has a voter identity can vote for a chunk that is received. A block can be validated by all nodes only after a certain number of votes have been received. Observer Identity does not have any special permissions, can only do a record block node.

A node can have both Maker and voter identities. voting Smart Contract

Quorumchain is realized by a solidity blockvoting intelligent contract (contract source). When the Quorum client is created, the contract is compiled and stored in the Genesis block. If you want to modify the voting mechanism, you need to recompile the new solidity code before the Quorum client starts. In blockvoting, contracts provide Addvoter, Removevoter, Addblockmaker, removeblockmaker, etc. to increase or decrease voter and Maker.

When a node receives a new chunk, the node calls the voting contract to confirm the voting results for the last block. This result will determine which block the new block will be connected to. Maker Nodes

The Maker node is primarily used to package transactions and generate chunks. The address information for all Maker nodes will be registered in the blockvoting contract. There must be at least one registered Maker in the blockvoting contract. When the Quorum was just set up, the information of the Maker node was preset in Genesis.json. However, in the process of network operation, it is possible to delete the Maker nodes by blockvoting the specific method in the contract.

Maker nodes can also exist as voter nodes. Voter Nodes

The primary responsibility of the voter node is to vote on the newly generated legal blocks. As with Maker, voter is initialized at the time the network is started according to the preset configuration in Genesis.json. Similarly, in the process of network operation voter can through blockvoting contract to delete. The voter node can vote for blocks of the same block chain depth. At a certain depth, the block that gets the most votes becomes the block at that location on the chain and is agreed by the entire network. (This will be mentioned in the Block voting section). Block creation

In Quorumchain, multiple Maker nodes can exist at the same time. Each node will maintain a random time of its own. When the random time is up and the Maker does not receive a message from other Maker to generate chunks, it packs the transaction and generates chunks. Once the production block is started, Maker will broadcast to the network and tell the other nodes that they are starting to produce blocks. At the same time, refresh their own random time, waiting for the next round of block generation. For other nodes, once the node has started to block the message, immediately refresh their random time, wait time to read seconds after the start of production block.

When a Maker node is ready to generate a new chunk, it verifies the legality of the last block on the local chain. By invoking the method in the Blockvoting contract, you get the hash of the block that won the most votes in the previous ballot, and then compare the hash to the hash of the local last block. If the two are the same, the local chain is OK, and then the new blocks are connected to the local chain and broadcast. If the two are inconsistent, the local chain is not correct. The last block in the local area was not the one that won the most voter votes in the previous round. The steps to build the block will be terminated. Steps can refer to the following figure:

Block voting

In Quorumchain, the consensus of each cycle block includes: Block generation-> Block broadcast-> block verification-> Block voting such a process. According to the block generation mechanism mentioned above, although the probability is very small, but there is a certain probability of two Maker to generate blocks at the same time. To address this situation, Quorumchain introduced the voting mechanism. Suppose the current is the nth round block consensus process. A node with an identity of voter will first verify the contents of the chunk after it receives a new block. If the verification succeeds, it will be voted to the block through the blockvoting contract. If there are other blocks in this round, the subsequent blocks will not be voted on. When the block of the n+1 wheel is received, the node obtains the first n round block voting result through the blockvoting contract, thus determining the block n round which is really accepted by most voter of the whole network. a cycle of block consensus process

In one cycle:

The Maker node's random time reads the second end and does not receive any other Maker to generate the block the message, this node starts the production block. At the same time, this node will package the voting information TX of the last period to the block.

The newly generated blocks are broadcast to the whole network through the Peer-to-peer protocol of the Ether Square. All nodes of any identity can receive this block.

When the voter node receives this block, it verifies the contents of the block. This verification step includes: see if the producer of the new zone block is in the Maker list through the blockvoting contract. Executes all the TX in the new block. Look through the blockvoting contract to see if the parent block pointed to by the new zone is getting enough voter votes. Calculates the hash value of all TX generated in the new zone block, and compares the hash value in the new zone block.

After the check is passed, the voter node will vote for the new block through the blockvoting contract and broadcast the TX of this vote to the whole network. This TX is only packaged into chunks the next time the block is generated.

A Maker node randomly reads the second end and is ready to start generating new chunks. Into the next cycle. End subsequent content raft-based Consensus References:

Quorum Wiki

Quorum Github Main Page

Quorum official Page