Different from the public chain environment, all the members of the enterprise chain or alliance chain with access threshold actually obtained certain recognition and permission when they joined, so the members of the enterprise chain/alliance chain have a certain trust base. In the enterprise chain, we don't need to use POW or POS, which is a waste of computing power or inefficient trading knowledge.
Quorum provides a variety of * * * knowledge for users to adopt:
Before talking about Raft, it is necessary to mention Paxos algorithm, which is a message-based consistency algorithm proposed by Leslie Lamport in 1990. But because the algorithm is difficult to understand, it didn't get much attention at first. Then the author published it on ACM eight years later, that is, 1998. However, because the algorithm is difficult to understand, it has not been taken seriously. The author later republished a paper Paxos Made Simple in a more acceptable way.
It can be seen that Paxos algorithm is difficult to understand. Even now, many students and professors still feedback that Paxos algorithm is difficult to understand. At the same time, Paxos algorithm is also difficult to realize in practical application. This is also the reason why Raft algorithm was put forward later.
Raft is an algorithm to realize distributed knowledge, which is mainly used to manage the consistency of log replication. It has the same function as Paxos, but compared with Paxos, Raft algorithm is easier to understand and apply to practical systems. Raft algorithm is also a * * * knowledge algorithm used by alliance chain.
Raft I * * * has three role states:
Each node has an election timeout, and the time is randomly between 150ms and 300ms. There are several situations that reset the timeout:
In the distributed system, "time synchronization" is a big problem, because each machine may cause different degrees of clock inconsistency due to geographical location, machine environment and other factors, but in order to identify "outdated information", time information is essential.
Raft algorithm uses the concept of $ Term ($ Term) to divide the time into $ Term (and each node will also maintain the currentTerm locally), which can be considered as logical time, as shown in the following figure.
The beginning of each term is the election of leaders, and one or more candidates will try to become leaders. If a person wins the election, he will become a $ TERM for the rest of his term. In some cases, votes may be scored and leaders may not be elected (such as t3), then another term will begin and the next election will begin immediately. Raft algorithm ensures that there is at least one leader under given conditions.
Handling of special circumstances
In the Ethereum, the node itself has no function, so when using the knowledge of Raft***, we call the leader node as the mining node:
Raft*** knowledge mechanism itself ensures that there is only one leader at most at the same time, so there will only be one blockader when it is used in the Ethereum model, which avoids blocking or wasting computing power at the same time.
At the level of single transaction, Quorum still follows the p2p transmission mechanism of Ethereum, and only at the level of block will the Raft transmission mechanism be used.
It should be noted that in Ethereum, a node will keep an account immediately after receiving a block, while in Quorum model, the record of a block must conform to the Raft protocol. After each node receives the block sent by the leader, it must report to the leader to confirm the receipt, and then the leader informs all nodes to submit data (records).
In the Quorum model, the information of the new block is likely to be inconsistent with the header information of the existing block, and the most likely thing is the replacement of voters (replacement of mining nodes), which is described as follows:
Suppose there are two nodes, node 1 and node2, node 1 is the existing leader, the latest block of the existing chain is 0xbeda, and its parent block is 0xacaa.
The marking of "expansion" or "no operation" of a block is completed at a higher level and is not realized by the logging mechanism of raft itself. Because within raft, there is no distinction between valid and invalid information, and only at the level of blockchain will there be the meaning of valid and invalid blocks.
It should be noted that Quorum's bookkeeping mechanism is completely different from the LVC (longest chain mechanism) of Ethereum itself.
By default, the arbitration block frequency is 50 milliseconds, which can be set by the-raftblocktime parameter.
Speculative congestion is not one of the core mechanisms necessary for Ethereum to understand Raft strictly, but it is an effective way to improve congestion efficiency.
It actually takes some time for a block to go through the whole raft process from production to actual recording. If we record the last block in the ledger and start to generate the next block, it will take more time to record a transaction successfully.
In speculative stripping, we allow new blocks to be generated before their parent blocks are recorded. By analogy, in a period of time, it will actually produce a "speculative chain". Before the ancestor block is recorded in the account book, a new block has formed a temporary chain fragment in order, waiting to be recorded.
For transactions that have been recorded in the speculative block, we will mark them as "suggested transactions" in the trading pool.
As we said before, two mining nodes may compete for blocks and bookkeeping under the raft mechanism, so it is very likely that the blocks in the middle of a speculative chain will not be recorded in the ledger. In this case, we will also modify the transaction status in the transaction pool. (InvalidRaftOrdering event)
At present, Quorum does not limit the length of speculative chain, but it is mentioned in its future planning that it will be added to the development process as a performance optimization item. Finally, even if a mining node is not connected to the raft*** knowledge layer, it can always shield the downline and generate its own speculative chain.
The speculative chain consists of the following parts:
In block transmission, we use the default http transmission of etcd Raft. Of course, p2p transmission in Ethereum can also be used, but Quorum team found that the performance of ETH p2p under high load is not as good as raft p2p.
Quorum uses port 50400 as the default listening port of the Raft transport layer, or it can be set by itself through the-raftport parameter.
The default maximum number of nodes in a cluster is 25, which can be set by-maxpeers N, where n is your maximum number of nodes.
Quorum's IBFT is actually PBFT, but JPMorgan Chase calls his own PBFT IBFT, so the basic principles of IBFT are the same as those of PBFT. The difference is that IBFT combines three stages of * * * knowledge.
Istanbul BFT is improved from PBFT algorithm and includes three stages: preparation, preparation and submission. In a network with n nodes, the algorithm can tolerate at most f failed nodes, where N=3F+ 1.
The block in Istanbul BFT algorithm is deterministic, which means that the chain is not bifurcated, and the legal block must be in the chain. In order to prevent malicious nodes from generating different chains, each verifier must put 2F+ 1 commit signature into the external data field of the block header before inserting the block into the chain. Therefore, the block can be self-verified (because it is signed) and supported by lightweight clients.
However, dynamic extraData can also cause hash calculation problems of blocks. Because a block can be verified by different verifiers, it will have different signatures, so the same block will have different hashes. The solution is to exclude the submission signature when calculating the block hash. Therefore, we can still verify the * * * knowledge while ensuring the consistency of the block hash.
Because the knowledge of POA*** in Ethereum has been introduced a lot on the Internet, the author will not introduce it in detail here, but only sort out and introduce the important characteristics and workflow of POA.