Block synchronization method and apparatus, and blockchain system

Abstract

The specification provides a block synchronization method and device and a blockchain system, applied to a first node in a blockchain network. The method comprises: obtaining block synchronization data from a second node in the blockchain network, wherein the block synchronization data comprises a first block and a key in a read-write set corresponding to a transaction included in the first block; reading a corresponding value from a local database according to the key in the read-write set; executing a transaction in the first block according to the pre-read value, and writing a generated first block into the local database according to an execution result.

Description

Technical Field

[0001] The embodiments in this specification belong to the field of blockchain technology, and in particular relate to a block synchronization method, device and blockchain system. Background Technology

[0002] Blockchain is a novel application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and cryptographic algorithms. In a blockchain network, data blocks are sequentially linked together in a chain-like data structure, and a distributed ledger is cryptographically guaranteed to be immutable and unforgeable. Due to its decentralized, immutable, and autonomous characteristics, blockchain is receiving increasing attention and application.

[0003] In related technologies, during block synchronization, nodes need to obtain the read-write sets corresponding to the blocks and block transactions, and execute the corresponding blocks based on the read-write sets to achieve block synchronization. However, the above process requires transmitting the complete read-write sets and storing them in a local database. Due to the large amount of data in the read-write sets, the consensus and storage costs are high, and the efficiency of block synchronization is not high. Summary of the Invention

[0004] The purpose of this specification is to provide a block synchronization method, apparatus, and blockchain system.

[0005] According to a first aspect of one or more embodiments of this specification, a block synchronization method is proposed, applied to a first node in a blockchain network, the method comprising:

[0006] Obtain block synchronization data from the second node in the blockchain network. The block synchronization data includes first block information and keys in the read / write set corresponding to the transactions contained in the first block.

[0007] Read the corresponding value from the local database according to the key in the read / write set;

[0008] The transactions in the first block are executed based on the pre-read values, and the generated first block is written to the local database based on the execution results.

[0009] According to a second aspect of one or more embodiments of this specification, a block synchronization method is proposed, applied to a second node in a blockchain network, the method comprising:

[0010] Generate block synchronization data, which includes the first block information pre-stored by the second node and the keys in the read / write set corresponding to the transactions contained in the first block;

[0011] The generated block synchronization data is sent to the first node in the blockchain network, so that the first node: reads the corresponding value from the local database according to the key contained in the read-write set information, executes the transaction in the first block according to the pre-read value, and writes the generated first block into the local database according to the execution result.

[0012] According to a third aspect of one or more embodiments of this specification, a blockchain system is proposed, comprising a first node and a second node, wherein:

[0013] The second node is used to generate block synchronization data and send the generated block synchronization data to the first node. The block synchronization data includes the first block information pre-stored by the second node and the keys in the read / write set corresponding to the transactions contained in the first block.

[0014] The first node is used to read the corresponding value from the local database according to the key in the read-write set when it obtains the block synchronization data from the second node; execute the transaction in the first block according to the pre-read value; and write the generated first block into the local database according to the execution result.

[0015] According to a fourth aspect of one or more embodiments of this specification, a block synchronization device is provided for use in a first node of a blockchain network, the device comprising:

[0016] Acquisition Unit: Acquires block synchronization data from the second node in the blockchain network, wherein the block synchronization data includes the first block and the keys in the read / write set corresponding to the transactions contained in the first block;

[0017] Reading unit: Reads the corresponding value from the local database according to the key in the read / write set;

[0018] Execution unit: Executes the transactions in the first block according to the pre-read values, and writes the generated first block to the local database according to the execution results.

[0019] According to a fifth aspect of one or more embodiments of this specification, a block synchronization device is provided for use as a second node in a blockchain network, the device comprising:

[0020] Generation unit: Generates block synchronization data, which includes the first block information pre-stored by the second node and the keys in the read / write set corresponding to the transactions contained in the first block;

[0021] Sending unit: sends the generated block synchronization data to the first node in the blockchain network, so that the first node: reads the corresponding value from the local database according to the key contained in the read-write set information, executes the transaction in the first block according to the pre-read value, and writes the generated first block into the local database according to the execution result.

[0022] According to a sixth aspect of one or more embodiments of this specification, an electronic device is provided, comprising:

[0023] processor;

[0024] Memory used to store processor-executable instructions;

[0025] The processor implements the method as described in any one of the first and second aspects by executing the executable instructions.

[0026] According to a seventh aspect of one or more embodiments of this specification, a computer-readable storage medium is provided that stores computer instructions thereon, which, when executed by a processor, implement the steps of the method as described in any one of the first and second aspects.

[0027] In the embodiments of this specification, on the one hand, during block synchronization, the block synchronization data only includes the keys in the read / write sets corresponding to the transactions contained in the block, and does not include the values ​​in the read / write sets. This reduces the amount of data synchronized, and allows the first and second nodes to store only the data corresponding to the keys, without storing the data corresponding to the values, thereby reducing storage costs and consensus costs. On the other hand, by reading the corresponding values ​​from the local database based on the keys in the read / write sets before executing a transaction, the transaction can be executed directly based on the pre-read values ​​without temporary reading, improving the efficiency of transaction execution and thus improving the efficiency of block synchronization. Attached Figure Description

[0028] To more clearly illustrate the technical solutions of the embodiments in this specification, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0029] Figure 1 This is a schematic diagram of a blockchain system provided in an exemplary embodiment.

[0030] Figure 2 This is a flowchart of a block synchronization method provided in an exemplary embodiment.

[0031] Figure 3This is a schematic diagram of the structure of any two nodes in a blockchain system provided as an exemplary embodiment.

[0032] Figure 4 This is a flowchart of a method for obtaining block synchronization data provided in an exemplary embodiment.

[0033] Figure 5 This is a flowchart of another block synchronization method provided in an exemplary embodiment.

[0034] Figure 6 This is a schematic diagram of another blockchain system provided in an exemplary embodiment.

[0035] Figure 7 This is a schematic diagram of the structure of a device provided in an exemplary embodiment.

[0036] Figure 8 This is a block diagram of a block synchronization device provided in an exemplary embodiment.

[0037] Figure 9 This is a block diagram of another block synchronization device provided in an exemplary embodiment. Detailed Implementation

[0038] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.

[0039] Figure 1 This is a schematic diagram of a blockchain system provided in an exemplary embodiment. For example... Figure 1As shown, a blockchain system is a distributed network built from multiple nodes. It involves peer-to-peer (P2P) communication between any two nodes at the application layer. For example, any two nodes from n1 to n5 can communicate at the application layer via a P2P network. The blockchain system utilizes a chain-like block structure to construct a decentralized (or multi-centralized) distributed ledger, which is stored on each node (or most nodes, such as consensus nodes) in the distributed blockchain network. Therefore, the blockchain system needs to address the consistency and correctness of the ledger data across these decentralized (or multi-centralized) nodes. Accordingly, each node in the blockchain system runs a blockchain program. Under certain fault-tolerance requirements, a consensus mechanism ensures that all loyal nodes have the same transactions, thereby guaranteeing consistent execution results for the same transactions. Transactions are packaged into blocks, and the world state is updated based on the execution results of the same transactions. The current mainstream consensus mechanisms include, but are not limited to: Proof of Work (POW), Proof of Stake (POS), Practical Byzantine Fault Tolerance (PBFT) algorithm, Honey Badger Byzantine Fault Tolerance (HoneyBadgerBFT) algorithm, etc.

[0040] Accounts in a blockchain system are typically categorized into two types: user accounts / externally owned accounts and contract accounts. Contract accounts store the contract code and related state values ​​of smart contracts and can usually only be activated and accessed through external accounts. The design of external and contract accounts essentially maps account addresses to account states. Account states typically include, but are not limited to, fields such as Nonce, Balance, Storage_Root, and CodeHash. Nonce and Balance exist in both external and contract accounts, while CodeHash and Storage_Root are usually only valid for contract accounts. Among these fields, Nonce represents a counter; for external accounts, its value represents the number of transactions sent from the account address; for contract accounts, its value represents the number of smart contracts created by the account. The Balance value represents the amount of digital resources owned by the corresponding external account. Storage_Root represents the hash of the root node of an MPT (Merkle Patricia Tree), which is used to organize the storage of contract account state variables. CodeHash represents the hash value of the contract code. For contract accounts, it is the code of the smart contract that has been hashed and stored. For external accounts, since it does not include the smart contract, it can be an empty string or a string of all zeros.

[0041] MPT is a tree structure that combines Merkle Tree and Patricia Tree (a compressed prefix tree, a more space-efficient trie tree). Merkle Tree algorithms calculate a hash value for each transaction, then join pairs of transactions and calculate the hash again, continuing until the top-level Merkle root. Ethereum uses an improved MPT tree, such as a hexadecimal structure, often simply referred to as an MPT tree. The Ethereum MPT tree's data structure includes a state trie.

[0042] The state tree contains key-value pairs representing the storage content for each account in Ethereum. The "key" in the state tree can be a 160-bit identifier (such as an Ethereum account address), distributed across the storage from the root node to the leaf node. The "value" in the state tree is generated by encoding the Ethereum account information using recursive-length prefix encoding (RLP). As mentioned earlier, for external accounts, the value can include Nonce and Balance; for contract accounts, the value can include Nonce, Balance, CodeHash, and Storage_Root, etc.

[0043] A contract account is used to store the state of a smart contract. Once a smart contract is deployed in a blockchain system, a corresponding contract account is assigned to it. This contract account typically has several states, defined by state variables within the smart contract and updated with new values ​​during the contract's creation and execution. The smart contracts described in this specification generally refer to contracts defined digitally in a blockchain environment that can automatically execute their terms. Once an event triggers a clause in the contract (meeting the execution conditions), the code can execute automatically.

[0044] The read-write set corresponding to a transaction is the execution result obtained from the pre-execution of the transaction in the virtual machine, and this execution result is in key-value pair form. The read-write set includes, for example, a read set and a write set. The read set includes key-value pairs of variables read during the pre-execution of the transaction, and the write set includes key-value pairs of variables written during the pre-execution of the transaction. These variables may include, for example, external accounts in the blockchain or variables defined in a contract account.

[0045] In related technologies, during block synchronization, nodes need to obtain the read-write sets corresponding to the blocks and block transactions, and execute the corresponding blocks based on the read-write sets to achieve block synchronization. However, the above process requires transmitting the complete read-write sets and storing them in a local database. Due to the large amount of data in the read-write sets, the consensus and storage costs are high, and the efficiency of block synchronization is not high.

[0046] To address the problems existing in related technologies, this specification proposes a block synchronization method.

[0047] Figure 2 This is a flowchart of an exemplary block synchronization method applied to the first node in a blockchain network, such as... Figure 2 As shown, it includes at least the following steps:

[0048] Step 202: Obtain block synchronization data from the second node in the blockchain network. The block synchronization data includes the first block information and the keys in the read / write set corresponding to the transactions contained in the first block.

[0049] A block can be a data block on a blockchain, which may include transactions, hash values, state data, and so on.

[0050] As mentioned earlier, a read-write set can include a read set and a write set. The read set contains several unique keys, as well as key-value pairs read from the committed world state corresponding to each of the aforementioned keys. The write set also contains several unique keys, as well as key-value pairs expected to be committed corresponding to each of the aforementioned keys; furthermore, if a transaction deletes a key from the world state, the write set will also record a corresponding marker for the deleted key. It is important to note that if the transaction to be executed is a contract call transaction used to invoke a smart contract, its read-write set may contain not only state parameters related to external accounts, but also several contract parameters related to the smart contract's contract state.

[0051] The following exemplifies the process by which node n1 pre-executes transactions Tx1 through Tx5 sequentially. It is assumed that transactions Tx1 and Tx2 are contract call transactions initiated by external accounts A1 and A2 respectively to invoke smart contract C1, and that smart contract C1 corresponds to contract account B1. Furthermore, it is assumed that transaction Tx3 is a transfer transaction initiated by external account A1 to external account A3, transaction Tx4 is a transfer transaction initiated by external account A4 to external account A5, and transaction Tx5 is a transfer transaction initiated by external account A6 to external account A7. Node n1, through its pre-execution process, pre-executes transactions Tx1 through Tx5, and may obtain the pre-execution information for each of transactions Tx1 through Tx5 as exemplified in Table 1 below.

[0052] trade Reading Collection Collection of Writings Trading Tx1 k1 = v11, k2 = v21 k1 = v12, k2 = v22 Trading Tx2 k3 = v31, k4 = v41 k3 = v32, k4 = v42 Trading Tx3 k1 = v12, k5 = v51 k1 = v13, k5 = v52 Trading Tx4 k6 = v61, k7 = v71 k6 = v62, k7 = v72 Trading Tx5 k8 = v81, k9 = v91 k8 = v82, k9 = v92

[0053] Table 1

[0054] For the parameters provided in Table 1 above, for example, k1 represents the key of the balance of external account A1, k2 represents the key of a certain status parameter under contract account B1, k3 represents the key of the balance of external account A2, k4 represents the key of a certain status parameter under contract account B1, and k5 to k9 represent the keys of the balance under external accounts A3 to A7 respectively. v11, v12, v13, and v21 to v92 respectively represent the values ​​of their corresponding keys. It should be noted that since transaction Tx3 is executed after transaction Tx1, the value of k1 in the read set of transaction Tx3 is the value of k1 in the write set of transaction Tx1.

[0055] However, the block synchronization data of this method only includes the keys in the read / write set, not the values ​​corresponding to those keys. For example...

[0056] As shown in Table 2, compared with Table 1, only keys k1 to k9 are recorded, and values ​​v11, v12, v13, and v21 to v92 are not recorded.

[0057] trade Reading Collection Collection of Writings Trading Tx1 k1, k2 k1, k2 Trading Tx2 k3, k4 k3, k4 Trading Tx3 k1, k5 k1, k5 Trading Tx4 k6, k7 k6, k7 Trading Tx5 k8, k9 k8, k9

[0058] Table 2

[0059] Step 204: Read the corresponding value from the local database according to the key in the read / write set.

[0060] The local database refers to the database corresponding to the first node.

[0061] Before executing a block transaction, the corresponding value is read from the local database based on the key in the read / write set. For example, in transaction Tx1, the value = v11 is read based on k1 in the read set, and the value = v21 is read based on k2. It is worth noting that the first node can read the values ​​corresponding to the keys in the read / write sets of all transactions at once, or it can read them in batches. It only needs to cache all the key-value pairs required for the transaction locally before executing the transaction. This specification does not restrict the reading order.

[0062] Step 206: Execute the transactions in the first block according to the pre-read values, and write the generated first block to the local database according to the execution results.

[0063] As shown in Table 1, after reading the values ​​corresponding to all keys in the read / write set, transactions Tx1 to Tx5 can be executed sequentially according to the pre-read values. Of course, the execution order of transactions does not have to follow the naming order; they can be executed in reverse order or according to the dependencies between transactions. This specification does not impose any restrictions on this. After all transactions have been executed, the first block generated can be written to the local database based on the execution results.

[0064] In this embodiment, on the one hand, during block synchronization, the synchronized data only includes the keys in the read / write sets corresponding to the transactions contained in the block, excluding the values ​​in the read / write sets. This reduces the amount of data synchronized and also reduces the amount of data that the second node needs to store, thereby lowering storage and consensus costs. On the other hand, by reading the corresponding values ​​from the local database based on the keys in the read / write sets before executing a transaction, the transaction can be executed directly based on the pre-read values ​​without the need for temporary reading, improving the efficiency of transaction execution and thus improving the efficiency of block synchronization.

[0065] In one embodiment, the block synchronization data further includes grouping information corresponding to the transactions contained in the first block, wherein the grouping information is generated based on the read / write sets corresponding to each transaction in the first block; the step of executing the transactions in the first block according to the pre-read values ​​includes: obtaining multiple transaction groups according to the grouping information; and sending the multiple transaction groups to different computing processes to achieve parallel execution. Further, the transactions in different transaction groups involve contract parameters of different contracts.

[0066] Conflicting dependencies exist between different transactions in a blockchain. For example, the execution result of transaction A will change variable C, while transaction B needs to read variable C during execution. In this case, transaction A must be executed first, followed by transaction B. As mentioned earlier, the read-write set corresponding to a transaction is the execution result obtained by pre-executing the transaction in the virtual machine. Therefore, different transactions can be grouped based on their corresponding read-write sets, grouping dependent transactions into the same group and non-dependent transactions into different groups, and generating grouping information for each transaction based on the grouping and the order within each group.

[0067] A process refers to a single execution of a program with a certain independent function within an application, based on a set of data. In other words, a process is a procedure in a computer that occurs through the sequential execution of instructions in an application by the CPU. Each process is allocated its own memory address space upon creation. Multiple processes on any given node can represent multiple computing devices or multiple processes within a virtual computing node.

[0068] In one embodiment, writing the generated first block to the local database based on the execution result includes: submitting the status data corresponding to the first block; and storing the first block, the grouping information corresponding to each transaction in the first block, and the read / write set to the local database.

[0069] The following is combined with Figure 3 This embodiment will be described in detail. Figure 3 This is a schematic diagram of the structure of any two nodes in a blockchain system provided as an exemplary embodiment. Figure 3Nodes n1 and n2 shown are the first and second nodes described in this scheme, respectively. Node n2 can be the master node in the blockchain system, and node n1 can be a slave node. Multiple processes can run on nodes n1 and n2 to provide various services, such as... Figure 3 As shown, nodes n1 and n2 each run an access process (such as access process 1 running in node n1 and access process 2 running in node n2; the process numbering below is similar and will not be repeated) for providing access services, a caching process for providing caching services, a pre-execution process for providing pre-execution services, a network process for providing network services, a consensus process for providing consensus services, a control process for providing block management services, and a storage process for providing storage services. In addition, node n1, as a slave node, can also run multiple computing processes for providing computing services, such as computing process 11, computing process 12, and computing process 13.

[0070] It should be noted that the solutions provided in the embodiments of this specification are not limited to master-slave blockchain systems; in other words, node n1 and node n2 mentioned in this solution can be any two blockchain nodes in the blockchain system.

[0071] The access process can be used to receive transactions from user devices, and then the access process can call the caching process to add the received transactions to the pending transaction queue for caching.

[0072] Node n2's pre-execution process 2 can call cache process 2 to sequentially read cached transactions from the pending transaction queue and verify them, such as verifying the user equipment's signature on the transaction, and then return the verified transactions to cache process 2. Furthermore, node n2 can also broadcast verified transactions stored in its cache process 2 to the network processes of other nodes through its network process 2; thus, transactions received by node n1 from node n2 through its network process 1 can be cached by its cache process 1 and added to the pending transaction queue. Therefore, the pending transaction queue cached in node n1's cache process 1 includes not only transactions received through its access process 1, but also transactions received through its network process 1 from other nodes (such as node n2).

[0073] The pre-execution process 2 of node n2 can also call the caching process 2 to sequentially read its cached transactions from the pending transaction queue and verify at least the transactions from user devices connected to node n2. Furthermore, the pre-execution process 2 of node n2 can pre-execute the transactions it receives sequentially from the caching process 2 to obtain pre-execution information for the transactions. This pre-execution information may include a pre-execution read set, a pre-execution write set, and resource consumption information (characterizing the amount of digital / computing resources consumed to execute the transaction). The pre-execution read / write set described in this specification includes the pre-execution read set and / or the pre-execution write set. Moreover, after completing the pre-execution of each batch of transactions, the pre-execution process 2 of node n2 can return the pre-execution information of that batch of transactions to the caching process 2 for caching in the pending consensus transaction queue.

[0074] The consensus process of node n1 can invoke its cache process to sequentially read multiple transactions and their related data from the queue of transactions awaiting consensus to generate a consensus proposal. This consensus proposal may include, for example, pre-execution information corresponding to each of the multiple transactions, the consensus order of the multiple transactions (the consensus order is the same as the pre-execution order of the multiple transactions), and indication information for each of the multiple transactions (e.g., the digest value of each of the multiple transactions). Node n2 can also calculate grouping information corresponding to the multiple transactions based on the pre-execution information indicated by the consensus proposal, and carry this grouping information in the consensus proposal so that other nodes participating in the consensus process can group the aforementioned multiple transactions based on this grouping information.

[0075] After consensus is reached on the consensus proposal, since the transactions received by nodes n1 and n2 from the user equipment they are connected to are added to the transaction queue to be processed by the caching process 2 of node n2 in the order of receipt, and the pre-execution process 2 of node n2 pre-executes each transaction in the transaction queue to be processed in the order, the consensus process 2 of node n2 can send the pre-execution information of the aforementioned multiple transactions to its control process 2 in the order of pre-execution / consensus of the aforementioned multiple transactions. The control process 2 submits part or all of the pre-execution information of the aforementioned multiple transactions as the state data of the corresponding block to the storage service 2, thereby obtaining the state root for generating the corresponding block and generating a block containing the state root and the aforementioned multiple transactions.

[0076] Node n1, for example, during the consensus process of the consensus proposal generated by node n2, or after reaching consensus on the consensus proposal generated by node n2, can read the pre-execution information of each of the aforementioned multiple transactions from the consensus proposal through its consensus process 1 and / or control process 1, and then group the multiple transactions based on the pre-execution information to obtain M (M is an integer greater than 1) transaction groups; or it can read the grouping information of the aforementioned multiple transactions from the consensus proposal and group the aforementioned multiple transactions based on the grouping information to obtain M transaction groups. For example, if the pre-execution information includes pre-execution read-write sets, the consensus process 1 can receive the pre-execution read-write sets of each of the multiple transactions from the second node in the blockchain system, determine the read-write set conflict relationship between the multiple transactions based on the pre-execution read-write sets, and determine the sequential dependency relationship of at least some of the multiple transactions based on the read-write set conflict relationship; and group the multiple transactions according to the sequential dependency relationship to obtain the M transaction groups. Afterwards, the consensus process 1 can send the M transaction groups to the control process 1. For example, consensus process 1 can also calculate grouping information based on the pre-execution information of each of the aforementioned transactions, and send the grouping information, the aforementioned transactions, and their respective pre-execution read / write sets to control process 1 of node n1; then control process 1 divides the aforementioned transactions into M transaction groups based on the grouping information. After obtaining the M transaction groups, control process 1 can schedule tasks for the N computing processes 1 in node n1.

[0077] In obtaining the aforementioned M transaction groups, it is necessary to ensure that any two transactions within any two transaction groups do not conflict with each other. Specifically, "any two transactions do not conflict" means that no two transactions fall into one of the following categories: either the pre-execution read set of one transaction contains the same key as the pre-execution write set of another transaction, or the pre-execution write set of one transaction contains the same key as the pre-execution write set of another transaction. For any two conflicting transactions, they must be assigned to the same transaction group. In other words, if the pre-execution write sets of any two transactions contain the same key, it is considered that the two conflicting transactions accessed the same parameter and therefore conflict, and these two transactions must be assigned to the same transaction group; if the pre-execution read set of one of the two transactions contains the same key as the pre-execution write set of the other transaction, it is considered that the two transactions accessed the same parameter and therefore conflict, and these two transactions must be assigned to the same transaction group.

[0078] In one embodiment, obtaining block synchronization data from a second node in the blockchain network includes: requesting synchronization of the first block from F+1 nodes in the blockchain network respectively; and determining the correctness of the received block synchronization data if the block synchronization data returned by the F+1 nodes is the same; wherein the total number of nodes in the blockchain network is not less than 3F+1, and F is a positive integer.

[0079] According to the Byzantine Fault Tolerance (BTT) algorithm, when there are N nodes in a blockchain network, the network can accommodate a maximum of F faulty nodes, where N is not less than 3F+1, and F is a positive integer. Therefore, to ensure the correctness of the obtained block synchronization data, if the same block synchronization data is obtained from F+1 nodes, the obtained block synchronization data must be correct. For example, if there are 4 nodes in the blockchain network, then as long as the same block synchronization data is obtained from 2 nodes, the correctness of the block synchronization data can be determined.

[0080] Furthermore, if any node in the blockchain network returns incorrect block synchronization data, that node will be added to a blacklist to prevent subsequent requests for block synchronization from being made to nodes on the blacklist.

[0081] Figure 4 This is a flowchart of a method for obtaining block synchronization data provided in an exemplary embodiment, such as... Figure 4 As shown, the method includes at least the following steps:

[0082] Step 402: Request synchronization of the first block from each of the F+1 nodes. Step 404: Receive the block synchronization data returned by the F+1 nodes.

[0083] Step 406: Determine whether the block synchronization data is consistent.

[0084] If the block synchronization data returned by F+1 nodes is the same, proceed to step 408a to verify the correctness of the obtained block synchronization data, which can then be used for subsequent operations. If the block synchronization data returned by F+1 nodes contains different block synchronization data, proceed to step 408b to add the node with incorrect block synchronization data to the blacklist. Specifically, the correctness of the block synchronization data can be determined by comparing the hash values ​​corresponding to the blocks in the block synchronization data.

[0085] This embodiment, on the one hand, further verifies the correctness of block synchronization data through the Byzantine consensus algorithm, preventing the synchronization of incorrect blocks. On the other hand, by adding nodes with incorrect block synchronization data to a blacklist, subsequent block retrieval will no longer trust those nodes, thus improving the efficiency of obtaining block synchronization data.

[0086] Figure 5 This is a flowchart of another block synchronization method provided in an exemplary embodiment, applied to a second node in a blockchain network, such as... Figure 5 As shown, it includes at least the following steps:

[0087] Step 502: Generate block synchronization data, which includes the first block information pre-stored by the second node and the keys in the read / write set corresponding to the transactions contained in the first block.

[0088] As mentioned above, the block synchronization data also includes grouping information corresponding to the transactions contained in the first block, and the grouping information is generated based on the read / write sets corresponding to each transaction in the first block.

[0089] Step 504: The generated block synchronization data is sent to the first node in the blockchain network, so that the first node: reads the corresponding value from the local database according to the key contained in the read-write set information, executes the transaction in the first block according to the pre-read value, and writes the generated first block into the local database according to the execution result.

[0090] In this embodiment, on the one hand, during block synchronization, the synchronized data only includes the keys in the read / write sets corresponding to the transactions contained in the block, excluding the values ​​in the read / write sets. This reduces the amount of data synchronized and also reduces the amount of data that the second node needs to store, thereby lowering storage and consensus costs. On the other hand, by reading the corresponding values ​​from the local database based on the keys in the read / write sets before executing a transaction, the transaction can be executed directly based on the pre-read values ​​without the need for temporary reading, improving the efficiency of transaction execution and thus improving the efficiency of block synchronization.

[0091] Figure 6 This is a schematic diagram of another blockchain system provided in an exemplary embodiment. The blockchain system 60 includes a first node 61 and a second node 62, wherein:

[0092] The second node 62 is used to generate block synchronization data and send the generated block synchronization data to the first node 61. The block synchronization data includes the first block information pre-stored by the second node and the keys in the read / write set corresponding to the transactions contained in the first block.

[0093] The first node 61 is used to read the corresponding value from the local database according to the key in the read-write set when it obtains the block synchronization data from the second node 62; execute the transaction in the first block according to the pre-read value; and write the generated first block into the local database according to the execution result.

[0094] As mentioned above, the block synchronization data also includes group information corresponding to the transactions contained in the first block. This group information is generated based on the read / write sets corresponding to each transaction in the first block. Executing the transactions in the first block according to the pre-read values ​​includes: the first node 61 obtaining multiple transaction groups based on the group information and sending these multiple transaction groups to different computing processes to achieve parallel execution. Furthermore, the transactions in different transaction groups involve contract parameters of different contracts.

[0095] As mentioned above, obtaining block synchronization data from the second node 62 in the blockchain network includes: the first node requesting synchronization of the first block from F+1 nodes in the blockchain network respectively, and determining the correctness of the received block synchronization data if the block synchronization data returned by the F+1 nodes is the same; wherein, the total number of nodes in the blockchain network is not less than 3F+1, and F is a positive integer.

[0096] As mentioned above, the system further includes: when any node in the blockchain network returns incorrect block synchronization data, the first node adds the incorrect node to a blacklist to avoid subsequently requesting block synchronization from nodes in the blacklist.

[0097] As mentioned above, the step of writing the generated first block to the local database based on the execution result includes: the first node 61 submits the status data corresponding to the first block, and stores the first block, the grouping information corresponding to each transaction in the first block, and the read / write set to the local database.

[0098] In this embodiment, on the one hand, during block synchronization, the synchronized data only includes the keys in the read / write sets corresponding to the transactions contained in the block, excluding the values ​​in the read / write sets. This reduces the amount of data synchronized and also reduces the amount of data that the second node needs to store, thereby lowering storage and consensus costs. On the other hand, by reading the corresponding values ​​from the local database based on the keys in the read / write sets before executing a transaction, the transaction can be executed directly based on the pre-read values ​​without the need for temporary reading, improving the efficiency of transaction execution and thus improving the efficiency of block synchronization.

[0099] Figure 7 This is a schematic structural diagram of a device provided in an exemplary embodiment. Please refer to... Figure 7At the hardware level, the device includes a processor 702, an internal bus 704, a network interface 706, memory 708, and non-volatile memory 710, and may also include other hardware required for its functions. One or more embodiments of this specification can be implemented in software, for example, the processor 702 reads the corresponding computer program from the non-volatile memory 710 into memory 708 and then runs it. Of course, in addition to software implementation, one or more embodiments of this specification do not exclude other implementation methods, such as logic devices or a combination of hardware and software, etc. That is to say, the execution subject of the following processing flow is not limited to each logic unit, but can also be hardware or logic devices.

[0100] like Figure 8 As shown, Figure 8 This is a block diagram of an exemplary embodiment of a block synchronization device, which can be applied to, for example... Figure 8 The device shown implements the technical solution of this specification; the device is applied to a first node in a blockchain network, and the device includes:

[0101] The acquisition unit 802 is used to acquire block synchronization data from the second node in the blockchain network. The block synchronization data includes first block information and keys in the read / write set corresponding to the transactions contained in the first block.

[0102] The reading unit 804 is used to read the corresponding value from the local database according to the key in the read / write set;

[0103] Execution unit 806 is used to execute the transactions in the first block according to the pre-read value, and write the generated first block into the local database according to the execution result.

[0104] Optionally, the block synchronization data further includes grouping information corresponding to the transactions contained in the first block, wherein the grouping information is generated based on the read / write sets corresponding to each transaction in the first block; the execution unit 806 is specifically used for:

[0105] Multiple transaction groups are obtained based on the grouping information;

[0106] The multiple transaction groups are sent to different computing processes to achieve parallel execution.

[0107] Optionally, transactions in different transaction groups within the plurality of transaction groups may involve contract parameters of different contracts.

[0108] Optionally, the acquisition unit 802 is specifically used for:

[0109] Each of the F+1 nodes in the blockchain network requests synchronization of the first block.

[0110] If the block synchronization data returned by the F+1 nodes is the same, the correctness of the received block synchronization data is determined; wherein, the total number of nodes in the blockchain network is not less than 3F+1, and F is a positive integer.

[0111] Optionally, the method further includes:

[0112] The addition unit 808 is used to add any node to the blacklist when any node in the blockchain network returns incorrect block synchronization data, so as to avoid subsequent requests for block synchronization from nodes in the blacklist.

[0113] Optionally, the execution unit 806 is specifically used for:

[0114] Submit the status data corresponding to the first block;

[0115] Store the first block, the grouping information corresponding to each transaction in the first block, and the read / write set to the local database.

[0116] like Figure 9 As shown, Figure 9 This is a block diagram of another block synchronization device provided in an exemplary embodiment, which can be applied to, for example... Figure 9 The device shown implements the technical solution of this specification; the device is applied to a second node in a blockchain network, and the device includes:

[0117] The generation unit 902 is used to generate block synchronization data, which includes the first block information pre-stored by the second node and the keys in the read / write set corresponding to the transactions contained in the first block;

[0118] The sending unit 904 is used to send the generated block synchronization data to the first node in the blockchain network, so that the first node: reads the corresponding value from the local database according to the key contained in the read-write set information, executes the transaction in the first block according to the pre-read value, and writes the generated first block into the local database according to the execution result.

[0119] Optionally, the block synchronization data may also include grouping information corresponding to the transactions contained in the first block, wherein the grouping information is generated based on the read / write sets corresponding to each transaction in the first block.

[0120] In the 1990s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the methodology). However, with technological advancements, many methodological improvements today can be considered direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved methodology into the hardware circuit. Therefore, it cannot be said that a methodological improvement cannot be implemented using hardware physical modules. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user programming the device. Designers can program and "integrate" a digital system onto a PLD themselves, without needing chip manufacturers to design and manufacture dedicated integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software. Similar to the software compiler used in program development, the original code before compilation must be written in a specific programming language, called a Hardware Description Language (HDL). There are many HDLs, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, and RHDL (Ruby Hardware Description Language). Currently, the most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should understand that by simply performing some logic programming on the method flow using one of these hardware description languages ​​and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.

[0121] The controller can be implemented in any suitable manner. For example, it can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicon Labs C8051F320. A memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code form, the same functionality can be achieved by logically programming the method steps to make the controller take the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the means included therein for implementing various functions can also be considered as structures within the hardware component. Alternatively, the means for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

[0122] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or physical entities, or by products with certain functions. A typical implementation device is a server system. Of course, this invention does not exclude the possibility that, with the future development of computer technology, the computer implementing the functions of the above embodiments can be, for example, a personal computer, a laptop computer, an in-vehicle human-machine interaction device, a cellular phone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or any combination of these devices.

[0123] While one or more embodiments of this specification provide the operational steps of the methods described in the embodiments or flowcharts, more or fewer operational steps may be included based on conventional or non-inventive means. The order of steps listed in the embodiments is merely one possible order of execution among many steps and does not represent the only possible order. In actual device or end product execution, the methods shown in the embodiments or drawings may be executed sequentially or in parallel (e.g., in a parallel processor or multi-threaded processing environment, or even a distributed data processing environment). The terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, product, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, product, or apparatus. Without further limitations, the presence of other identical or equivalent elements in the process, method, product, or apparatus that includes the elements is not excluded. For example, the use of terms such as "first," "second," etc., is to denote names and does not indicate any particular order.

[0124] For ease of description, the above devices are described in terms of function, divided into various modules. Of course, when implementing one or more of these specifications, the functions of each module can be implemented in one or more software and / or hardware components, or a module that performs the same function can be implemented by a combination of multiple sub-modules or sub-units. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, indirect coupling or communication connection between devices or units, and may be electrical, mechanical, or other forms.

[0125] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0126] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0127] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0128] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0129] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0130] Computer-readable media, including both permanent and non-permanent, removable and non-removable media, can store information using any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage, graphene storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0131] Those skilled in the art will understand that one or more embodiments of this specification can be provided as a method, system, or computer program product. Therefore, one or more embodiments of this specification may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, one or more embodiments of this specification may take the form of a computer program product implemented on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0132] One or more embodiments of this specification can be described in the general context of computer-executable instructions, such as program modules, that are executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a particular task or implement a particular abstract data type. One or more embodiments of this specification can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In a distributed computing environment, program modules can reside in local and remote computer storage media, including storage devices.

[0133] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, system embodiments are basically similar to method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments. In the description of this specification, the terms "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of this specification. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described can be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification and the features of different embodiments or examples.

[0134] The above description is merely an embodiment of one or more embodiments of this specification and is not intended to limit the scope of this specification. Various modifications and variations can be made to the one or more embodiments of this specification by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification should be included within the scope of the claims.

Claims

1. A block synchronization method, applied to the first node in a blockchain network, the method comprising: Obtain block synchronization data from the second node in the blockchain network. The block synchronization data includes first block information and keys in the read / write set corresponding to the transactions contained in the first block. Read the corresponding value from the local database according to the key in the read / write set; Execute the transactions in the first block according to the pre-read values, and write the generated first block to the local database according to the execution results; The step of writing the generated first block to the local database based on the execution result includes: Submit the status data corresponding to the first block; Store the first block, the grouping information corresponding to each transaction in the first block, and the read / write set to the local database.

2. The method according to claim 1, wherein the block synchronization data further includes grouping information corresponding to the transactions contained in the first block, the grouping information being generated based on the read / write sets corresponding to each transaction in the first block; The step of executing the transactions in the first block based on the pre-read value includes: Multiple transaction groups are obtained based on the grouping information; The multiple transaction groups are sent to different computing processes to achieve parallel execution.

3. The method according to claim 2, wherein the transactions in different transaction groups of the plurality of transaction groups involve contract parameters of different contracts.

4. The method according to claim 1, wherein obtaining block synchronization data from a second node in the blockchain network comprises: Each of the F+1 nodes in the blockchain network requests synchronization of the first block. If the block synchronization data returned by the F+1 nodes is the same, the correctness of the received block synchronization data is determined; wherein, the total number of nodes in the blockchain network is not less than 3F+1, and F is a positive integer.

5. The method according to claim 4, further comprising: If any node in the blockchain network returns incorrect block synchronization data, that node will be added to a blacklist to prevent subsequent requests for block synchronization from being made to nodes on the blacklist.

6. A block synchronization method, applied to a second node in a blockchain network, the method comprising: Generate block synchronization data, which includes the first block information pre-stored by the second node and the keys in the read / write set corresponding to the transactions contained in the first block; The generated block synchronization data is sent to the first node in the blockchain network, so that the first node: reads the corresponding value from the local database according to the key in the read-write set, executes the transaction in the first block according to the pre-read value, and writes the generated first block into the local database according to the execution result; The step of writing the generated first block to the local database based on the execution result includes: Submit the status data corresponding to the first block; Store the first block, the grouping information corresponding to each transaction in the first block, and the read / write set to the local database.

7. The method according to claim 6, wherein the block synchronization data further includes grouping information corresponding to the transactions contained in the first block, the grouping information being generated based on the read / write sets corresponding to each transaction in the first block.

8. A blockchain system comprising a first node and a second node, wherein: The second node is used to generate block synchronization data and send the generated block synchronization data to the first node. The block synchronization data includes the first block information pre-stored by the second node and the keys in the read / write set corresponding to the transactions contained in the first block. The first node is used to read the corresponding value from the local database according to the key in the read-write set when it obtains the block synchronization data from the second node; Execute the transactions in the first block according to the pre-read values, and write the generated first block to the local database according to the execution results; The step of writing the generated first block to the local database based on the execution result includes: Submit the status data corresponding to the first block; Store the first block, the grouping information corresponding to each transaction in the first block, and the read / write set to the local database.

9. The system according to claim 8, wherein the block synchronization data further includes grouping information corresponding to the transactions contained in the first block, the grouping information being generated based on the read / write sets corresponding to each transaction in the first block; the step of executing the transactions in the first block according to the pre-read value includes: The first node obtains multiple transaction packets based on the grouping information and sends the multiple transaction packets to different computing processes to achieve parallel execution.

10. The system according to claim 9, wherein the transactions in different transaction groups of the plurality of transaction groups involve contract parameters of different contracts.

11. The system according to claim 8, wherein the first node obtains block synchronization data from the second node in the blockchain system, comprising: The first node requests synchronization of the first block from F+1 nodes in the blockchain system respectively, and determines the correctness of the received block synchronization data if the block synchronization data returned by the F+1 nodes is the same; wherein, the total number of nodes in the blockchain system is not less than 3F+1, and F is a positive integer.

12. The system according to claim 8, further comprising: When any node in the blockchain system returns incorrect block synchronization data, the first node adds that node to a blacklist to prevent subsequent requests for block synchronization from nodes in the blacklist.

13. A block synchronization device, applied to a first node in a blockchain network, the device comprising: Acquisition Unit: Acquires block synchronization data from the second node in the blockchain network. The block synchronization data includes first block information and keys in the read / write set corresponding to the transactions contained in the first block. Reading unit: Reads the corresponding value from the local database according to the key in the read / write set; Execution unit: Executes the transactions in the first block according to the pre-read values, and writes the generated first block to the local database according to the execution results; The step of writing the generated first block to the local database based on the execution result includes: Submit the status data corresponding to the first block; Store the first block, the grouping information corresponding to each transaction in the first block, and the read / write set to the local database.

14. A block synchronization device, applied to a second node in a blockchain network, the device comprising: Generation unit: Generates block synchronization data, which includes the first block information pre-stored by the second node and the keys in the read / write set corresponding to the transactions contained in the first block; Sending unit: sends the generated block synchronization data to the first node in the blockchain network, so that the first node: reads the corresponding value from the local database according to the key in the read-write set, executes the transaction in the first block according to the pre-read value, and writes the generated first block into the local database according to the execution result; The step of writing the generated first block to the local database based on the execution result includes: Submit the status data corresponding to the first block; Store the first block, the grouping information corresponding to each transaction in the first block, and the read / write set to the local database.

15. An electronic device comprising: processor; Memory used to store processor-executable instructions; The processor implements the method as described in any one of claims 1-7 by executing the executable instructions.

16. A computer-readable storage medium having stored thereon computer instructions that, when executed by a processor, implement the steps of the method as claimed in any one of claims 1-7.

Images