CN107688945B

CN107688945B - Design method of efficient permission chain based on delay state consensus

Info

Publication number: CN107688945B
Application number: CN201710684961.2A
Authority: CN
Inventors: 谢晗剑
Original assignee: Hangzhou Rivtower Technology Co Ltd
Current assignee: Hangzhou Rivtower Technology Co Ltd
Priority date: 2017-08-11
Filing date: 2017-08-11
Publication date: 2020-04-10
Anticipated expiration: 2037-08-11
Also published as: CN107688945A

Abstract

The invention discloses a design method of an efficient permit chain based on delay state consensus, wherein in a block chain, transaction sequencing, consensus and state calculation operations are processed asynchronously, each node uses one process to perform transaction sequencing and consensus, and the other process performs state calculation, so that the two types of time-consuming operations can completely and independently utilize block interval time instead of sharing the block interval time through serial processing. In the peak period with large transaction amount, if the state calculation cannot keep up with the peak period, the transaction list can be packed and identified firstly, the state identification can be delayed by more than one block, and the calculation capacity and the throughput of the block chain are improved to the maximum extent.

Description

Design method of efficient permission chain based on delay state consensus

Technical Field

On the basis of the original block chain model, the invention discusses how to process the sequence problems of transaction sequencing, state calculation and state consensus under the condition of a permission chain so as to improve the calculation capability and the throughput of the block chain to the maximum extent.

Background

The block chain is a new distributed technology, users initiate individual transactions, the node of the block verifies the validity of the transactions, and broadcasts the transactions to other nodes for consensus after the transactions are sequenced and packed into blocks. Current blockchain systems synchronize transaction ordering and status consensus, all within a single block.

The block of bitcoins only stores the transaction list, and the list of unspent currencies as a full chain state has no record displayed in the block. When the blocking person packs the transaction, the verification range comprises the transaction signature and also comprises whether the input of the transaction is in a full-chain state, if the input of the transaction is not in a state of spending money, the transaction is legal, and the transaction is packed and broadcasted. Other nodes keep the same list of local unspent currencies, do the same checks, and modify the local state. The transaction ordering, state calculation and state consensus of the tiles are synchronized and completed within one tile.

The blocks of the ether house store the transaction list, the return root, the latest status root. When the block-out nodes of the ether house perform packaging transaction, verifying the signatures of the transaction one by one, calculating whether the balance of a user is enough for transferring accounts and paying commission fees, if so, adding the balance into the block, modifying the local state, finally performing the evidence storage processing of the Merkle Patricia Tree on the receipt and the latest state to generate two root, storing the two root in the current block, and broadcasting the root to other nodes for verification. And other nodes calculate according to the transaction list of the block to be verified and the local state of the other nodes, compare the return root with the root in the latest state, and if the return root is consistent with the root in the latest state, the other nodes are legal blocks. Transaction ordering, status calculation and status consensus for the tiles are also synchronized and completed within a tile.

The current public chain generally has a certain block-out time interval, for example, the ether house is about 15 seconds, but if the transaction ordering and the state are in common, the block-out node needs to firstly spend half of the time to verify the block chain broadcasted by other block-out nodes during the 15 seconds, and then spend half of the time to calculate the next new block on the basis of the block. In the case of a grant chain, it may be less than half the time, and since many rounds of voting may consume much network time, the computation time for a single block is only about one third of the block interval.

In the context of a public chain, if a node simply verifies a signature and packages transactions without performing state calculations, there may be many invalid transactions packaged into blocks, such as a balance insufficient to pay a commission on computational consumption. Under the condition of an admission chain, users all have actual identities, and a simplified balance model and a simplified calculation consumption model are arranged in the system, so that the condition of large-scale malicious transmission of invalid transactions cannot occur, the transactions can be directly packed into blocks without calculation, the calculation is completed through the asynchronous condition, but if the state consensus is not carried out, the consistency of the states among the nodes cannot be ensured, and the state root can be recorded in the following blocks by adopting a delayed consensus method.

Disclosure of Invention

The invention aims to provide an efficient permission chain based on delay state consensus, aiming at the defects of the prior art.

The purpose of the invention is realized by the following technical scheme: an efficient permission chain based on delayed state consensus is disclosed, in which the operations of transaction sequencing, consensus and state calculation are processed asynchronously, each node uses one process to perform transaction sequencing and consensus, and the other process performs state calculation,

wherein the transaction ordering steps are as follows:

step 1: the required data is placed in the created block, creating a created block state root _0, and the license chain is started from the created block.

Step 2: and generating local empty state lists root _ list by all nodes for storing the states of which the calculation is finished, setting a first element root _ list [0] in the root _ list as a root _0 after creating the blocks synchronously, and setting the height consensus _ h of which the consensus is finished at present as 0.

And step 3: and the user sends the transaction, signs and broadcasts to the consensus node.

And 4, step 4: when a block with the height H (H is more than or equal to 1) is to be taken out by a block-out node, user transactions are firstly collected, the user authority and transaction signatures of the transactions are verified, but the user authority and the transaction signatures are not calculated, the user transactions are directly packed into the block, a state sublist root _ delta (which can be empty) with subscript in the root _ list (the subscript refers to the serial number of elements in the root _ list starting from 0) being more than or equal to consensus _ H is taken out, and the root _ delta is also placed into the block as a preamble state.

And 5: the node of the block signs a block with height H and broadcasts to other nodes and sets consensus _ H to H.

The block consensus comprises the following steps:

step 1: when a node receives a block with the broadcast height of H, firstly verifying user authority and a transaction signature of transaction in the block, and taking out a subset root _ delta 'consisting of block roots with subscripts larger than or equal to consensus _ H from the root _ list of the node, and if the number of elements of the root _ delta' is smaller than that of elements of the root _ delta in the received block, waiting for a certain time and then re-taking.

Step 2: and comparing all the states of the root _ delta' and the root _ delta by the node, if the states are consistent, indicating that the state consensus verification is passed, taking the block as a legal block to perform subsequent voting and other operations, and setting consensus _ H as H.

Further, the method of state calculation is as follows:

step 1: and all the nodes monitor the new blocks after the consensus is completed, and if the blocks are received, the blocks are put into a queue waiting for calculation and calculation is carried out according to the sequence that the block heights are gradually increased.

Step 2: after each block is calculated by the node, the latest state is added to the tail of the root _ list. And updates the state height state _ h and deletes the block from the queue waiting for computation.

The invention has the beneficial effects that: the invention asynchronously processes the operations of transaction sequencing, state calculation and state consensus, so that the node can use one process consensus to perform transaction sequencing and consensus on historical block states, and the other process chain performs state calculation, so that the two types of time-consuming operations can completely and independently utilize the block interval time instead of sharing the block interval time in a serial processing mode. And in the peak period with large transaction amount, if the state calculation cannot keep up with the peak period, the transaction list can be packed and identified firstly, the state identification can delay more than one block, and the calculation capability and the throughput of the block chain are improved to the maximum extent.

Drawings

FIG. 1 is an architecture diagram of a high efficiency license chain;

fig. 2 is a schematic diagram of delay consensus.

Detailed Description

Each node in the blockchain will perform the following two processes:

1. transaction ordering and process consensus on historical block status: and sequencing, verifying and packaging the new transaction to obtain blocks, broadcasting the blocks to other nodes, and performing state consensus on the other nodes. The consensus height is conconsus _ h, which is the height of the blockchain that the current node has completed consensus. The method comprises the following specific steps:

(1) transaction sequencing:

(2) Consensus on historical block status:

2. And a step of calculating the progress chain, namely receiving the new blocks which are commonly recognized, carrying out state calculation on the new blocks one by one, and putting the calculated state into the tail of the root _ list. The length of the root _ list is the state height state _ h. The specific process is as follows:

As shown in fig. 2, at a specific time, the state height state _ h is delayed from the consensus height consensus _ h. As per the example of fig. 2, at time T1, the height at which consensus has been completed is 1 and the state height is 0, i.e., the state consensus is delayed by 1 height; at time T2, the height at which consensus has been completed is 3 and the state height is 2, i.e., the state consensus is delayed by 1 height; at time T3, the height at which consensus has been completed is 4 and the state height is 2, i.e., the state consensus is delayed by 2 heights.

The present invention will be further described with reference to the following examples.

1. Transaction sequencing and consensus process:

node A: when the current consensus _ h is 2, a new transaction notification is received, and the following steps are executed:

(1) collect new transactions, sort transactions, validate, but do not make state calculations.

(2) A new block blk _3 with the height of 3 is taken out, a root _ delta in the preamble state of blk _3 is set, the root _ delta is a sublist formed by elements with subscripts larger than or equal to 2 in the root _ list, and the following different situations can be analyzed according to the progress speed of the root _ list:

root_list	root_delta
		[root_0,root_1,root_2]	[root_2]
[root_0,root_1]	air conditioner

[root_0]

Air conditioner

(3) Broadcast to other nodes and update the consensus _ h to 3

Node B: when the current consensus _ h is 2, the broadcasted blk _3 is received, and the preamble state in blk _3 is assumed to be [ root _2 ]. The following steps are carried out:

(1) and verifying the block, and taking out the state with the subscript being more than or equal to 3 from the local root _ list to form local root _ delta'.

(2) Comparing the root _ delta' with the root _ delta in blk _3, the following different situations can be analyzed:

2. and (3) calculating a process:

node I, the current root _ list is [ root _0, root _1], receives the new block blk2, blk3 after consensus completion, and executes the following steps:

(1) and calculating blk2 to obtain a new state root _2, and adding the new state root _2 into the root _ list.

(2) And calculating blk3 to obtain a new state root _3, and adding the new state root _3 into the root _ list.

Claims

1. A design method of a permission chain based on delay state consensus is characterized in that operations of transaction sequencing, consensus and state calculation are processed asynchronously in a block chain, each node uses one process to perform transaction sequencing and consensus, and the other process performs state calculation;

the transaction sequencing method comprises the following steps:

step 1: putting required data into the created block, generating a created block state root _0, and starting a permission chain from the created block;

step 2: all nodes generate a local empty state list root _ list which is used for storing the states of completed calculation, after creating a block synchronously, a first element root _ list [0] in the root _ list is set as a root _0, and the height consensus _ h of the current completed consensus is 0;

and step 3: the user sends a transaction, and broadcasts the transaction to the consensus node after signing;

and 4, step 4: when a block with the height H is to be taken out by a block outlet node, wherein H is more than or equal to 1, user transaction is firstly collected, the user authority and transaction signature of the transaction are verified, but calculation is not carried out, the block outlet node is directly packed into the block, and a subscript in a root _ list is taken out, wherein the subscript refers to the sequence number of elements in the root _ list starting from 0, a state sublist root _ delta which is more than or equal to consensus _ H can be empty, and the root _ delta is also placed in the block as a preamble state;

and 5: a block with the node signature height H is output and broadcasted to other nodes, and the consensus _ H is set to be H;

the block consensus comprises the following steps:

step 1: when a node receives a block with the broadcast height of H, firstly verifying user authority and a transaction signature of transaction in the block, and taking out a subset root _ delta 'consisting of block roots with subscripts larger than or equal to consensus _ H from the root _ list of the node, and if the number of elements of the root _ delta' is smaller than that of the elements of the root _ delta in the received block, waiting for a certain time and then re-taking;

step 2: and comparing all the states of the root _ delta' and the root _ delta by the node, if the states are consistent, indicating that the state consensus verification is passed, taking the block as a legal block to perform subsequent voting operation, and setting consensus _ H as H.

2. The design method of claim 1, wherein the state calculation is performed by:

step 1: all nodes monitor new blocks after consensus is completed, if the blocks are received, the blocks are placed in a queue waiting for calculation, and calculation is carried out according to the sequence that the block heights are gradually increased;

step 2: after each block is calculated by the node, adding the latest state to the tail of the root _ list; and updates the state height state _ h and deletes the block from the queue waiting for computation.