A data processing method in a blockchain and a blockchain node device

Abstract

An embodiment of this specification provides a data processing method in a blockchain and a blockchain node. The method is executed by a first node in a first blockchain and includes: sequentially executing transactions in N transaction sets in chronological order, and the execution of the transactions in the N transaction sets causes the states of M first accounts to change; obtaining the signature information of each first account for its state; generating a first proof according to the root of the first world state, the root of the second world state, and the M signature information, where the first proof is used to prove that the first world state is generated after executing the transactions in the N transaction sets based on the second world state, and the second world state is the world state before executing the transactions in the N transaction sets; storing the root of the first world state and the first proof in a second blockchain. When improving the overall expansion of the blockchain network, this method can not limit the number of participants and has an infinite data compression ratio.

Description

Technical Field

[0001] The embodiments of this specification belong to the technical field of blockchain, and particularly relate to a data processing method in a blockchain and a blockchain node device. Background Art

[0002] Blockchain is a new application mode of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanism, and encryption algorithms. In a blockchain system, data blocks are combined into a chained data structure in a sequential connection manner according to the time sequence, and the data is guaranteed to be tamper-proof and unforgeable by cryptographic means. Due to the characteristics of decentralization, information immutability, and autonomy of the blockchain, the blockchain has received more and more attention and applications.

[0003] Currently, all transaction and status data in a blockchain network need to be synchronized and stored in all nodes, and its storage cost is much greater than that of a traditional database. Therefore, it is unrealistic to store all data in a single blockchain network. Generally, a Layer 2 solution can be adopted to reduce the data storage on Layer 1, so as to improve the scalability and throughput of Layer 1. Summary of the Invention

[0004] The embodiments of this specification aim to provide a data processing method in a blockchain and a blockchain node device, which can not limit the number of participants and have an infinite data compression ratio when improving the overall expansion of the blockchain network.

[0005] To achieve the above object, the first aspect of this specification provides a data processing method in a blockchain. The method is executed by a first node in a first blockchain, and the method includes:

[0006] Sequentially execute the transactions in N transaction sets in chronological order, where N≥1. The execution of the transactions in the N transaction sets causes the state changes of M first accounts, where M≥1;

[0007] Obtain the signature information of each of the first accounts for its state;

[0008] Generate a first proof according to the root of the first world state, the root of the second world state, and the M signature information. The first proof is used to prove that the first world state is generated after executing the transactions in the N transaction sets on the basis of the second world state, and the second world state is the world state before executing the transactions in the N transaction sets;

[0009] Store the root of the first world state and the first proof in a second blockchain.

[0010] The second aspect of this specification provides a blockchain node device, including:

[0011] A processing unit configured to sequentially execute transactions in N transaction sets in chronological order, where N ≥ 1, and the execution of the transactions in the N transaction sets causes the status changes of M first accounts, where M ≥ 1;

[0012] An acquisition unit configured to acquire the signature information of each of the first accounts for their status;

[0013] The processing unit is further configured to generate a first proof based on the root of the first world state, the root of the second world state, and the M signature information, and the first proof is used to prove that the first world state is generated after executing the transactions in the N transaction sets on the basis of the second world state, and the second world state is the world state before executing the transactions in the N transaction sets;

[0014] A storage unit configured to store the root of the first world state and the first proof in a second blockchain.

[0015] The third aspect of this specification provides a blockchain system, including: a first blockchain and a second blockchain, where the first node in the first blockchain is used for the method provided in the first aspect of the embodiments of this specification, and the second blockchain is used to store the root of the first world state and the first proof transmitted by the first node.

[0016] The fourth aspect of this specification provides a computer-readable storage medium, on which a computer program is stored. When the computer program is executed in a computing device, the computing device executes the method described in the first aspect above.

[0017] The fifth aspect of this specification provides a computing device, including a memory and a processor. A computer program is stored in the memory, and when the processor executes the computer program, the method described in the first aspect above is implemented.

[0018] Through the method and node provided in one or more embodiments of this specification, a state transition proof can be generated in a blockchain based on the signature information of the accounts that generate status changes for their own asset information, and the conversion proof and the root of the latest world state tree can be transmitted to another blockchain for storage. Thus, it realizes unlimited number of participating parties, has the same security as Layer1, and has an infinite data compression ratio, bringing infinite possibilities for the overall expansion of the blockchain network. Description of the Drawings

[0019] To more clearly illustrate the technical solutions of the embodiments of this specification, the following will briefly introduce the accompanying drawings required for the description of the embodiments. Obviously, the accompanying drawings in the following description are only some embodiments recorded in this specification. For those of ordinary skill in the art, without creative efforts, other accompanying drawings can also be obtained based on these drawings.

[0020] Figure 1 is a schematic diagram of data transmission based on a state channel in an embodiment of this specification;

[0021] Figure 2 is a network schematic diagram of a blockchain network in an embodiment of this specification;

[0022] Figure 3 is a schematic diagram of a simplified state tree in an embodiment of this specification;

[0023] Figure 4 is a flowchart of a data transmission method in a blockchain in an embodiment of this specification;

[0024] Figure 5 is a schematic diagram of the structure of a blockchain node in an embodiment of this specification;

[0025] Figure 6 is a schematic diagram of the architecture of a blockchain system in an embodiment of this specification. Specific Embodiments

[0026] To enable those skilled in the art to better understand the technical solutions in this specification, the following will clearly and completely describe the technical solutions in the embodiments of this specification in conjunction with the accompanying drawings in the embodiments of this specification. Obviously, the described embodiments are only a part of the embodiments of this specification, rather than all the embodiments. Based on the embodiments in this specification, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the scope of protection of this specification.

[0027] Exemplarily, the Layer2 solution refers to off-chain expansion. It establishes a second-layer transaction network outside the main chain, so it is called "Layer2". Among them, the main chain can be called "Layer1". In the Layer2 solution, transactions can be executed in Layer2, and data related to the transactions can be stored in Layer1. Generally, in the Layer2 solution, solutions such as state channels and Rollups can be adopted.

[0028] Among them, for the state channel solution, taking the transaction between Alice and Bob as an example, as Figure 1As shown, it can be described as the following steps: First, Alice and Bob each store a sum of money in the smart contract on Layer1, recording the balances of the two respectively: {Alice: 10 yuan, Bob: 5 yuan}. Then, a transaction can occur between Alice and Bob. For example, Alice wants to pay Bob a transaction of 2 yuan. So they update the balances of the two to: {Alice: 8 yuan, Bob: 7 yuan, Date: XXX}, and both of them sign this balance distribution plan. After that, Bob wants to pay Alice 3 yuan. So they update the balances of the two to: {Alice: 11 yuan, Bob: 4 yuan, Date: XXX}, and both of them sign this balance distribution plan. And so on. As long as the amount paid by Alice and Bob is sufficient in the balance of the channel and they always cooperate with each other in signing, they can keep paying like this. Finally, when one of them, say Bob, intends to withdraw the balance, at this time, Bob can submit the balance distribution plan with the signatures of both parties to the smart contract in the blockchain. After the signature verification passes, the smart contract transfers the money for both parties according to the latest balance to complete the settlement. From this, it can be seen that the state channel solution has almost an infinite compression ratio. In theory, Alice and Bob can conduct an infinite number of off-chain transactions (an infinite number of different balance distribution plans) and finally settle only one transaction on-chain. Moreover, the smart contract in the blockchain can faithfully settle according to the latest balance distribution plan, that is, the security of the two-way payment channel in Layer2 is guaranteed by Layer1. However, when adopting the state channel solution, the participating parties are easily restricted because the update of the balance distribution plan requires the signatures of all parties. Then it is less likely to have too many participating parties, otherwise the complexity will increase exponentially.

[0029] For the Rollup solution, its working principle is as follows: calculations are performed off-chain, and the calculation results are stored on-chain. Generally, a world state tree is used off-chain to store account states. At the same time, user transactions can be collected off-chain and each transaction can be executed. A new world state tree can be generated after the transaction execution is completed. Then, based on the root of the original world state, the root of the latest world state, all the transactions, and using zero-knowledge proof algorithms, such as the zk-stark algorithm, the zk-snark algorithm, etc., a state transition proof Proof for proving the correctness of the off-chain state transition can be generated. Finally, all the transactions, the state transition proof Proof, the root of the original world state, and the root of the latest world state can be packaged and submitted to the chain. Among them, after the smart contract on the chain verifies that the state transition proof Proof is passed, the new state can be written to the chain. At this time, the smart contract on the chain does not need to verify the legality of each transaction separately, but only needs to verify whether the state transition proof Proof is valid, reducing the resource consumption on the chain. It can be seen that in the Rollup solution, there is no longer a specific limitation on the participating parties within a certain range; at the same time, ZKRollup based on zero-knowledge proof has the same security as Layer1, and its state transition proof completely depends on mathematical proofs and the state of Layer1. However, since the state transition proof Proof in Rollup needs to package and compress all the transactions, in order to fully reflect the original transactions and the state transition proof Proof, this makes its compression ratio have a certain upper limit.

[0030] In view of the above problems, in the embodiments of this specification, a data processing method in a blockchain is provided, which combines the state channel solution and the Rollup solution. In Layer2, a state transition proof is generated based on the signature information of the account that generates the state change for its own asset information, and the transition proof and the root of the latest world state tree are transmitted to Layer1, achieving the ability to not limit the number of participating parties, having the same security as Layer1, and having an infinite data compression ratio, bringing infinite possibilities for the overall expansion of the blockchain network.

[0031] Exemplarily, Figure 2 is a schematic diagram of the architecture of a blockchain network provided in the embodiments of this specification. As Figure 2 shown, this blockchain contains, for example, 10 nodes. Each node can be any device, server, or device cluster with computing and processing capabilities. The connections between the nodes schematically represent P2P (Peer to Peer) connections.

[0032] The full ledger can be stored on these nodes, that is, the states of all blocks and all accounts are stored. Among them, each node in the blockchain can generate the same state in the blockchain by executing the same transactions, and each node in the blockchain can store the same state database. It can be understood that Figure 2 Although 10 nodes are shown in Figure 2 , the embodiments of this specification are not limited thereto, but may include other numbers of nodes. Specifically, the nodes included in the blockchain can meet the requirements of Byzantine Fault Tolerance (BFT). The so-called Byzantine Fault Tolerance requirements can be understood as that Byzantine nodes can exist inside the blockchain, but the blockchain does not exhibit Byzantine behavior externally. Generally, in some Byzantine Fault Tolerance algorithms, it is required that the number of nodes is greater than (3f + 1), where f is the number of Byzantine nodes. For example, the Practical Byzantine Fault Tolerance (PBFT) algorithm.

[0033] Transactions in the blockchain field can refer to task units that are executed and recorded in the blockchain. Transactions usually include a sending field (From), a receiving field (To), and a data field (Data). Among them, in the case of a transfer transaction, the From field represents the account address that initiates the transaction (that is, initiates the transfer task to another account), the To field represents the account address that receives the transaction (that is, receives the transfer), and the Data field includes the transfer amount. In the case of a transaction invoking a smart contract in the blockchain, the From field represents the account address that initiates the transaction, the To field represents the account address of the contract invoked by the transaction, and the Data field includes data such as the function name in the invoked contract and the input parameters to the function, so as to obtain the code of the function from the blockchain and execute the code of the function when the transaction is executed.

[0034] The blockchain can provide the function of smart contracts. Smart contracts on the blockchain are contracts that can be triggered and executed by transactions on the blockchain system. Smart contracts can be defined in the form of code. Invoking a smart contract in Ethereum is to initiate a transaction pointing to the smart contract address, so that each node in the Ethereum network runs the smart contract code distributively. It should be noted that in addition to smart contracts that can be created by users, smart contracts can also be set by the system in the genesis block. Such contracts are generally called system contracts. Generally, some data structures, parameters, attributes, and methods of the blockchain can be set in the system contract. In addition, an account with system administrator privileges can create or modify system-level contracts (simply referred to as system contracts). Among them, the system contract can be used to add data structures for different services in the blockchain.

[0035] In the scenario of deploying a contract, for example, Bob sends a transaction containing information for creating a smart contract (i.e., deploying a contract) to the blockchain as shown in Figure 2 . The data field of this transaction includes the code of the contract to be created (such as bytecode or machine code), and the to field of the transaction is empty to indicate that this transaction is used to deploy a contract. After the nodes reach an agreement through the consensus mechanism, the contract address "0x6f8ae93..." of the contract is determined. Each node adds a contract account corresponding to the contract address of the smart contract to the state database, allocates the state storage corresponding to this contract account, and saves the contract code in the state storage of this contract, thus the contract is successfully created.

[0036] In the scenario of calling a contract, for example, Bob sends a transaction for calling a smart contract to the blockchain as shown in Figure 2 . The from field of this transaction is the address of the account of the transaction initiator (i.e., Bob), and "0x6f8ae93..." in the to field represents the address of the smart contract to be called. The data field of the transaction includes the method and parameters for calling the smart contract. After the transaction is consensus in the blockchain, each node in the blockchain can execute this transaction respectively, thus executing this contract respectively, and updating the state database based on the execution of this contract.

[0037] In addition, after a smart contract is deployed on the blockchain, a corresponding contract account will be generated. This contract account generally has some states, which are defined by the state variables in the smart contract and new values are generated when the smart contract is created and executed. Among them, the contract account can be used to store the states related to the smart contract. Once an event triggers the terms in the smart contract (meets the execution conditions), the code can be automatically executed. In the blockchain, the relevant states of the contract are saved in the storage trie, and the hash value of the root node of the storage trie is stored in the above storage_root, thus locking all the states of this contract to this contract account through the hash. The storage trie is also an MPT tree structure, which stores the key-value mapping from the state address to the state value. From the root node to the leaf node of the storage trie, the address of a state is stored, and the value of a state is stored in a leaf node.

[0038] In addition, several external accounts may also be involved in the blockchain system. An external account can be understood as a user's account, such as an Ethereum owner account. The design of external accounts and contract accounts is actually a mapping from account addresses to account states. The state of an account usually includes fields such as nonce, balance, storage_root, and codeHash. Nonce and balance exist in both external accounts and contract accounts. The codeHash and storage_root attributes are generally only valid for contract accounts. Among them, nonce can be understood as a counter; for an external account, this number represents the number of transactions sent from the account address; for a contract account, it is the number of contracts created by the account. Balance can be understood as the account balance. Storage_root can be understood as the hash of the root node of an MPT tree, which organizes the storage of the state variables of the contract account. CodeHash can be understood as the hash value of the smart contract code; for a contract account, this is the code of the smart contract that has been hashed and stored; for an external account, since it does not include a smart contract, the codeHash field can generally be an empty string / all 0 string.

[0039] MPT stands for Merkle Patricia Tree, which is a tree structure that combines Merkle Tree and Patricia Tree (a more space-saving Trie tree, also known as a dictionary tree). In the Merkle Tree algorithm, a Hash value is calculated for each transaction, and then they are connected in pairs and hashed again until the top-level Merkle root. In Ethereum, an improved MPT tree is adopted, such as a 16-way tree structure, which is usually simply referred to as the MPT tree.

[0040] The data structure of the Ethereum MPT tree includes a state trie. The state trie contains key-value pairs of the storage content corresponding to each account in the Ethereum network. The "key" in the state trie can be a 160-bit identifier (the address of the Ethereum account), and this account address is distributed in the storage from the root node to the leaf nodes of the state trie. The "value" in the state trie is generated by encoding the information of the Ethereum account (using the Recursive-Length Prefix encoding (RLP) method). As mentioned above, for an external account, the value includes nonce and balance; for a contract account, the value includes nonce, balance, codehash, and storage_root.

[0041] Exemplarily,Figure 3 It is a schematic diagram of a simplified state tree. There are several external accounts in the blockchain system, such as Figure 3 the externally numbered External Account 1, External Account 2, ... in Figure 3 In addition, there are several contract accounts in the blockchain system, such as Figure 3 the contract accounts numbered Contract Account 1, Contract Account 2, ... in

[0042] Continue to refer to Figure 2 , Figure 2 The blockchain network shown in Figure 2 can be composed of a main chain and two side chains. Different side chains can be associated with different services. For example, side chain a can be associated with the payment service related to Alipay, and side chain b can be associated with the storage service related to banks, etc. Smart contracts can be configured in both the main chain and the side chains. Figure 2 The main chain shown in

[0043] Exemplarily, Figure 4 is a schematic flowchart of a data processing method in a blockchain provided in an embodiment of this specification. Among them, the data processing method in this blockchain mainly involves side chains, the main chain, and user terminals logged in with accounts. The accounts involved in the user terminals logged in with accounts can be accounts corresponding to services related to side chains. For example, when the side chain is related to the payment service related to Alipay, the account can be the user's Alipay account. Figure 4 The timing for the side chain shown in

[0044] to submit data to the main chain is: submit once every F transactions are executed. Figure 4 As shown in

[0045] In S402, node A in the side chain collects F transactions, where F ≥ 1.

[0046] In this embodiment, after a user terminal logged in with an account conducts a business (such as a transfer business, etc.), the corresponding transaction can be sent to node A in the side chain. In this way, node A can collect the transactions corresponding to each account. Exemplarily, the value of F can be preset, such as 100, 200, etc.

[0047] In some embodiments, after receiving a transaction, node A can verify the legality of the transaction. For example, the transaction can include the transaction content and a digital signature generated by the initiator based on its own account private key, and node A can verify the digital signature in the received transaction through the account public key corresponding to the initiator to determine that the received district transaction has not been tampered with during the transmission process, improving the security of blockchain transactions.

[0048] In S404, node A in the side chain executes F transactions, generates a new world state tree, and determines E accounts with state changes from the original world state tree and the new world state tree, where E≥1.

[0049] In this embodiment, after node A in the side chain collects F transactions, it can sequentially execute these F transactions in chronological order, that is, batch process the transactions it collects. Among them, after node A executes, the world state tree T1 (i.e., the original world state tree) in the side chain can be transformed into the world state tree T2 (i.e., the new world state tree). Exemplarily, the world state tree T1 can be the latest obtained world state tree among the executions of the F transactions. Additionally, after generating the world state tree T2, the world state tree can be stored in the side chain.

[0050] After obtaining the world state tree T2, node A can determine E accounts with state changes after executing the F transactions based on the world state tree T1 and the world state tree T2, where E≥1. Exemplarily, the world state tree T1 and the world state tree T2 can be compared to determine the E accounts with state changes. Additionally, the accounts with state changes can also be recorded during the execution of the transactions to obtain the E accounts.

[0051] In S406, node A in the side chain generates a state transition proof P1 based on the F transactions, the root of the world state tree T1, and the root of the world state tree T2. The state transition proof P1 is used to prove that the root of the world state tree T2 is correct.

[0052] In this embodiment, after obtaining the world state tree T2, node A can generate a state transition proof P1 based on F transactions, the root of the world state tree T1, and the root of the world state tree T2. The state transition proof P1 is used to prove that the transition from the original world state to the new world state is correct; that is to say, the state transition proof P1 can be used to prove that the new world state is generated after executing F transactions on the basis of the original world state.

[0053] In some embodiments, node A can process F transactions, the root of the world state tree T1, and the root of the world state tree T2 based on zero-knowledge proof algorithms, such as the zk-stark algorithm, the zk-SNARKs algorithm, etc., to generate the state transition proof P1. Exemplarily, node A can call the prove function in the smart contract in the side chain and use F transactions, the root of the world state tree T1, and the root of the world state tree T2 as the inputs of the proof function, so that the proof function outputs the state transition proof P1. The proof function can be obtained from pre-compiled gate circuits. Exemplarily, the inputs of the gate circuit can be F transactions, the root of the world state tree T1, and the root of the world state tree T2, and the output of the gate circuit can be the state transition proof P1. The gate circuit can be, but is not limited to, a PLONK circuit.

[0054] In S408, node A in the side chain sends a request for obtaining the signature information of each account for its status to the terminals logged in with each of the E accounts. The request includes the state transition proof P1.

[0055] In this embodiment, after obtaining the state transition proof P1, node A in the side chain can obtain the signature information of each of the E accounts for its respective status. The signature information can represent the approval of the corresponding account for the change of its internal asset information. When node A obtains the signature information of each of the E accounts, it can send a request for obtaining the signature information of each account for its status to the terminals logged in with each of the E accounts respectively. The request can include the state transition proof P1.

[0056] In S410, the terminals logged in with each of the E accounts all send the corresponding signature information to node A in the side chain.

[0057] In this embodiment, after the terminals logged in with each of the E accounts obtain the request sent by node A, they can all learn from the state transition proof P1 carried in the request that the transition from the original world state to the new world state is correct. At the same time, each of the E accounts can sign its own asset information to obtain the corresponding signature information. Moreover, the signature information is transmitted to node A through the terminals logged in with the accounts, so that node A obtains the E signature information. In some embodiments, after obtaining the E signature information, node A can delete the F transactions it executed to save storage space.

[0058] In S412, node A in the side chain generates a state transition proof P2 based on the E signature information, the root of the original world state tree, and the root of the new world state tree. The state transition proof P2 is used to prove that the transition from the original world state to the new world state is correct.

[0059] In this embodiment, node A can process the E signature information, the root of the world state tree T1 (i.e., the original world state tree), and the root of the world state tree T2 (i.e., the new world state tree) based on the aforementioned zero-knowledge proof algorithm to generate the state transition proof P2. Among them, the state transition proof P2 can be used to prove that the transition from the original world state to the new world state is correct; that is to say, the state transition proof P2 can be used to prove that the new world state is generated after executing F transactions on the basis of the original world state. Exemplarily, node A can call the prove function in the smart contract in the side chain and use the E signature information, the root of the world state tree T1, and the root of the world state tree T2 as the input of the prove function, so that the prove function outputs the state transition proof P2. Among them, the prove function can be obtained from pre-compiled gate circuits. Exemplarily, the prove function can be, but is not limited to, the same as the function for generating the state transition proof P1 described above.

[0060] In S414, node A in the side chain submits the root of the new world state and the state transition proof P2 to the main chain.

[0061] In this embodiment, after obtaining the state transition proof P2, node A can submit the root of the new world state and the state transition proof P2 to the main chain for storage by the main chain.

[0062] In some embodiments, after the main chain obtains the root of the new world state and the state transition proof P2, it can verify the correctness of the state transition proof P2. Among them, when verifying, the nodes in the main chain can call the verify function in the smart contract in the main chain, and process the root of the world state tree T1 (i.e., the original world state), the root of the world state tree T2 (i.e., the new world state), and the state transition proof P2 to verify the correctness of the state transition proof P2. It should be understood that since the state transition proof P2 is used to prove that the transition from the original world state to the new world state is correct, when the main chain verifies through the verification function that the state transition proof P2 is correct, the main chain can determine that the new world state obtained in the side chain is correct. Exemplarily, the verification function can also be obtained from pre-compiled gate circuits. Exemplarily, the gate circuits required for the verification function and the proof function can be the same gate circuit.

[0063] Thus, the data processing method in the blockchain provided in this embodiment combines the state channel solution and the Rollup solution. In Layer 2, a state transition proof is generated based on the signature information of the account that generates the state change for its own asset information, and the root of the latest world state tree and the state transition proof are transmitted to Layer 1, achieving the ability to not limit the number of participants. Moreover, since the amount of data of the signature information is very small, an infinite data compression ratio can be achieved, which brings infinite possibilities for the overall expansion of the blockchain network. In addition, since all state transitions rely on zero-knowledge proofs, the security of this solution is also relatively high.

[0064] In some embodiments, Figure 4 In addition to submitting data to the main chain once every F transactions are executed as shown, the timing for the side chain to submit data to the main chain can also be once after every N transaction sets are executed, where N ≥ 2; each transaction set can include F transactions. Among them, the data submitted to the main chain after executing N transaction sets can include: the root of the world state tree obtained after executing N transactions and the latest generated state transition proof. The latest state transition proof can be used to prove that the world state after executing N transaction sets is correct compared to the world state before executing N transaction sets.

[0065] Among them, the node A in the side chain can sequentially execute the transactions in N transaction sets in chronological order. In addition, after executing the transactions in each transaction set, the node A in the side chain can generate a new state transition proof based on the state transition proof generated in the previous time, the signature information of the account whose state changes after executing the transaction this time, the root of the new world state generated after executing the transaction this time, and the root of the world state obtained most recently before executing the transaction this time. The new state transition proof can be used to prove that the new world state obtained from the latest world state between the transactions in the first transaction set among the N transaction sets to the new world state obtained after executing the transaction this time is correct.

[0066] For example, if N = 4, after executing the first transaction set, the state transition proof P11 can be obtained based on the signature information of the account whose state changes after executing the transaction, the world state before executing the transaction this time, and the world state after executing the transaction this time. After executing the second transaction set, the state transition proof P12 can be obtained based on the signature information of the account whose state changes after executing the transaction, the world state before executing the transaction this time, the world state after executing the transaction this time, and the state transition proof P11. After executing the third transaction set, the state transition proof P13 can be obtained based on the signature information of the account whose state changes after executing the transaction, the world state before executing the transaction this time, the world state after executing the transaction this time, and the state transition proof P12. After executing the fourth transaction set, the state transition proof P14 can be obtained based on the signature information of the account whose state changes after executing the transaction, the world state before executing the transaction this time, the world state after executing the transaction this time, and the state transition proof P13. The state transition proof P14 can be used to prove that the new world state obtained from the latest world state before executing the first transaction set to the world state obtained after executing the fourth transaction set is correct; that is to say, the state transition proof P14 can be used to prove that the new world state is generated after executing 4 transaction sets on the basis of the latest world state before executing the first transaction set.

[0067] Based on the same concept as the foregoing method embodiment, an embodiment of the present specification also provides a blockchain node device.

[0068] Exemplarily, Figure 5 is a schematic structural diagram of a blockchain node device provided in an embodiment of the present specification. As Figure 5 shown, the blockchain node device 500 includes: a processing unit 510, an acquisition unit 520, and a storage unit 530. Among them, the processing unit 510 is configured to sequentially execute the transactions in N transaction sets in chronological order, N ≥ 1, and the execution of the transactions in the N transaction sets causes the states of M first accounts to change, M ≥ 1;

[0069] An obtaining unit 520, configured to obtain the signature information of each first account for its status;

[0070] A processing unit 510, further configured to generate a first proof according to the root of the first world state, the root of the second world state, and M signature information, where the first proof is used to prove that the first world state is generated after executing the transactions in the N transaction sets on the basis of the second world state, and the second world state is the world state before executing the transactions in the N transaction sets;

[0071] A storage unit 530, configured to store the root of the first world state and the first proof into the second blockchain.

[0072] In some embodiments, when N = 1, the processing unit 510 is further configured to: input the root of the first world state, the root of the second world state, and M signature information into a preset proof function to generate a first proof.

[0073] In some embodiments, when N≥2,

[0074] The processing unit 510 is further configured to: execute the transactions in the Nth transaction set;

[0075] The obtaining unit 520 is further configured to obtain the signature information of Q first accounts;

[0076] The processing unit 510 is further configured to: generate a first proof according to the signature information of Q first accounts, the second proof generated by the (N - 1)th transaction set, the root of the first world state, and the root of the third world state, where the second proof is used to prove that the third world state is generated after executing the transactions in the (N - 1)th transaction set on the basis of the world state obtained by executing the (N - 2)th transaction set, and the third world state is the world state obtained by executing the transactions in the (N - 1)th transaction set.

[0077] In some embodiments, the processing unit 510 is further configured to:

[0078] Input the signature information of Q first accounts, the second proof, the root of the first world state, and the root of the third world state into a preset proof function to generate a first proof.

[0079] In some embodiments, the N transaction sets include a first transaction set, and the execution of the transactions included in the first transaction set causes the status changes of S first accounts, where 1≤S≤M;

[0080] The processing unit 510 is further configured to: generate a third proof according to the transactions included in the first transaction set, the fourth world state, and the fifth world state, where the fourth world state is the world state obtained after executing the transactions in the first transaction set, the fifth world state is the latest world state obtained before executing the transactions in the first transaction set, and the third proof is used to prove that the fourth world state is generated by executing the transactions in the first transaction set based on the fifth world state;

[0081] The blockchain node device further includes:

[0082] A communication unit (not shown in the figure), configured to send a first request for obtaining signature information to each terminal corresponding to the S first accounts, where the first request includes the third proof;

[0083] The communication unit is further configured to obtain the signature information returned by each terminal corresponding to the S first accounts.

[0084] It should be understood that the above device is used to execute the method in the above embodiment. For the corresponding program module in the device, its implementation principle and technical effect are similar to the description in the above method. The working process of the device can refer to the corresponding process in the above method and will not be elaborated here.

[0085] Based on the same concept as the foregoing method embodiment, an embodiment of the present specification also provides a blockchain system.

[0086] Exemplarily, Figure 6 is a schematic architecture diagram of a blockchain system provided in an embodiment of the present specification. As Figure 6 shown, the blockchain system 600 includes a first blockchain 610 and a second blockchain 620. Among them, the first node in the first blockchain 610 is used to implement the foregoing method, and the second blockchain is used to store the root of the first world state and the first proof transmitted by the first node. Exemplarily, the first blockchain 610 can be Figure 4 the side chain shown in Figure 4 and the second blockchain 620 can be Figure 4 the main chain described in

[0087] In some embodiments, the second blockchain is further used to input the root of the first world state, the root of the second world state, and the first proof into a preset verification function to verify the correctness of the first proof.

[0088] In the 1990s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to circuit structures such as diodes, transistors, switches, etc.) or software improvements (improvements to method flows). However, with the development of technology, many method flow improvements today can be regarded as direct improvements to hardware circuit structures. Designers almost always obtain the corresponding hardware circuit structure by programming the improved method flow into the hardware circuit. Therefore, it cannot be said that an improvement to a method flow cannot be implemented using a hardware entity module. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logical function is determined by the user programming the device. Designers can program themselves to "integrate" a digital system onto a single PLD, without having to ask a chip manufacturer to design and fabricate a dedicated integrated circuit chip. Moreover, nowadays, instead of manually fabricating integrated circuit chips, this programming is mostly implemented using "logic compiler" software, which is similar to the software compiler used in program development and writing. The original code before compilation also has to be written in a specific programming language, which is called a Hardware Description Language (HDL), and there is not just one kind of HDL, but many 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. Currently, the most commonly used are VHDL (Very-High-Speed Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should also be aware that by simply performing a little logical programming on the method flow using the above-mentioned several hardware description languages and programming it into the integrated circuit, it is easy to obtain the hardware circuit that implements the logical method flow.

[0089] The controller can be implemented in any suitable manner. For example, the controller can take the form of, for example, a microprocessor or a processor and a computer-readable medium storing computer-readable program code (such as software or firmware) executable by the (micro)processor, logic gates, switches, an application specific integrated circuit (ASIC), a programmable logic controller, and an embedded microcontroller. Examples of the controller include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicone Labs C8051F320. The memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art also know that in addition to implementing the controller in the form of pure computer-readable program code, it is entirely possible to logically program the method steps to enable the controller to be implemented in the form of logic gates, switches, application specific integrated circuits, programmable logic controllers, embedded microcontrollers, etc. to achieve the same function. Therefore, such a controller can be considered a hardware component, and the devices included therein for implementing various functions can also be regarded as the structures within the hardware component. Or even, the devices for implementing various functions can be regarded as either software modules for implementing the method or the structures within the hardware component.

[0090] The systems, devices, modules, or units illustrated in the above embodiments can be specifically implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a server system. Of course, this application does not exclude that with the development of future computer technologies, the computers for implementing the functions of the above embodiments can be, for example, personal computers, laptop computers, in-vehicle human-machine interaction devices, cellular phones, camera phones, smart phones, personal digital assistants, media players, navigation devices, email devices, game consoles, tablet computers, wearable devices, or any combination of these devices.

[0091] Although one or more embodiments of this specification provide method operation steps as described in the embodiments or flowcharts, additional or fewer operation steps may be included based on conventional or non-creative means. The order of steps listed in the embodiments is only one way among many execution orders of steps and does not represent the only execution order. When the actual device or terminal product is executing, it may be executed in the order of the method shown in the embodiments or the drawings or executed in parallel (for example, in an environment of parallel processors or multi-threaded processing, or even in a distributed data processing environment). The terms "include", "comprise" or any other variant thereof are intended to cover non-exclusive inclusion, such that a process, method, product or device comprising a series of elements includes not only those elements but also other elements not expressly listed, or also includes elements inherent to such process, method, product or device. Without further limitation, there is no exclusion of additional identical or equivalent elements in the process, method, product or device comprising the said elements. For example, if terms such as first and second are used to denote names, they do not denote any particular order.

[0092] For convenience of description, the above device is described by dividing it into various modules according to functions. Of course, when implementing one or more of this specification, the functions of each module may be implemented in the same or multiple software and / or hardware, or the modules implementing the same function may be realized by a combination of multiple sub-modules or sub-units, etc. The device embodiments described above are merely illustrative. For example, the division of the units is only a logical function division, and there may be other division methods in actual implementation. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Another point is that the displayed or discussed coupling or direct coupling or communication connection to each other may be through some interfaces, and the indirect coupling or communication connection of the device or unit may be in electrical, mechanical or other forms.

[0093] The present invention is described with reference to the flowcharts and / or block diagrams of methods, devices (systems), and computer program products according to embodiments of the present invention. It should be understood that each flow and / or block in the flowchart and / or block diagram, and the combination of flows and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to the processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to generate a machine, such that the instructions executed by the processor of the computer or other programmable data processing device generate a device for implementing the functions specified in Figure 1 one flow or multiple flows and / or blocks Figure 1 one block or multiple blocks.

[0094] These computer program instructions can also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to operate in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means that implement the function specified in one or more of the flows Figure 1 one or more of the flows and / or boxes Figure 1 specified in one or more boxes or functions.

[0095] These computer program instructions can 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, so that the instructions executed on the computer or other programmable apparatus provide steps for implementing the function specified in one or more of the flows Figure 1 one or more of the flows and / or boxes Figure 1 specified in one or more boxes or functions.

[0096] In a typical configuration, a computing device includes one or more processors (CPUs), an input / output interface, a network interface, and memory.

[0097] The memory may include non-permanent memory in a computer-readable medium, random access memory (RAM) and / or non-volatile memory such as read only memory (ROM) or flash memory (flash RAM). Memory is an example of a computer-readable medium.

[0098] Computer-readable media includes both permanent and non-permanent, removable and non-removable media implemented by any method or technology for storing information. The 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, 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 that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transitory computer-readable media such as modulated data signals and carrier waves.

[0099] Those skilled in the art should understand that one or more embodiments of this specification can be provided as a method, a system, or a computer program product. Therefore, one or more embodiments of this specification can take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware aspects. Moreover, one or more embodiments of this specification can 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.) that contain computer-usable program code.

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

[0101] Each embodiment in this specification is described in a progressive manner. For the same or similar parts among the embodiments, reference can be made to each other. Each embodiment focuses on the differences from other embodiments. In particular, for system embodiments, since they are basically similar to method embodiments, the description is relatively simple. For the relevant parts, reference can be made to the description of the method embodiments. In the description of this specification, the description of reference terms such as "one embodiment", "some embodiments", "example", "specific example", or "some examples" means that the specific features, structures, materials, or characteristics described in connection with the embodiment or example are included in at least one embodiment or example of this specification. In this specification, the schematic expressions of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials, or characteristics described can be combined in a suitable manner in any one or more embodiments or examples. In addition, without contradiction, those skilled in the art can combine and combine the different embodiments or examples described in this specification and the features of different embodiments or examples.

[0102] The above description is only for the embodiments of one or more embodiments of this specification and is not used to limit one or more embodiments of this specification. For those skilled in the art, one or more embodiments of this specification can have various changes and modifications. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of this specification shall be included within the scope of the claims.

Claims

1. A data processing method in a blockchain, which is executed by a first node in a first blockchain. The method includes: Sequentially execute the transactions in N transaction sets in chronological order, where N≥1. The execution of the transactions in the N transaction sets causes the state changes of M first accounts, where M≥1; Obtain the signature information of each of the first accounts for its state; Generate a first proof based on the root of the first world state, the root of the second world state, and the signature information of the M first accounts. The first proof is used to prove that the first world state is generated after executing the transactions in the N transaction sets based on the second world state, and the second world state is the world state before executing the transactions in the N transaction sets; Store the root of the first world state and the first proof in a second blockchain.

2. The method according to claim 1, wherein, When N = 1, the generating of the first proof according to the root of the first world state, the root of the second world state, and the signature information of the M first accounts includes: Input the root of the first world state, the root of the second world state, and the signature information of the M first accounts into a preset proof function to generate the first proof.

3. The method according to claim 1, wherein When N≥2, the generating of the first proof according to the root of the first world state, the root of the second world state, and the signature information of the M first accounts includes: Execute the transactions in the Nth transaction set, and obtain the signature information of Q first accounts; Generate the first proof based on the signature information of the Q first accounts, the second proof generated by the (N - 1)th transaction set, the root of the first world state, and the root of the third world state. The second proof is used to prove that the third world state is generated after executing the transactions in the (N - 1)th transaction set based on the world state obtained by executing the (N - 2)th transaction set, and the third world state is the world state obtained by executing the transactions in the (N - 1)th transaction set.

4. The method according to claim 3, wherein, The generating of the first proof based on the signature information of the Q first accounts, the second proof generated by the (N - 1)th transaction set, the root of the first world state, and the root of the third world state includes: Input the signature information of the Q first accounts, the second proof, the root of the first world state, and the root of the third world state into a preset proof function to generate the first proof.

5. The method according to any one of claims 1 to 4, wherein The N transaction sets include a first transaction set. The execution of the transactions included in the first transaction set causes the state changes of S first accounts, where 1≤S≤M. The obtaining of the signature information of each of the first accounts for its state includes: Generate a third proof based on the transactions included in the first transaction set, the fourth world state, and the fifth world state. The fourth world state is the world state obtained after executing the transactions in the first transaction set, and the fifth world state is the most recently obtained world state before executing the transactions in the first transaction set. The third proof is used to prove that the fourth world state is generated after executing the transactions in the first transaction set based on the fifth world state; Send a first request for obtaining the signature information to each terminal corresponding to the S first accounts, where the third proof is included in the first request; Obtain the signature information returned by each terminal corresponding to the S first accounts.

6. A blockchain node device is provided in a first blockchain. The blockchain node device includes: A processing unit configured to sequentially execute the transactions in N transaction sets in chronological order, N≥1, and the execution of the transactions in the N transaction sets causes the states of M first accounts to change, M≥1; An obtaining unit configured to obtain the signature information of each first account for its state; The processing unit is further configured to generate a first proof based on the root of the first world state, the root of the second world state, and the M signature information, where the first proof is used to prove that the first world state is generated after executing the transactions in the N transaction sets based on the second world state, and the second world state is the world state before executing the transactions in the N transaction sets; A storage unit configured to store the root of the first world state and the first proof in a second blockchain.

7. The blockchain node device according to claim 6, wherein, When N = 1, the processing unit is further configured to: Input the root of the first world state, the root of the second world state, and the M signature information into a preset proof function to generate the first proof.

8. The blockchain node device according to claim 6, wherein, When N≥2, the processing unit is further configured to: execute the transactions in the Nth transaction set; The obtaining unit is further configured to obtain the signature information of Q first accounts; The processing unit is further configured to: generate the first proof based on the signature information of the Q first accounts, the second proof generated by the (N - 1)th transaction set, the root of the first world state, and the root of the third world state, where the second proof is used to prove that the third world state is generated after executing the transactions in the (N - 1)th transaction set based on the world state obtained by executing the (N - 2)th transaction set, and the third world state is the world state obtained by executing the transactions in the (N - 1)th transaction set.

9. The blockchain node device according to claim 8, wherein, The processing unit is further configured to: Input the signature information of the Q first accounts, the second proof, the root of the first world state, and the root of the third world state into a preset proof function to generate the first proof.

10. The blockchain node device according to any one of claims 6 to 9, wherein, The N transaction sets include a first transaction set, and the execution of the transactions included in the first transaction set causes the states of S first accounts to change, 1≤S≤M; The processing unit is further configured to: generate a third proof based on the transactions included in the first transaction set, the fourth world state, and the fifth world state, where the fourth world state is the world state obtained after executing the transactions in the first transaction set, and the fifth world state is the most recently obtained world state before executing the transactions in the first transaction set, and the third proof is used to prove that the fourth world state is generated by executing the transactions in the first transaction set based on the fifth world state; The blockchain node device further includes: A communication unit, configured to send a first request for obtaining the signature information to each terminal corresponding to each of the S first accounts, where the third proof is included in the first request; The communication unit is further configured to obtain the signature information returned by each terminal corresponding to each of the S first accounts.

11. A blockchain system, comprising: A first blockchain and a second blockchain, where a first node in the first blockchain is configured to execute the method according to any one of claims 1 to 5, and the second blockchain is configured to store the root of the first world state and the first proof transmitted by the first node.

12. The blockchain system according to claim 11, wherein, The second blockchain is further configured to input the root of the first world state, the root of the second world state, and the first proof into a preset verification function to verify the correctness of the first proof.

13. A computer-readable storage medium, having stored thereon a computer program, wherein when the computer program is executed in a computing device, the computing device executes the method according to any one of claims 1 to 5.

14. A computing device, comprising a memory and a processor, wherein a computer program is stored in the memory, and when the processor executes the computer program, the method according to any one of claims 1 to 5 is implemented.

Images