A blockchain transaction processing method, apparatus and device

Abstract

The embodiments of the present specification disclose a blockchain transaction processing method, which is applied to a blockchain system deployed with a notarization node and a plurality of contract nodes, and each contract node is associated with one or more smart contracts. The scheme includes: a first contract node receives a transaction sent by a user, and when the transaction is to be executed, the first contract node queries the notarization node according to the contract address of the smart contract associated with the first contract node; the notarization node returns the contract code corresponding to the contract address stored on the notarization node in response to the query; the first contract node loads and executes the contract code for the transaction, modifies the world state set stored on the first contract node according to the execution result, and notifies the notarization node, wherein a second contract node not associated with the smart contract does not execute the contract code and does not modify the world state set stored on the second contract node accordingly; and the notarization node packages the transaction into a block for consensus, and stores the block on the notarization node after the consensus is successfully passed.

Description

Technical Field

[0001] This specification relates to the field of blockchain technology, and in particular to a blockchain transaction processing method, apparatus, and device. Background Technology

[0002] Blockchain technology was originally designed by a person using the pseudonym Satoshi Nakamoto. It is a special distributed database technology that is suitable for storing simple, sequential data that can be verified within the system. It uses cryptography and consensus algorithms to ensure that the data is immutable and unforgeable.

[0003] In traditional blockchain designs, information stored after consensus and contract computation are all completed on the same node (generally called a blockchain node). All nodes must perform contract computation and consensus for each transaction to stay synchronized with the latest block. This design forcibly binds the blockchain's information storage and computational resources. It prevents the expansion of resources such as disk space, CPU, or memory based on actual needs, and places high demands on the computational power and storage capacity of each node.

[0004] For a more intuitive view, see Figure 1 , Figure 1 This diagram illustrates the traditional blockchain system's handling of smart contract transactions. It shows that contract execution, consensus, and notarization all occur on the same blockchain node. Each participating node needs to run the smart contract and maintain the world state tree. As transaction volume increases, each blockchain node still needs to sort each transaction before executing the smart contract, and only after consensus is reached is a specific transaction considered complete. With the accumulation of historical transactions, the on-chain states of different smart contracts are stored in the same world state tree. The depth of this tree and the scale of stored key-value (KV) values ​​become increasingly difficult to maintain. Furthermore, since contract computation, notarization, and consensus are all performed within the same node, the machines hosting the blockchain nodes require high standards in terms of storage capacity, CPU, and memory.

[0005] Therefore, a more flexible, efficient, and easy-to-maintain blockchain system solution is needed. Summary of the Invention

[0006] This specification provides one or more embodiments of a blockchain transaction processing method, apparatus, device, and storage medium to solve the following technical problem: the need for a more flexible, efficient, and easy-to-maintain blockchain system solution.

[0007] To solve the above-mentioned technical problems, one or more embodiments of this specification are implemented as follows:

[0008] This specification provides one or more embodiments of a blockchain transaction processing method, applied to a blockchain system with evidence storage nodes and multiple contract nodes deployed, each of the contract nodes being associated with one or more smart contracts. The method includes:

[0009] The first contract node among the multiple contract nodes receives the transaction sent by the user, and when it is about to execute the transaction, it queries the evidence storage node according to the contract address of the smart contract it is associated with.

[0010] In response to the query, the evidence storage node returns the contract code corresponding to the contract address stored on it;

[0011] The first contract node loads and executes the contract code for the transaction, modifies the world state set stored on itself according to the execution result, and notifies the evidence storage node. The second contract node among the multiple contract nodes that is not associated with the smart contract does not execute the contract code, nor does it modify the world state set stored on itself accordingly.

[0012] The evidence storage node packages the transaction into a block for consensus, and after the consensus is successfully passed, it stores the block on its own disk.

[0013] This specification provides one or more embodiments of a blockchain transaction processing device, applied to a blockchain system with evidence storage nodes and multiple contract nodes deployed, each of the contract nodes being associated with one or more smart contracts, the device comprising:

[0014] The contract code query module of the first contract node among the multiple contract nodes receives the transaction sent by the user, and when the transaction is to be executed, it queries the evidence storage node according to the contract address of the smart contract it is associated with.

[0015] The contract code return module of the evidence storage node, in response to the query, returns the contract code stored on itself corresponding to the contract address;

[0016] The contract transaction execution module of the first contract node loads and executes the contract code for the transaction, modifies the world state set stored on itself according to the execution result, and notifies the evidence storage node. The second contract node among the multiple contract nodes that is not associated with the smart contract does not execute the contract code, nor does it modify the world state set stored on itself accordingly.

[0017] The transaction consensus storage module of the storage node packages the transaction into a block for consensus, and after the consensus is successfully passed, stores the block on its own disk.

[0018] This specification provides one or more embodiments of a blockchain transaction processing device, applied to a blockchain system with evidence storage nodes and multiple contract nodes, each of the contract nodes being associated with one or more smart contracts. The device includes:

[0019] At least one processor; and,

[0020] A memory communicatively connected to the at least one processor; wherein,

[0021] The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform:

[0022] The first contract node among the multiple contract nodes receives the transaction sent by the user, and when it is about to execute the transaction, it queries the evidence storage node according to the contract address of the smart contract it is associated with.

[0023] In response to the query, the evidence storage node returns the contract code corresponding to the contract address stored on it;

[0024] The first contract node loads and executes the contract code for the transaction, modifies the world state set stored on itself according to the execution result, and notifies the evidence storage node. The second contract node among the multiple contract nodes that is not associated with the smart contract does not execute the contract code, nor does it modify the world state set stored on itself accordingly.

[0025] The evidence storage node packages the transaction into a block for consensus, and after the consensus is successfully passed, it stores the block on its own disk.

[0026] This specification provides one or more embodiments of a non-volatile computer storage medium applied to a blockchain system with evidence storage nodes and multiple contract nodes deployed thereon. Each contract node is associated with one or more smart contracts. The medium stores computer-executable instructions, which are configured as follows:

[0027] The first contract node among the multiple contract nodes receives the transaction sent by the user, and when it is about to execute the transaction, it queries the evidence storage node according to the contract address of the smart contract it is associated with.

[0028] In response to the query, the evidence storage node returns the contract code corresponding to the contract address stored on it;

[0029] The first contract node loads and executes the contract code for the transaction, modifies the world state set stored on itself according to the execution result, and notifies the evidence storage node. The second contract node among the multiple contract nodes that is not associated with the smart contract does not execute the contract code, nor does it modify the world state set stored on itself accordingly.

[0030] The evidence storage node packages the transaction into a block for consensus, and after the consensus is successfully passed, it stores the block on its own disk.

[0031] The above-mentioned at least one technical solution adopted in one or more embodiments of this specification can achieve the following beneficial effects: Traditional blockchain nodes are split into contract nodes and storage nodes, realizing the separation of contract computation and world state maintenance from data storage; different contract nodes are only associated with the smart contracts they are interested in, and correspondingly, when executing contract transactions, they only execute the smart contracts they are associated with, and maintain only this part of the world state, without executing other contract transactions unrelated to themselves. This effectively controls the size of their own world state set, avoids wasting computing resources, and can process the contract transactions they care about more efficiently; at the same time, storage nodes can focus on storing the contract code and all transactions of all smart contracts in the blockchain system to provide data support for each contract node, without participating in contract computation; this system architecture achieves differentiated isolation processing to meet different needs through contract nodes, and global data uniformity through storage nodes, making it more flexible, efficient, and easier to maintain than traditional architectures. Attached Figure Description

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

[0033] Figure 1 This is a schematic diagram illustrating how traditional blockchain systems process transactions involving smart contracts.

[0034] Figure 2 A flowchart illustrating a blockchain transaction processing method provided in one or more embodiments of this specification;

[0035] Figure 3 A schematic diagram illustrating a blockchain system and its transaction processing method involving smart contracts, provided for one or more embodiments of this specification;

[0036] Figures 4(a) and 4(b) are functional diagrams of the contract node and evidence storage node provided in one or more embodiments of this specification;

[0037] Figure 5 This is a schematic diagram illustrating the relationship between contract nodes and evidence storage nodes provided in one or more embodiments of this specification.

[0038] Figure 6 A schematic diagram illustrating organizational control of contract nodes provided in one or more embodiments of this specification;

[0039] Figure 7 A schematic diagram of the structure of a blockchain transaction processing device provided for one or more embodiments of this specification;

[0040] Figure 8 This is a schematic diagram of the structure of a blockchain transaction processing device provided for one or more embodiments of this specification. Detailed Implementation

[0041] This specification provides a blockchain transaction processing method, apparatus, device, and storage medium through its embodiments.

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

[0043] To address the problems raised in the background section, and especially in the case of different consortiums on the same blockchain, data between consortia needs to be isolated and non-interfering. The actual business requirement is that each consortium is only concerned with the correctness of its own on-chain data and transactions, and is unwilling to endorse transactions of other consortiums, thus avoiding the waste of computational resources. Based on this, this application proposes a blockchain design scheme that separates computation and storage. By distinguishing between contract nodes primarily used for computation and evidence storage nodes primarily used for storage, the characteristics of blockchain are utilized more effectively, and flexible business needs can be met.

[0044] Figure 2This diagram illustrates a blockchain transaction processing method provided in one or more embodiments of this specification. The method can be applied to blockchain systems in various business sectors, including electronic payment, e-commerce, instant messaging, gaming, and government services. The process can be executed on node devices within these sectors, and certain input parameters or intermediate results can be manually adjusted to improve accuracy.

[0045] Figure 2 The method is applied to a blockchain system with one or more evidence storage nodes and multiple contract nodes, each contract node being associated with one or more smart contracts. Transactions in the blockchain system are categorized into two types: one involves smart contracts, requiring execution through contract computation to complete the transaction and then storing it on the blockchain; this type of transaction is called a contract transaction, and the solution in this application primarily addresses contract transactions. The other type does not involve smart contracts, requiring no contract computation; the main task is to store the transaction-related data on the blockchain, and this type of transaction is called an evidence storage transaction. Evidence storage transactions can also be performed in the blockchain system proposed in this application. Furthermore, both types of transactions require consensus; in the blockchain system proposed in this application, contract transactions may even require two consensus processes before being stored on the blockchain.

[0046] Traditional blockchain systems do not distinguish the roles of nodes and refer to them all as blockchain nodes. The same blockchain node can perform both contract calculations and transaction data storage. This application splits the functions of such blockchain nodes into two different roles: contract nodes and storage nodes, and makes corresponding improvements to the transaction processing process.

[0047] Figure 2 The process may include the following steps:

[0048] S202: The first contract node among the plurality of contract nodes receives the transaction sent by the user, and when it is about to execute the transaction, it queries the evidence storage node according to the contract address of the smart contract it is associated with.

[0049] In a blockchain system, in addition to nodes, there are also clients. Users send transactions to nodes through clients. Clients do not participate in the consensus process and generally do not store transaction data in the blockchain system locally.

[0050] In one or more embodiments of this specification, different contract nodes may be associated with different smart contracts. A contract node only participates in the contract computation of the smart contract it is associated with, and does not participate in the contract computation of other smart contracts. A contract node may be controlled by one or more organizations (e.g., companies, government agencies, other groups), which pre-determine which smart contracts the contract node is associated with. For example, if a company's specific business logic needs to be implemented through a certain smart contract, the company can associate its controlled contract nodes with that smart contract so that the smart contract can be run through the contract node to execute the company's on-chain transactions.

[0051] For smart contracts that an organization is not focused on, an association is established between the contract nodes controlled by the organization and the smart contract. In this way, contract nodes focus on processing a subset of transactions that directly affect their interests, rather than all transactions on the blockchain system, improving the transaction processing efficiency of each node. For the organization, this reduces unnecessary resource waste and lowers organizational costs. Similarly, contract nodes could also be controlled by individuals, but this is expected to be relatively rare.

[0052] In one or more embodiments of this specification, any contract node among multiple contract nodes in a blockchain system may, if needed, actively apply to associate with a specified smart contract. If the application is approved, the association between the contract node and the specified smart contract is established. The entity processing the application may be a subject with corresponding permissions, such as a specific external account used by an organization, other contract nodes already associated with the specified smart contract, the smart contract account corresponding to the specified smart contract, etc.

[0053] In one or more embodiments of this specification, the transaction sent by the user is a contract transaction, which requires the execution of a smart contract. In this case, a contract node associated with the smart contract is needed to process it. For ease of description, such a contract node is referred to as the first contract node, and a contract node not associated with the smart contract is referred to as the second contract node. If the second contract node receives the transaction, it can either discard the transaction or forward it to the first contract node.

[0054] In practical applications, the user sending the transaction is part of an organization. In this case, there is a high probability that the user will directly send the transaction to the contract node controlled by the organization (for example, the organization is a company, the user is an employee of the company, and the transaction is sent through a client on an office machine). The organization has already pre-set the association between the contract node and the smart contract. Therefore, the contract node belongs to the first contract node and can correctly process the transaction.

[0055] In one or more embodiments of this specification, the contract node is responsible for running smart contracts to execute transactions. Specifically, this includes loading and executing the contract code of the smart contract. The contract code is stored on a storage node, allowing the contract node to retrieve the contract code from the storage node based on the corresponding contract address. The contract address can be pre-configured on the contract node or specified by the currently received transaction.

[0056] If transactions are frequent, contract nodes can also temporarily cache the acquired contract code on themselves for later use, thereby avoiding frequent queries to the storage node.

[0057] In one or more embodiments of this specification, a first contract node receives multiple transactions in succession, sorts the received transactions, and retrieves and executes each transaction in order (e.g., the order in which the transactions were initiated). This helps to avoid some transactions failing due to out-of-order execution.

[0058] S204: The evidence storage node, in response to the query, returns the contract code corresponding to the contract address stored on itself.

[0059] S206: The first contract node loads and executes the contract code for the transaction, modifies the world state set stored on itself according to the execution result, and notifies the evidence storage node. The second contract node among the multiple contract nodes that is not associated with the smart contract does not execute the contract code, nor does it modify the world state set stored on itself accordingly.

[0060] A world state set typically has a tree structure, which is called a world state tree. The world state tree records the accounts in the blockchain system (e.g., smart contract accounts representing smart contracts, external accounts representing users, etc.) and their states, such as contract execution status data, total number of executed transactions, and user account balances. In traditional blockchain systems, each blockchain node executes all transactions and correspondingly maintains the full world state, ensuring consistency in their respective world state trees. This significantly increases the burden on the nodes.

[0061] In one or more embodiments of this specification, a set of world states is stored on the contract node. However, it should be noted that each contract node only cares about and maintains the world state related to itself. Thus, the set of world states on different contract nodes no longer needs to be consistent. Compared with traditional blockchain nodes, such contract nodes have a significantly reduced burden and improved privacy of transaction and contract data.

[0062] S208: The evidence storage node packages the transaction into a block for consensus, and after the consensus is successfully passed, stores the block on its own disk.

[0063] In one or more embodiments of this specification, multiple evidence storage nodes are deployed in the blockchain system. Each evidence storage node is used to store the contract code of all smart contracts and all transactions in the blockchain system. Based on this, contract nodes are localized, while evidence storage nodes are global, and any evidence storage node can simultaneously provide data storage support for multiple contract nodes. The global nature of the evidence storage nodes and the consensus-based evidence storage process ensure that the blockchain system improved in this application still possesses the characteristics of trustworthiness and immutability.

[0064] The processes of packaging blocks, reaching consensus, and storing evidence on disk in S208 can be referenced from the general process of uploading data to the blockchain, and will not be explained in detail here.

[0065] In addition, since the evidence storage node and the contract node are separate nodes, the evidence storage node can also perform corresponding verification on the notification of the first contract node before packaging the block for consensus, in order to determine whether the operation and result on the first contract node's side are normal and reliable. If they are normal and reliable, the subsequent normal processing steps can be continued. Otherwise, the evidence storage node can refuse to store the transaction, so that the transaction cannot take effect.

[0066] pass Figure 1 This method splits traditional blockchain nodes into contract nodes and storage nodes, separating contract computation and world state maintenance from data storage. Different contract nodes are only associated with the smart contracts they are interested in, and correspondingly, when executing contract transactions, they only execute their associated smart contracts and maintain only that part of the world state, without executing other unrelated contract transactions. This effectively controls the size of their own world state set, avoids wasting computational resources, and can process the contract transactions they care about more efficiently. Meanwhile, storage nodes can focus on storing the contract code and all transactions of all smart contracts in the blockchain system, providing data support for each contract node without participating in contract computation. This system architecture achieves differentiated isolation processing to meet different needs through contract nodes and global data uniformity through storage nodes, making it more flexible, efficient, and easier to maintain than traditional architectures.

[0067] based on Figure 1 In addition to the method described herein, this specification also provides some specific implementation schemes and extension schemes of this method, which will be further explained below.

[0068] In one or more embodiments of this specification, it was mentioned earlier that contract transactions may require two consensus processes before being stored on the blockchain, which will be explained here. In traditional blockchain systems, blockchain nodes package transactions into consensus before they are uploaded to the chain, involving only one consensus process. This is mainly because contract execution and data storage occur on the same node. However, by separating these into contract nodes and storage nodes, the independence of these two types of nodes is enhanced, and the privacy of contract nodes (the privacy of the data contract computation of their respective organizations) is improved, while storage nodes have relatively more global public visibility.

[0069] In this scenario, to further decouple the work of these two types of nodes and reduce the possibility of risk transmission between them, consensus is achieved separately on the contract node and the notarization node. The consensus on the contract node is primarily used to reach consensus on the results of contract computation and world state updates, and is called contract transaction consensus. The consensus on the contract node is primarily used to reach consensus on the blocks obtained after packaging transactions (i.e., data to be notarized), and is called transaction block consensus.

[0070] For contract transaction consensus, the first contract node can reach a consensus on the execution result with at least some of the other contract nodes that are also associated with the smart contract, to obtain a first consensus result. If the first consensus result indicates that the consensus has been successfully passed, the first consensus result is notified to the storage node. Preferably, at least four contract nodes participate in the consensus to meet conditions such as Byzantine fault tolerance. The contract nodes participating in the consensus can be selected by the current first contract node or the smart contract.

[0071] Similarly, for transaction block consensus, the evidence storage node verifies the first consensus result notified by the contract node. If the verification passes, it packages multiple such transactions into a block and reaches a consensus with other evidence storage nodes to obtain a second consensus result. After the second consensus result indicates that the consensus has been successfully passed, the block is stored on its own disk.

[0072] Based on the above description, and more intuitively, one or more embodiments of this specification provide a schematic diagram of a blockchain system and its transaction processing method involving smart contracts, as shown below. Figure 3 As shown.

[0073] exist Figure 3In this system, users can initiate contract transactions through corresponding external accounts. Transaction execution occurs on contract nodes, while contract code, transactions, and other content are stored on evidence storage nodes. The world state tree is also stored on contract nodes, and smart contracts run on these nodes. A contract transaction is executed and endorsed by a majority of contract nodes. If successful, it is sent to evidence storage nodes. These nodes determine that the transaction has achieved consensus among a majority of contract nodes based on the signature information and can then wait for block packaging consensus. Throughout this process, evidence storage nodes do not run smart contracts to verify transactions; they only perform global consensus on the stored information. Some of these steps have already been explained above and will not be repeated here.

[0074] based on Figure 3 The descriptions in the document illustrate the functions of the contract nodes and evidence storage nodes defined in this application. More intuitively, Figures 4(a) and 4(b) are functional diagrams of the contract nodes and evidence storage nodes provided in one or more embodiments of this specification. The responsibilities of each type of node are designed for the separation of duties, and each node has the function corresponding to its responsibilities.

[0075] As shown in Figure 4(a), the evidence storage node can store only data and blocks, including data types such as contract transactions, evidence storage transactions, and contract code. In Figure 4(b), the contract node is responsible for the execution of contracts and the personalized preservation of contract states (i.e., the world state tree) (which can involve only a portion of the contracts it is interested in, rather than all of them).

[0076] Furthermore, Figure 5 This is a schematic diagram illustrating the relationship between contract nodes and evidence storage nodes provided in one or more embodiments of this specification.

[0077] In terms of this relationship, a contract node can be associated with one or more smart contracts. For each smart contract, at least four contract nodes can be selected to run. Contract nodes can join a specified smart contract by applying, and once the application is approved, an association relationship with that smart contract can be established.

[0078] for example, Figure 5 The document shows three smart contracts, namely Contract A, Contract B, and Contract C, six contract nodes, namely Contract Nodes 1 to 6, and six evidence storage nodes, namely Evidence Storage Nodes 1 to 6.

[0079] Each contract node is labeled with its associated contracts in parentheses below it; contract node 1 is associated with contract A, contract node 2 is associated with both contract A and contract B, contract node 3 is associated with both contract A and contract C, and so on. Each evidence storage node can provide data support for any contract node.

[0080] Figure 5The document also shows the contract verification conditions, namely which contract nodes are required to participate in the consensus for each contract. Taking the contract verification conditions of contract A as an example, only contract nodes associated with contract A (i.e., contract nodes 1, 2, 3, and 4) can run contract A. Therefore, at least 3 of these nodes can be selected for consensus during the consensus process. Only after these 3 nodes have verified the results of the contract execution and the corresponding modifications to the world state can the notification node be further notified to package the corresponding transactions for block consensus.

[0081] For a new contract node to join the blockchain system, denoted as a third contract node, it can obtain the contract code and historical transactions stored in the blockchain system from any storage node. Then, it executes the historical transactions according to the contract code to update the world state set stored on itself. By replaying historical transactions in this way, it can be updated to a more recent world state, after which the third contract node can be put into normal use.

[0082] In one or more embodiments of this specification, the blockchain system's multiple contract nodes include one or more contract node alliances, each established by a corresponding organization. For example, assuming a company controls several contract nodes, these contract nodes can be divided into a contract node alliance; or, for instance, several companies have a cooperative relationship (considering these companies as an alliance), and each of them controls one or more contract nodes, then all the contract nodes controlled by these companies can be divided into a contract node alliance; and so on.

[0083] For an alliance, the focus is often solely on its own internal business and the smart contracts built for that business. Therefore, it can associate its contract nodes only with its own smart contracts, without concern for the execution of contracts from other alliances. In this scenario, different organizations may associate different smart contracts with their respective contract node alliances. Compared to all smart contracts in the blockchain system, the smart contracts associated with a particular contract node alliance may represent only a small percentage, thus reducing the processing burden and costs for each alliance.

[0084] Similarly, several evidence storage nodes can form an evidence storage node alliance to serve certain contract nodes, which helps improve local efficiency.

[0085] More intuitively, Figure 6This diagram illustrates the control of contract nodes by an organization, as provided in one or more embodiments of this specification. There are two contract node alliances, Contract Node Alliance 1 and Contract Node Alliance 2, controlled by Organization 1 and Organization 2 respectively, and one evidence storage node alliance. Contract nodes in Contract Node Alliance 1 are associated with Contract 1, while contract nodes in Contract Node Alliance 2 are associated with Contract 2 and Contract 3. Transaction 1 requires the execution of Contract 1, so Transaction 1 is executed by Contract Node Alliance 1 without the participation of Contract Node Alliance 2. Similarly, Transaction 2 requires the execution of Contract 2, and Transaction 3 requires the execution of Contract 3, so Transaction 2 and Transaction 3 are executed by Contract Node Alliance 2 without the participation of Contract Node Alliance 1. The evidence storage node alliance provides services to both Contract Node Alliance 1 and Contract Node Alliance 2.

[0086] from Figure 5 As can be seen, dividing the contract node alliance improves the business privacy of different organizational alliances (mainly referring to the contract computation process involved in the business) and reduces the processing burden. To further improve business privacy, an organization can set a privacy key for a specific smart contract corresponding to its contract node alliance, and distribute the privacy key to at least some contract nodes in the corresponding contract node alliance. In this case, when the first contract node executes the contract code, if the smart contract corresponding to the contract code has a privacy key set and the privacy key has been distributed to the first contract node, then the first contract node uses the privacy key to execute the contract code, while contract nodes that do not hold the privacy key cannot execute the contract code. During the evidence storage stage, the privacy key can also be used to encrypt and store the input and output parameters and other data of the corresponding evidence storage nodes, thereby achieving privacy protection for organizations and alliances at the global level.

[0087] In summary, this application presents a blockchain design scheme that separates computation and storage, which can more effectively utilize and allocate machine resources through separation of responsibilities. Multiple contract nodes can exist on a single storage node, and users can own contract nodes and only care about their own smart contract operations, thus avoiding waste of computing resources.

[0088] A single evidence storage node consortium (e.g., a cluster at the device level) can contain multiple contract node consortia. Smart contracts undergo consensus computation within the consortium and can be encrypted internally, i.e., the evidence storage node data is encrypted. Contract nodes maintain their own personalized world state, performing key-value storage on demand to prevent the full volume of contract information from overwhelming the key-value storage repository. Contract nodes can apply to join a specific smart contract and retrieve the latest transactions through evidence storage node data.

[0089] Based on the same idea, one or more embodiments of this specification also provide apparatus and devices corresponding to the above methods, such as... Figure 7 , Figure 8 As shown.

[0090] Figure 7 This specification provides a schematic diagram of the structure of a blockchain transaction processing device according to one or more embodiments. The device is applied to a blockchain system with a storage node and multiple contract nodes, each of which is associated with one or more smart contracts. The device includes:

[0091] The contract code query module 702 of the first contract node among the multiple contract nodes receives the transaction sent by the user, and when the transaction is to be executed, queries the evidence storage node according to the contract address of the smart contract associated with it.

[0092] The contract code return module 704 of the evidence storage node, in response to the query, returns the contract code stored on itself corresponding to the contract address;

[0093] The contract transaction execution module 706 of the first contract node loads and executes the contract code for the transaction, modifies the world state set stored on itself according to the execution result, and notifies the evidence storage node. The second contract node among the multiple contract nodes that is not associated with the smart contract does not execute the contract code, nor does it modify the world state set stored on itself accordingly.

[0094] The transaction consensus storage module 708 of the storage node packages the transaction into a block for consensus, and after the consensus is successfully passed, stores the block on its own disk.

[0095] Optionally, the contract transaction execution module 706 of the first contract node, together with other contract nodes that are also associated with the smart contract among the plurality of contract nodes, reaches a consensus on the execution result to obtain a first consensus result;

[0096] If the first consensus result indicates that the consensus was successfully passed, then the first consensus result is notified to the evidence storage node.

[0097] Optionally, it also includes:

[0098] The smart contract application module 710 of the contract node among the multiple contract nodes applies to associate with a specified smart contract. If the application is approved, the association relationship between the contract node and the specified smart contract is established.

[0099] Optionally, the plurality of contract nodes may include one or more contract node alliances, each established by a corresponding organization.

[0100] Optionally, the smart contracts associated with the contract node alliances of different organizations may differ.

[0101] Optionally, it also includes:

[0102] The organization's privacy key processing module 712 sets a privacy key required for running the specified smart contract for the specified smart contract corresponding to its contract node alliance, and distributes the privacy key to at least some of the contract nodes in the corresponding contract node alliance.

[0103] If the smart contract corresponding to the contract code is set with a privacy key and the privacy key has been distributed to the first contract node, the first contract node uses the privacy key to execute the contract code.

[0104] Optionally, it also includes:

[0105] The third contract node's historical transaction replay module 714 is newly added to the blockchain system, and obtains the contract code and historical transactions stored in the blockchain system from the evidence storage node;

[0106] Execute the historical transactions according to the contract code to update the world state set stored on itself.

[0107] Optionally, the contract code query module 702 of the first contract node sorts the accepted multiple transactions so as to retrieve and execute each transaction in sequence.

[0108] Optionally, the transaction consensus notarization module 708 of the notarization node verifies the first consensus result notified by the contract node;

[0109] If the verification passes, the transaction is packaged into a block, and consensus is reached with other evidence storage nodes to obtain a second consensus result. After the second consensus result indicates that the consensus has been successfully passed, the block is stored on its own disk.

[0110] Optionally, the blockchain system is equipped with multiple evidence storage nodes, each of which is used to store the contract code of all smart contracts and all transactions in the blockchain system.

[0111] Figure 8 This specification provides a schematic diagram of the structure of a blockchain transaction processing device according to one or more embodiments. The device is applied to a blockchain system with a storage node and multiple contract nodes, each of which is associated with one or more smart contracts. The device includes:

[0112] At least one processor; and,

[0113] A memory communicatively connected to the at least one processor; wherein,

[0114] The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform:

[0115] The first contract node among the multiple contract nodes receives the transaction sent by the user, and when it is about to execute the transaction, it queries the evidence storage node according to the contract address of the smart contract it is associated with.

[0116] In response to the query, the evidence storage node returns the contract code corresponding to the contract address stored on it;

[0117] The first contract node loads and executes the contract code for the transaction, modifies the world state set stored on itself according to the execution result, and notifies the evidence storage node. The second contract node among the multiple contract nodes that is not associated with the smart contract does not execute the contract code, nor does it modify the world state set stored on itself accordingly.

[0118] The evidence storage node packages the transaction into a block for consensus, and after the consensus is successfully passed, it stores the block on its own disk.

[0119] The processor and memory can communicate via a bus, and the device can also include input / output interfaces for communicating with other devices.

[0120] Based on the same idea, one or more embodiments of this specification also provide corresponding... Figure 2 A non-volatile computer storage medium is provided by a Chinese method for use in a blockchain system with evidence storage nodes and multiple contract nodes. Each contract node is associated with one or more smart contracts. The medium stores computer-executable instructions, which are configured as follows:

[0121] The first contract node among the multiple contract nodes receives the transaction sent by the user, and when it is about to execute the transaction, it queries the evidence storage node according to the contract address of the smart contract it is associated with.

[0122] In response to the query, the evidence storage node returns the contract code corresponding to the contract address stored on it;

[0123] The first contract node loads and executes the contract code for the transaction, modifies the world state set stored on itself according to the execution result, and notifies the evidence storage node. The second contract node among the multiple contract nodes that is not associated with the smart contract does not execute the contract code, nor does it modify the world state set stored on itself accordingly.

[0124] The evidence storage node packages the transaction into a block for consensus, and after the consensus is successfully passed, it stores the block on its own disk.

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

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

[0127] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, a computer can be, for example, a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email device, game console, tablet computer, wearable device, or any combination of these devices.

[0128] For ease of description, the above devices are described in terms of function, divided into various units. Of course, in implementing this specification, the functions of each unit can be implemented in one or more software and / or hardware.

[0129] Those skilled in the art will understand that the embodiments of this specification can be provided as methods, systems, or computer program products. Therefore, the embodiments of this specification can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the 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.) containing computer-usable program code.

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

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

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

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

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

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

[0136] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

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

[0138] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the embodiments of apparatus, devices, and non-volatile computer storage media are basically similar to the method embodiments, so the descriptions are relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0139] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

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

Claims

1. A blockchain transaction processing method, applied to a blockchain system with evidence storage nodes and multiple contract nodes, each of the contract nodes being associated with one or more smart contracts, the method comprising: The first contract node among the multiple contract nodes receives the transaction sent by the user, and when it is about to execute the transaction, it queries the evidence storage node according to the contract address of the smart contract it is associated with. In response to the query, the evidence storage node returns the contract code corresponding to the contract address stored on it; The first contract node loads and executes the contract code for the transaction, modifies the world state set stored on itself based on the execution result, and notifies the evidence storage node. The second contract node, which is not associated with the smart contract, does not execute the contract code or modify its own stored world state set. The world state set stored on each contract node is only a partial state corresponding to the smart contract associated with that contract node, and the world state sets on different contract nodes do not need to be consistent. The evidence storage node packages the transaction into a block for consensus, and after the consensus is successfully passed, it stores the block on its own disk.

2. The method as described in claim 1, wherein notifying the evidence storage node specifically includes: The first contract node, together with other contract nodes that are also associated with the smart contract among the plurality of contract nodes, reaches a consensus on the execution result to obtain a first consensus result; If the first consensus result indicates that the consensus was successfully passed, then the first consensus result is notified to the evidence storage node.

3. The method of claim 1, further comprising: A contract node among the multiple contract nodes applies to associate with a specified smart contract. If the application is approved, the association between the contract node and the specified smart contract is established.

4. The method according to any one of claims 1 to 3, wherein the plurality of contract nodes includes one or more contract node alliances, each established by a corresponding organization.

5. The method as described in claim 4, wherein the smart contracts associated with the contract node alliances corresponding to different organizations are different.

6. The method of claim 4, further comprising: The organization sets a privacy key required to run the specified smart contract for the specified smart contract corresponding to its corresponding contract node alliance, and distributes the privacy key to at least some of the contract nodes in the corresponding contract node alliance. The first contract node executes the contract code, specifically including: If the smart contract corresponding to the contract code has a privacy key, and the privacy key has been distributed to the first contract node, then the first contract node uses the privacy key to execute the contract code.

7. The method of claim 1, further comprising: The third contract node is newly added to the blockchain system and obtains the contract code and historical transactions stored in the blockchain system from the evidence storage node. Execute the historical transactions according to the contract code to update the world state set stored on itself.

8. The method as described in claim 1, wherein the first contract node, receiving a transaction sent by the user, further includes: The first contract node sorts the accepted transactions so that each transaction can be retrieved and executed in sequence.

9. The method as described in claim 2, wherein the notarization node, in the step of packaging the transaction into a block for consensus, specifically includes: The evidence storage node verifies the first consensus result notified by the contract node. If the verification passes, the transaction is packaged into a block, and consensus is reached with other evidence storage nodes to obtain a second consensus result. After the second consensus result indicates that the consensus has been successfully passed, the block is stored on its own disk.

10. The method according to any one of claims 1 to 3, wherein multiple evidence storage nodes are deployed in the blockchain system, and each evidence storage node is used to store the contract code of all smart contracts and all transactions in the blockchain system.

11. A blockchain transaction processing device, applied to a blockchain system with evidence storage nodes and multiple contract nodes, each of the contract nodes being associated with one or more smart contracts, the device comprising: The contract code query module of the first contract node among the multiple contract nodes receives the transaction sent by the user, and when the transaction is to be executed, it queries the evidence storage node according to the contract address of the smart contract it is associated with. The contract code return module of the evidence storage node, in response to the query, returns the contract code stored on itself corresponding to the contract address; The contract transaction execution module of the first contract node loads and executes the contract code for the transaction, modifies the world state set stored on itself according to the execution result, and notifies the evidence storage node. Among the multiple contract nodes, the second contract node that is not associated with the smart contract does not execute the contract code, nor does it modify the world state set stored on itself accordingly. The world state set stored on each contract node is only a part of the state corresponding to the smart contract associated with that contract node, and the world state sets on different contract nodes do not need to be consistent. The transaction consensus storage module of the storage node packages the transaction into a block for consensus, and after the consensus is successfully passed, stores the block on its own disk.

12. The apparatus of claim 11, wherein the contract transaction execution module of the first contract node, together with other contract nodes among the plurality of contract nodes that are also associated with the smart contract, reaches a consensus on the execution result to obtain a first consensus result; If the first consensus result indicates that the consensus was successfully passed, then the first consensus result is notified to the evidence storage node.

13. The apparatus of claim 11, further comprising: The smart contract application module of the contract node among the multiple contract nodes applies to associate with the specified smart contract. If the application is approved, the association between the contract node and the specified smart contract is established.

14. The apparatus according to any one of claims 11 to 13, wherein the plurality of contract nodes includes one or more contract node alliances, each established by a corresponding organization.

15. The apparatus of claim 14, wherein the smart contracts associated with the contract node alliances corresponding to different organizations are different.

16. The apparatus of claim 14, further comprising: The organization's privacy key processing module sets the privacy key required to run the smart contract for the specified smart contract corresponding to its corresponding contract node alliance, and distributes the privacy key to at least some of the contract nodes in the corresponding contract node alliance. If the smart contract corresponding to the contract code in the first contract node has a privacy key and the privacy key has been distributed to the first contract node, then the first contract node uses the privacy key to execute the contract code.

17. The apparatus of claim 11, further comprising: The historical transaction replay module of the third contract node is newly added to the blockchain system, and obtains the contract code and historical transactions stored in the blockchain system from the evidence storage node. Execute the historical transactions according to the contract code to update the world state set stored on itself.

18. The apparatus of claim 11, wherein the contract code query module of the first contract node sorts the accepted multiple transactions so as to retrieve and execute each of the transactions in sequence.

19. The apparatus of claim 12, wherein the transaction consensus notarization module of the notarization node verifies the first consensus result notified by the contract node; If the verification passes, the transaction is packaged into a block, and consensus is reached with other evidence storage nodes to obtain a second consensus result. After the second consensus result indicates that the consensus has been successfully passed, the block is stored on its own disk.

20. The apparatus according to any one of claims 11 to 13, wherein a plurality of evidence storage nodes are deployed in the blockchain system, and each evidence storage node is used to store the contract code of all smart contracts and all transactions in the blockchain system.

21. A blockchain transaction processing device, applied to a blockchain system with evidence storage nodes and multiple contract nodes deployed, each of the contract nodes being associated with one or more smart contracts, the device comprising: At least one processor; as well as, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform: The first contract node among the multiple contract nodes receives the transaction sent by the user, and when it is about to execute the transaction, it queries the evidence storage node according to the contract address of the smart contract it is associated with. In response to the query, the evidence storage node returns the contract code corresponding to the contract address stored on it; The first contract node loads and executes the contract code for the transaction, modifies the world state set stored on itself based on the execution result, and notifies the evidence storage node. The second contract node, which is not associated with the smart contract, does not execute the contract code or modify its own stored world state set. The world state set stored on each contract node is only a partial state corresponding to the smart contract associated with that contract node, and the world state sets on different contract nodes do not need to be consistent. The evidence storage node packages the transaction into a block for consensus, and after the consensus is successfully passed, it stores the block on its own disk.

Images