Transaction execution methods and nodes in blockchain systems

Abstract

A transaction execution method and node in a blockchain system, the blockchain system comprising multiple blockchain nodes configured with TEEs, wherein the multiple blockchain nodes include multiple consensus nodes. The method, executed by the blockchain node, comprises: receiving a transaction request from a user device, the transaction request comprising transaction ciphertext obtained by encrypting a first transaction using a first key, and key ciphertext obtained by encrypting the first key using a public key of the TEE; decrypting the key ciphertext in the TEE of the blockchain node using a private key of the TEE to obtain the first key, encrypting target information using a second key to obtain forwarding ciphertext, the target information including the first key, causing a consensus proposal node among the multiple consensus nodes to generate a consensus proposal comprising the transaction request and the forwarding ciphertext, so that the consensus node, in its TEE, decrypts the forwarding ciphertext using the second key to obtain the first key, decrypts the transaction ciphertext using the first key to obtain the first transaction, and executes the first transaction.

Description

Technical Field

[0001] The embodiments of this specification belong to the field of blockchain, and more particularly to a transaction execution method and node in a blockchain system. Background Art

[0002] Blockchain is a novel application model for computer technologies, including distributed data storage, peer-to-peer transmission, consensus mechanisms, and encryption algorithms. In a blockchain system, data blocks are linked sequentially in chronological order to form a chain-like data structure, cryptographically guaranteeing an unalterable and unforgeable distributed ledger. Due to its decentralized, tamper-proof, and autonomous nature, blockchain is gaining increasing attention and application. Summary of the Invention

[0003] The purpose of the present invention is to provide a transaction execution method and node in a blockchain system, which is conducive to improving the performance of the blockchain system.

[0004] In a first aspect, a transaction execution method in a blockchain system is provided, wherein the blockchain system includes multiple blockchain nodes, the multiple blockchain nodes include multiple consensus nodes, the multiple consensus nodes include consensus proposal nodes, the blockchain nodes are configured with a trusted execution environment (TEE), the TEEs of the multiple blockchain nodes are configured with the same public-private key pair, and the method is executed by the blockchain nodes. The method includes: receiving a transaction request from a user device, the transaction request including a transaction ciphertext obtained by symmetrically encrypting a first transaction using a first key, and a key ciphertext obtained by asymmetrically encrypting the first key using a public key of the TEE; in the TEE of the blockchain node, asymmetrically decrypting the key ciphertext using the private key of the TEE to obtain the first key, symmetrically encrypting target information using a second key to obtain a forwarding ciphertext, the target information at least including the first key, and providing the forwarding ciphertext to the outside of the TEE, so that the consensus proposal node generates a consensus proposal including the transaction request and the forwarding ciphertext, so that when the consensus node reaches a consensus on the consensus proposal, the consensus node symmetrically decrypts the forwarding ciphertext in its TEE according to the second key to obtain the first key, symmetrically decrypts the transaction ciphertext using the first key to obtain the first transaction, and executes the first transaction.

[0005] In a second aspect, a transaction execution method in a blockchain system is provided, wherein the blockchain system includes multiple blockchain nodes, the multiple blockchain nodes include multiple consensus nodes, the multiple consensus nodes include consensus proposal nodes, the blockchain nodes are configured with TEEs, and the TEEs of the multiple blockchain nodes are configured with the same public-private key pair, and the method is executed by the consensus nodes. The method includes: reaching consensus on a consensus proposal generated by the consensus proposal node, the consensus proposal including a transaction request from a user device and its corresponding forwarding ciphertext, the transaction request including a transaction ciphertext obtained by symmetrically encrypting a first transaction using a first key, and a key ciphertext obtained by asymmetrically encrypting the first key using a public key of the TEE, the forwarding ciphertext is obtained by a target node using a second key to symmetrically encrypt target information in its TEE, the target information includes the first key obtained by asymmetrically decrypting the key ciphertext using a private key of the TEE, and the target node is a blockchain node that receives the transaction request from the user device; when consensus is reached on the consensus proposal, in the TEE of the consensus node, the forwarding ciphertext is symmetrically decrypted according to the second key to obtain the first key, the transaction ciphertext is symmetrically decrypted using the first key to obtain the first transaction, and the first transaction is executed.

[0006] According to a third aspect, a blockchain node in a blockchain system is provided, wherein the blockchain system includes multiple blockchain nodes, the multiple blockchain nodes include multiple consensus nodes, the multiple consensus nodes include consensus proposal nodes, the blockchain node is configured with a TEE, and the TEEs of the multiple blockchain nodes are configured with the same public-private key pair, and the blockchain node includes: a communication processing unit configured to receive a transaction request from a user device, wherein the transaction request includes a transaction ciphertext obtained by symmetric encryption of a first transaction using a first key, and a key ciphertext obtained by asymmetric encryption of the first key using the public key of the TEE; the TEE is configured to use The consensus proposal node generates a consensus proposal including the transaction request and the forwarding ciphertext, so that when the consensus node reaches a consensus on the consensus proposal, the consensus node symmetrically decrypts the forwarding ciphertext in its TEE according to the second key to obtain the first key, symmetrically decrypts the transaction ciphertext using the first key to obtain the first transaction, and executes the first transaction.

[0007] In a fourth aspect, a consensus node in a blockchain system is provided, wherein the blockchain system includes multiple blockchain nodes, the multiple blockchain nodes include multiple consensus nodes, the multiple consensus nodes include consensus proposal nodes, the blockchain nodes are configured with TEEs, and the TEEs of the multiple blockchain nodes are configured with the same public-private key pair. The consensus node includes: a consensus processing unit, configured to reach a consensus on a consensus proposal generated by the consensus proposal node, the consensus proposal including a transaction request from a user device and its corresponding forwarding ciphertext, the transaction request including a transaction ciphertext obtained by symmetrically encrypting a first transaction using a first key, and a key ciphertext obtained by asymmetrically encrypting the first key using the public key of the TEE, the forwarding ciphertext is obtained by the target node using a second key to symmetrically encrypt target information in its TEE, the target information includes the first key obtained by asymmetrically decrypting the key ciphertext using the private key of the TEE, and the target node is a blockchain node that receives the transaction request from the user device; the TEE is configured to, when consensus is reached on the consensus proposal, symmetrically decrypt the forwarding ciphertext according to the second key to obtain the first key, symmetrically decrypt the transaction ciphertext using the first key to obtain the first transaction, and execute the first transaction.

[0008] In the embodiments of this specification, a blockchain node that receives a transaction request from a user device can asymmetrically decrypt the key ciphertext in the transaction request using its private key within its TEE to obtain a first key used to encrypt the corresponding transaction. It can then symmetrically encrypt the first key using a second key corresponding to the transaction request to obtain a forwarding ciphertext corresponding to the transaction request, so that both the transaction request and its corresponding forwarding ciphertext are provided to the consensus proposal node. Accordingly, the consensus node can reach consensus on a consensus proposal generated by the consensus proposal node, including the transaction request and its corresponding forwarding ciphertext. After reaching consensus on the consensus proposal, the consensus node can symmetrically decrypt the forwarding ciphertext corresponding to the transaction request within its TEE using the second ciphertext corresponding to the transaction request to obtain a first key used to symmetrically decrypt the transaction ciphertext in the transaction request. It can then decrypt the corresponding transaction ciphertext using the first key to obtain the corresponding transaction and execute the transaction. This eliminates the need for the consensus node to expend excessive time asymmetrically decrypting the key ciphertext included in each transaction request in the consensus proposal. The asymmetrical decryption process for each key ciphertext is essentially distributed across multiple blockchain nodes in the entire blockchain system, which improves the performance of the blockchain system. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] In order to more clearly illustrate the technical solutions of the embodiments of this specification, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments recorded in this specification. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0010] Figure 1 This is an architecture diagram of a blockchain system provided in the embodiments of this specification;

[0011] Figure 2 This is a schematic diagram of the consensus process in the PBFT consensus algorithm;

[0012] Figure 3 This is one of the flow charts of a transaction execution method in a blockchain system provided in an embodiment of this specification;

[0013] Figure 4 This is the second flowchart of a transaction execution method in a blockchain system provided in an embodiment of this specification;

[0014] Figure 5 This is a schematic diagram of the structure of a blockchain node in a blockchain system provided in an embodiment of this specification;

[0015] Figure 6 This is a schematic diagram of the structure of a consensus node in a blockchain system provided in an embodiment of this specification. DETAILED DESCRIPTION

[0016] To help those skilled in the art better understand the technical solutions in this specification, the following will provide a clear and complete description of the technical solutions in the embodiments of this specification, in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of this specification, not all of them. All other embodiments derived by those skilled in the art based on the embodiments in this specification without creative effort shall fall within the scope of protection of this specification.

[0017] Figure 1 This is an architectural diagram of a blockchain system provided as an example in the embodiments of this specification. Figure 1 In the block chain system architecture diagram shown in FIG, the block chain system 100 may include, for example, N block chain nodes, where Figure 18 blockchain nodes, Node 1 through Node 8, are shown as examples. The lines between the nodes schematically represent P2P (Peer to Peer) connections, which can be, for example, Transmission Control Protocol (TCP) connections, used to support data transmission between different nodes.

[0018] A transaction in a blockchain system refers to a unit of work executed and recorded within the blockchain system. A transaction typically includes a sender (From), a receiver (To), and a data field (Data). In the case of a transfer transaction, the From field indicates the address of the account initiating the transaction (i.e., initiating a transfer task to another account), the To field indicates the address of the account receiving the transaction (i.e., receiving the transfer), and the Data field includes the transfer amount.

[0019] Blockchain systems can provide smart contract functionality. Smart contracts on blockchain systems are contracts that can be triggered and executed by transactions within the blockchain system. Smart contracts can be defined in code. Calling a smart contract in a blockchain system involves initiating a transaction directed to the smart contract address, enabling nodes within the blockchain system to execute the smart contract code in a distributed manner.

[0020] In the scenario of deploying a contract, for example, Bob sends a transaction containing the information of creating a smart contract (ie deploying the contract) to Figure 1 In the blockchain shown, the transaction's data field contains the code (such as bytecode or machine code) for the contract to be created. The transaction's to field is empty, indicating that the transaction is for deploying the contract. After the nodes reach consensus through the consensus mechanism, they determine the contract address "0x6f8ae93..." Each node adds a contract account corresponding to the smart contract's contract address to the state database, allocates state storage corresponding to the contract account, stores the contract code, and saves the hash of the contract code in the contract's state storage, successfully creating the contract.

[0021] In the scenario of calling a contract, for example, Bob sends a transaction for calling a smart contract to Figure 1 In the blockchain shown, the transaction's "from" field is the address of the account of the transaction initiator (Bob). The "to" field, for example, "0x6f8ae93...", is the address of the smart contract being called. The transaction's "data" field includes the method and parameters for calling the smart contract. After consensus is reached on the blockchain, each node in the blockchain can execute the transaction, thereby executing the contract and updating the state database based on the contract's execution.

[0022] The consensus mechanism in a blockchain system is a mechanism by which blockchain nodes reach a consensus across the entire network on block information (or block data), ensuring that the latest block is accurately added to the blockchain. Current mainstream consensus mechanisms include Proof of Work (POW), Proof of Stake (POS), Delegated Proof of Stake (DPOS), and Practical Byzantine Fault Tolerance (PBFT). Among these various consensus algorithms, consensus on a consensus proposal is typically considered successful only when a predetermined number of consensus nodes agree on the consensus data (i.e., the consensus proposal). Specifically, in the PBFT algorithm, for N ≥ 3f + 1 consensus nodes, f malicious nodes can be tolerated. In other words, consensus is considered successful when 2f + 1 of the N consensus nodes agree. In related technologies, to achieve consensus, the consensus nodes store the full ledger, i.e., the status of all blocks and all accounts. Thus, each node in the blockchain system can generate the same state in the blockchain system by executing the same transaction, so that each node in the blockchain system stores the same state database.

[0023] Figure 2 This is a schematic diagram of the consensus process in the PBFT consensus algorithm. Figure 2 As shown, according to the PBFT consensus algorithm, the consensus process can be divided into four phases: Request, Pre-Prepare (PP), Prepare (P), and Commit (C). Assume that a blockchain includes four consensus nodes, nodes n1 through n4, where node n1 is, for example, the master node and nodes n2 through n4 are slave nodes. According to the PBFT algorithm, nodes n1 through n4 can tolerate f = 1 malicious nodes. Specifically, in the Request phase, a blockchain user can send a request to node n1 via their user device. This request, for example, is in the form of a blockchain transaction. In the Pre-Prepare phase, after receiving multiple transactions from one or more user devices, node n1 packages these transactions into a consensus proposal and sends this consensus proposal and its signature to the other consensus nodes (i.e., nodes n2 through n4) for block generation. The consensus proposal may include information such as the transaction bodies and the order in which the transactions should be submitted. In the Prepare phase, each slave node can sign the consensus proposal and send it to the other nodes. Assuming that node n4 is a malicious node, after receiving signatures of 2f=2 other consensus nodes on the consensus proposal, nodes n1, n2, and n3 can determine that the preparation phase is complete and can enter the submission phase. Figure 2As shown in , after receiving the signatures of nodes n2 and n3, node n1 verifies that both their signatures are correct signatures of the consensus proposal, thus determining that the preparation phase is complete. Node n2 also determines that the preparation phase is complete after receiving and verifying the signatures of node n3 and node n1 from the preparation phase. During the commit phase, each consensus node signs the consensus proposal for the commit phase and sends it to the other consensus nodes. After receiving the commit phase signatures of 2f = 2 other consensus nodes, each consensus node determines that the commit phase is complete and consensus is successful. For example, after receiving and verifying the commit phase signatures of nodes n2 and n3, node n1 determines that the commit phase is complete. Thus, node n1 can execute the multiple transactions according to the consensus proposal, generate and store a block (e.g., block N) containing the multiple transactions, update the world state based on the execution results of the multiple transactions, and return the execution results of the multiple transactions to the user device. Similarly, after determining that the commit phase is complete, nodes n2 and n3 execute the multiple transactions, update the world state based on the execution results of the multiple transactions, and generate and store block N. Through the above process, the storage of nodes n1, n2, and n3 is identical. In other words, even if there is a malicious node, nodes n1-n4 can still successfully reach consensus on the consensus proposal and complete the execution of the block.

[0024] To ensure the security of transactions and state data in a blockchain system, blockchain nodes can be configured with a TEE. Furthermore, during the request phase of the consensus process, transaction requests sent by user devices to the blockchain system may be encrypted using envelope encryption. For example, the user device may select a symmetric key to symmetrically encrypt the desired transaction to obtain the transaction ciphertext. The selected symmetric key is then asymmetrically encrypted using the public key of the blockchain node's TEE to obtain the key ciphertext. The user device then sends a transaction request containing both the transaction ciphertext and the key ciphertext to the blockchain system, rather than directly sending the transaction itself. During the preparatory phase of the consensus process, a consensus proposal may include multiple transaction requests. Accordingly, the node that reaches consensus on the consensus proposal can decrypt the multiple transaction requests contained in the consensus proposal within its TEE, obtain the multiple transactions corresponding to the multiple transaction requests, and then execute the multiple transactions. It is important to note that different transaction requests / user devices typically use different symmetric keys to symmetrically encrypt the corresponding transactions.

[0025] In the related art, the node that reaches consensus on a consensus proposal needs to use the TEE's private key to asymmetric decrypt the key ciphertext included in each of the multiple transaction requests in the consensus proposal. However, the time required to perform asymmetric decryption is substantially longer than the time required to perform symmetric decryption, resulting in the consensus node spending a considerable amount of time to complete the asymmetric decryption of the key ciphertext included in each of the multiple transaction requests in the consensus proposal.

[0026] In view of the above issues, embodiments of this specification provide a transaction execution method and node in a blockchain system. A blockchain node that receives a transaction request from a user device can asymmetrically decrypt the key ciphertext in the transaction request using its private key in its TEE to obtain a first key used to encrypt the corresponding transaction. The first key can then be symmetrically encrypted using a second key corresponding to the transaction request to obtain a forwarding ciphertext corresponding to the transaction request, so that both the transaction request and its corresponding forwarding ciphertext are provided to a consensus proposal node. Accordingly, the consensus node can reach consensus on a consensus proposal generated by the consensus proposal node, including the transaction request and its corresponding forwarding ciphertext. After reaching consensus on the consensus proposal, the consensus node can symmetrically decrypt the forwarding ciphertext corresponding to the transaction request in its TEE using the second ciphertext corresponding to the transaction request to obtain a first key used to symmetrically decrypt the transaction ciphertext in the transaction request. The node can then use the first key to decrypt the corresponding transaction ciphertext to obtain the corresponding transaction and execute the transaction. In this way, the consensus node does not need to spend too much time to asymmetric decrypt the key ciphertext included in each transaction request in the consensus proposal. The process of asymmetric decryption of each key ciphertext is actually distributed to multiple blockchain nodes in the entire blockchain system, which is conducive to improving the performance of the blockchain system.

[0027] Figure 3 This is one of the flow charts of a transaction execution method in a blockchain system provided in an embodiment of this specification. The blockchain system includes multiple blockchain nodes configured with TEEs, and the TEEs of the multiple blockchain nodes are configured with the same public-private key pair. Some of the multiple blockchain nodes can serve as consensus nodes, that is, the multiple blockchain nodes can include multiple consensus nodes, and the multiple consensus nodes include consensus proposal nodes. This method can be executed by any blockchain node among the aforementioned multiple blockchain nodes. Through this method, the blockchain node in the blockchain system that serves as a consensus proposal node can obtain any transaction request Q1 from a user device and its corresponding forwarding ciphertext ED. See Figure 3 As shown, the method may include but is not limited to part or all of the following steps S31 to S37.

[0028] In step S31, the blockchain node receives a transaction request Q1 from a user device. The transaction request Q1 includes at least a transaction ciphertext ET obtained by symmetric encryption of the transaction Tx1 using the key key1 and a key ciphertext EK obtained by asymmetric encryption of the transaction ciphertext ET using the public key of the TEE.

[0029] For example, when a user device wishes to send a transaction Tx1 (i.e., a first transaction) to a blockchain system, it may generate / select a key key1 (i.e., a first key) for symmetric encryption of the transaction Tx1 according to a certain rule, symmetric encrypt the transaction Tx1 using key1 to obtain a transaction ciphertext ET, asymmetric encrypt key1 using the public key of the TEE in the blockchain node to obtain a key ciphertext EK, and then send a transaction request Q1 to the blockchain node connected to the user device. The transaction request Q1 includes at least the transaction ciphertext ET and the key ciphertext EK, and may also include a hash value of the transaction Tx1 calculated by the user device.

[0030] In step S32, the blockchain node provides a transaction request Q1 to its TEE.

[0031] In step S33, the TEE of the blockchain node uses its private key to asymmetrically decrypt the key ciphertext EK to obtain the key key1.

[0032] Optionally, the TEE of the blockchain node may execute the following step S34 to determine the key key2 corresponding to the transaction request Q1.

[0033] The key key2 (i.e., the second key) corresponding to the transaction request Q1 can be obtained by processing the transaction request Q1 based on a certain preset rule. For example, when the transaction request Q1 includes the hash value of the transaction Tx1, the key key2 corresponding to the transaction request Q1 can be calculated based on the hash value of the transaction Tx1 and the private key of the TEE.

[0034] In step S35, the TEE of the blockchain node uses the key key2 to symmetrically encrypt the target information to obtain the forwarding ciphertext ED.

[0035] The key key2 in step S35 is, for example, the key key2 determined in step S34, or may be the private key of the TEE.

[0036] The target information includes at least the key key1, and may also include the hash value of the transaction Tx1 in the transaction request Q1 and / or the random number obtained by the TEE of the blockchain node. The purpose of adding the random number to the target information is to prevent intruders from cracking the private key of the TEE based on the forwarded ciphertext ED.

[0037] In step S36, the TEE of the blockchain node provides the forwarding ciphertext ED to the outside.

[0038] When the blockchain node executing the aforementioned steps S31 to S36 is a consensus proposal node, the consensus proposal node can obtain the transaction request Q1 and its corresponding forwarding ciphertext ED by executing the aforementioned steps S31 to S36.

[0039] When the blockchain node executing the aforementioned steps S31 to S36 is not a consensus proposal node, the blockchain node may further proceed to execute the following step S37 to send a transaction request Q1 and its corresponding forwarding ciphertext ED to the consensus proposal node.

[0040] It is understood that for each transaction request issued by a user device, a process identical to or similar to steps S31 to S37 can be performed to enable the consensus proposal node in the blockchain system to obtain the transaction request and its corresponding forwarding ciphertext. Accordingly, after obtaining multiple transaction requests and their corresponding forwarding ciphertexts, the consensus proposal node can initiate a consensus proposal containing the multiple transaction requests and their corresponding forwarding ciphertexts and perform the subsequent transaction execution process.

[0041] Figure 4 This is a flowchart of a transaction execution method in a blockchain system provided in an embodiment of this specification. The blockchain system includes multiple blockchain nodes configured with TEEs, and the TEEs of the multiple blockchain nodes are configured with the same public and private key pairs. The multiple blockchain nodes include multiple consensus nodes, and the multiple consensus nodes include consensus proposal nodes. In addition, the consensus proposal nodes can, for example, be configured through the aforementioned Figure 3 The method shown obtains multiple transaction requests and their corresponding forwarding ciphertexts. This method can be executed by any consensus node among the aforementioned multiple consensus nodes. Through this method, the blockchain node serving as the consensus node in the blockchain system can complete the execution of multiple transactions. Figure 4 As shown, the method may include but is not limited to part or all of the following steps S41 to S48.

[0042] When a consensus node is used as a consensus proposal node, it needs to execute step S41 to generate a consensus proposal, which includes multiple transaction requests arranged in sequence and their corresponding forwarding ciphertexts. Then, it will execute the following step S42.

[0043] If the consensus node is not designated as a consensus proposing node, step S42 may be directly executed to reach consensus with the remaining consensus nodes in the plurality of consensus nodes on the consensus proposal generated by the consensus proposing node. The process of reaching consensus on the consensus proposal can be found in the various stages of the consensus process based on the PBFT consensus algorithm described above and will not be further described here.

[0044] When consensus is reached on the consensus proposal, the consensus node executes step S43 to provide its TEE with multiple transaction requests in the consensus proposal and their corresponding forwarding ciphertexts.

[0045] The TEE of the consensus node can execute part or all of the following steps S44 to S48 for any transaction request Q1 among the multiple transaction requests to complete the execution of the transaction Tx1 corresponding to the transaction request Q1.

[0046] Optionally, in step S44 , a key key2 corresponding to the transaction request Q1 is determined.

[0047] The key key2 can be obtained by the same method as the aforementioned step S34. For example, the TEE of the consensus node can obtain the hash value of the transaction Tx1 from the transaction request Q1, and then calculate the key key2 based on the hash value of the transaction Tx1 and the private key of the TEE.

[0048] Step S45 : Using the key key2 symmetrically decrypt the forwarded ciphertext ED corresponding to the transaction request Q1 to obtain target information, where the target information at least includes the key key1 .

[0049] As mentioned above, the target information includes at least key1 and may also include the hash value and / or random number of transaction Tx1. The key2 in the aforementioned step S45 is, for example, the key2 determined in step S45, or may be the private key of the TEE.

[0050] When the target information includes the hash value of transaction Tx1, the transaction request Q1 received by the consensus node's TEE from the outside should also include the hash value of transaction Tx1. In this case, the consensus node's TEE can also execute the following step S46.

[0051] Step S46 verifies the hash value of transaction Tx1. In other words, it verifies whether the hash value of transaction Tx1 included in transaction request Q1 is the same as the hash value of transaction Tx1 included in the target information. If they are different, it indicates that an intruder outside the TEE may have forged the forwarding ciphertext ED corresponding to transaction request Q1 provided to the consensus node's TEE. If they are the same, it means that the hash value of transaction Tx1 has passed verification, and the consensus node's TEE can proceed to the following step S47.

[0052] Step S47: Use the key key1 to symmetrically decrypt the transaction ciphertext ET in the transaction request Q1 to obtain the transaction Tx1.

[0053] Step S48, execute transaction Tx1.

[0054] It should be noted that the consensus node may not provide the forwarding ciphertext corresponding to the transaction request Q1 to its TEE. In this case, the TEE of the consensus node does not need to execute steps S44 to S46, but instead uses its private key to asymmetrically decrypt the key ciphertext EK in the transaction request Q1 to obtain the key key1, and then execute subsequent steps S47 and S48.

[0055] It should be noted that if the hash value of transaction Tx1 fails to pass verification, the TEE of the consensus node can also use its private key to asymmetric decrypt the key ciphertext EK in the transaction request Q1 to obtain the key key1, and then execute steps S47 and S48.

[0056] In each of the above method embodiments, the consensus node does not need to spend too much time to asymmetric decrypt the key ciphertext included in each transaction request in the consensus proposal. The process of asymmetric decryption of each key ciphertext is essentially distributed to multiple blockchain nodes in the entire blockchain system, which is conducive to improving the performance of the blockchain system.

[0057] Based on the same concept as the aforementioned method embodiment, the embodiment of this specification provides a blockchain node in a blockchain system, wherein the blockchain system includes multiple blockchain nodes, the multiple blockchain nodes include multiple consensus nodes, the multiple consensus nodes include consensus proposal nodes, the blockchain nodes are configured with TEE, and the TEEs of the multiple blockchain nodes are configured with the same public and private key pairs. Figure 5 As shown, the blockchain node includes: a communication processing unit 51, configured to receive a transaction request from a user device, wherein the transaction request includes a transaction ciphertext obtained by symmetrically encrypting a first transaction using a first key, and a key ciphertext obtained by asymmetrically encrypting the first key using the public key of the TEE; TEE 53, configured to asymmetrically decrypt the key ciphertext using its private key to obtain the first key, symmetrically encrypt the target information using a second key to obtain a forwarding ciphertext, wherein the target information includes at least the first key, and provide the forwarding ciphertext to the outside, so that the consensus proposal node generates a consensus proposal including the transaction request and the forwarding ciphertext, so that when the consensus node reaches a consensus on the consensus proposal, the forwarding ciphertext is symmetrically decrypted according to the second key in its TEE to obtain the first key, and the transaction ciphertext is symmetrically decrypted using the first key to obtain the first transaction, and the first transaction is executed.

[0058] In a possible implementation, the transaction request also includes a hash value of the first transaction, and the second key is calculated based on the private key of the TEE and the hash value of the first transaction.

[0059] In a possible implementation manner, the target information further includes a random number and a hash value of the first transaction.

[0060] In a possible implementation, the blockchain node is not the consensus proposal node, and the communication processing unit 51 is further configured to send the transaction request and the forwarding ciphertext to the consensus proposal node.

[0061] Based on the same concept as the aforementioned method embodiment, the embodiment of this specification also provides a consensus node in a blockchain system, wherein the blockchain system includes multiple blockchain nodes, the multiple blockchain nodes include multiple consensus nodes, the multiple consensus nodes include consensus proposal nodes, the blockchain nodes are configured with TEE, and the TEEs of the multiple blockchain nodes are configured with the same public and private key pairs. Figure 6 As shown, the consensus node includes: a consensus processing unit 61, configured to reach a consensus on the consensus proposal generated by the consensus proposal node, the consensus proposal including a transaction request from a user device and its corresponding forwarding ciphertext, the transaction request including a transaction ciphertext obtained by symmetrically encrypting a first transaction using a first key, and a key ciphertext obtained by asymmetrically encrypting the first key using the public key of the TEE, the forwarding ciphertext is obtained by the target node using a second key to symmetrically encrypt the target information in its TEE, the target information includes the first key obtained by asymmetrically decrypting the key ciphertext using the private key of the TEE, and the target node is a blockchain node that receives the transaction request from the user device; TEE63, configured to, when consensus is reached on the consensus proposal, symmetrically decrypt the forwarding ciphertext according to the second key to obtain the first key, symmetrically decrypt the transaction ciphertext using the first key to obtain the first transaction, and execute the first transaction.

[0062] In a possible implementation, the transaction request also includes a hash value of the first transaction, and the TEE 63 of the consensus node is further configured to calculate the second key based on its private key and the hash value of the first transaction.

[0063] In one possible implementation, the TEE 63 of the consensus node is configured to symmetrically decrypt the forwarded ciphertext according to the second key to obtain the target information, where the target information includes the first key, the hash value of the first transaction, and a random number.

[0064] In one possible implementation, the TEE 63 of the consensus node is further configured to verify the hash value of the first transaction; and, if the hash value of the first transaction fails the verification, asymmetrically decrypt the key ciphertext according to the private key of the TEE to obtain the first key.

[0065] In one possible implementation, the consensus node is the consensus proposal node, and the consensus node further includes: a communication processing unit 65, configured to receive the transaction request and the forwarding ciphertext from other blockchain nodes; and the consensus processing unit 61, further configured to generate the consensus proposal.

[0066] The embodiments of this specification also provide a computer-readable storage medium having a computer program stored thereon. When the computer program is executed in a computer, the computer is caused to execute the various method steps performed by the TEE in the blockchain node or consensus node in the aforementioned method embodiments.

[0067] In the 1990s, technological improvements could be clearly distinguished as either hardware improvements (for example, improvements to circuit structures like diodes, transistors, and switches) or software improvements (improvements to process flows). However, with the advancement of technology, many process flow improvements today can now be considered direct improvements to hardware circuit structures. Designers almost always create the corresponding hardware circuit structure by programming the improved process flow into the hardware circuit. Therefore, it cannot be said that a process flow improvement cannot be implemented using hardware modules. For example, a programmable logic device (PLD), such as a field programmable gate array (FPGA), is an integrated circuit whose logical function is determined by user programming. Designers can "integrate" a digital system on a PLD through their own programming, without having to hire a chip manufacturer to design and manufacture a dedicated integrated circuit chip. Moreover, nowadays, instead of manually fabricating integrated circuit chips, this programming is mostly done using "logic compiler" software. This is similar to the software compiler used when developing programs. Before compilation, the original code must also be written in a specific programming language, called a hardware description language (HDL). There is not just one HDL, but many, 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. The most commonly used ones are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art will also understand that by simply programming the method flow in one of these hardware description languages ​​and then programming it into an integrated circuit, a hardware circuit that implements the logic method flow can be easily obtained.

[0068] The controller can be implemented in any suitable manner. For example, the controller 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 Silicone Labs C8051F320. The memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also know that in addition to implementing the controller in a purely computer-readable program code format, the controller can be implemented in the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers by logically programming the method steps. Therefore, such a controller can be considered a hardware component, and the devices included therein for implementing various functions can also be considered as structures within the hardware component. Or even, the devices for implementing various functions can be considered as both software modules that implement the method and structures within the hardware component.

[0069] The systems, devices, modules or units described in the above embodiments may be 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 future development of computer technology, the computer that implements the functions of the above embodiments may be, for example, a personal computer, a laptop computer, an in-vehicle human-computer interaction device, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.

[0070] Although one or more embodiments of this specification provide method operation steps as described in the embodiments or flow charts, more 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 of executing the order of many steps and does not represent the only execution order. When the device or terminal product in practice is executed, it can be executed in sequence or in parallel according to the method shown in the embodiments or the drawings (for example, a parallel processor or a multi-threaded processing environment, or even a distributed data processing environment). The term "comprise", "include" or any other variant thereof is intended to cover non-exclusive inclusion, so that the process, method, product or equipment including a series of elements includes not only those elements, but also includes other elements that are not clearly listed, or also includes elements inherent to such process, method, product or equipment. In the absence of more restrictions, it is not excluded that there are other identical or equivalent elements in the process, method, product or equipment including the elements. For example, if the words first, second, etc. are used to represent the name, they do not represent any particular order.

[0071] For the convenience of description, the above devices are described in terms of functions divided into various modules. Of course, when implementing one or more of the present specifications, the functions of each module can be implemented in the same or multiple software and / or hardware, or the module that implements the same function can be implemented by a combination of multiple sub-modules or sub-units, etc. The device embodiments described above are merely schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, devices or units, which can be electrical, mechanical or other forms.

[0072] The present invention is described with reference to flowcharts and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the present invention. It should be understood that each process and / or block in the flowcharts and / or block diagrams, as well as combinations of processes and / or blocks in the flowcharts 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, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowcharts and / or block diagrams. Figure 1 a process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0073] These computer program instructions may also be stored in a computer readable memory that can direct a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 a process or multiple processes and / or boxes Figure 1 The function specified in one or more boxes.

[0074] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operational steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing the instructions executed on the computer or other programmable device for implementing the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.

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

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

[0077] Computer-readable media include permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. 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 technology, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassettes, magnetic disk storage, graphene storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer-readable media does not include transitory media such as modulated data signals and carrier waves.

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

[0079] One or more embodiments of this specification may 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, and the like that perform specific tasks or implement specific abstract data types. One or more embodiments of this specification may also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communications network. In a distributed computing environment, program modules may be located in local and remote computer storage media, including storage devices.

[0080] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between the various embodiments can be referenced to each other. Each embodiment focuses on the differences from other embodiments. In particular, since the system embodiments are generally similar to the method embodiments, the description is relatively simple. For relevant parts, reference can be made to the description of the method embodiments. Throughout this specification, reference to the terms "one embodiment," "some embodiments," "examples," "specific examples," or "some examples" means that the specific features, structures, materials, or characteristics described in conjunction with that embodiment or example are included in at least one embodiment or example of this specification. In this specification, the schematic representations of these terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples. Furthermore, those skilled in the art may combine and integrate the different embodiments or examples, and features of different embodiments or examples, described in this specification, unless they conflict with each other.

[0081] The foregoing description is merely an example of one or more embodiments of this specification and is not intended to limit the one or more embodiments of this specification. Those skilled in the art will appreciate that various modifications and variations of one or more embodiments of this specification are possible. Any modifications, equivalent substitutions, or improvements made within the spirit and principles of this specification are intended to be included within the scope of the claims.

Claims

1. A transaction execution method in a blockchain system, the blockchain system comprising a plurality of blockchain nodes, the plurality of blockchain nodes comprising a plurality of consensus nodes, the plurality of consensus nodes comprising a consensus proposal node, the blockchain nodes being configured with a trusted execution environment (TEE), the TEEs of the plurality of blockchain nodes being configured with the same public-private key pair, the method being executed by the blockchain nodes, the method comprising: Receiving a transaction request from a user device, the transaction request including a transaction ciphertext obtained by symmetrically encrypting a first transaction using a first key and a key ciphertext obtained by asymmetrically encrypting the first key using a public key of the TEE; In the TEE of the blockchain node, the key ciphertext is asymmetrically decrypted using its private key to obtain the first key, and the target information is symmetrically encrypted using the second key to obtain a forwarding ciphertext, where the target information at least includes the first key, and the forwarding ciphertext is provided to the outside of the TEE, so that the consensus proposal node generates a consensus proposal including the transaction request and the forwarding ciphertext, so that when the consensus node reaches a consensus on the consensus proposal, the forwarding ciphertext is symmetrically decrypted in its TEE according to the second key to obtain the first key, the transaction ciphertext is symmetrically decrypted using the first key to obtain the first transaction, and the first transaction is executed.

2. According to the method of claim 1, the transaction request also includes a hash value of the first transaction, and the second key is calculated based on the private key of the TEE and the hash value of the first transaction.

3. The method according to claim 1, wherein the target information further includes a random number and a hash value of the first transaction.

4. The method according to any one of claims 1 to 3, wherein the blockchain node is not the consensus proposal node, and the method further comprises: Send the transaction request and the forwarding ciphertext to the consensus proposal node.

5. A transaction execution method in a blockchain system, the blockchain system comprising a plurality of blockchain nodes, the plurality of blockchain nodes including a plurality of consensus nodes, the plurality of consensus nodes including a consensus proposal node, the blockchain nodes being configured with a trusted execution environment (TEE), the TEEs of the plurality of blockchain nodes being configured with the same public-private key pair, the method being executed by the consensus nodes, the method comprising: Reaching consensus on a consensus proposal generated by the consensus proposal node, the consensus proposal including a transaction request from a user device and its corresponding forwarding ciphertext, the transaction request including a transaction ciphertext obtained by symmetrically encrypting a first transaction using a first key, and a key ciphertext obtained by asymmetrically encrypting the first key using the public key of the TEE, the forwarding ciphertext being obtained by symmetrically encrypting target information using a second key in the TEE of the target node, the target information including the first key obtained by asymmetrically decrypting the key ciphertext using the private key of the TEE, and the target node being the blockchain node that receives the transaction request from the user device; When consensus is reached on the consensus proposal, in the TEE of the consensus node, the forwarded ciphertext is symmetrically decrypted according to the second key to obtain the first key, the transaction ciphertext is symmetrically decrypted using the first key to obtain the first transaction, and the first transaction is executed.

6. The method according to claim 5, wherein the transaction request further includes a hash value of the first transaction; the method further includes: In the TEE of the consensus node, the second key is calculated based on its private key and the hash value of the first transaction.

7. The method according to claim 5, wherein the symmetrically decrypting the forwarded ciphertext according to the second key to obtain the first key comprises: The forwarded ciphertext is symmetrically decrypted according to the second key to obtain the target information, where the target information includes the first key, the hash value of the first transaction, and a random number.

8. The method according to claim 7, further comprising: In the TEE of the consensus node, verify the hash value of the first transaction; In the TEE of the consensus node, when the hash value of the first transaction fails to pass verification, the key ciphertext is asymmetrically decrypted according to the private key of the TEE to obtain the first key.

9. The method according to any one of claims 5 to 8, wherein the consensus node is the consensus proposal node; the method further comprising: Receive the transaction request and the forwarding ciphertext from other blockchain nodes; and generating the consensus proposal.

10. A blockchain node in a blockchain system, the blockchain system comprising multiple blockchain nodes, the multiple blockchain nodes comprising multiple consensus nodes, the multiple consensus nodes comprising a consensus proposal node, the blockchain node being configured with a trusted execution environment (TEE), the TEEs of the multiple blockchain nodes being configured with the same public-private key pair, the blockchain node comprising: a communication processing unit configured to receive a transaction request from a user device, the transaction request including a transaction ciphertext obtained by symmetrically encrypting a first transaction using a first key and a key ciphertext obtained by asymmetrically encrypting the first key using a public key of the TEE; The TEE is configured to use its private key to asymmetrically decrypt the key ciphertext to obtain the first key, use the second key to symmetrically encrypt target information to obtain a forwarding ciphertext, where the target information includes at least the first key, and provide the forwarding ciphertext to the outside of the TEE, so that the consensus proposal node generates a consensus proposal including the transaction request and the forwarding ciphertext, so that when the consensus node reaches a consensus on the consensus proposal, the consensus node, in its TEE, symmetrically decrypts the forwarding ciphertext according to the second key to obtain the first key, uses the first key to symmetrically decrypt the transaction ciphertext to obtain the first transaction, and executes the first transaction.

11. The blockchain node according to claim 10, wherein the transaction request also includes a hash value of the first transaction, and the second key is calculated based on the private key of the TEE and the hash value of the first transaction.

12. The blockchain node according to claim 10, wherein the target information further includes a random number and a hash value of the first transaction.

13. The blockchain node according to claim 10, wherein the blockchain node is not the consensus proposal node, and the communication processing unit is further used to send the transaction request and the forwarding ciphertext to the consensus proposal node.

14. A consensus node in a blockchain system, the blockchain system comprising multiple blockchain nodes, the multiple blockchain nodes including multiple consensus nodes, the multiple consensus nodes including a consensus proposal node, the blockchain nodes configured with a trusted execution environment (TEE), the TEEs of the multiple blockchain nodes configured with the same public-private key pair, the consensus node comprising: a consensus processing unit configured to reach a consensus on a consensus proposal generated by the consensus proposal node, the consensus proposal comprising a transaction request from a user device and its corresponding forwarding ciphertext, the transaction request comprising a transaction ciphertext obtained by symmetrically encrypting a first transaction using a first key, and a key ciphertext obtained by asymmetrically encrypting the first key using a public key of the TEE, the forwarding ciphertext being obtained by symmetrically encrypting target information in the TEE using a second key by a target node, the target information comprising the first key obtained by asymmetrically decrypting the key ciphertext using a private key of the TEE, and the target node being a blockchain node that receives the transaction request from the user device; The TEE is configured to, when consensus is reached on the consensus proposal, symmetrically decrypt the forwarded ciphertext according to the second key to obtain the first key, symmetrically decrypt the transaction ciphertext using the first key to obtain the first transaction, and execute the first transaction.

15. The consensus node according to claim 14, wherein the transaction request also includes a hash value of the first transaction, and the TEE of the consensus node is further configured to calculate the second key based on its private key and the hash value of the first transaction.

16. The consensus node according to claim 14, the TEE of the consensus node is configured to symmetrically decrypt the forwarded ciphertext according to the second key to obtain the target information, wherein the target information includes the first key, the hash value of the first transaction and the random number.

17. The consensus node according to claim 16, the TEE of the consensus node is further configured to verify the hash value of the first transaction; and, if the hash value of the first transaction fails to pass the verification, asymmetrically decrypt the key ciphertext according to the private key of the TEE to obtain the first key.

18. The consensus node according to claim 16, wherein the consensus node is the consensus proposal node, and the consensus node further comprises: a communication processing unit, configured to receive the transaction request and the forwarding ciphertext from other blockchain nodes; The consensus processing unit is further configured to generate the consensus proposal.

Images