CN115426125A - Block validity verification method for block chain fragmentation system - Google Patents
Block validity verification method for block chain fragmentation system Download PDFInfo
- Publication number
- CN115426125A CN115426125A CN202210727404.5A CN202210727404A CN115426125A CN 115426125 A CN115426125 A CN 115426125A CN 202210727404 A CN202210727404 A CN 202210727404A CN 115426125 A CN115426125 A CN 115426125A
- Authority
- CN
- China
- Prior art keywords
- block
- verification
- fragment
- transaction
- state
- 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.)
- Pending
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/083—Network architectures or network communication protocols for network security for authentication of entities using passwords
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
-
- 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
-
- 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
- H04L9/3252—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 using DSA or related signature schemes, e.g. elliptic based signatures, ElGamal or Schnorr schemes
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
A block validity verification method for a blockchain sharding system, the blockchain sharding system comprising a plurality of shards, each shard generating a new block based on transaction requirements and reaching consensus within the shard generating verification evidence of the block, the method comprising the steps of: randomly selecting other fragments with 2 times of preset number except the fragment of the block in the block chain fragmentation system to form a verification fragment set; verifying the block by adopting each fragment in the verification fragment set, and broadcasting a verification result to other fragments; and when at least half of the fragments in the fragment verification set verify that the block is valid, judging that the block and the fragment where the block is located are successfully verified.
Description
Technical Field
The invention relates to the field of blockchain, in particular to the technical field of blockchain expansibility research, and more particularly to a block validity verification method for a blockchain fragmentation system, a cross-fragment transaction method based on the blockchain fragmentation system and a fault-tolerant blockchain fragmentation system.
Background
Since the appearance of the blockchain in 2008, the blockchain has received wide attention from the academic and industrial fields due to the characteristics of decentralization, security, non-tampering and the like. Currently, the blockchain technology has been widely applied to various fields, and provides a reliable infrastructure for online payment, supply chain finance and other decentralized applications, but most of the current blockchain practical floor applications are still limited to functional application fields with low performance requirements, such as storage and traceability. For performance type applications, the current performance of the blockchain of tens of transactions/second is difficult to adapt to its requirements. The actual landing of the blockchain technology is severely limited by the excessively low transaction processing performance of the blockchain, the current mainstream blockchain architecture can only process 7-10 transactions per second, and the processing capacity of the blockchain architecture is different from the processing capacity of hundreds of thousands of transactions per second of the traditional centralized application such as payment treasures, weChat and the like by orders of magnitude.
The fragmentation technology is a key technology for improving the transaction processing capability of the block chain, and the throughput level of the block chain is greatly improved by improving the parallelism degree of a system and changing a linear transaction processing mode under a single chain.
In 2016, loi Luu proposed an elasto fragmentation scheme in CCS'16 conference, in which when the system starts to process a new batch of transactions, block link nodes are randomly assigned to the consensus committees of the respective fragments constituting the fragments by a secure random algorithm, and meanwhile, transaction sets are also assigned to different fragments for processing according to prefixes of transaction hashes. And processing transactions among the fragments in parallel and independently generating blocks. And finally, gathering the states of different fragments together by a certain fragment through collecting the blocks generated by each fragment to serve as the initial state of the next round of transaction processing, and starting the next round of system circulation. Because different fragments in the system adopt a parallel processing mode when processing transactions, the processing performance of a block chain can be improved by times, but in the elastic fragmentation scheme, nodes are required to be redistributed after each round of block generation, and finally, all blocks generated in each round need to be converged together again, so that a large amount of time is consumed in the process, and the final transaction processing speed is only 40 strokes/second.
In the omnilink protocol proposed in 2018, the scheme improves the transaction processing throughput of the fragments by optimizing the overall architecture of the blockchain fragments. The Ominilediger protocol optimizes the distribution mode and the rotation mechanism of the nodes in the Elastico, provides an efficient node random algorithm, does not need to rotate again after each block of the nodes in the Elastico, and adopts a cuckoo rule for regularly rotating a small number of nodes. Meanwhile, the Ominilediger realizes state fragmentation, namely the states of all the fragments are completely independent, and the nodes do not need to converge the states of all the fragments again. For the cross-slice transaction, the Ominilediger protocol also provides a cross-slice transaction processing mechanism, and realizes data interaction and transaction settlement among all slices in a cross-slice transaction mode. In order to ensure that the fragment state can be correctly updated among different fragments, the system needs each fragment to ensure the security thereof, so that the proportion of the Byzantine nodes (malicious nodes) of the system global is specified to be less than 1/4, and the Byzantine nodes number of each fragment is ensured to be less than 1/3 (the safety threshold of the Byzantine fault-tolerant consensus algorithm) by maintaining the scale of more than 600 consensus nodes for each fragment, thereby ensuring that the Byzantine consensus algorithm can normally operate among the nodes of each fragment and ensuring that the system state is correct. In the same year, mahdi Zamani proposes a rappidcain protocol, which optimizes a random allocation algorithm of nodes, a transmission mode of cross-chip information, and a consensus mode of fragmentation. The RappidChain protocol introduces synchronous class consensus into a fragmentation algorithm, and reduces the safety threshold of a malicious node in each fragment to 1/2, so that the proportion of global Byzantine nodes can be increased from less than 1/4 to less than 1/3, finally, under the same safety level, the scale of the consensus node can be safely reduced to more than 200, and the overall flux level of the system is increased. 2019. In the year, hung Dang proposes to introduce the TEE into a block chain fragmentation algorithm on the SIGMOD'19 conference, so that the consensus security of a block chain is greatly improved, ambiguous attacks of Byzantine nodes are avoided through a TEE trusted execution environment, the proportion of the tolerable Byzantine nodes of each fragment is increased to 1/2, and the consensus scale of the nodes in the fragment is greatly reduced under the guarantee that the global Byzantine nodes are smaller than 1/4. Both of the above-mentioned methods can tolerate a small number of node errors within a slice.
In addition, the Rongjiaping doctor proposes a monooxide protocol in the NSDI'19 conference, the protocol binds the computing power of different fragments together, and the nodes can simultaneously carry out common recognition on a plurality of fragments to realize the sharing of the computing power by the fragmentation mode, so that the highest computing power of the fragments can be equal to the computing power of the whole network, the computing power required for attacking the single fragments theoretically needs 50% of the computing power of the whole network, and the safety of each fragment is greatly improved. However, such promotion is limited by the actual performance of the node, and in order to achieve the theoretical security guarantee, all the nodes still need to run all the fragmentation consensus protocols, that is, block generation operations are performed on a plurality of fragments at the same time, which brings great burden to the processing performance, storage and communication overhead of the nodes.
In the existing scheme, the general procedure of the block chain fragmentation basically comprises: randomly selecting a certain scale of fragment consensus node from a global node pool through a certain random algorithm; each fragment node in each fragment runs a consensus protocol to process various transaction information received by the fragment; in order to avoid node corruption, the consensus nodes in each sub-slice are periodically updated and exchanged. However, the same problem exists in the existing fragmentation schemes, and the system cannot tolerate the control of any one fragment by a malicious attacker, namely the fragments cannot be fault-tolerant. In the current fragmentation protocol, the security of the system is achieved by ensuring the security of all fragments. Under this assumption, the shards are mutually trusted. For example, for a cross-slice transaction, after processing the front portion of the cross-slice transaction, the source slice generates a tacle tree path certificate in the tacle tree of the block included in the transaction, and sends the transaction and certificate to the destination slice. After receiving the transaction, the destination fragment only checks whether the transaction is contained in a certain block of the source fragment by checking the merkel tree path or the signature information of the transaction, and as long as the transaction exists in the source fragment block, the destination fragment considers that the cross-fragment transaction is valid, and as the preamble of the cross-fragment is correctly executed in the source fragment, the destination fragment executes the subsequent part of the transaction. Therefore, if a fragment is controlled by a malicious attacker, the entire system will be paralyzed. A malicious attacker can maliciously change the local state and generate a large amount of illegal cross-fragment transactions in an untrusted state, so that other fragments update the fragment state wrongly, and the whole system fails. Therefore, the current fragment system must ensure that the number of malicious attackers in all fragments is within a safety interval to ensure the safety of the whole system
However, this security mechanism that is not fault tolerant severely limits the transaction capability of the blockchain system. To avoid fragmentation errors (i.e., control by a malicious attacker), blockchain systems often require that each fragment maintain a large number of consensus nodes. Further, as the number of fragments increases, the size of the fragment consensus node also needs to increase linearly to ensure the security of the system. For example, assuming that each fragment has a probability of being controlled by a malicious attacker of p, with the security of the system (1-p) n The formation is decreased exponentially. In order to ensure the security, only the size of the error probability p can be reduced, and then each fragment needs to maintain a larger number of common identification nodes, so as to ensure that the probability p that each fragment is maliciously controlled is small enough. Taking omniridge as an example, a 10-segment system needs to maintain at least 650 consensus nodes per segment to ensure the overall security of the system. Even if the RapidCHain-like protocol is adopted by adopting a synchronous Byzantine consensus protocol which can tolerate a higher proportion of Byzantine nodes, the consensus node scale of more than 200 must be maintained for each fragment under the scale of 10 fragments, and the node scale is increased along with the increase of the number of the fragmentsThe sexual performance is improved. However, due to the limitation of the byzantine consensus protocol, the consensus efficiency is greatly reduced as the number of the consensus nodes is increased, and the large scale of the consensus nodes means lower transaction processing capacity and extremely high message complexity. In the existing consensus protocol, the scale of hundreds of consensus nodes causes the consensus efficiency to be very slow, at most two or three hundred transactions can be processed every second, and the transaction processing capacity of the fragments is severely limited. Therefore, whether the processing capacity of a single fragment or the fragment parallel scale of the system is limited, the performance level and the expandability of the system are severely limited by the security mechanism of the current fragment scheme.
In summary, the following disadvantages mainly exist in the block chain fragmentation technology in the prior art:
1. although the existing blockchain fragmentation technology can tolerate errors of a small number of nodes in the fragments, the security guarantee of the whole blockchain system still depends on the premise that all fragments are safe, the tolerance of malicious conditions existing in the small number of fragments is lacked, and once a certain fragment has an error, the illegal cross-fragment transaction generated by the certain fragment can cause the whole blockchain system to be paralyzed.
2. In the existing blockchain fragmentation technology, a large number of common identification nodes must be maintained for each fragment to ensure that the fragment cannot make mistakes, but the excessive number of common identification nodes in the fragment can limit the common identification efficiency, the excessive complexity of the message can limit the transaction processing level of the fragment, and the overall flux level of the blockchain fragment is limited.
Disclosure of Invention
Therefore, an object of the present invention is to overcome the above-mentioned drawbacks of the prior art, and to provide a block validity verification method for a blockchain fragmentation system, a cross-fragment transaction method based on the blockchain fragmentation system, and a fault-tolerant blockchain fragmentation system.
According to a first aspect of the present invention, there is provided a method for verifying the validity of a block in a blockchain slicing system, the blockchain slicing system comprising a plurality of slices, each slice generating a new block based on transaction requirements and reaching consensus within the slices to generate verification evidence of the block, the method comprising the steps of: randomly selecting other fragments with 2 times of preset number except the fragment of the block in the block chain fragmentation system to form a verification fragment set; verifying the block by adopting each fragment in the verification fragment set, and broadcasting the verification result to other fragments; and when at least half of the fragments in the fragment set are verified to verify that the block is valid, judging that the block and the fragment where the block is located are verified successfully.
In some embodiments of the present invention, each slice in the verification slice set verifies the to-be-verified block as follows: acquiring a block to be verified and a verification evidence thereof, and verifying the validity of the state of the block; after the validity of the block state passes the verification, executing transaction information on the block, updating the block state, and judging whether an error is reported in the transaction execution; when the transaction execution is not wrong, verifying whether the updated block state of the block is consistent with the state information recorded by the block; and when the three items of verification contents pass, the block to be verified is considered to be verified to be effective, otherwise, the block to be verified is considered to be wrong, and the result of verification or mistake is broadcasted to all the fragments in the block chain fragmentation system.
Preferably, the block verification evidence is generated as follows: in response to a transaction demand, generating a new block in a slicing mode; the method comprises the steps that account state information related to a transaction process is executed by a fragment collection block, and a block verification evidence is generated through a locally maintained account state tree; the fragmentation agrees on the generated block and block validation evidence.
Preferably, the preset number is a number within a range of the number of fragments in the blockchain fragment system, where the preset number is greater than or equal to 1 and less than or equal to the number of fragments in the blockchain fragment system, and the preset number is used to indicate a maximum number of malicious fragments that can be tolerated by the blockchain fragment system.
In some embodiments of the present invention, the blocks are divided into blocks in a ready state, blocks in a pre-commit state, and blocks in a commit state according to whether verification is performed or not and a verification result, wherein the blocks in the ready state refer to blocks newly generated by fragmentation, and only achieve consensus within the fragments and are not verified by other fragments; the block in the pre-commit state is a block in a ready state that passes validity verification; the committed state block is a pre-committed state block in which the preceding blocks are all committed states.
According to a second aspect of the present invention, there is provided a cross-slice transaction method based on a blockchain fragmentation system, for executing a cross-slice transaction initiated by a source fragmentation block to a destination fragmentation, the method including: s1, generating a new block and a block verification certificate corresponding to cross-chip transaction sent to a target fragment by a source fragment; s2, verifying the validity of the block in the step S1 by adopting the method of the first aspect of the invention to obtain the state of the block; s3, verifying whether the verification evidence of the block which enters the submission state and is successfully verified in the step S2 is consistent with the information corresponding to the transaction root of the block, if so, executing the cross-chip transaction initiated by the block, and if not, terminating the transaction; and S4, initiating a rotation mechanism for the blocks which are verified to be invalid in the step S2, wherein the rotation mechanism comprises the steps of rotating the fragments where the blocks are located and the fragments containing the subsequent cross-fragment transactions of the blocks out, returning each fragment in the fragment system to a state of passing the verification last time, and regenerating a new verification fragment set to re-verify the blocks which are verified to be invalid until the blocks are verified to be successful so as to re-execute the transactions.
In some embodiments of the invention, the rotation mechanism refers to: both the intra-chip transaction and the cross-chip transaction of the rotated outgoing segment are suspended and the right of the rotated outgoing segment as the verification segment of other segments is cancelled until the verification segment is verified again successfully.
According to a third aspect of the present invention, a fault-tolerant blockchain fragmentation system is provided, where the blockchain fragmentation system includes a plurality of fragments, each fragment generating a new blocky based on transaction requirements and reaching consensus within the fragments to generate proof of verification of the blocky, and the blockchain fragmentation system performs a fragmented cross-fragment transaction using the method as described in the second aspect of the present invention.
Compared with the prior art, the invention has the advantages that:
1. the fault-tolerant mechanism of the block chain fragmentation is realized by performing cross validation based on the state between the fragments, so that the block chain fragmentation system can still work normally under the condition that a small amount of fragments are in error.
2. The scale of the fragmentation consensus node is reduced through a fragmentation fault-tolerant mechanism, the fragmentation performance is improved, the system parallelism degree is improved, and the overall flux level of the block chain system is improved from multiple dimensions.
Drawings
Embodiments of the invention are further described below with reference to the accompanying drawings, in which:
fig. 1 is a schematic diagram of a blockchain fault-tolerant sharding mechanism according to an embodiment of the present invention;
fig. 2 is a schematic flow chart of a cross-chip transaction method based on a blockchain fragmentation system according to an embodiment of the present invention;
FIG. 3 is a flowchart illustrating an exemplary block and block verification evidence generation process in tile A according to an embodiment of the invention;
fig. 4 is a flowchart illustrating a verification process of the example shard B with respect to the chunks generated by the example shard a according to an embodiment of the present invention;
FIG. 5 is a flowchart illustrating a cross-slice transaction process in which an example slice A generates blocks and sends the blocks to an example slice D, according to an embodiment of the present invention.
Detailed Description
In order to make the objects, technical solutions and advantages of the present invention more apparent, the present invention is further described in detail by the following embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and do not limit the invention.
For better understanding of the present invention, the technical idea of the present invention is described below.
Since the related knowledge involved in the blockchain is a known technology, the invention only briefly explains the content involved in implementing blockchain fragmentation. As mentioned in the background art, the security guarantee of the existing blockchain fragmentation technology depends heavily on the premise that all fragments are safe, the tolerance of a small number of fragments to malicious conditions is lacked, and once a certain fragment is in error, the illegal cross-fragment transaction generated by the certain fragment can cause the whole blockchain system to be paralyzed. Meanwhile, in the existing block chain fragmentation technology, each fragment must maintain a large number of common identification nodes to ensure that the fragment cannot make mistakes, but the excessive number of common identification nodes in the fragment can limit the common identification efficiency, especially can limit the transaction processing level of the fragment when the message complexity is too high, and is mainly reflected in limiting the overall flux level of the block chain fragment, so that the transaction processing performance of the whole block chain fragmentation system is low. Based on this, the invention provides a stateless verification scheme based on a block, and by means of designating a plurality of verification fragments for verification of each fragment to judge the validity of the verification fragments, the invention realizes that any fragment can check whether the state conversion of a specific block of the fragment is correct or not and whether the state conversion of the specific block of the fragment meets set rules or not under the condition of no state data of other fragments, and identifies malicious fragments and limits the transaction capability of the malicious fragments and the capability of verifying other fragments by means of consensus voting among the fragments of a block chain, so that the influence of a small number of malicious fragments on the block verification result on the whole system is eliminated, thereby forming a cross verification mechanism of the state among the fragments, and realizing the discovery of error fragments and the fault tolerance of the system on the small number of malicious fragments. In addition, the invention also provides verification traceability of the whole block chain fragmentation system and distributed verification of call relations among all the fragments based on the dependency relations among the blocks, a real-time effective state set of the fragments in the whole system is obtained by gathering the verification results of all the fragments and the dependency relations among the blocks so as to realize correct update of the system state, and system errors are controlled in a small number of error fragments so as to realize control of the error states.
The present invention will be described in detail below with reference to the accompanying drawings and examples.
The related terms and symbol definitions in the blockchain slicing technique involved in the present invention are described below.
1. Account
The account status is as follows: i.e. the status information of the subscriber, contains basic information such as balance, sent transaction etc.
Account private key: a256-bit (32-byte) string is generated from the secp256k1 curve.
Account public key: and the account private key is mapped by an Elliptic Curve Digital Signature Algorithm (ECDSA) to obtain a 512-bit (64-byte) character string.
Account address: the account public key is used for indexing each account and identifying the account in a transaction by the last 160 bits (20 bytes) of the hash value obtained by the Keccak-256 algorithm, wherein the first 2 bits are used for identifying the affiliated fragmentation information.
2. Affairs
Transaction: namely, the transaction, namely the operation of account state transition in the present architecture, includes fields such as source address, destination address, transfer amount, transaction sequence number, etc., wherein:
source address/destination address: i.e., sender and receiver account addresses.
Source fragmentation/destination fragmentation: i.e. the fragment where the sender and the receiver are located, can be calculated from the source address/destination address, if the source fragment is different from the destination fragment, the transaction is a cross-fragment transaction, and in the present invention, the cross-fragment transaction execution adopts a two-phase protocol, i.e. the cross-fragment transaction is executed first on the source fragment (referred to as a pre-sequence transaction) and then on the destination fragment (referred to as a post-sequence transaction).
Transferring amount: the amount of funds transferred from the source address to the destination address.
Transaction number: the next transaction initiated by the source address.
And (3) transaction certification: the default is null, and the null is filled by the out-block node, and is used for proving that the preamble transaction of the cross-slice transaction is completely executed in the source-slice destination block, and the method comprises the following steps: source fragmentation block hashing; the Merckel tree proof of the transaction, i.e. the computation path of the Merckel tree, is used to prove that the block contains the preceding transaction of the transaction.
3. Block
Block head: i.e., abbreviated index information of the block, including: the last block hash, namely the hash value of one block on the current fragment; block heightI.e. the first block of the slice, for indexing the blocks; the transaction root is the root node hash value of the Mercker tree formed by the transaction set contained in the block; state root, namely the hash of the root node of the Mercker tree formed by the latest state after the block is executed; the hash value of the block is used to index the block; block verification evidence hash, namely a hash value of the block verification evidence; dependent blocks refer to source blocks corresponding to cross-slice transactions, which may comprise a collection of blocks, such as a transaction Tx A Refers to the transfer from the B slice to the a slice,
(Block in B-slice) Packed transaction Tx A In the preamble of (a) to (b),
(blocks in A slice) performing transaction Tx A A subsequent part of, then
Is contained in
In the dependent block of (1); dependent chunk hash values, which refer to which chunks the cross-slice transactions of the subsequent stage executed in the current slice come from; and others.
And (3) transaction collection: that is, all transactions executed in the local chunk, including the on-chip transaction of the local chunk and the cross-chip transactions of other chunks, for the cross-chip transactions of the subsequent stage of execution, the node will be recorded in the dependent chunk hash value in the chunk header.
4. Proof of block verification
Block hashing: the block verification evidence corresponds to a block hash of the block.
Account status: i.e., account status information that is read or modified during block execution.
And (3) state certification: the method is used for verifying whether the account status is correct, and may be, but is not limited to, using a method such as a default tree path, and verifying by using a status root in a block header.
The symbol definitions related to the relevant examples in the embodiments of the present invention are shown in table 1, where table 1 shows relevant definitions of example shard a, and other shards refer to example shard a.
TABLE 1
The following describes a mechanism for discovering the error status of the slice in the blockchain slicing system according to the present invention. In the initial stage of a block chain fragmentation system and the process of verifying fragment set rotation, the system randomly generates a globally uniform seed of the system by using a fragment random number generation algorithm, the system randomly generates a verification relation between fragments in the current round based on the seed, and each fragment randomly selects the rest 2 times f shard The number of the fragments is used as a verification fragment set, and each verification fragment verifies all blocks generated by the fragment to be verified in the current round. For example, if a slice randomly selects B slice as verification slice in the tth round, then a slice generates every block in the tth round
All the information needs to be sent to the B fragment, the common identification node in the B fragment carries out verification and broadcasts the result to the whole system, and the signature is used for proving the validity of the information. Because each fragment only stores the state information of the fragment and does not store the state information of other fragments, the invention provides a stateless block verification algorithm for block verification, the verification fragment can verify whether the state conversion of the block is correct and the verification algorithm which accords with the relevant conversion rule without knowing the state information of the fragment to be verified, namely, the verification fragment can verify the block state
Whether or not it is in state
Performed on a basis of
The correct state is obtained by state transition. In the stateless block verification algorithm described above, the block verification proof
The specific contained information is flexibly designed and determined according to different verification algorithms and actual requirements, and the verification algorithms of the evidence in the invention include but are not limited to a Merckel tree verification algorithm, a state tree subtree verification algorithm, a zero knowledge proof verification algorithm and a related state verification algorithm based on a cryptology mechanism.
Verifying the to-be-verified block by verifying the fragments in the fragment set according to the following modes: obtaining the block to be verified and its verification evidence, verifying the validity of the block state, i.e. verifying
Whether it is from the last block
After execution of the state information, i.e.
After the validity of the block state is verified, transaction information is executed on the block and the block state is updated, namely, the block state is in a minimum state
Lower execution
Transaction message in (1)Information processing device
And updated according to the same rule
Namely that
And judging whether the transaction execution is error; when the transaction execution is not error-reported, it is verified whether the updated block status of the block is consistent with the status information recorded in the block, that is, whether the updated block status is consistent with the status information recorded in the block itself
And when all the three items of verification contents pass, the block to be verified is considered to be verified to be valid, otherwise, the block to be verified is considered to be in error, and the result of valid verification or error is broadcast to all the fragments in the block chain fragmentation system. The minimum state refers to a state set related to (modifying query) the block during block execution, and does not include a state unrelated to block execution. In addition, since the slice of the default generated block must be approved, even if only f is available shar The successful verification of a slice, plus the slice that generated the block, is equivalent to 2f shar In +1 slices there is f shar +1 approved blocks are majority, so when a block is f except itself shard When a fragment is verified as valid, the fragment is considered to be successfully verified, and when a fragment block is verified by f except for the fragment block, f shard When +1 piece verifies and fails, the piece is considered to be verified and failed.
The following describes the mechanism for managing and recovering the error status of the partition in the blockchain partitioning system according to the present invention. The above-mentioned mechanism for finding the error state of the blockchain fragment verifies whether the block state conversion is correct and meets the conversion rule and whether the updated block state is the state recorded in the root block, but since the pre-block does not participate in the verification, the minimum state of the block cannot be guaranteedIs correct, and thus the verification result is actually established on the premise that the previous block of the block to be verified is correct, when cross-chip transactions are involved, for example
When the C segment in (1) initiates cross-segment transaction to the A segment, the cross-segment transaction is actually initiated
And
there is a certain dependency relationship between them, and the method of the present invention is essentially assumed to be
And
if correct, verify
The correctness of the data. In summary, the present invention constructs the dependency relationship between the blocks as a dependency relationship network, and provides a method for managing the block state to manage and control the error state area of the block chain fragments according to the dependency relationship.
According to an embodiment of the present invention, the blocks in the blockchain sharding system of the present invention are divided into blocks in a ready state (prepare state), blocks in a pre-commit state (pre-commit state), and blocks in a commit state (commit state) according to whether verification is performed or not and the verification result, wherein: the block in the preparation state refers to a block newly generated by slicing, and only achieves consensus in the slice and is not verified by other slices; the pre-committed block is a ready block that passes validity verification, i.e., a ready block is successfully completed shard The verification of each fragment is successful, namely the state conversion of each fragment is proved to be correct; the block in the commit status refers to a pre-commit status in which the preceding blocks are all in the commit statusA block in a state, i.e. a block in a pre-commit state, whose preceding blocks have all entered the commit state, can enter the commit state, at which point the state information in the block is proven to be correct and trusted. It should be noted that, in the field of blockchain, it is specified that the first block (created block) in each slice is trusted all over the network, and it is directly the commit status. For cross-slice transaction, normal slices can only execute cross-slice transaction sent from the chunk under the commit state, and for cross-slice transaction sent from other states, the cross-slice transaction can only be executed until the source chunk enters the commit state. For example, in a block chain fragmentation example as shown in fig. 1, A1 chunk in a fragment a is verified to be faulty, then the A1 chunk never enters the pre-commit state, even if A2 and A3 chunks are both verified by the rest of fragments and enter the pre-commit state, but they cannot enter the commit state due to the limitation of A1, and the cross-fragment transaction contained therein is not executed by the other fragments, so the faulty area can be controlled within the fragment a, and the fault will not spread to other fragments.
When a block fails to be verified, f in the verification fragment set shard The +1 verification fragments broadcast the error information of the to-be-verified block in the whole block chain system, and the block chain fragmentation system triggers a fragmentation consensus node rotation mechanism, which comprises the following steps: and (3) the partition where the block is located and the partitions containing the subsequent cross-partition transaction are all alternately outgoing, each partition in the partition system is returned to the state of passing the verification last time, and a new verification partition set is regenerated to re-verify the block which fails in verification until the verification is successful so as to re-execute the transaction. The rotation mechanism refers to: and both the on-chip transaction and the cross-chip transaction of the rotated outgoing fragments are stopped and the right of the rotated outgoing fragments as the verification fragments of other fragments is cancelled until the verification fragments are successfully re-verified, and finally, the transaction rollback and the error recovery are completed to ensure the normal operation of the system.
Based on fault-tolerant blockchain sharding system, as shown in fig. 2, cross-sharding transaction includes: s1, generating a new block and a block verification evidence corresponding to cross-piece transaction sent to a target piece by a source piece; s2, verifying the validity of the block in the step S1 by adopting the method to obtain the state of the block; s3, verifying whether the verification evidence of the block which enters the submission state and is successfully verified in the step S2 is consistent with the information corresponding to the transaction root of the block, if so, executing the cross-chip transaction initiated by the block, and if not, terminating the transaction; and S4, initiating a switching mechanism for the blocks which fail to be verified in the step S2.
For a better understanding of the mechanism of operation of the fault-tolerant blockchain fragmentation system, the present invention is described below in conjunction with specific figures and examples. Assuming that the fault-tolerant blockchain fragmentation system includes four fragments (fragment a, fragment B, fragment C, fragment D), a specific workflow of the fragmentation system will be described by taking a scenario in which the system performs a transaction as an example.
As shown in fig. 3, the generation process of the block verification evidence of the partition a includes:
step A1, slicing A to generate new blocks
And generating a proof of verification for the block.
Step A1.1, slice A counts and collects account status information involved in the execution of the block, and the original status before the execution (i.e. the original status before the execution of the block is collected)
) Added to the block verification proof for that block.
Step A1.2, taking the Mercker tree verification path as an example, segment A will generate a block by relying on the account state tree maintained locally
A status proof of the account status.
Step A1.3, the leader of the fragment A writes the hash of the verification evidence of the block into the block, and the block is subjected to verification
A consensus was reached.
As shown in fig. 4, the verification process of the partition B for the partition generated by the partition a includes:
step B1, slicing A to generate new blocks
And generating a proof of verification for the block.
Step B1.1, the leader of the fragment A writes the hash of the verification evidence of the block into the block, and the block is subjected to verification
A consensus was reached.
Step B1.2, partition A blocks
And its proof of verification is sent to fragment B.
Step B2, receiving the block by the fragment B
After verifying the proof, determining whether the hash of the proof matches the block
The block verification evidence in the block header is consistent in hash, and if the block verification evidence is inconsistent in hash, the fragment A is required to resend the block verification evidence.
Step B2.1, judging the block
Whether the signature information accords with the on-chip consensus rule or not and whether the consensus is achieved in the fragment A or not, and if the verification fails, the fragment A is required to retransmit the block information.
Step B2.2, judging the block
In the middle block head, the last block (i.e., the
) Whether the hash value of the block hash, the block height, the transaction root and the local block is correct or not is verified, and if the hash value is verified to be invalid, the block is broadcasted all over the network
An error message.
Step B2.3, the segment B adds the account state in the block verification evidence in the local memory and verifies whether the block verification evidence is consistent with the account state according to the state certificate
The middle state root corresponds to, namely whether the Merck tree root constructed according to the state verification evidence and the account state corresponds to
The account is the root of the mercker tree before the transaction is executed. If the verification fails, the whole network broadcasts the block
An error message.
Step B2.4, the fragment B executes in the local memory based on the same transaction processing principle and sequence
And the transaction set verifies whether error information or a state missing condition exists in the transaction execution, and updates the account state information of the segment A in the memory according to the execution result. If there is an erroneous execution, the block is broadcast over the entire network
An error message.
Step B2.5, the fragment B verifies whether the Merkel tree root constructed by the fragment B is in contact with the account state of the fragment A according to the state certificate and the updated account state of the fragment A
The middle state root is consistent, namely whether the two are in the same account state after the transaction is executed is verified, if the two are not consistent, the whole network broadcasting block is judged
An error message.
Step B3, the verification block of the B slice is divided
If successful, broadcast the block to the whole network
A positive message.
Fig. 5 shows a cross-slice transaction working process in which a slice a generates a block and sends the block to a slice D, wherein a slice B and a slice C are used as verification slices to verify the block generated by the slice a, and the working process includes;
step C1, slicing A to generate new blocks
And generating a proof of verification for the block.
Step C1.1, partition A pair of blocks
And the block verification evidence is consensus, block
A ready state is entered.
Step C1.2, partition A pair of blocks
And sending the block verification evidence to the fragments B and C for verification.
Step C1.3, partition A blocks
Cross-slice transaction Tx of the preamble stage of intermediate execution A The Merck tree for the transaction of the root block generates a transaction certificate (Merck tree verification path), writes it in the transaction field, and sends Tx A To slice D.
Step C2, receiving the block by the fragment B/the fragment C
After the certification, verification is carried out, and if the verification is passed, the broadcast is carried out to the whole network
Verify correct information otherwise broadcast
Verifying the error information.
Step C3, the fragment D receives the fragment B or the fragment C
Verification information, if one of the verifications is correct, then step C3.1 is entered, otherwise both verifications are wrong, then the transaction Tx is discarded A The transaction execution flow ends and the system proceeds to step C4.
Step C3.1, block
Enter a pre-commit state and wait for its dependent blocks and
the blocks all enter the commit state, if they depend on the blocks to enter the commit state, step C3.2 is performed, if the pre-state thereof is in error, transaction Tx is discarded A The transaction execution flow ends and the system proceeds to step C4.
Step C3.2, validate Tx A Whether the related transaction certification information is related to
The transaction root (i.e. the transaction root) in (1) is consistent, if consistent, the related transaction is executedAnd agreeing, otherwise discarding the transaction Tx A And the transaction execution is finished.
And step C4, the block chain fragmentation system initiates a rotation mechanism, common identification node replacement is carried out on the fragments to which the error blocks belong, and error state rollback is carried out.
Through the steps of the above embodiment, it can be seen that the present invention achieves the purpose of adding a fault-tolerant mechanism to the blockchain fragmentation system, and in order to better illustrate the effect of the present invention, the following description is made for comparing the performance of the blockchain fragmentation system before and after adding the fault-tolerant mechanism. Assuming that each fragment can tolerate 1/3 of the number of malicious attackers, the ratio of the malicious attackers in the global environment is 1/4, m represents the scale of the consensus node in each fragment, and n represents the number of fragments, the probability that a certain fragment is in error (controlled by a malicious attacker) is:
the error probability of the whole system before fault tolerance is as follows:
P system ＝1-(1-P shar ) n ≈nP shard
the error probability of the whole system after fault tolerance is as follows:
under the same parameter condition, the error probability of the whole system is obviously reduced compared with that before fault tolerance. Under the same security level, the interior of the fault-tolerant shards can be further relaxed, so that fewer shards can be adopted to know the node size m, which also means that the system has a higher transaction processing level. In summary, the fault-tolerant mechanism of the fragmentation can effectively reduce the requirement of the fragmentation on the scale of the common node to improve the transaction processing capability of the fragmentation, and the specific effect is as shown in table 2, and the transaction processing capability of each fragmentation can be effectively improved by at least 1-2 times by tolerating a small number of fragmentation errors.
TABLE 2
Compared with the prior art, the invention has the advantages that:
1. the fault-tolerant mechanism of the block chain fragmentation is realized by performing cross validation based on the state between the fragments, so that the block chain fragmentation system can still work normally under the condition that a small amount of fragments are in error.
2. The scale of the sharding consensus node is reduced through a shareable fault-tolerant mechanism, the sharding performance is improved, the system parallelism degree is improved, and the overall flux level of the block chain system is improved from multiple dimensions.
It should be noted that, although the steps are described in a specific order, it is not meant that the steps must be executed in the specific order, and in fact, some of the steps may be executed concurrently or even in a different order as long as the required functions are achieved.
The present invention may be a system, method and/or computer program product. The computer program product may include a computer-readable storage medium having computer-readable program instructions embodied therewith for causing a processor to implement various aspects of the present invention.
The computer readable storage medium may be a tangible device that holds and stores the instructions for use by the instruction execution device. The computer readable storage medium may include, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of the computer readable storage medium would include the following: a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a Static Random Access Memory (SRAM), a portable compact disc read-only memory (CD-ROM), a Digital Versatile Disc (DVD), a memory stick, a floppy disk, a mechanical coding device, such as a punch card or an in-groove raised structure having instructions stored thereon, and any suitable combination of the foregoing.
Having described embodiments of the present invention, the foregoing description is intended to be exemplary, not exhaustive, and not limited to the embodiments disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is chosen in order to best explain the principles of the embodiments, the practical application, or improvements made to the technology in the marketplace, or to enable others of ordinary skill in the art to understand the embodiments disclosed herein.
Claims (11)
1. A block validity verification method for a blockchain fragmentation system, wherein the blockchain fragmentation system comprises a plurality of fragments, each fragment generates a new block based on transaction requirements and reaches consensus within the fragments to generate verification evidence of the block, and the method is characterized by comprising the following steps:
randomly selecting other fragments with 2 times of preset number except the fragment of the block in the block chain fragmentation system to form a verification fragment set;
verifying the block by adopting each fragment in the verification fragment set, and broadcasting a verification result to other fragments;
and when at least half of the fragments in the fragment set are verified to verify that the block is valid, judging that the block and the fragment where the block is located are verified successfully.
2. The method of claim 1, wherein each tile in the set of authentication tiles authenticates the block to be authenticated as follows:
acquiring a block to be verified and a verification evidence thereof, and verifying the validity of the state of the block;
after the validity of the block state passes the verification, executing transaction information on the block, updating the block state, and judging whether an error is reported in the transaction execution;
when the transaction execution is not wrong, verifying whether the updated block state of the block is consistent with the state information recorded by the block;
and when all the three items of verification contents pass, the block to be verified is considered to be verified to be effective, otherwise, the block to be verified is considered to be wrong, and the result of the verification or the error is broadcast to all the fragments in the block chain fragmentation system.
3. The method of claim 2, wherein the block verification proof is generated as follows:
responding to the transaction requirement, and generating a new block in a slicing mode;
the method comprises the steps that account state information related to a transaction process executed by a block is collected in a slicing mode, and a block verification evidence is generated through a locally maintained account state tree;
the sharding agrees with the generated chunk and the chunk verification evidence.
4. The method according to claim 1, wherein the preset number is a number within a range from 1 or more to less than or equal to the number of slices in the blockchain slice system, and the preset number is used to indicate a maximum number of malicious slices tolerable for the blockchain slice system.
5. The method of claim 1, wherein the blocks are divided into blocks in ready state, blocks in pre-commit state, and blocks in commit state according to whether verification is performed or not and the verification result, wherein the blocks in ready state refer to the blocks newly generated by fragmentation, and only achieve consensus within the fragments and are not verified by other fragments; the block in the pre-commit state is a block in a ready state that passes validity verification; the committed state block is a pre-committed state block in which the preceding blocks are all committed.
6. A cross-slice transaction method based on a blockchain slicing system is used for executing cross-slice transaction initiated by a source slicing block to a destination slicing, and is characterized in that the method comprises the following steps:
s1, generating a new block and a block verification evidence corresponding to a cross-chip transaction sent to a target chip by a source chip;
s2, verifying the validity of the block in the step S1 by adopting the method according to any one of claims 1-5 to obtain the state of the block;
and S3, verifying whether the verification evidence of the block which enters the submission state and is successfully verified in the step S2 is consistent with the information corresponding to the transaction root, if so, executing the cross-chip transaction initiated by the block, and if not, terminating the transaction.
7. The method of claim 6, further comprising:
and S4, initiating a rotation mechanism for the block failed in verification in the step S2, wherein the rotation mechanism comprises that the fragment where the block is located and the fragments containing subsequent cross-fragment transactions of the block are all rotated to be out, returning each fragment in the fragment system to a state of passing the verification at the last time, and simultaneously regenerating a new verification fragment set to re-verify the block failed in verification until the block is successfully verified so as to re-execute the transactions.
8. The method of claim 7, wherein the rotation mechanism is: both the intra-slice transaction and the cross-slice transaction of the rotated out-going slice are aborted and cancelled as the authentication slices of other slices until they are successfully re-authenticated.
9. A fault-tolerant blockchain sharding system, the blockchain sharding system comprising a plurality of shards, each shard generating a new blockwhich is based on transaction requirements and achieving consensus within the shards to generate proof of verification of the blockwhich is characterized in that the blockchain sharding system adopts the method of claims 6-8 to perform sharded cross-sharding transactions.
10. A computer-readable storage medium, having stored thereon a computer program executable by a processor to perform the steps of the method of any one of claims 1-5 or 6-8.
11. An electronic device, comprising:
one or more processors;
storage means for storing one or more programs which, when executed by the one or more processors, cause the electronic device to carry out the steps of the method of any of claims 1-5 or 6-8.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210106322 | 2022-01-28 | ||
| CN2022101063229 | 2022-01-28 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN115426125A true CN115426125A (en) | 2022-12-02 |
Family
ID=84196639
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202210727404.5A Pending CN115426125A (en) | 2022-01-28 | 2022-06-24 | Block validity verification method for block chain fragmentation system |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN115426125A (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN116055064A (en) * | 2023-03-17 | 2023-05-02 | 安徽中科晶格技术有限公司 | Method, system, medium and equipment for multi-block simultaneous consensus in block chain segmentation |
-
2022
- 2022-06-24 CN CN202210727404.5A patent/CN115426125A/en active Pending
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN116055064A (en) * | 2023-03-17 | 2023-05-02 | 安徽中科晶格技术有限公司 | Method, system, medium and equipment for multi-block simultaneous consensus in block chain segmentation |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11791982B2 (en) | Concurrent transaction processing in a high performance distributed system of record | |
| US11736586B2 (en) | High performance distributed system of record | |
| CN111736963B (en) | Transaction processing system and method for backbone-free multi-partition block chain | |
| US11283634B2 (en) | System and method for detecting replay attack | |
| US10681083B2 (en) | System and method for detecting replay attack | |
| CN112041872A (en) | Maintaining blocks of a blockchain in a partitioned blockchain network | |
| US11687522B2 (en) | High performance distributed system of record with delegated transaction signing | |
| US11323475B2 (en) | System and method for detecting replay attack | |
| US10735464B2 (en) | System and method for detecting replay attack | |
| US20200167779A1 (en) | High performance distributed system of record with confidence-based consensus | |
| CN113826355A (en) | Short transaction identifier collision detection and coordination | |
| CN113064764B (en) | Method and apparatus for executing blocks in a blockchain system | |
| Sohrabi et al. | ZyConChain: A scalable blockchain for general applications | |
| WO2021070106A1 (en) | Methods and devices for secure symbiotic mining | |
| CN115426125A (en) | Block validity verification method for block chain fragmentation system | |
| Li et al. | ISCP: An Improved Blockchain Consensus Protocol. | |
| CN113157450A (en) | Method and apparatus for performing blocks in a blockchain system | |
| US11720453B2 (en) | High performance distributed system of record with unspent transaction output (UTXO) database snapshot integrity | |
| US20220237594A1 (en) | High performance distributed system of record with wallet services resiliency | |
| TWI836988B (en) | Computer-implemented method, system, and computer-readable storage medium for maintaining blocks of a blockchain in a partitioned blockchain network | |
| Nikolaou et al. | Moving participants turtle consensus | |
| Ramsay | IoT. money: Proposing Triangle Sharded Blockchain, for Realtime Global Scalability | |
| CN113807847A (en) | Trusted block chain fragmentation performance optimization method | |
| Lane | Scaling Byzantine Replication to Wide-area Networks |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |