CA2995772A1 - A method of block building based on byzantine consensus via four rounds of communication - Google Patents
A method of block building based on byzantine consensus via four rounds of communication Download PDFInfo
- Publication number
- CA2995772A1 CA2995772A1 CA2995772A CA2995772A CA2995772A1 CA 2995772 A1 CA2995772 A1 CA 2995772A1 CA 2995772 A CA2995772 A CA 2995772A CA 2995772 A CA2995772 A CA 2995772A CA 2995772 A1 CA2995772 A1 CA 2995772A1
- Authority
- CA
- Canada
- Prior art keywords
- nodes
- node
- block
- bit
- array
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
- H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
Abstract
A byzantine fault tolerant blockchain system and method are disclosed. The method involves four rounds of communication for private blockchains. In the disclosed method all nodes hash their received transactions to obtain a bit-array which is sent to all other nodes, and each node receives the bit-arrays from 2/3 or more nodes to carry the set function for a resulting intersecting bit-array. According to the resulting bit-array a block building node obtains a set of transactions and submits the block to the other nodes. A node receiving the block performs verification steps by comparing its own bit-array with the set of transactions in the block, and sends a digital signature for the verification result to all other nodes. In a second round of voting, each node signs all the received voting results and forwards them to all the other nodes, so that each node receives the votes of all of nodes in the system. The votes are tallied to get the final result which is used to decide whether to accept the proposed block into the blockchain.
Description
A Method of Block Building Based on Byzantine Consensus via Four Rounds of Communication Technical Field [0001]
The present application relates generally to blockchain, and in particular to a Byzantine fault-tolerant block building system and method.
Background Art In a blockchain system, each node maintains a copy or instance of the blockchain respectively. To ensure the consistency of data on all nodes, it is necessary to ensure that each instance of blockchain maintained by each node is identical. With the rapid development of distributed applications such as e-commerce websites, the system may suffer attacks or hacking attempts, resulting in the existence of compromised nodes or "traitor nodes".
Under such scenarios, the system should keep normal nodes consistent and operate normally. In such cases, the block building method based on the Byzantine algorithm is needed. Critical services need not only to tolerate benign mistakes, but also to tolerate Byzantine errors. A
reference paper on the subject is Leslie Lamport, Robert Shostak, and Marshall Pease. The byzantine generals problem.
ACM Trans. Program. Lang. Syst., 4(3 ): 3 82-40 1 , 1 982.
[0003]
Transactions stored in current blockchain systems originate from within the system, that is, transactions are generated between system nodes. Transaction-level verification is achieved through a digital signature. If the transaction source is to be extended to include those outside of the blockchain system, then new challenges are encountered. For example, the verification for transactions breaks down as single nodes cannot verify the validity of transactions independently after receiving them.
[0004]
For the current public blockchain scenarios such as Bitcoin and Ethereum, the block building is realized by mining. Mining itself is an otherwise meaningless calculation which wastes a lot of resources. In the case of a limited number of blockchain nodes, submission of building blocks by a single node may cause Byzantine error, i.e. data inconsistency.
LEGAL_28686222 1 - 1 -101 I 352-256534-Kw-FT
[0005]
The blockchain system is a distributed ledger that may face potential economic losses due to benign error modification of the blockchain. It is thus desirable that, in the face of hacking attacks, the system is able to ensure that data cannot be tampered with, or that most nodes in the system cannot be tampered with.
Summary of Invention [0006]
In accordance with one aspect of the present invention, there is provided a blockchain system characterized by system consistency, with the ability to overcome Byzantine errors and to prevent or mitigate attacks.
[0007]
In accordance with another aspect of the present invention, there is provided a four-round communication Byzantine fault-tolerant blockchain block building method.
The method includes verification and voting on transaction level; building blocks;
verifying blocks; and (4) making decisions on admission of blocks.
Brief Description of Drawings [0008]
In the figures, which illustrate by way of example only, embodiments of the present invention:
[0009]
FIG. 1 is a schematic diagram illustrating a four-way communication in accordance with an exemplary embodiment of the present invention;
[0010]
FIG. 2 is a schematic diagram of the bit-array structure according to an exemplary embodiment of the present invention;
[0011]
FIG. 3 is a schematic diagram representing voting information according to an exemplary embodiment of the present invention; and [0012]
FIG. 4 is a schematic diagram representing voting statistics according to an exemplary embodiment of the present invention.
LEGAL_28686222 1 - 2 -Description of Embodiments [0013]
Exemplary embodiments of the present invention provide blockchain systems and methods of building blocks that lead to system consistency by overcoming Byzantine errors and by preventing and/or mitigating attacks.
[0014]
Specific embodiments of the present invention will be presented in detail, with reference to the above described drawings. Like parts are denoted by like reference numerals in the drawings. Persons of skill in the art will readily appreciate that the drawings are not necessarily drawn to scale.
[0015] A
four-round communication Byzantine fault-tolerant blockchain block building method, includes the steps of: (1) verification and voting on transaction level; (2) building blocks; (3) verifying blocks; and (4) making a decision on admission of blocks.
[0016]
In the first step (1) of verification and voting on transaction level, all nodes perform hash mapping of received transactions to get a bit-array, and send the bit-array to all other nodes whereby each node performs a 2/3 intersecting operation on the received bit-arrays to obtain a resultant bit-array covering more than 2/3 of all nodes.
[0017]
In the second step (2) of building blocks, the block building node makes the transaction set according to its bit-array to build the block, and the block is submitted to the other nodes.
[0018]
In the third step (3) of verifying the block, each node receives a block and compares the received block's transaction set with its own bit-array to make the verification, and thereafter the verification is digitally signed and sent to all the other nodes.
[0019]
In the fourth step (4), in a second round of voting, all nodes receive all the first round voting with signatures and forward them to other nodes, so that each node receives the votes of all the nodes and counts the votes to get the final result, so as to decide whether to admit the block.
LEGAL_28686222 1 - 3 -[0020]
For the first step (1), a hash calculation is performed to obtain an integer m from 0 to 1664. Assuming that the length of the bit-array is n and the initial value of each bit is 0, a modulo m'Yon operation is performed to obtain a integer num between 0 and (n-1), the numth bit of the bit-array is assigned a value of 1, and then this bit-array is sent to all the other nodes.
[0021]
The building block operation in the step (2) includes several steps. The steps include steps 2a, 2b, 2c and 2d which are described below. In step (2a) each node makes an intersecting operation on the bit-arrays received from all the other nodes, to obtain the bit-array corresponding to the intersection of all the transactions. In step (2b) a Round-robin algorithm is executed inside the node to select a unique block building node. In step (2c) the block building node collects transactions from all nodes and maps them to the bit-array to get the transaction set corresponding to the intersection, and uses this part of the transactions to build a block. In step (2d) the block building node sends the block to the other nodes.
[0022]
The verification of the block in step (3) is completed by the first round of voting and includes several smaller steps. The steps include steps (3a), (3b), and (3c) which are described below. In step (3a) all nodes verify the received block by their own bit-array and if the transaction set is consistent and the block builder is the right elected building node, then the block is considered valid. In step (3b) the block verification is represented by 0 and 1, 0 means fail, 1 means approved. By using the private key encryption, sign the digital signature to the voting result and the hash of the block. In step (3c) a digital signature is sent to the other nodes.
[0023]
Step (4) also includes smaller steps (4a) and (4b) which are described below.
In step (4a) each node gets a voting set after receiving the first round of voting from the other nodes, and signs the set with its own private key. In step (4b) each node, after receiving the votes of the second round of the voting results, tallies the votes to get the final result, so as to decide whether to admit the block into the blockchain.
[0024]
To ensure the consistency and security of different nodes in the current blockchain, a four-step consistency algorithm can be used in exemplary embodiments of the present invention.
LEGAL_28686222 1 - 4 -The consistency algorithm requires four communications, which have the following advantages over the traditional blockchain consistency algorithms.
[0025]
Firstly, the building method introduces voting on the transaction level. This design allows the confirmation of the transactions and the confirmation of new blocks to be performed in parallel. By increasing the number of machines at a single node or by using multi-threading to improve machine performance, the speed of building blocks can be greatly increased, making it possible to scale the system.
[0026]
Secondly, it allows the accommodation of transactions from external trading systems, which extends the use of blockchain to a larger set of applications.
To guarantee the correctness of the transactions from outside the system, one voting step on the transactions is first conducted, that is, transaction-level voting is used. All nodes perform transaction intersecting operations, ensuring that all transactions are received by each node are identical, thereby preventing a fake transaction on any node.
[0027]
Thirdly, the use of bit-array makes verification on transactional levels much faster.
Communicating just a bit-array among nodes lead to a substantial improvement in communication speed, and permits simple operations on bit-arrays to get the transaction intersection in a very efficient manner. It is thus an effective technical implementation for transaction verification.
[0028]
As a fourth advantage, Byzantine voting thereafter can guarantee data consistency that tolerates Byzantine errors. The voting process uses the Byzantine fault tolerance algorithm to ensure that the system can still function normally even if there is one third or less of compromised nodes in the system. That is, the system can tolerate erroneous nodes, if the number of erroneous nodes accounts for no more than 1/3 of all nodes.
[0029]
According to the above noted reference (Lamport, Robert Shostak, and Marshall Pease. The byzantine generals problem. ACM Trans. Program. Lang. Syst., 4(3):382-401,1982), in order to tolerate Byzantine failure of f machines, redundant system requires at least 3f + 1 stand-alone nodes, which means that the system must have at least 4 nodes, 4 nodes can tolerate 1 node failure or under attack. To tolerate f node failures or attacks, the system needs 3f + 1 nodes. If the system is to tolerate up to 2 nodes failure or attack, then there should be at least 7 nodes. When a node fails or is attacked, as long as the total number of nodes exceeds 3 times the number of compromised or failed nodes, the system's fault tolerance algorithm can ensure normal operation of the other normal nodes.
[0030] In one round of block building, if the final number of positive votes is less than 2/3 of the total nodes, then this round of building blocks fails, a new round of building blocks is required, and the height of the chain will not increase. The system can work normally if less than 1/3 of the nodes in the voting process fail or are under an attacker's control. After a compromised or abnormal node returns to normal, there will be a synchronization mechanism, sending requests to the other nodes to get a complete blockchain. In this way, any node can normally participate in a new round of voting after becoming normal, keeping the data integrity and consistency of the distributed system on each node.
[0031] All nodes use digital signatures during the voting process.
Therefore, the Byzantine algorithm of the patent is a consensus algorithm by which voting information is identifiable and cannot be forged. Each node uses its own private key to encrypt the voting result and the block hash value during the voting to get the digital signature and sends digital signature and voting information to all the other nodes. After receiving the digital signature, all the nodes decrypt the digital signature by the sender's public key to obtain the original information, and if the information is identical to the voting information, all nodes will consider the received information credible. All the nodes participate in the voting process will do the digital signature to ensure the voting information cannot be denied and cannot be tampered with.
[0032] Example [0033] Suppose there are 4 nodes in the blockchain system (i.e. M = 4), which are node A, node B, node C and node D respectively. When constructing the block by the method of the LEGAL 28686222.1 - 6 -present patent, each node first fetches the transactions to form a bit-array, shown in FIG. 2, and start the first communication:
[0034] Node A: Map transactions received by itself to bit-array and send the bit-array to nodes B, C and D;
[0035] Node B: Map transactions received by itself to bit-array and send the bit-array to nodes A, C and D;
[0036] Node C: Map transactions received by itself to bit-array and send the bit-array to nodes A, B, D;
[0037] Node D: Map transactions received by itself to bit-array and send the bit-array to nodes A, B, C;
[0038] After the first communication, all nodes calculate 2/3 intersection based on the obtained bit-arrays, and the result of the operation is recorded as BA. That is to say, if the values at certain position of 2/3 or more of the bit-arrays' are 1, the bit-array set 1 to the position, otherwise set 0, computing results recorded as BA.
[0039] Run a round-robin algorithm in the system, to get a block building node. The specific approach is based on the current block height H and R do hash mapping, the hash value modes M, and according to the modulus result to decide the leader node. Without lack of generality, suppose node A is elected as leader, then node A gets a transaction set BS
according to the BA
and the transactions it has received, and the BS satisfies that each transaction mapping bit in the corresponding BA is 1. Use this transaction set to build a block AB and start the second round of communication:
[0040] Node A: Send the block AB to Node B, C, D;
[0041] After receiving the block AB, the nodes B, C and D use their own BA
to traverse the transactions in the block AB. If one transaction in the block mapping to a bit in the BA with value 0, then the voting information is 0 + hash (AB) , otherwise 1 + hash (AB). The voting LEGAL_28686222 1 - 7 -lOt 1152-256514-KB'T
information of node A is 1 + hash (AB). The voting information is encrypted by using its own private key to obtain a digital signature. The voting information structure is as shown in FIG. 3.
Start the third communication, that is, the first round of voting:
[0042] Node A: Send voting information and digital signature to Node B, C, D;
[0043] Node B: Send voting information and digital signatures to nodes A, C, D;
[0044] Node C: Send voting information and digital signatures to nodes A, B, D;
[0045] Node D: Send voting information and digital signatures to nodes A, B, C;
[0046] Each node receives 3 votes, first verifying the authenticity of the received voting information based on the digital signature. After discarding all the illegal voting information, a voting set is obtained. After obtaining the hash value of the voting set, the digital signature is made by using its own private key. The structure of the specific sending message is as shown in FIG. 4. Then start the fourth communication that the second round of voting:
[0047] Node A: Send Voting List and Digital Signature to Node B, C, D;
[0048] Node B: Sending voting lists and digital signatures to nodes A, C, D;
[0049] Node C: Sending voting lists and digital signatures to nodes A, B, D;
[0050] Node D: Sending voting lists and digital signatures to nodes A, B, C;
[0051] Each node can get the voting information of all nodes and use the digital signatures to verify the legitimacy. They think that all the illegal voting information is negative votes. All voting information is tallied. Without lack of generality, taking node A's statistics on voting results as an example, the statistics of each node are shown.
[0052] According to the vote node A received from node B in the third communication, and the votes node C and D received from node B in the fourth communication, node A gets node B's votes to all the other 3 nodes, assuming that node B's voting results (A:1, C:1, D:1), since the number of affirmative votes is more than two-thirds, it is considered that the voting result of node B is 1, otherwise node B's vote is considered as zero. For node C, D, the votes are processed in the same way, to get the final voting results.
[0053]
According to nodes B, C, D and their own votes, if the number of votes exceeds three (two-thirds of the total number of nodes), the block is considered valid and stored in the chain. Otherwise the block is abandoned.
[0054]
The above only shows the case of M = 4. When M 5 or 6, the principle and method for two rounds of communication are the same as in the case of M = 4.
[0055]
Having thus described, by way of example only, embodiments of the present invention, it is to be understood that the invention as defined by the appended claims is not to be limited by particular details set forth in the above description of exemplary embodiments as many variations and permutations are possible without departing from the scope of the claims.
LEGAL_28686222 1 - 9 -
The present application relates generally to blockchain, and in particular to a Byzantine fault-tolerant block building system and method.
Background Art In a blockchain system, each node maintains a copy or instance of the blockchain respectively. To ensure the consistency of data on all nodes, it is necessary to ensure that each instance of blockchain maintained by each node is identical. With the rapid development of distributed applications such as e-commerce websites, the system may suffer attacks or hacking attempts, resulting in the existence of compromised nodes or "traitor nodes".
Under such scenarios, the system should keep normal nodes consistent and operate normally. In such cases, the block building method based on the Byzantine algorithm is needed. Critical services need not only to tolerate benign mistakes, but also to tolerate Byzantine errors. A
reference paper on the subject is Leslie Lamport, Robert Shostak, and Marshall Pease. The byzantine generals problem.
ACM Trans. Program. Lang. Syst., 4(3 ): 3 82-40 1 , 1 982.
[0003]
Transactions stored in current blockchain systems originate from within the system, that is, transactions are generated between system nodes. Transaction-level verification is achieved through a digital signature. If the transaction source is to be extended to include those outside of the blockchain system, then new challenges are encountered. For example, the verification for transactions breaks down as single nodes cannot verify the validity of transactions independently after receiving them.
[0004]
For the current public blockchain scenarios such as Bitcoin and Ethereum, the block building is realized by mining. Mining itself is an otherwise meaningless calculation which wastes a lot of resources. In the case of a limited number of blockchain nodes, submission of building blocks by a single node may cause Byzantine error, i.e. data inconsistency.
LEGAL_28686222 1 - 1 -101 I 352-256534-Kw-FT
[0005]
The blockchain system is a distributed ledger that may face potential economic losses due to benign error modification of the blockchain. It is thus desirable that, in the face of hacking attacks, the system is able to ensure that data cannot be tampered with, or that most nodes in the system cannot be tampered with.
Summary of Invention [0006]
In accordance with one aspect of the present invention, there is provided a blockchain system characterized by system consistency, with the ability to overcome Byzantine errors and to prevent or mitigate attacks.
[0007]
In accordance with another aspect of the present invention, there is provided a four-round communication Byzantine fault-tolerant blockchain block building method.
The method includes verification and voting on transaction level; building blocks;
verifying blocks; and (4) making decisions on admission of blocks.
Brief Description of Drawings [0008]
In the figures, which illustrate by way of example only, embodiments of the present invention:
[0009]
FIG. 1 is a schematic diagram illustrating a four-way communication in accordance with an exemplary embodiment of the present invention;
[0010]
FIG. 2 is a schematic diagram of the bit-array structure according to an exemplary embodiment of the present invention;
[0011]
FIG. 3 is a schematic diagram representing voting information according to an exemplary embodiment of the present invention; and [0012]
FIG. 4 is a schematic diagram representing voting statistics according to an exemplary embodiment of the present invention.
LEGAL_28686222 1 - 2 -Description of Embodiments [0013]
Exemplary embodiments of the present invention provide blockchain systems and methods of building blocks that lead to system consistency by overcoming Byzantine errors and by preventing and/or mitigating attacks.
[0014]
Specific embodiments of the present invention will be presented in detail, with reference to the above described drawings. Like parts are denoted by like reference numerals in the drawings. Persons of skill in the art will readily appreciate that the drawings are not necessarily drawn to scale.
[0015] A
four-round communication Byzantine fault-tolerant blockchain block building method, includes the steps of: (1) verification and voting on transaction level; (2) building blocks; (3) verifying blocks; and (4) making a decision on admission of blocks.
[0016]
In the first step (1) of verification and voting on transaction level, all nodes perform hash mapping of received transactions to get a bit-array, and send the bit-array to all other nodes whereby each node performs a 2/3 intersecting operation on the received bit-arrays to obtain a resultant bit-array covering more than 2/3 of all nodes.
[0017]
In the second step (2) of building blocks, the block building node makes the transaction set according to its bit-array to build the block, and the block is submitted to the other nodes.
[0018]
In the third step (3) of verifying the block, each node receives a block and compares the received block's transaction set with its own bit-array to make the verification, and thereafter the verification is digitally signed and sent to all the other nodes.
[0019]
In the fourth step (4), in a second round of voting, all nodes receive all the first round voting with signatures and forward them to other nodes, so that each node receives the votes of all the nodes and counts the votes to get the final result, so as to decide whether to admit the block.
LEGAL_28686222 1 - 3 -[0020]
For the first step (1), a hash calculation is performed to obtain an integer m from 0 to 1664. Assuming that the length of the bit-array is n and the initial value of each bit is 0, a modulo m'Yon operation is performed to obtain a integer num between 0 and (n-1), the numth bit of the bit-array is assigned a value of 1, and then this bit-array is sent to all the other nodes.
[0021]
The building block operation in the step (2) includes several steps. The steps include steps 2a, 2b, 2c and 2d which are described below. In step (2a) each node makes an intersecting operation on the bit-arrays received from all the other nodes, to obtain the bit-array corresponding to the intersection of all the transactions. In step (2b) a Round-robin algorithm is executed inside the node to select a unique block building node. In step (2c) the block building node collects transactions from all nodes and maps them to the bit-array to get the transaction set corresponding to the intersection, and uses this part of the transactions to build a block. In step (2d) the block building node sends the block to the other nodes.
[0022]
The verification of the block in step (3) is completed by the first round of voting and includes several smaller steps. The steps include steps (3a), (3b), and (3c) which are described below. In step (3a) all nodes verify the received block by their own bit-array and if the transaction set is consistent and the block builder is the right elected building node, then the block is considered valid. In step (3b) the block verification is represented by 0 and 1, 0 means fail, 1 means approved. By using the private key encryption, sign the digital signature to the voting result and the hash of the block. In step (3c) a digital signature is sent to the other nodes.
[0023]
Step (4) also includes smaller steps (4a) and (4b) which are described below.
In step (4a) each node gets a voting set after receiving the first round of voting from the other nodes, and signs the set with its own private key. In step (4b) each node, after receiving the votes of the second round of the voting results, tallies the votes to get the final result, so as to decide whether to admit the block into the blockchain.
[0024]
To ensure the consistency and security of different nodes in the current blockchain, a four-step consistency algorithm can be used in exemplary embodiments of the present invention.
LEGAL_28686222 1 - 4 -The consistency algorithm requires four communications, which have the following advantages over the traditional blockchain consistency algorithms.
[0025]
Firstly, the building method introduces voting on the transaction level. This design allows the confirmation of the transactions and the confirmation of new blocks to be performed in parallel. By increasing the number of machines at a single node or by using multi-threading to improve machine performance, the speed of building blocks can be greatly increased, making it possible to scale the system.
[0026]
Secondly, it allows the accommodation of transactions from external trading systems, which extends the use of blockchain to a larger set of applications.
To guarantee the correctness of the transactions from outside the system, one voting step on the transactions is first conducted, that is, transaction-level voting is used. All nodes perform transaction intersecting operations, ensuring that all transactions are received by each node are identical, thereby preventing a fake transaction on any node.
[0027]
Thirdly, the use of bit-array makes verification on transactional levels much faster.
Communicating just a bit-array among nodes lead to a substantial improvement in communication speed, and permits simple operations on bit-arrays to get the transaction intersection in a very efficient manner. It is thus an effective technical implementation for transaction verification.
[0028]
As a fourth advantage, Byzantine voting thereafter can guarantee data consistency that tolerates Byzantine errors. The voting process uses the Byzantine fault tolerance algorithm to ensure that the system can still function normally even if there is one third or less of compromised nodes in the system. That is, the system can tolerate erroneous nodes, if the number of erroneous nodes accounts for no more than 1/3 of all nodes.
[0029]
According to the above noted reference (Lamport, Robert Shostak, and Marshall Pease. The byzantine generals problem. ACM Trans. Program. Lang. Syst., 4(3):382-401,1982), in order to tolerate Byzantine failure of f machines, redundant system requires at least 3f + 1 stand-alone nodes, which means that the system must have at least 4 nodes, 4 nodes can tolerate 1 node failure or under attack. To tolerate f node failures or attacks, the system needs 3f + 1 nodes. If the system is to tolerate up to 2 nodes failure or attack, then there should be at least 7 nodes. When a node fails or is attacked, as long as the total number of nodes exceeds 3 times the number of compromised or failed nodes, the system's fault tolerance algorithm can ensure normal operation of the other normal nodes.
[0030] In one round of block building, if the final number of positive votes is less than 2/3 of the total nodes, then this round of building blocks fails, a new round of building blocks is required, and the height of the chain will not increase. The system can work normally if less than 1/3 of the nodes in the voting process fail or are under an attacker's control. After a compromised or abnormal node returns to normal, there will be a synchronization mechanism, sending requests to the other nodes to get a complete blockchain. In this way, any node can normally participate in a new round of voting after becoming normal, keeping the data integrity and consistency of the distributed system on each node.
[0031] All nodes use digital signatures during the voting process.
Therefore, the Byzantine algorithm of the patent is a consensus algorithm by which voting information is identifiable and cannot be forged. Each node uses its own private key to encrypt the voting result and the block hash value during the voting to get the digital signature and sends digital signature and voting information to all the other nodes. After receiving the digital signature, all the nodes decrypt the digital signature by the sender's public key to obtain the original information, and if the information is identical to the voting information, all nodes will consider the received information credible. All the nodes participate in the voting process will do the digital signature to ensure the voting information cannot be denied and cannot be tampered with.
[0032] Example [0033] Suppose there are 4 nodes in the blockchain system (i.e. M = 4), which are node A, node B, node C and node D respectively. When constructing the block by the method of the LEGAL 28686222.1 - 6 -present patent, each node first fetches the transactions to form a bit-array, shown in FIG. 2, and start the first communication:
[0034] Node A: Map transactions received by itself to bit-array and send the bit-array to nodes B, C and D;
[0035] Node B: Map transactions received by itself to bit-array and send the bit-array to nodes A, C and D;
[0036] Node C: Map transactions received by itself to bit-array and send the bit-array to nodes A, B, D;
[0037] Node D: Map transactions received by itself to bit-array and send the bit-array to nodes A, B, C;
[0038] After the first communication, all nodes calculate 2/3 intersection based on the obtained bit-arrays, and the result of the operation is recorded as BA. That is to say, if the values at certain position of 2/3 or more of the bit-arrays' are 1, the bit-array set 1 to the position, otherwise set 0, computing results recorded as BA.
[0039] Run a round-robin algorithm in the system, to get a block building node. The specific approach is based on the current block height H and R do hash mapping, the hash value modes M, and according to the modulus result to decide the leader node. Without lack of generality, suppose node A is elected as leader, then node A gets a transaction set BS
according to the BA
and the transactions it has received, and the BS satisfies that each transaction mapping bit in the corresponding BA is 1. Use this transaction set to build a block AB and start the second round of communication:
[0040] Node A: Send the block AB to Node B, C, D;
[0041] After receiving the block AB, the nodes B, C and D use their own BA
to traverse the transactions in the block AB. If one transaction in the block mapping to a bit in the BA with value 0, then the voting information is 0 + hash (AB) , otherwise 1 + hash (AB). The voting LEGAL_28686222 1 - 7 -lOt 1152-256514-KB'T
information of node A is 1 + hash (AB). The voting information is encrypted by using its own private key to obtain a digital signature. The voting information structure is as shown in FIG. 3.
Start the third communication, that is, the first round of voting:
[0042] Node A: Send voting information and digital signature to Node B, C, D;
[0043] Node B: Send voting information and digital signatures to nodes A, C, D;
[0044] Node C: Send voting information and digital signatures to nodes A, B, D;
[0045] Node D: Send voting information and digital signatures to nodes A, B, C;
[0046] Each node receives 3 votes, first verifying the authenticity of the received voting information based on the digital signature. After discarding all the illegal voting information, a voting set is obtained. After obtaining the hash value of the voting set, the digital signature is made by using its own private key. The structure of the specific sending message is as shown in FIG. 4. Then start the fourth communication that the second round of voting:
[0047] Node A: Send Voting List and Digital Signature to Node B, C, D;
[0048] Node B: Sending voting lists and digital signatures to nodes A, C, D;
[0049] Node C: Sending voting lists and digital signatures to nodes A, B, D;
[0050] Node D: Sending voting lists and digital signatures to nodes A, B, C;
[0051] Each node can get the voting information of all nodes and use the digital signatures to verify the legitimacy. They think that all the illegal voting information is negative votes. All voting information is tallied. Without lack of generality, taking node A's statistics on voting results as an example, the statistics of each node are shown.
[0052] According to the vote node A received from node B in the third communication, and the votes node C and D received from node B in the fourth communication, node A gets node B's votes to all the other 3 nodes, assuming that node B's voting results (A:1, C:1, D:1), since the number of affirmative votes is more than two-thirds, it is considered that the voting result of node B is 1, otherwise node B's vote is considered as zero. For node C, D, the votes are processed in the same way, to get the final voting results.
[0053]
According to nodes B, C, D and their own votes, if the number of votes exceeds three (two-thirds of the total number of nodes), the block is considered valid and stored in the chain. Otherwise the block is abandoned.
[0054]
The above only shows the case of M = 4. When M 5 or 6, the principle and method for two rounds of communication are the same as in the case of M = 4.
[0055]
Having thus described, by way of example only, embodiments of the present invention, it is to be understood that the invention as defined by the appended claims is not to be limited by particular details set forth in the above description of exemplary embodiments as many variations and permutations are possible without departing from the scope of the claims.
LEGAL_28686222 1 - 9 -
Claims (8)
1. A method of block building based on Byzantine Consensus in a blockchain system, the method comprising the steps of (A) voting and confirmation of transaction level wherein all nodes receive transactions and hash received transactions to generate a bit-array, and send the bit-array to all other nodes, each node performing matrix cross computing with received bit-arrays and outputting a corresponding bit-array covering transactions from more than 2/3 of total nodes;
(B) building blocks wherein a block-generator node builds a new block based on the value of output bit-array, and send the new block to the other nodes;
(C) block verification in a first-round voting wherein: upon receiving the new block, each node verifies the new block by comparing the new block's bit-array value with its own output bit-array and thereafter sends the verification result with its own digital signature to all the other nodes; and (D) second-round voting wherein each node signs on all the first-round votes received from other nodes and forwards to all the other nodes, so that each node can have the full sets of votes from every other nodes and wherein in accordance with the full set of votes, the system decides whether to accept the block.
(B) building blocks wherein a block-generator node builds a new block based on the value of output bit-array, and send the new block to the other nodes;
(C) block verification in a first-round voting wherein: upon receiving the new block, each node verifies the new block by comparing the new block's bit-array value with its own output bit-array and thereafter sends the verification result with its own digital signature to all the other nodes; and (D) second-round voting wherein each node signs on all the first-round votes received from other nodes and forwards to all the other nodes, so that each node can have the full sets of votes from every other nodes and wherein in accordance with the full set of votes, the system decides whether to accept the block.
2. The method of claim 1, wherein step (A) includes, (i) hash mapping to get an integer m between 0 to 16 64, the bit-array having a length n, with initial values of each bit in the array set to 0;
(ii) obtaining an integer num where 0 <= num <= (n-1) by a modulo operation of m% n;
(iii) setting the num th bit of the bit-array to a value of 1; and (iv) sending the bit-array to all the other nodes.
(ii) obtaining an integer num where 0 <= num <= (n-1) by a modulo operation of m% n;
(iii) setting the num th bit of the bit-array to a value of 1; and (iv) sending the bit-array to all the other nodes.
3. The method of claim 1, wherein the building block operation in step (B) comprises:
(a) after each node receives bit-arrays from all the other nodes, summing all the received bit-arrays to obtain an intersection, thereby completing voting of the transaction;
(b) executing round-robin algorithm inside the blockchain to obtain the unique building node;
(c) at the building node, obtaining a transaction intersection of all nodes from collected transactions according to bit-arrays corresponding to the intersection set, and using this set of the transaction to build the block; and (d) at the building node, sending the block built to all the other nodes.
(a) after each node receives bit-arrays from all the other nodes, summing all the received bit-arrays to obtain an intersection, thereby completing voting of the transaction;
(b) executing round-robin algorithm inside the blockchain to obtain the unique building node;
(c) at the building node, obtaining a transaction intersection of all nodes from collected transactions according to bit-arrays corresponding to the intersection set, and using this set of the transaction to build the block; and (d) at the building node, sending the block built to all the other nodes.
4. The method of claim 1, wherein the verification of the block in step (C) is completed by the first round of voting, comprising:
(a) comparing the bit-array intersection obtained from its own operation on the node with that of the received block, after all the nodes receive the block, wherein upon the transaction set being found the same and the block builder being the selected building node, the block is declared valid;
(b) representing result of the block verification by 0 or 1, where 0 means invalid and 1 means valid, and encrypting a hash signature of the voting result and block with a private key to obtain a digital signature; and (c) sending the digital signature to the other nodes nodes.
(a) comparing the bit-array intersection obtained from its own operation on the node with that of the received block, after all the nodes receive the block, wherein upon the transaction set being found the same and the block builder being the selected building node, the block is declared valid;
(b) representing result of the block verification by 0 or 1, where 0 means invalid and 1 means valid, and encrypting a hash signature of the voting result and block with a private key to obtain a digital signature; and (c) sending the digital signature to the other nodes nodes.
5. The method of claim 1, wherein the step (D) comprises:
(a) after each node receives the first round of votes from all the other nodes, a union of the votes is obtained, and the union is signed with a private key; and (b) each node counting the votes after receiving the second round of votes, to obtain the final result, so as to decide whether to accept the block into the blockchain.
(a) after each node receives the first round of votes from all the other nodes, a union of the votes is obtained, and the union is signed with a private key; and (b) each node counting the votes after receiving the second round of votes, to obtain the final result, so as to decide whether to accept the block into the blockchain.
6. The method of claim 1, wherein the system comprises 3f + 1 nodes and is thereby able to tolerate a Byzantine failure in f individual nodes.
7. The method of claim 6, wherein if less than 1/3 of the nodes in a voting process fail, the system can operate normally and wherein after a failed node returns to normal, a synchronization mechanism sends requests to remaining nodes that have not failed to obtain a complete blockchain, and ensures that any node can normally participate in the new round after the synchronization process.
8. The method of claim 1, wherein each node uses its own private key to vote and encrypt block hash value to obtain a digital signature wherein the digital signature and the voting information are sent to all the other nodes together; an wherein after receiving a vote containing the digital signature, all the nodes decrypt the digital signature by using a sender node's public key to obtain decrypted information and wherein upon the decrypted information and voting information being the same, the decrypted information is declared credible
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CA2995772A CA2995772A1 (en) | 2018-02-21 | 2018-02-21 | A method of block building based on byzantine consensus via four rounds of communication |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CA2995772A CA2995772A1 (en) | 2018-02-21 | 2018-02-21 | A method of block building based on byzantine consensus via four rounds of communication |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CA2995772A1 true CA2995772A1 (en) | 2019-08-21 |
Family
ID=68095899
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA2995772A Abandoned CA2995772A1 (en) | 2018-02-21 | 2018-02-21 | A method of block building based on byzantine consensus via four rounds of communication |
Country Status (1)
| Country | Link |
|---|---|
| CA (1) | CA2995772A1 (en) |
Cited By (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110796547A (en) * | 2019-10-30 | 2020-02-14 | 桂林电子科技大学 | Improved practical Byzantine fault-tolerant system based on alliance block chain |
| CN111431696A (en) * | 2020-03-26 | 2020-07-17 | 深圳市欧欣泰科技有限公司 | Identity-based block chain sealing mechanism |
| CN111464356A (en) * | 2020-04-01 | 2020-07-28 | 腾讯科技（深圳）有限公司 | Block consensus period switching method and device and computer equipment |
| CN112100659A (en) * | 2020-09-14 | 2020-12-18 | 电子科技大学 | Block chain federal learning system and Byzantine attack detection method |
| US11250021B2 (en) | 2020-04-17 | 2022-02-15 | International Business Machines Corporation | Faster view change for blockchain |
| CN116846916A (en) * | 2023-09-01 | 2023-10-03 | 武汉趣链数字科技有限公司 | Data synchronization method, device, electronic equipment and computer readable storage medium |
-
2018
- 2018-02-21 CA CA2995772A patent/CA2995772A1/en not_active Abandoned
Cited By (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110796547A (en) * | 2019-10-30 | 2020-02-14 | 桂林电子科技大学 | Improved practical Byzantine fault-tolerant system based on alliance block chain |
| CN111431696A (en) * | 2020-03-26 | 2020-07-17 | 深圳市欧欣泰科技有限公司 | Identity-based block chain sealing mechanism |
| CN111431696B (en) * | 2020-03-26 | 2023-10-17 | 深圳市欧欣泰科技有限公司 | Block chain seal mechanism based on identity |
| CN111464356A (en) * | 2020-04-01 | 2020-07-28 | 腾讯科技（深圳）有限公司 | Block consensus period switching method and device and computer equipment |
| US11250021B2 (en) | 2020-04-17 | 2022-02-15 | International Business Machines Corporation | Faster view change for blockchain |
| US11775556B2 (en) | 2020-04-17 | 2023-10-03 | International Business Machines Corporation | Faster view change for blockchain |
| CN112100659A (en) * | 2020-09-14 | 2020-12-18 | 电子科技大学 | Block chain federal learning system and Byzantine attack detection method |
| CN116846916A (en) * | 2023-09-01 | 2023-10-03 | 武汉趣链数字科技有限公司 | Data synchronization method, device, electronic equipment and computer readable storage medium |
| CN116846916B (en) * | 2023-09-01 | 2023-12-08 | 武汉趣链数字科技有限公司 | Data synchronization method, device, electronic equipment and computer readable storage medium |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CA2995772A1 (en) | A method of block building based on byzantine consensus via four rounds of communication | |
| US11411721B2 (en) | Systems and methods for selecting and utilizing a committee of validator nodes in a distributed system | |
| CN111066287B (en) | Retrieving public data of blockchain networks using trusted execution environments | |
| CN106447311B (en) | A kind of block chain of Byzantine failure tolerance algorithms of four communications builds block method | |
| CN108632362B (en) | Method for electing private block chain building block node | |
| CN111066285B (en) | SM2 signature based public key recovery method | |
| CN101981889B (en) | Secure communications in computer cluster systems | |
| US20190386829A1 (en) | Method and system for byzantine fault - tolerance replicating of data | |
| CN113301114B (en) | Block chain consensus node selection method and device, computer equipment and storage medium | |
| JP2022501971A (en) | Methods for key management, user devices, management devices, storage media and computer program products | |
| EP3659060B1 (en) | Consensus protocol for permissioned ledgers | |
| CN112865959B (en) | Consensus method of distributed node equipment, node equipment and distributed network | |
| CN110213228B (en) | Method, device, storage medium and computer equipment for authenticating communication | |
| WO2023045972A1 (en) | Consensus method and device for blockchain system | |
| US20190258610A1 (en) | Byzantine fault-tolerant algorithm with four steps | |
| CN114868359B (en) | Multi-block inter-chain light communication protocol device and method | |
| CN113259123B (en) | Block chain data writing and accessing method and device | |
| Esfahani et al. | Secure blockchain-based energy transaction framework in smart power systems | |
| GB2555183A (en) | Method for secure data management in a computer network | |
| CN110867012A (en) | Method, device and system for de-centering electronic voting based on intelligent contract and storage medium | |
| CN116132118A (en) | Encryption communication method and system based on block chain technology | |
| CN113923093B (en) | Novel Bayesian-preemption fault-tolerant consensus method based on trusted execution environment | |
| US20210111900A1 (en) | Verification information attaching device, verification device, information management system, method, and program | |
| Liu et al. | A secure shard reconfiguration protocol for sharding blockchains without a randomness | |
| CN116881936A (en) | Trusted computing method and related equipment |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| FZDE | Discontinued |
Effective date: 20201214 |