CN116821242A

CN116821242A - Block synchronization method, device and block chain system

Info

Publication number: CN116821242A
Application number: CN202310801498.0A
Authority: CN
Inventors: 陶友贤
Original assignee: Ant Blockchain Technology Shanghai Co Ltd
Current assignee: Ant Blockchain Technology Shanghai Co Ltd
Priority date: 2023-06-30
Filing date: 2023-06-30
Publication date: 2023-09-29

Abstract

The present disclosure provides a block synchronization method, apparatus and a block chain system, applied to a first node in a block chain network, the method comprising: obtaining block synchronization data from a second node in the block chain network, wherein the block synchronization data comprises a first block and keys in a read-write set corresponding to transactions contained in the first block; reading corresponding values from a local database according to the keys in the read-write set; and executing the transaction in the first block according to the pre-read value, and writing the generated first block into a local database according to the execution result.

Description

Block synchronization method, device and block chain system

Technical Field

The embodiment of the specification belongs to the technical field of block chains, and particularly relates to a block synchronization method, a device and a block chain system.

Background

Blockchain (Blockchain) is a new application mode of computer technologies such as distributed data storage, point-to-point transmission, consensus mechanisms, encryption algorithms, and the like. The data blocks are combined into a chain data structure in a sequential connection mode according to the time sequence in the block chain network, and the distributed account book which is not tamperable and counterfeit and is ensured in a cryptographic mode. Because the blockchain has the characteristics of decentralization, non-tamperability of information, autonomy and the like, the blockchain is also receiving more and more attention and application.

In the related art, in the process of block synchronization, a node needs to acquire a read-write set corresponding to a block and block transaction, and execute a corresponding block according to the read-write set to realize the synchronization of the blocks. However, the above process needs to transmit the complete read-write set and store it in the local database, which makes the cost of consensus and storage larger and the efficiency of block synchronization not high due to the larger data volume of the read-write set.

Disclosure of Invention

The present disclosure is directed to a block synchronization method, apparatus and block chain system.

According to a first aspect of one or more embodiments of the present specification, there is provided a block synchronization method applied to a first node in a blockchain network, the method comprising:

obtaining block synchronization data from a second node in the block chain network, wherein the block synchronization data comprises first block information and keys in a read-write set corresponding to transactions contained in the first block;

reading corresponding values from a local database according to the keys in the read-write set;

and executing the transaction in the first block according to the pre-read value, and writing the generated first block into a local database according to the execution result.

According to a second aspect of one or more embodiments of the present specification, there is provided a block synchronization method applied to a second node in a blockchain network, the method comprising:

Generating block synchronous data, wherein the block synchronous data comprises first block information prestored by the second node and keys in a read-write set corresponding to transactions contained in the first block;

transmitting the generated block synchronization data to a first node in the blockchain network for use by the first node: and reading a corresponding value from a local database according to a key contained in the read-write set information, executing the transaction in the first block according to the pre-read value, and writing the generated first block into the local database according to an execution result.

According to a third aspect of one or more embodiments of the present specification, there is provided a blockchain system comprising a first node and a second node, wherein:

the second node is used for generating block synchronous data, and sending the generated block synchronous data to the first node, wherein the block synchronous data comprises first block information prestored by the second node and keys in a read-write set corresponding to transactions contained in the first block;

the first node is used for reading corresponding values from a local database according to keys in the read-write set under the condition that the block synchronous data are acquired from the second node; and executing the transaction in the first block according to the pre-read value, and writing the generated first block into a local database according to the execution result.

According to a fourth aspect of one or more embodiments of the present specification, there is provided a block synchronization apparatus for application to a first node in a blockchain network, the apparatus comprising:

an acquisition unit: obtaining block synchronization data from a second node in the block chain network, wherein the block synchronization data comprises a first block and keys in a read-write set corresponding to transactions contained in the first block;

a reading unit: reading corresponding values from a local database according to the keys in the read-write set;

an execution unit: and executing the transaction in the first block according to the pre-read value, and writing the generated first block into a local database according to the execution result.

According to a fifth aspect of one or more embodiments of the present specification, there is provided a block synchronization apparatus for use in a second node in a blockchain network, the apparatus comprising:

a generation unit: generating block synchronous data, wherein the block synchronous data comprises first block information prestored by the second node and keys in a read-write set corresponding to transactions contained in the first block;

a transmitting unit: transmitting the generated block synchronization data to a first node in the blockchain network for use by the first node: and reading a corresponding value from a local database according to a key contained in the read-write set information, executing the transaction in the first block according to the pre-read value, and writing the generated first block into the local database according to an execution result.

According to a sixth aspect of one or more embodiments of the present specification, there is provided an electronic device comprising:

a processor;

a memory for storing processor-executable instructions;

wherein the processor implements the method of any one of the first and second aspects by executing the executable instructions.

According to a seventh aspect of one or more embodiments of the present description, there is provided a computer readable storage medium having stored thereon computer instructions which, when executed by a processor, implement the steps of the method as in any one of the first and second aspects.

In the embodiment of the present disclosure, on the one hand, in the process of block synchronization, the block synchronization data only includes the keys in the read-write set corresponding to the transaction contained in the block, and does not include the values in the read-write set, which reduces the amount of data to be synchronized, and makes the first node and the second node only need to store the amount of data corresponding to the keys, and does not need to store the amount of data corresponding to the values, thereby reducing the storage cost and the consensus cost. On the other hand, before executing the transaction, the corresponding value is read from the local database according to the key in the read-write set, so that the transaction can be directly executed according to the pre-read value without temporary reading when executing the transaction, the transaction execution efficiency is improved, and the block synchronization efficiency is further improved.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present disclosure, the drawings that are needed in the description of the embodiments will be briefly described below, and it is obvious that the drawings in the following description are only some embodiments described in the present disclosure, and that other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.

FIG. 1 is a schematic diagram of a blockchain system provided by an exemplary embodiment.

Fig. 2 is a flowchart of a block synchronization method according to an exemplary embodiment.

FIG. 3 is a schematic diagram of any two nodes in a blockchain system in accordance with an exemplary embodiment.

Fig. 4 is a flowchart of a method for acquiring block synchronization data according to an exemplary embodiment.

Fig. 5 is a flowchart of another block synchronization method provided by an exemplary embodiment.

FIG. 6 is a schematic diagram of another blockchain system provided by an exemplary embodiment.

Fig. 7 is a schematic diagram of an apparatus according to an exemplary embodiment.

Fig. 8 is a block diagram of a block synchronization apparatus provided in an exemplary embodiment.

Fig. 9 is a block diagram of another block synchronization apparatus provided by an exemplary embodiment.

Detailed Description

In order to make the technical solutions in the present specification better understood by those skilled in the art, the technical solutions in the embodiments of the present specification will be clearly and completely described below with reference to the drawings in the embodiments of the present specification, and it is obvious that the described embodiments are only some embodiments of the present specification, not all embodiments. All other embodiments, which can be made by one of ordinary skill in the art without undue burden from the present disclosure, are intended to be within the scope of the present disclosure.

FIG. 1 is a schematic diagram of a blockchain system provided by an exemplary embodiment. As shown in fig. 1, the blockchain system is a distributed network established by a plurality of nodes (nodes), which includes a point-to-point (P2P) network between any two nodes to implement communication connection at an application layer, for example, any two nodes from Node n1 to Node n5 included in the blockchain system may implement communication connection at the application layer through the P2P network. The blockchain system uses the decentralized (or called multicentric) distributed ledger constructed by the chain type blockchain structure to be stored on each node (or on a large number of nodes, such as common nodes) in the distributed blockchain network, so that the blockchain system needs to solve the problem of consistency and correctness of the data of the respective ledger on a plurality of decentralised (or multicentric) nodes. In view of this, each node of the blockchain system is running a blockchain program, and under the design of a certain fault tolerance requirement, all the loyalty nodes are guaranteed to have the same transaction through a consensus (consensus) mechanism, so that the consistency of the execution results of all the loyalty nodes on the same transaction is guaranteed, the transactions are packed into blocks, and the world state is updated based on the execution results of the same transaction. Among the currently prevailing consensus mechanisms include, but are not limited to: proof of Work (POW), proof of stock (POS), practical bezels fault tolerance (Practical Byzantine Fault Tolerance, PBFT) algorithms, meles bezels fault tolerance (honeybadger bft) algorithms, and the like.

Accounts in blockchain systems are typically divided into two types, user accounts/external accounts (Externally owned account) and contract accounts (contract account); wherein the contract account is used to store the contract code and associated status values of the smart contract, which are typically only activated and invoked through an external account. The design of external accounts and contracted accounts is actually a mapping of account addresses to account states. The account status may typically include, but is not limited to, nonce, balance, storage _ Root, codeHash fields, where Nonce, balance exists in both external and contract accounts, while the CodeHash and storage_root attributes are typically valid only on contract accounts. In the foregoing fields, nonce characterizes a counter whose value for the external account represents the number of transactions sent from the account address; for a contract account, its value represents the number of smart contracts that the account creates. The value of Balance characterizes the number of digital resources owned by the corresponding external account. Storage_root characterizes the hash of one MPT (Merkle Patricia Tree) Root node, which is used to organize the Storage of the state variables of the contract account. CodeHash characterizes the hash value of the contract code, which is the hashed and stored code of the smart contract for the contract account, and which can be either an empty string or an all 0 string for external accounts because the smart contract is not included.

MPT is a Tree structure combining Merkle Tree and Patricia Tree (compressed prefix Tree, a more space-saving Trie Tree, dictionary Tree). The Merkle Tree algorithm calculates a Hash value for each transaction, then the two-by-two connections calculate the Hash again, up to the top-most Merkle root. Improved MPT trees, such as 16-ary tree structures, also commonly referred to simply as MPT trees, are employed in ethernet. Wherein the data structure of the ethernet MPT tree comprises a state tree (state trie).

The state tree contains key value pairs (Key and Value pair) of the stored content corresponding to each account in the ethernet. The "Key" in the state tree may be a 160bit identifier (e.g., the address of an ethernet account) that is distributed in storage starting from the root node to the leaf node of the state tree. The "Value" in the state tree is generated by encoding the information of the ethernet account (using a Recursive-Length Prefix encoding, RLP) method. As previously described, for external accounts, the values may include nonces and Balance; for a contract account, the values may include Nonce, balance, codeHash and storage_root, etc.

The contract account is used to store smart contract-related status. After the intelligent contracts are deployed in the blockchain system, a corresponding contract account is allocated. This contract account will typically have states defined by state variables in the smart contract and generating new state values during the creation and execution of the smart contract. Intelligent contracts, as used herein, generally refer to contracts that are defined in digital form in a blockchain environment that are capable of automatically enforcing terms. The code may be executed automatically once some event triggers a term in the contract (execution condition is met).

The read-write set corresponding to the transaction is an execution result obtained by pre-executing the transaction in the virtual machine, and the execution result is in a key value pair form. The read-write set includes, for example, a read set including a key-value pair of a variable that the transaction reads in the pre-execution and a write set including a key-value pair of a variable that the transaction writes in the pre-execution. The variables include, for example, external accounts in the blockchain, or variables defined in a contract account.

In order to solve the problems in the related art, the present specification proposes a block synchronization method.

Fig. 2 is a flowchart of a block synchronization method applied to a first node in a blockchain network according to an exemplary embodiment, and includes at least the following steps as shown in fig. 2:

step 202, obtaining block synchronization data from a second node in the blockchain network, wherein the block synchronization data includes first block information and keys in a read-write set corresponding to transactions contained in the first block.

The blocks may be data blocks on a blockchain, including transactions, hash values, status data, and the like.

As previously described, the read-write sets may include a read set and a write set. The read set contains a number of unique keys (keys) and also includes key values (values) corresponding to the respective keys read from the submitted world state. The write set also contains a number of unique keys (keys), and also contains key values (values) corresponding to the respective keys that are expected to be submitted; furthermore, if a transaction performs deletion processing on a key in world state, the write set will record a corresponding mark on the deleted key. It should be noted that if the transaction being pre-executed is a contract call transaction for calling a smart contract, the read-write set may include not only state parameters related to the external account, but also several contract parameters related to the contract state of the smart contract.

The following exemplary description of the process by which node n1 pre-executes transactions Tx1 through Tx5 in sequence, assuming that transactions Tx1 and Tx2 are contract invoking transactions for invoking smart contract C1 initiated by external account A1 and external account A2, respectively, and assuming that smart contract C1 corresponds to contract account B1; further assume that transaction Tx3 is a transfer transaction initiated by external account A1 directed to external account A3, transaction Tx4 is a transfer transaction initiated by external account A4 directed to external account A5, and transaction Tx5 is a transfer transaction initiated by external account A6 directed to external account A7. The node n1 pre-executes the transactions Tx1 to Tx5 by its pre-execution process, and it is possible to obtain the pre-execution information of each of the transactions Tx1 to Tx5 as exemplified in table 1 below.

Transaction	Read-out set	Write set
			Transaction Tx1	k1＝v11，k2＝v21	k1＝v12，k2＝v22
Transaction Tx2	k3＝v31，k4＝v41	k3＝v32，k4＝v42
			Transaction Tx3	k1＝v12，k5＝v51	k1＝v13，k5＝v52
Transaction Tx4	k6＝v61，k7＝v71	k6＝v62，k7＝v72
			Transaction Tx5	k8＝v81，k9＝v91	k8＝v82，k9＝v92

TABLE 1

For each of the parameters exemplarily provided in the foregoing table 1, for example, k1 represents the key of the balance of the external account A1, k2 represents the key of a certain status parameter under the contract account B1, k3 represents the key of the balance of the external account A2, k4 represents the key of a certain status parameter under the contract account B1, and k5 to k9 represent the keys of the balance under the external accounts A3 to A7 in sequence. Wherein v11, v12, v13, and v 21-v 92 each characterize the value of their respective corresponding keys. It should be noted that, since transaction Tx3 is performed 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 Tx 1.

However, the block synchronization data of the method only includes keys in the read-write set, and does not include values corresponding to the keys in the read-write set. Such as

As shown in table 2, in comparison with table 1, only keys such as k1 to k9 are recorded, and v11, v12, v13, and v21 to v92 are not recorded.

Transaction	Read-out set	Write set
			Transaction Tx1	k1，k2	k1，k2
Transaction Tx2	k3，k4	k3，k4
			Transaction Tx3	k1，k5	k1，k5
Transaction Tx4	k6，k7	k6，k7
			Transaction Tx5	k8，k9	k8，k9

TABLE 2

And step 204, reading corresponding values from the local database according to the keys in the read-write set.

The local database refers to a database corresponding to the first node.

Before executing the block transaction, the corresponding value is read from the local database according to the keys in the read-write set. For example: in the transaction Tx1, the corresponding value=v11 is read according to k1 in the read set, and the corresponding value=v21 is read according to k 2. It should be noted that, the first node may read the values corresponding to the read-write centralized keys of all transactions at one time, or may read the values in batches, and only need to cache all key values required by the transactions locally before executing the transactions, which is not limited in the reading sequence in this specification.

And step 206, executing the transaction in the first block according to the pre-read value, and writing the generated first block into a local database according to the execution result.

As shown in table 1, after reading the values corresponding to all keys in the read-write set, transactions Tx1 to Tx5 may be sequentially performed according to the pre-read values. Of course, the order of execution of the transactions may not be in the named order, may be performed upside down, or may be performed in accordance with a dependency relationship between the transactions, which is not limited in this specification. After all transactions are executed, the generated first block can be written into the local database according to the execution result.

In this embodiment, on the one hand, in the process of block synchronization, the block synchronization data only includes the keys in the read-write set corresponding to the transaction contained in the block, and does not include the values in the read-write set, which reduces the amount of data to be synchronized, and also reduces the amount of data to be stored by the second node, thereby reducing the storage cost and the consensus cost. On the other hand, before executing the transaction, the corresponding value is read from the local database according to the key in the read-write set, so that the transaction can be directly executed according to the pre-read value without temporary reading when executing the transaction, the transaction execution efficiency is improved, and the block synchronization efficiency is further improved.

In an embodiment, the block synchronization data further includes grouping information corresponding to transactions contained in the first block, where the grouping information is generated based on a read-write set corresponding to each transaction in the first block; the executing the transaction in the first block according to the pre-read value includes: acquiring a plurality of transaction groups according to the grouping information; and respectively sending the transaction groups to different computing processes to realize parallel execution. Further, transactions in different ones of the plurality of transaction groups relate to contract parameters of different contracts.

There are conflicting dependencies between different transactions of a blockchain, such as: the execution result of the A transaction changes the variable C, and the B transaction needs to read the variable C when executing, at this time, the A transaction must be executed first, and then the B transaction must be executed. As described above, the read-write set corresponding to the transaction is an execution result obtained by pre-executing the transaction in the virtual machine, so that different transactions can be grouped based on the read-write set corresponding to the transaction, transactions with a dependency relationship are divided into the same group, transactions without a dependency relationship are divided into different groups, and grouping information corresponding to the transactions is generated according to the grouping and the sequence in the group.

A process refers to a running activity of a program with a certain independent function in an application with respect to a data set, i.e. the process is a process in a computer by sequentially executing instructions in the application program by a CPU, and each process is allocated its own memory address space at the time of creation. The plurality of processes in any node may be a plurality of computing devices or a plurality of processes in a virtual computing node.

In an embodiment, the writing the generated first block into the local database according to the execution result includes: submitting state data corresponding to the first block; and storing the first block, grouping information corresponding to each transaction in the first block and a read-write set to a local database.

This embodiment is described in detail below with reference to fig. 3. FIG. 3 is a schematic diagram of any two nodes in a blockchain system in accordance with an exemplary embodiment. The node n1 and the node n2 shown in fig. 3 are a first node and a second node according to the present solution, where the node n2 may be a master node in a blockchain system, and the node n1 may be a slave node in the blockchain system. The node n1 and the node n2 may respectively run a plurality of processes to provide a plurality of services, as shown in fig. 3, where the node n1 and the node n2 each run an access process for providing an access service (e.g., the access process 1 running in the node n1 and the access process 2 running in the node n2, and the process numbers are similar to those described in detail below), a caching process for providing a caching service, a pre-execution process for providing a pre-execution service, a network process for providing a network service, a consensus process for providing a consensus service, a control process for providing a block management service, and a storage process for providing a storage service. In addition, the node n1 as a slave node may also run a plurality of computing processes for providing computing services, such as the computing process 11, the computing process 12, and the computing process 13.

It should be noted that, the scheme provided in the embodiments of the present disclosure is not limited to the blockchain system of the master-slave architecture; in other words, the node n1 and the node n2 in this embodiment may be any two blockchain nodes in the blockchain system.

The access process can be used for receiving the transaction from the user equipment, and the access process further calls the caching process to realize that the received transaction is added into a pending transaction queue for caching.

The pre-execution process 2 of node n2 may invoke the caching process 2 to effect reading of its cached transactions in order from the pending transaction queue and verification of the transaction, e.g. verification of the signature of the transaction by the user device, and return of the verified transaction to the caching process 2. In addition, node n2 may also broadcast the validated transaction stored in its cache process 2 to the network processes of the remaining nodes via its network process 2; thus, a transaction received by node n1 through its network process 1 from node n2 may be cached by its caching process 1 for inclusion in a pending transaction queue. The pending transaction queue thus cached by the caching process 1 of node n1 through its memory 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 n 2.

The pre-execution process 2 of node n2 may also invoke the caching process 2 to effect sequential reading of its cached transactions from the pending transaction queue and at least verification of transactions from the user device connected to node n 2. The pre-execution process 2 of the node n2 may also pre-execute transactions that it receives in sequence from the caching process 2 to obtain pre-execution information for the transaction, where the pre-execution information may include a pre-execution read set, a pre-execution write set, and resource consumption information (to characterize the number of digital/computing resources that need to be consumed to execute the transaction), among others. Wherein, the pre-execution read-write set described in the specification comprises the pre-execution read set and/or the pre-execution write set. And the pre-execution process 2 of the node n2 can also return the pre-execution information of a batch of transactions to the caching process 2 for caching in a transaction queue to be commonly known after the pre-execution process finishes pre-execution of the batch of transactions.

The consensus process of the node n1 may invoke its caching process to sequentially read a plurality of transactions and related data thereof from a transaction queue to be consensus to generate a consensus proposal, where the consensus proposal may include, for example, pre-execution information corresponding to each of the plurality of transactions, a consensus sequence of the plurality of transactions (the consensus sequence of the plurality of transactions is the same as the pre-execution sequence of the plurality of transactions), and indication information of each of the plurality of transactions or each of the plurality of transactions (e.g., a summary value of each of the plurality of transactions). The node n2 may also calculate grouping information corresponding to the plurality of transactions based on the pre-execution information of each of the plurality of transactions indicated by the consensus proposal, and carry the grouping information in the consensus proposal, so that other nodes participating in consensus of the consensus proposal may group the plurality of transactions based on the grouping information.

After the consensus proposal is agreed, since the node n1 and the node n2 each receive the transaction from the user equipment connected thereto, the caching process 2 of the node n2 adds the transaction to the transaction queue to be processed according to the receiving sequence, and the pre-execution process 2 of the node n2 pre-executes each transaction in the transaction queue to be processed in sequence, the consensus process 2 of the node n2 can send the pre-execution information of the plurality of transactions to the control process 2 thereof according to the pre-execution sequence/consensus sequence of the plurality of transactions, and the control process 2 submits the state data of the corresponding block, which is part or all of the pre-execution information of the plurality of transactions, to the storage service 2, thereby obtaining the state root for generating the corresponding block and generating the block containing the state root and the plurality of transactions.

The node n1 may, for example, read, through its consensus process 1 and/or control process 1, the pre-execution information of each of the plurality of transactions from the consensus proposal generated by the node n2 during the consensus of the consensus proposal generated by the node n2 or after the consensus of the consensus proposal generated by the node n2, and group the plurality of transactions based on the pre-execution information of each of the plurality of transactions to obtain M (M is an integer greater than 1) transaction groups; or reading grouping information of the plurality of transactions from the consensus proposal and grouping the plurality of transactions based on the grouping information to obtain M transaction groups. For example, in the case where the pre-execution information includes a pre-execution read-write set, the consensus process 1 may receive a respective pre-execution read-write set of the plurality of transactions from a second node in the blockchain system, determine a read-write set conflict relationship between the plurality of transactions based on the pre-execution read-write set, and determine a front-to-back dependency relationship of at least some of the plurality of transactions based on the read-write set conflict relationship; and grouping the plurality of transactions according to the front-to-back dependency relationship to obtain the M transaction groups. Thereafter, the consensus process 1 may send the M transaction packets to the control process 1. For another example, the consensus process 1 may calculate grouping information based on the pre-execution information of each of the transactions, and send the grouping information, the transactions, and the pre-execution read-write sets corresponding to the transactions to the control process 1 of the node n 1; the plurality of transactions are further divided into M transaction groups based on the grouping information by the control process 1. After the M transaction packets are acquired, the control process 1 may perform task scheduling on N computing processes 1 in the node N1.

In the process of obtaining the M transaction groups, it is required to ensure that any two transactions in any two transaction groups do not conflict with each other. Any two transactions do not conflict with each other, specifically, any two transactions do not exist in one of the following cases: the pre-execution read set of one transaction includes the same Key as the pre-execution write set of another transaction, the pre-execution write set of one transaction and the pre-execution write set of another transaction include the same Key. For any two transactions with conflicts, the two transactions need to be divided into the same transaction group, in other words, if the pre-execution write sets of the two transactions respectively contain the same Key, namely, the two conflicting transactions are considered to access the same parameters and have conflicts, and the two transactions need to be divided into the same transaction group; if the pre-execution read set of one transaction of the arbitrary two transactions contains the same Key as the pre-execution write set of the other transaction, i.e., the arbitrary two transactions are considered to have access to the same parameters and have a conflict, the arbitrary two transactions need to be partitioned into the same transaction groups.

In an embodiment, the 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; under the condition that the block synchronous data returned by the F+1 nodes are the same, determining the correctness of the received block synchronous data; wherein the total number of nodes in the blockchain network is not less than 3F+1, and F is a positive integer.

According to the Bayesian consensus algorithm, when the total number of nodes in the blockchain network is N, the blockchain network can accommodate at most F fault nodes, N is not less than 3F+1, and F is a positive integer. Therefore, to ensure the correctness of the acquired block synchronization data, if the same block synchronization data is acquired from the f+1 nodes, the acquired block synchronization data must be correct. For example: there are 4 nodes in the blockchain network, then the correctness of the blocksync data can be determined as long as the same blocksync data is acquired from 2 nodes.

Further, when the block synchronization data returned by any node in the blockchain network is incorrect, adding the any node to a blacklist to avoid subsequent request of the synchronous block to the node in the blacklist.

Fig. 4 is a flowchart of a method for acquiring block synchronization data according to an exemplary embodiment, as shown in fig. 4, the method at least includes the following steps:

step 402, request f+1 nodes to synchronize the first block. Step 404, receiving the block synchronization data returned by the f+1 nodes.

Step 406, determining whether the block synchronization data is consistent.

If the block synchronization data returned by the f+1 nodes are the same, step 408a is performed to determine the correctness of the obtained block synchronization data, and the block synchronization data can be used for subsequent operations. If there are different block synchronization data in the block synchronization data returned by the f+1 nodes, step 408b is entered to add the node with incorrect block synchronization data to the blacklist. Specifically, the hash value corresponding to the block in the block synchronous data can be compared, so as to judge the correctness of the block synchronous data.

In this embodiment, on one hand, the correctness of the block synchronization data is further verified by the bayer consensus algorithm, and synchronization to an incorrect block is prevented. On the other hand, by adding the node with incorrect block synchronous data to the blacklist, the node is not trusted when the block is acquired later, and the acquisition efficiency of the block synchronous data is improved.

FIG. 5 is a flowchart of another block synchronization method applied to a second node in a blockchain network according to an exemplary embodiment, including at least the following steps, as shown in FIG. 5:

step 502, generating block synchronization data, where the block synchronization data includes first block information pre-stored by the second node and a key in a read-write set corresponding to a transaction included in the first block.

As described above, the block synchronization data further includes grouping information corresponding to the transactions contained in the first block, where the grouping information is generated based on the read-write set corresponding to each transaction in the first block.

Step 504, sending the generated block synchronization data to a first node in the blockchain network, so that the first node can: and reading a corresponding value from a local database according to a key contained in the read-write set information, executing the transaction in the first block according to the pre-read value, and writing the generated first block into the local database according to an execution result.

FIG. 6 is a schematic diagram of another blockchain system provided by an exemplary embodiment, the blockchain system 60 including a first node 61 and a second node 62, wherein:

the second node 62 is configured to generate block synchronization data, and send the generated block synchronization data to the first node 61, where the block synchronization data includes first block information pre-stored by the second node and a key in a read-write set corresponding to a transaction included in the first block;

the first node 61 is configured to, when the block synchronization data is acquired from the second node 62, read a corresponding value from a local database according to a key in the read-write set; and executing the transaction in the first block according to the pre-read value, and writing the generated first block into a local database according to the execution result.

As described above, the block synchronization data further includes grouping information corresponding to the transactions contained in the first block, where the grouping information is generated based on the read-write set corresponding to each transaction in the first block; the executing the transaction in the first block according to the pre-read value includes: the first node 61 obtains a plurality of transaction packets according to the packet information, and sends the transaction packets to different computing processes respectively, so as to implement parallel execution. Further, transactions in different ones of the plurality of transaction groups relate to contract parameters of different contracts.

As previously described, the acquiring block synchronization data from the second node 62 in the blockchain network includes: the first node requests F+1 nodes in the blockchain network to synchronize the first block respectively, and determines the correctness of the received block synchronization data under the condition that the block synchronization data returned by the F+1 nodes are the same; wherein the total number of nodes in the blockchain network is not less than 3F+1, and F is a positive integer.

As previously mentioned, the system further comprises: when the block synchronization data returned by any node in the blockchain network is incorrect, the first node adds the any node to a blacklist so as to avoid the subsequent request of the nodes in the blacklist for the synchronization block.

As described above, the writing the generated first block into the local database according to 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 a local database.

Fig. 7 is a schematic block diagram of an apparatus according to an exemplary embodiment. Referring to fig. 7, at the hardware level, the device includes a processor 702, an internal bus 704, a network interface 706, a memory 708, and a non-volatile storage 710, although other hardware required for other functions may be included. One or more embodiments of the present description may be implemented in a software-based manner, such as by the processor 702 reading a corresponding computer program from the non-volatile storage 710 into the memory 708 and then running. Of course, in addition to software implementation, one or more embodiments of the present disclosure do not exclude other implementation manners, such as a logic device or a combination of software and hardware, etc., that is, the execution subject of the following processing flow is not limited to each logic unit, but may also be hardware or a logic device.

As shown in fig. 8, fig. 8 is a block diagram of a block synchronization apparatus according to an exemplary embodiment, where the apparatus may be applied to the device shown in fig. 8 to implement the technical solution of the present specification; the apparatus is applied to a first node in a blockchain network, the apparatus comprising:

an obtaining unit 802, configured to obtain, from a second node in the blockchain network, block synchronization data, where the block synchronization data includes first block information and a key in a read-write set corresponding to a transaction included in the first block;

A reading unit 804, configured to read a corresponding value from a local database according to the key in the read-write set;

an execution unit 806 for executing the transaction in the first block according to the pre-read value and writing the generated first block into the local database according to the execution result

Optionally, the block synchronization data further includes grouping information corresponding to transactions contained in the first block, where the grouping information is generated based on a read-write set corresponding to each transaction in the first block; the execution unit 806 is specifically configured to:

acquiring a plurality of transaction groups according to the grouping information;

and respectively sending the transaction groups to different computing processes to realize parallel execution.

Optionally, transactions in different ones of the plurality of transaction groups relate to contract parameters of different contracts.

Optionally, the acquiring unit 802 is specifically configured to:

requesting synchronization of the first block from f+1 nodes in the blockchain network, respectively;

under the condition that the block synchronous data returned by the F+1 nodes are the same, determining the correctness of the received block synchronous data; wherein the total number of nodes in the blockchain network is not less than 3F+1, and F is a positive integer.

Optionally, the method further comprises:

and the adding unit 808 is configured to add any node in the blockchain network to a blacklist when the block synchronization data returned by the any node is incorrect, so as to avoid a subsequent request for a synchronization block from the node in the blacklist.

Optionally, the execution unit 806 is specifically configured to:

submitting state data corresponding to the first block;

and storing the first block, grouping information corresponding to each transaction in the first block and a read-write set to a local database.

As shown in fig. 9, fig. 9 is a block diagram of another block synchronization apparatus according to an exemplary embodiment, where the apparatus may be applied to the device shown in fig. 9 to implement the technical solution of the present specification; the apparatus is applied to a second node in a blockchain network, the apparatus comprising:

a generating unit 902, configured to generate block synchronization data, where the block synchronization data includes first block information pre-stored by the second node and a key in a read-write set corresponding to a transaction included in the first block;

a sending unit 904, configured to send the generated block synchronization data to a first node in the blockchain network, so that the first node: and reading a corresponding value from a local database according to a key contained in the read-write set information, executing the transaction in the first block according to the pre-read value, and writing the generated first block into the local database according to an execution result.

Optionally, the block synchronization data further includes grouping information corresponding to the transactions contained in the first block, where the grouping information is generated based on the read-write set corresponding to each transaction in the first block.

In the 90 s of the 20 th century, improvements to one technology could clearly be distinguished as improvements in hardware (e.g., improvements to circuit structures such as diodes, transistors, switches, etc.) or software (improvements to the process flow). However, with the development of technology, many improvements of the current method flows can be regarded as direct improvements of hardware circuit structures. Designers almost always obtain corresponding hardware circuit structures by programming improved method flows into hardware circuits. Therefore, an improvement of a method flow cannot be said to be realized by a hardware entity module. For example, a programmable logic device (Programmable Logic Device, PLD) (e.g., field programmable gate array (Field Programmable Gate Array, FPGA)) is an integrated circuit whose logic function is determined by the programming of the device by a user. A designer programs to "integrate" a digital system onto a PLD without requiring the chip manufacturer to design and fabricate application-specific integrated circuit chips. Moreover, nowadays, instead of manually manufacturing integrated circuit chips, such programming is mostly implemented by using "logic compiler" software, which is similar to the software compiler used in program development and writing, and the original code before the compiling is also written in a specific programming language, which is called hardware description language (Hardware Description Language, HDL), but not just one of the hdds, but a plurality of kinds, 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, RHDL (Ruby Hardware Description Language), etc., VHDL (Very-High-Speed Integrated Circuit Hardware Description Language) and Verilog are currently most commonly used. It will also be apparent to those skilled in the art that a hardware circuit implementing the logic method flow can be readily obtained by merely slightly programming the method flow into an integrated circuit using several of the hardware description languages described above.

The controller may be implemented in any suitable manner, for example, the controller may take the form of, for example, 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 (Application Specific Integrated Circuit, ASIC), programmable logic controllers, and embedded microcontrollers, examples of which include, but are not limited to, the following microcontrollers: ARC 625D, atmel AT91SAM, microchip PIC18F26K20, and Silicone Labs C8051F320, the memory controller may also be implemented as part of the control logic of the memory. Those skilled in the art will also appreciate that, in addition to implementing the controller in a pure computer readable program code, it is well possible to implement the same functionality by logically programming the method steps such that the controller is in the form of logic gates, switches, application specific integrated circuits, programmable logic controllers, embedded microcontrollers, etc. Such a controller may thus be regarded as a kind of hardware component, and means for performing various functions included therein may also be regarded as structures within the hardware component. Or even means for achieving the various functions may be regarded as either software modules implementing the methods or structures within hardware components.

The system, apparatus, module or unit set forth in the above embodiments may be implemented in particular by a computer chip or entity, or by a product having a certain function. One typical implementation device is a server system. Of course, the invention does not exclude that as future computer technology advances, the computer implementing the functions of the above-described embodiments may be, for example, a personal computer, a laptop computer, a car-mounted human-computer interaction device, a cellular telephone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.

Although one or more embodiments of the present description provide method operational steps as 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 recited in the embodiments is merely one way of performing the order of steps and does not represent a unique order of execution. When implemented in an actual device or end product, the instructions may be executed sequentially or in parallel (e.g., in a parallel processor or multi-threaded processing environment, or even in a distributed data processing environment) as illustrated by the embodiments or by the figures. The terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, it is not excluded that additional identical or equivalent elements may be present in a process, method, article, or apparatus that comprises a described element. For example, if first, second, etc. words are used to indicate a name, but not any particular order.

For convenience of description, the above devices are described as being functionally divided into various modules, respectively. Of course, when one or more of the present description is implemented, the functions of each module may be implemented in the same piece or pieces of software and/or hardware, or a module that implements the same function may be implemented by a plurality of sub-modules or a combination of sub-units, or the like. The above-described apparatus embodiments are merely illustrative, for example, the division of the units is merely a logical function division, and there may be additional divisions when actually implemented, for example, multiple units or components may be combined or integrated into another system, or some features may be omitted or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed with each other may be an indirect coupling or communication connection via some interfaces, devices or units, which may be in electrical, mechanical or other form.

The present 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 flow and/or block of the flowchart illustrations and/or block diagrams, and combinations of flows and/or blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may 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, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

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

The memory may include volatile memory in a computer-readable medium, random Access Memory (RAM) and/or nonvolatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of computer-readable media.

Computer readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of storage media for a computer 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 technology, read only compact disc read only memory (CD-ROM), digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage, graphene storage or other magnetic storage devices, or any other non-transmission medium, which can be used to store information that can be accessed by a computing device. Computer-readable media, as defined herein, does not include transitory computer-readable media (transmission media), such as modulated data signals and carrier waves.

One skilled in the relevant art will recognize that one or more embodiments of the present description may be provided as a method, system, or computer program product. Accordingly, one or more embodiments of the present description may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Moreover, one or more embodiments of the present description can take the form of a computer program product on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) having computer-usable program code embodied therein.

One or more embodiments of the present specification may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. One or more embodiments of the present specification may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.

In this specification, each embodiment is described in a progressive manner, and identical and similar parts of each embodiment are all referred to each other, and each embodiment mainly describes differences from other embodiments. In particular, for system embodiments, since they are substantially similar to method embodiments, the description is relatively simple, as relevant to see a section of the description of method embodiments. In the description of the present specification, a description referring to terms "one embodiment," "some embodiments," "examples," "specific examples," or "some examples," etc., means that a particular feature, structure, material, or characteristic described in connection with the embodiment or example is included in at least one embodiment or example of the present specification. In this specification, schematic representations of the above terms are not necessarily directed to the same embodiment or example. Furthermore, the particular features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples. Furthermore, the different embodiments or examples described in this specification and the features of the different embodiments or examples may be combined and combined by those skilled in the art without contradiction.

The foregoing is merely an example of one or more embodiments of the present specification and is not intended to limit the one or more embodiments of the present specification. Various modifications and alterations to one or more embodiments of this description will be apparent to those skilled in the art. Any modification, equivalent replacement, improvement, or the like, which is within the spirit and principles of the present specification, should be included in the scope of the claims.

Claims

1. A block synchronization method applied to a first node in a blockchain network, the method comprising:

2. The method of claim 1, the block synchronization data further comprising grouping information corresponding to transactions contained in the first block, the grouping information generated based on read-write sets corresponding to transactions in the first block; the executing the transaction in the first block according to the pre-read value includes:

3. The method of claim 2, transactions in different ones of the plurality of transaction groups involving contract parameters of different contracts.

4. The method of claim 1, the obtaining block synchronization data from a second node in the blockchain network, comprising:

5. The method of claim 4, the method further comprising:

and when the block synchronization data returned by any node in the block chain network is incorrect, adding the any node to a blacklist so as to avoid the subsequent request of the nodes in the blacklist for synchronizing blocks.

6. The method of claim 1, the writing the generated first block to a local database according to the execution result, comprising:

Submitting state data corresponding to the first block;

7. A block synchronization method applied to a second node in a blockchain network, the method comprising:

8. The method of claim 7, the block synchronization data further comprising grouping information corresponding to transactions contained in the first block, the grouping information generated based on read-write sets corresponding to transactions in the first block.

9. A blockchain system comprising a first node and a second node, wherein:

10. The system of claim 9, the block synchronization data further comprising grouping information corresponding to transactions contained in the first block, the grouping information generated based on read-write sets corresponding to transactions in the first block; the executing the transaction in the first block according to the pre-read value includes:

the first node obtains a plurality of transaction groups according to the grouping information, and sends the transaction groups to different computing processes respectively so as to realize parallel execution.

11. The system of claim 10, transactions in different ones of the plurality of transaction groups involving contract parameters of different contracts.

12. The system of claim 9, the obtaining block synchronization data from a second node in the blockchain network, comprising:

the first node requests F+1 nodes in the blockchain network to synchronize the first block respectively, and determines the correctness of the received block synchronization data under the condition that the block synchronization data returned by the F+1 nodes are the same; wherein the total number of nodes in the blockchain network is not less than 3F+1, and F is a positive integer.

13. The system of claim 9, the system further comprising:

when the block synchronization data returned by any node in the blockchain network is incorrect, the first node adds the any node to a blacklist so as to avoid the subsequent request of the nodes in the blacklist for the synchronization block.

14. The system of claim 9, the writing the generated first block to the local database according to the execution result, comprising:

the first node submits the state data corresponding to the first block, and stores the first block, grouping information corresponding to each transaction in the first block and a read-write set to a local database.

15. A block synchronization apparatus for use with a first node in a blockchain network, the apparatus comprising:

An acquisition unit: obtaining block synchronization data from a second node in the block chain network, wherein the block synchronization data comprises first block information and keys in a read-write set corresponding to transactions contained in the first block;

16. A block synchronization apparatus for use with a second node in a blockchain network, the apparatus comprising:

17. An electronic device, comprising:

a processor;

a memory for storing processor-executable instructions;

wherein the processor is configured to implement the method of any of claims 1-8 by executing the executable instructions.

18. A computer readable storage medium having stored thereon computer instructions which, when executed by a processor, implement the steps of the method of any of claims 1-8.