Transaction execution method in a blockchain system and blockchain node

Abstract

A transaction execution method in a blockchain system and a blockchain node, TEEs of a plurality of blockchain nodes in the blockchain system are configured with the same public-private key pair. The method performed by the blockchain node comprises: receiving a first transaction request from a user device, including transaction ciphertext obtained by encrypting a first transaction with a first key, first key ciphertext obtained by encrypting the first key with a public key; in the TEE of the blockchain node, decrypting the first key ciphertext with a private key to obtain the first key, encrypting target information with a second key to obtain second key ciphertext, the target information including the first key, providing a second transaction request to the outside of the TEE, the second transaction request including the transaction ciphertext and the second key ciphertext, so that each blockchain node, in its TEE, decrypts the second key ciphertext with the second key to obtain the first key, decrypts the transaction ciphertext with the first key to obtain the first transaction, and executes the first transaction.

Description

TECHNICAL FIELD

[0001] Embodiments of the present specification belong to the field of blockchains, and particularly relate to a transaction execution method in a blockchain system and a blockchain node. BACKGROUND

[0002] Blockchain is a new application mode of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanism, and encryption algorithm. In a blockchain system, data blocks are combined into a chain-type data structure in a time sequence, and a distributed ledger is ensured to be unalterable and unforgeable by means of cryptography. Due to the characteristics of decentralization, unalterable information, and autonomy, blockchain has attracted more and more attention and application. SUMMARY

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

[0004] In a first aspect, a transaction execution method in a blockchain system is provided, the blockchain system comprising a plurality of blockchain nodes, the blockchain nodes being configured with a trusted execution environment (TEE), and the TEEs of the plurality of blockchain nodes being configured with the same public-private key pair, the method being performed by a first blockchain node of the plurality of blockchain nodes. The method comprises: receiving a first transaction request from a user device, the first transaction request comprising transaction ciphertext obtained by symmetrically encrypting a first transaction with a first key, and first key ciphertext obtained by asymmetrically encrypting the first key with a public key of the public-private key pair; in the TEE of the blockchain node, asymmetrically decrypting the first key ciphertext with a private key of the public-private key pair to obtain the first key, symmetrically encrypting target information with a second key to obtain second key ciphertext, the target information at least comprising the first key, and providing a second transaction request to the outside of the TEE, the second transaction request comprising the transaction ciphertext and the second key ciphertext, so that each of the blockchain nodes, in its TEE, symmetrically decrypts the second key ciphertext with the second key to obtain the first key, symmetrically decrypts the transaction ciphertext with 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, the blockchain system comprising a plurality of blockchain nodes, the blockchain nodes being configured with a TEE, the TEEs of the plurality of blockchain nodes being configured with a same public-private key pair, the method being performed by a second blockchain node of the plurality of blockchain nodes. The method comprises: obtaining a second transaction request provided by a TEE of a target node, the target node being a blockchain node that receives a first transaction request from a user device, the first transaction request comprising a transaction ciphertext obtained by symmetrically encrypting a first transaction with a first key, and a first key ciphertext obtained by asymmetrically encrypting the first key with a public key of the public-private key pair, the second transaction request comprising the transaction ciphertext and a second key ciphertext, the second key ciphertext being obtained by the target node in the TEE thereof by encrypting target information with a second key, the target information comprising the first key; in the TEE of the second blockchain node, symmetrically decrypting the second key ciphertext with the second key to obtain the first key, symmetrically decrypting the transaction ciphertext with the first key to obtain the first transaction, and executing the first transaction.

[0006] In a third aspect, a blockchain node in a blockchain system is provided, the blockchain system comprising a plurality of blockchain nodes, the blockchain nodes being configured with a TEE, the TEEs of the plurality of blockchain nodes being configured with a same public-private key pair. The blockchain node comprises: a communication processing unit configured to receive a first transaction request from a user device, the first transaction request comprising a transaction ciphertext obtained by symmetrically encrypting a first transaction with a first key, and a first key ciphertext obtained by asymmetrically encrypting the first key with a public key of the public-private key pair; and a TEE configured to asymmetrically decrypt the first key ciphertext with a private key of the public-private key pair to obtain the first key, symmetrically encrypt target information with a second key to obtain a second key ciphertext, the target information comprising at least the first key, and provide a second transaction request outside the TEE, the second transaction request comprising the transaction ciphertext and the second key ciphertext, such that each of the blockchain nodes, in the TEE thereof, symmetrically decrypts the second key ciphertext with the second key to obtain the first key, symmetrically decrypts the transaction ciphertext with the first key to obtain the first transaction, and executes the first transaction.

[0007] In a fourth aspect, a blockchain node in a blockchain system is provided, the blockchain system comprising a plurality of blockchain nodes, the blockchain nodes being configured with a trusted execution environment (TEE), and the TEEs of the plurality of blockchain nodes being configured with a same public-private key pair. The blockchain node comprises: a transaction obtaining unit, configured to obtain a second transaction request provided by a TEE of a target node, the target node being a blockchain node that receives a first transaction request from a user device, the first transaction request comprising transaction ciphertext obtained by symmetrically encrypting a first transaction with a first key, and first key ciphertext obtained by asymmetrically encrypting the first key with a public key in the public-private key pair, the second transaction request comprising the transaction ciphertext and second key ciphertext, the second key ciphertext being obtained by the target node in the TEE thereof by encrypting target information with a second key, the target information comprising the first key; and the TEE, configured to symmetrically decrypt the second key ciphertext with the second key to obtain the first key, symmetrically decrypt the transaction ciphertext with the first key to obtain the first transaction, and execute the first transaction.

[0008] In the scheme of the embodiments of the present specification, for a blockchain node that receives a first transaction request from a user device, the first key ciphertext in the first transaction request can be asymmetrically decrypted in the TEE thereof to obtain the first key used to encrypt the first transaction, and then the first key is symmetrically encrypted with a second key corresponding to the first transaction request to obtain second key ciphertext, and a second transaction request containing the transaction ciphertext and the second key ciphertext is provided to the outside of the TEE. Correspondingly, each blockchain node in the blockchain system can, in the TEE thereof, symmetrically decrypt the second key ciphertext in the second transaction request with the corresponding second key to obtain the first key used to symmetrically decrypt the transaction ciphertext in the second transaction request, and then symmetrically decrypt the transaction ciphertext with the first key to obtain the first transaction and execute the first transaction. In this way, for a single transaction request from a user device, it is not necessary for all blockchain nodes in the blockchain system to asymmetrically decrypt the key ciphertext included in the transaction request, which is beneficial to improving the performance of the blockchain system. BRIEF DESCRIPTION OF DRAWINGS

[0009] In order to more clearly illustrate the technical solutions of the embodiments of the present specification, the drawings needed in the embodiment description will be briefly introduced below. Obviously, the drawings in the following description are only some embodiments described in the present specification, and other drawings can also be obtained according to these drawings without creative labor.

[0010] Figure 1 An architecture diagram of a blockchain system provided in the embodiments of the present specification;

[0011] Figure 2 A schematic diagram of a consensus process in a PBFT consensus algorithm;

[0012] Figure 3 One of flowcharts of a transaction execution method in a blockchain system provided in an embodiment of the present specification;

[0013] Figure 4 Another of flowcharts of a transaction execution method in a blockchain system provided in an embodiment of the present specification;

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

[0015] Figure 6 Another of schematic diagrams of a structure of a blockchain node in a blockchain system provided in an embodiment of the present specification. DETAILED DESCRIPTION

[0016] In order to enable those skilled in the art to better understand the technical solutions in the present specification, the technical solutions in the embodiments of the present specification will be described clearly and completely in conjunction with the accompanying drawings in the embodiments of the present specification. Obviously, the described embodiments are only a part of the embodiments of the present specification, rather than all the embodiments. Based on the embodiments in the present specification, all other embodiments obtained by those skilled in the art without creative labor should belong to the scope of protection of the present specification.

[0017] Figure 1 An architecture diagram of a blockchain system exemplarily provided in an embodiment of the present specification. In Figure 1 In the architecture diagram of the blockchain system shown, the blockchain system 100 may, for example, include N blockchain nodes, wherein Figure 1 Exemplarily shown in the blockchain system 100 are eight blockchain nodes, i.e., node 1-node 8. The connection lines between the nodes schematically represent P2P (Peer to Peer) connections, and the aforementioned connections may, for example, be TCP (Transmission Control Protocol) connections, which are used to support the transmission of data between different nodes.

[0018] A transaction in a blockchain system can refer to a unit of task performed in the blockchain system and recorded in the blockchain system. A transaction usually includes a sending field (From), a receiving field (To) and a data field (Data). Among them, in the case of a transaction being a transfer transaction, the From field represents the account address of the account initiating the transaction (i.e., initiating the task of transferring funds to another account), the To field represents the account address receiving the transaction (i.e., receiving the transfer), and the Data field includes the transfer amount.

[0019] A smart contract can be provided in a blockchain system. A smart contract on a blockchain system is a contract that can be triggered and executed by a transaction on the blockchain system. A smart contract can be defined in the form of code. Invoking a smart contract in a blockchain system is to initiate a transaction pointing to the address of the smart contract, so that the nodes in the blockchain system run the smart contract code in a distributed manner.

[0020] In the scenario of deploying a contract, for example, Bob sends a transaction containing information for creating a smart contract (i.e., deploying a contract) to a blockchain as shown in Figure 1 The data field of the transaction includes the code (such as bytecode or machine code) of the contract to be created, and the to field of the transaction is empty, indicating that the transaction is used to deploy the contract. After the same is reached through the consensus mechanism among the nodes, the contract address "0x6f8ae93…" of the contract is determined, each node adds a contract account corresponding to the contract address of the smart contract in the state database, allocates a state storage corresponding to the contract account, stores the contract code, saves the hash value of the contract code in the state storage of the contract, and thus the contract is successfully created.

[0021] In the scenario of invoking a contract, for example, Bob sends a transaction for invoking a smart contract to a blockchain as shown in Figure 1 The from field of the transaction is the address of the account of the transaction initiator (i.e., Bob), the to field is, for example, "0x6f8ae93…" described above, i.e., the address of the invoked smart contract, and the data field of the transaction includes the method and parameters for invoking the smart contract. After the transaction is consensus in the blockchain, each node in the blockchain can execute the transaction respectively, thereby executing the contract respectively, and updating the state database based on the execution of the contract.

[0022] The consensus mechanism in a blockchain system is a mechanism by which blockchain nodes reach a network-wide consensus 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) algorithms. In various consensus algorithms, consensus on a proposal is typically determined when a predetermined number of consensus nodes agree on the data to be agreed upon (i.e., the consensus proposal). Specifically, in the PBFT algorithm, for N ≥ 3f+1 consensus nodes, f malicious nodes can be tolerated; that is, consensus is considered successful when 2f+1 out of N consensus nodes agree. In related technologies, to achieve consensus, the entire ledger is stored on the consensus nodes, meaning the state of all blocks and all accounts is stored. 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 a blockchain includes four consensus nodes: n1 to n4. Node n1 is, for example, the master node, and nodes n2 to n4 are, for example, slave nodes. According to the PBFT algorithm, f=1 malicious nodes can be tolerated among nodes n1 to n4. Specifically, in the Request phase, blockchain users can send requests to node n1 through their user devices. These requests can be, for example, in the form of blockchain transactions. In the Pre-Prepare phase, after receiving multiple transactions from one or more user devices, node n1 can package these transactions into a consensus proposal and send the consensus proposal, along with its signature, to other consensus nodes (i.e., nodes n2 to n4) for block generation. The consensus proposal may include information such as the transaction bodies and the submission order of the transactions. In the Prepare phase, each slave node can sign the consensus proposal and send it to the other nodes. Assuming node n4 is a malicious node, after nodes n1, n2, and n3 receive signatures of the consensus proposal from 2f = 2 other consensus nodes, they can determine that the preparation phase is complete and can proceed to the commit phase. For example, if... Figure 2As shown in the figure, after receiving the signatures of the nodes n2 and n3, the node n1 verifies that the signatures of the nodes n2 and n3 are correct signatures of the consensus proposal, and then determines that the preparation phase is completed. After receiving the signature of the node n3 and the signature of the node n1 in the preparation phase and verifying that the signature is correct, the node n2 determines that the preparation phase is completed. In the submission phase, each consensus node performs the signature of the submission phase on the consensus proposal and sends it to other consensus nodes. After receiving the signature of the submission phase of 2f=2 other consensus nodes, each consensus node can determine that the submission phase is completed and the consensus is successful. For example, after receiving the signatures of the nodes n2 and n3 in the submission phase and verifying that the signatures are correct, the node n1 determines that the submission phase is completed. Therefore, the node n1 can execute the plurality of transactions according to the consensus proposal, generate and store a block (for example, block N) including the plurality of transactions, update the world state according to the execution result of the plurality of transactions, and return the execution result of the plurality of transactions to the user device. Similarly, after determining that the submission phase is completed, the nodes n2 and n3 execute the plurality of transactions, update the world state according to the execution result of the plurality of transactions, and generate and store the block N. Through the above process, the storage consistency of the nodes n1, n2 and n3 is achieved. That is, the nodes n1-n4 can still achieve consensus success of the consensus proposal and complete the execution of the block in the presence of one malicious node.

[0024] In order to protect the privacy data in the blockchain system, the blockchain node can be configured with a TEE. The TEE is a trusted execution environment based on the security extension of CPU hardware and completely isolated from the outside. At present, the industry is very concerned about the TEE scheme, and almost all mainstream chips and software alliances have their own TEE solutions, such as TPM (Trusted Platform Module) in software and Intel SGX (Software Guard Extensions), ARM Trustzone (Trustzone) and AMD PSP (Platform Security Processor) in hardware. The TEE can act as a black box, and the code and data in the TEE cannot be snooped even by the operating system layer, and can only be operated through the pre-defined interface in the code. In terms of efficiency, due to the black box nature of the TEE, the operation in the TEE is performed on plaintext data, rather than the complex cryptography in homomorphic encryption, and the calculation process has almost no loss in efficiency. Therefore, the use of TEE technology can meet the trusted computing needs in the blockchain scenario to a great extent with relatively small performance loss.

[0025] In the TEE technology, Intel SGX (Intel Software Guard Extension, hereinafter referred to as SGX) technology is taken as an example for illustration. The blockchain node can create an enclave based on the SGX technology to serve as a TEE for executing a blockchain transaction. The blockchain node utilizes the newly added processor instructions in the CPU to allocate a part of the EPC (Enclave Page Cache) in the memory for hosting the enclave. The memory area corresponding to the EPC is encrypted by the MEE (Memory Encryption Engine) in the CPU, and the content (code and data in the enclave) in the memory area can only be decrypted in the CPU core, and the key for encryption and decryption is generated only when the EPC is started and stored in the CPU. It can be seen that the security boundary of the enclave only contains itself and the CPU, and neither privileged software nor unprivileged software can access the enclave, even the operating system administrator and the VMM (Virtual Machine Monitor, or Hypervisor) cannot affect the code and data in the enclave, thus having extremely high security. Under the premise of the above security guarantee, the CPU can process data in the enclave, having extremely high computing efficiency, thus balancing the data security and computing efficiency. In addition, the data in and out of the TEE can be encrypted, thus guaranteeing the privacy of the data.

[0026] After the TEE is created in the blockchain node (e.g., node 1 in Figure 1 , the specified program code can be loaded into the TEE. The specified program code includes, for example, program code for executing a transfer transaction, program code of a virtual machine (EVM) for executing a contract transaction, etc. The KMS (Key Management Server) can initiate a remote authentication process for the TEE, and the TEE can obtain a public-private key pair for encryption in the remote authentication process. The process is described below.

[0027] The SGX-enabled CPU, before it leaves the factory, will have a provisioning key and a sealing key burned into a fuse register in the CPU by the manufacturer. The fuse register is a one-time programmable register, once the data is burned into it, the fuse is blown, making the content in the register only readable but no longer writable. Intel promises that the keys burned into the fuse register are randomly generated; in addition, it also promises that all backups about the burned keys will be destroyed once burned, that is, even Intel itself does not know the burned keys. The provisioning key can represent part of the information in the CPU, such as the code of the CPU (for example, the sixth generation of cool, the seventh generation of cool, etc.), the model (such as desktop, mobile, etc.) and the like. For security considerations, the provisioning key is not directly used for encryption, signature and other operations, but a proof key derived from the provisioning key is used, so the provisioning key plays a deployment role.

[0028] Before the KMS initiates remote attestation to the TEE in the blockchain node, the CPU in the blockchain node can detect whether there is an attestation key. If not, initialization is initiated. The process of initialization can be based on a key generation protocol, through interaction with the Intel server, and generate an EPID (Enhanced Privacy IDentification) according to the generation rule of the provisioning key, which is used as the attestation key, generally as a private key sk1 in asymmetric encryption key. The EPID can be stored in the TEE for subsequent signature. Thus, Intel can obtain the public key pk1 corresponding to the EPID through the interaction process. In particular, the public key pk1 corresponding to the EPID is not publicly available, but is only kept by the Intel server. Such a feature is suitable for subsequent authentication by the server of Intel (also known as IAS, Intel Attestation Server) in the remote attestation process.

[0029] After the TEE is ready for the private key sk1 and the public key pk1 for signature, it can obtain the private key sk2 and the public key pk2 for asymmetric encryption through the following steps:

[0030] Step 1: The KMS initiates a challenge to the TEE in node 1, requiring it to present a report to prove that the program code included therein is correct code, specifically, the report is used to prove that the EVM code in the TEE is correct EVM code;

[0031] Step 2: After receiving the challenge, the TEE in node 1 calculates hash1 of the local code, generates a report quote including hash1, and signs the quote using the key sk1 to obtain a signature sig1, and sends the quote and the signature sig1 to the KMS;

[0032] The TEE in node 1 and the KMS can also negotiate a public key pk2 in step 1 and step 2 through a Diffie-Hellman key exchange (DH) algorithm or an Elliptic Curve Diffie-Hellman key exchange (ECDH) algorithm, in which case the hash value hash2 of the public key pk2 can also be included in the quote;

[0033] Step 3: Since the KMS does not have a public key pk1 corresponding to sk1, after receiving the quote and the signature sig1, the KMS sends the quote and the signature sig1 to the IAS;

[0034] Step 4: The IAS verifies the signature sig1 of the quote using the public key pk1 and returns the verification result to the KMS, wherein, in order to prevent the verification result from being intercepted or modified by an intermediate, the IAS can sign the verification result using its own private key to obtain a signature sig2, and sends the verification result and the signature sig2 to the KMS;

[0035] Step 5: After receiving the verification result, if the verification result indicates that sig1 is correct, the KMS verifies hash1 in the quote according to the correct hash value of the EVM code obtained in advance, and if they are consistent, the KMS confirms that the correct EVM is running in the TEE of node 1 through remote attestation verification;

[0036] Step 6: The KMS generates a private key sk2 corresponding to the public key pk2, symmetrically encrypts the private key sk2 using the public key pk2, and sends the ciphertext private key to the TEE of node 1;

[0037] Step 7: After receiving the ciphertext private key, the TEE of node 1 can decrypt the ciphertext private key using the public key pk2 to obtain the private key sk2, and store the private key sk2 together with the public key pk2 in the TEE.

[0038] After the KMS sends the private key sk2 to the TEE of node 1, the user device / client for sending transaction to the blockchain can obtain the public key pk2 from the KMS, for example, the KMS can send the public key pk2 and the signature of the KMS on the public key pk2 to the client, so that the client can verify the public key pk2 based on the signature of the KMS to ensure that the correct public key pk2 is received.

[0039] The TEE of other nodes (e.g. node 2) in the blockchain can likewise send a quote report to the KMS through the above steps 1 and 2, and negotiate a symmetric encryption key k1 with the KMS. After the remote authentication of the TEE of node 2 is passed, the KMS can symmetrically encrypt the public key pk2 and the private key sk2 using the key k1, and send the ciphertext of the public key pk2 and the private key sk2 to the TEE of node 2. The TEE of node 2 can obtain the same public key pk2 and private key sk2 as the TEE in node 1.

[0040] Through the process of the foregoing example, the TEEs of multiple blockchain nodes in the blockchain system can be configured with the same public-private key pair, i.e. the same public key pk2 and private key sk2; in addition, the user device can obtain the public key pk2. It can be understood that the same public-private key pair can also be configured to the TEEs of multiple blockchain nodes in the blockchain system through other implementation schemes.

[0041] In the case that multiple blockchain nodes are configured with the same public-private key pair, the user device can send a transaction request based on the public key pk2 to the blockchain system. For example, the user device can select a symmetric key k2 to symmetrically encrypt the transaction plaintext Tx1 to obtain a transaction ciphertext ET, asymmetrically encrypt the symmetric key k2 using the public key pk2 to obtain a key ciphertext EK1, and send a transaction request Q1 containing the transaction ciphertext ET and the key ciphertext EK1 to the blockchain system.

[0042] In the related technical solution, in the preparation stage of the consensus process, the consensus proposal can include multiple transaction requests from the user equipment; the consensus node that reaches consensus on the consensus proposal can perform envelope decryption on multiple transaction requests including transaction ciphertext and key ciphertext based on the public key pk2 in the TEE, obtain multiple transactions and execute the multiple transactions in the TEE. For example, for the transaction request Q1, the consensus node that reaches consensus on the consensus proposal can perform asymmetric decryption on the key ciphertext EK1 in the transaction request Q1 to obtain the symmetric key k2, perform symmetric decryption on the transaction ciphertext ET to obtain the transaction Tx1, and execute the transaction Tx1 in the TEE. In this technical solution, for a single transaction request, all consensus nodes participating in the consensus mechanism need to perform 1 asymmetric decryption operation on the transaction request, and the time consumed by the asymmetric decryption operation is relatively long, which has a negative impact on the performance of the blockchain system.

[0043] In view of the above problems, the embodiments of the present specification provide a transaction execution method and a node in a blockchain system. For a blockchain node receiving a first transaction request from a user equipment, the first key ciphertext in the first transaction request can be asymmetrically decrypted in the TEE to obtain a first key used for encrypting the first transaction, and then the first key can be symmetrically encrypted with a second key corresponding to the first transaction request to obtain a second key ciphertext, and a second transaction request including the transaction ciphertext and the second key ciphertext can be provided to the outside of the TEE. Correspondingly, each blockchain node in the blockchain system can perform symmetric decryption on the second key ciphertext in the second transaction request in the TEE with the corresponding second key, obtain the first key used for symmetric decryption of the transaction ciphertext in the second transaction request, and then perform symmetric decryption on the transaction ciphertext with the first key to obtain the first transaction and execute the first transaction. In this way, for a single transaction request from a user equipment, it is not necessary for all blockchain nodes in the blockchain system to perform asymmetric decryption on the key ciphertext included in the transaction request, which is beneficial to improve the performance of the blockchain system.

[0044] Figure 3 One of the flowcharts of the transaction execution method in a blockchain system provided in the embodiments of the present 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. The method can be performed by any blockchain node receiving a first transaction request from a user equipment in the multiple blockchain nodes, and through the method, the blockchain node as a consensus proposal node in the blockchain system can obtain the transaction request Q2 (second transaction request) corresponding to any transaction request Q1 (first transaction request) from the user equipment. Referring to Figure 3As shown, the method can include, but is not limited to, some or all of the following steps S31-S37.

[0045] At step S31, the blockchain node receives a transaction request Q1 from a user device, including transaction ciphertext ET obtained by symmetrically encrypting transaction Tx1 using key k2, and key ciphertext EK1 obtained by asymmetrically encrypting key k2 using public key pk2.

[0046] The user device may, for example, when expecting to send transaction Tx1 (first transaction) to the blockchain system, generate / select key k2 (i.e. first key) for symmetrically encrypting transaction Tx1 according to a certain rule, symmetrically encrypt transaction Tx1 using key k2 to obtain transaction ciphertext ET, asymmetrically encrypt k2 using public key pk2 of the TEE in the blockchain node to obtain key ciphertext EK1, and then send transaction request Q1 (first transaction request) to the blockchain node connected to the user device. The transaction request Q1 includes transaction ciphertext ET and key ciphertext EK1, and can also include the hash value of transaction Tx1 calculated by the user device.

[0047] At step S32, the blockchain node provides transaction request Q1 to its TEE.

[0048] At step S33, the TEE of the blockchain node asymmetrically decrypts key ciphertext EK1 using private key sk2 to obtain key k2.

[0049] Optionally, the TEE of the blockchain node can perform the following step S34 to determine key k3 corresponding to transaction request Q1.

[0050] Key k3 (i.e. second key) corresponding to transaction request Q1 can be obtained by processing transaction request Q1 based on a certain preset rule, for example, calculating k3 based on private key sk2 configured in the TEE and transaction ciphertext ET in transaction request Q1.

[0051] At step S35, the TEE of the blockchain node symmetrically encrypts target information using key k3 to obtain key ciphertext EK2.

[0052] Key k3 in step S35 is, for example, key k3 determined in step S34, or key k3 can be private key sk2 in the TEE, or key k3 can be a symmetric key externally transmitted when initializing the TEE of the blockchain node.

[0053] The target information at least includes key k2, and can also include random numbers and the like obtained by the TEE of the blockchain node, the random numbers serving to prevent an intruder from cracking key k3 based on transaction ciphertext ET and key ciphertext EK2 that the intruder can obtain.

[0054] Step S36, the TEE of the blockchain node provides the second transaction request to the outside of it.

[0055] The transaction request Q2 differs from the transaction request Q1 in that the key ciphertext EK1 in the transaction request Q1 is replaced by the key ciphertext EK2 in the corresponding transaction request Q2. In other words, the transaction request Q2 at least includes the transaction ciphertext ET and the key ciphertext EK2, and can further include the hash value of the transaction Tx1 originally located in the transaction request Q1.

[0056] When the blockchain node performing the foregoing steps S31-S36 is a consensus proposal node, the consensus proposal node can obtain the transaction request Q2 corresponding to the transaction request Q1 by performing the foregoing steps S31-S36.

[0057] When the blockchain node performing the foregoing steps S31-S36 is not a consensus proposal node, the blockchain node can further continue to perform the following step S37, and send the transaction request Q2 to the consensus proposal node.

[0058] It can be understood that for each first transaction request issued by the user device, a second transaction request corresponding to the first transaction request can be generated in the TEE of the blockchain node connected to the user device through the same / similar process as the foregoing steps S31-S37, and then the consensus proposal node in the blockchain system can obtain a plurality of second transaction requests corresponding to a plurality of first transaction requests. Correspondingly, after obtaining the plurality of second transaction requests, the consensus proposal node can initiate a consensus proposal containing the plurality of second transaction requests, and continue to perform the subsequent transaction execution process.

[0059] In a possible implementation, the blockchain node performing the steps S31-S36 can not only send the transaction request Q2 to the consensus proposal node, but also broadcast the transaction request Q2 to the remaining blockchain nodes in the blockchain system, so that each blockchain node locally stores the transaction request Q2; in other words, all the blockchain nodes in the blockchain system can obtain a plurality of second transaction requests corresponding to a plurality of first transaction requests. Correspondingly, after obtaining the plurality of second transaction requests, the consensus proposal node can initiate a consensus proposal containing the plurality of second transaction requests or the hash values of the plurality of second transaction requests, and continue to perform the subsequent transaction execution process.

[0060] Figure 4This is a second flowchart of a transaction execution method in a blockchain system provided in the embodiments of this specification. The blockchain system includes multiple blockchain nodes configured with TEEs, each TEE having the same public-private key pair. These multiple blockchain nodes include multiple consensus nodes, and among these consensus nodes is a consensus proposal node. The consensus proposal node can be based on the aforementioned... Figure 3 The method shown obtains multiple second transaction requests corresponding to multiple first transaction requests. Furthermore... Figure 4 The method shown is executed by any blockchain node N from a plurality of blockchain nodes, thereby completing the execution of one or more transactions. See also Figure 4 As shown, the method may include, but is not limited to, some or all of the following steps S41 to S48.

[0061] When blockchain node N is used as a consensus proposal node, it can execute step S41 to generate a consensus proposal, which includes multiple second transaction requests arranged in sequence. Then, it can continue to execute step S42. Note that, as mentioned earlier, the consensus proposal may not include multiple second transaction requests, but rather the hash values ​​of each of the multiple second transaction requests.

[0062] If blockchain node N is not used as a consensus proposal node but is used as a consensus node, the following step S42 can be executed directly.

[0063] Step S42: Reach consensus with the remaining consensus nodes among the multiple consensus nodes on the consensus proposal generated by the consensus proposal node.

[0064] For examples of the consensus process, please refer to the various stages of the consensus process based on the PBFT consensus algorithm mentioned above, which will not be repeated here.

[0065] When multiple consensus nodes reach a consensus on a consensus proposal, blockchain node N can execute step S43, providing its TEE with multiple second transaction requests located in the consensus proposal. Blockchain node N can obtain multiple second transaction requests to be executed from the consensus proposal that has reached a consensus, or, based on the hash values ​​of the multiple second transaction requests included in the consensus proposal, obtain multiple second transaction requests corresponding to them from local storage, and provide the obtained multiple second transaction requests to its own TEE.

[0066] The TEE of blockchain node N can execute some or all of the following steps S44 to S48 for any second transaction request among multiple second transaction requests, such as transaction request Q2, to complete the execution of transaction Tx1 corresponding to transaction request Q2.

[0067] Optionally, in step S44, the key k3 corresponding to transaction request Q2 is determined.

[0068] The key k3 can be obtained by the same method as the foregoing step S34, for example, the TEE of the consensus node can obtain the transaction ciphertext EK from the transaction request Q2, and then calculate the key k3 based on the private key k2 configured by the TEE and the transaction ciphertext EK.

[0069] In step S45, the key ciphertext EK2 in the transaction request Q2 is symmetrically decrypted by using the key k3 to obtain target information, and the target information includes the key k2.

[0070] According to the foregoing, the target information at least includes the key k2, and the target information can further include a random number. The key k3 in the foregoing step S45 is, for example, the key k3 determined in step S44, or the key k3 can be the private key sk2 in the TEE, or the key k3 can be a symmetric key externally transmitted when the TEE of the blockchain node is initialized.

[0071] In step S46, the transaction ciphertext ET in the transaction request Q2 is symmetrically decrypted by using the key k2 to obtain the transaction Tx1.

[0072] In step S48, the transaction Tx1 is executed.

[0073] In each of the foregoing method embodiments, for a single transaction request from a user device, only the blockchain node connected with the user device needs to perform an asymmetric decryption operation on the key ciphertext included in the transaction request by the TEE thereof; and for multiple transaction requests from multiple user devices, the process of asymmetrically decrypting the key ciphertexts in the multiple transaction requests can be dispersed to multiple blockchain nodes in the blockchain system to perform. In this way, the performance of the blockchain system is improved.

[0074] Based on the same concept as the foregoing method embodiments, a blockchain node in a blockchain system is provided in the embodiments of the present specification, the blockchain system includes a plurality of blockchain nodes, the blockchain node is configured with a TEE, and the TEEs of the plurality of blockchain nodes are configured with the same private key pair. As Figure 5As shown, the blockchain node comprises: the blockchain system comprises a plurality of blockchain nodes, the blockchain nodes are configured with a trusted execution environment (TEE), the TEEs of the plurality of blockchain nodes are configured with the same public-private key pair, the blockchain node comprises: a communication processing unit 51 configured to receive a first transaction request from a user device, the first transaction request comprising transaction ciphertext obtained by symmetrically encrypting a first transaction with a first key, and first key ciphertext obtained by asymmetrically encrypting the first key with a public key in the public-private key pair; a TEE 53 configured to asymmetrically decrypt the first key ciphertext with a private key in the public-private key pair to obtain the first key, symmetrically encrypt target information with a second key to obtain second key ciphertext, the target information at least comprising the first key, and provide a second transaction request outside the TEE, the second transaction request comprising the transaction ciphertext and the second key ciphertext, so that each of the blockchain nodes, in the TEE thereof, symmetrically decrypts the second key ciphertext with the second key to obtain the first key, symmetrically decrypts the transaction ciphertext with the first key to obtain the first transaction, and executes the first transaction.

[0075] In a possible implementation, the second key is pre-stored in the TEE; or, the second key is calculated based on a private key in the public-private key pair and the transaction ciphertext.

[0076] In a possible implementation, the target information further comprises a random number.

[0077] In a possible implementation, the communication processing unit 51 is further configured to send the second transaction request to a consensus proposal node in the plurality of blockchain nodes.

[0078] Based on the same concept as the foregoing method embodiment, the present specification embodiment also provides a consensus node in a blockchain system, the blockchain system comprising a plurality of blockchain nodes, the blockchain nodes being configured with a TEE, the TEEs of the plurality of blockchain nodes being configured with the same public-private key pair. As Figure 6As shown, the blockchain node comprises: a transaction obtaining unit 61, configured to obtain a second transaction request provided by a TEE of a target node, the target node being a blockchain node that receives a first transaction request from a user device, the first transaction request comprising transaction ciphertext obtained by symmetrically encrypting a first transaction by using a first key, and first key ciphertext obtained by asymmetrically encrypting the first key by using a public key in a public-private key pair, the second transaction request comprising the transaction ciphertext and second key ciphertext, the second key ciphertext being obtained by encrypting target information by using a second key in the TEE of the target node, the target information comprising the first key; a TEE 63, configured to symmetrically decrypt the second key ciphertext by using the second key to obtain the first key, symmetrically decrypt the transaction ciphertext by using the first key to obtain the first transaction, and execute the first transaction.

[0079] In a possible implementation, the transaction obtaining unit 61 is specifically configured to obtain the second transaction request from a consensus proposal.

[0080] In a possible implementation, the TEE 63 of the consensus node is further configured to calculate the second key according to a private key in the public-private key pair and the transaction ciphertext.

[0081] In a possible implementation, the blockchain node further comprises: a communication processing unit 65, configured to receive the second transaction request from the target node; and a consensus processing unit 67, configured to generate a consensus proposal comprising the second transaction request.

[0082] The specification also provides a computer-readable storage medium having a computer program stored thereon, when the computer program is executed in a computer, the computer program causes the computer to execute each method step performed by the TEE in the blockchain node or the consensus node in the foregoing method embodiments.

[0083] In the 1990s, it was quite obvious to distinguish whether an improvement in a technology was in hardware (e.g., improvement in circuit structures of diodes, transistors, switches, etc.) or in software (improvement in method flow). However, as technology has evolved, many improvements in method flow today can be considered as direct improvements in hardware circuit structures. Designers almost always obtain the corresponding hardware circuit structures by programming the improved method flow into hardware circuits. Therefore, it cannot be said that an improvement in a method flow cannot be implemented by hardware entity modules. For example, a programmable logic device (PLD) (e.g., a field programmable gate array (FPGA)) is an integrated circuit whose logic function is determined by user programming of the device. A digital system is "integrated" on a PLD by the designer programming it, rather than by asking a chip manufacturer to design and fabricate a custom integrated circuit chip. Moreover, instead of manually fabricating integrated circuit chips, this programming is now mostly implemented by "logic compiler" software, which is similar to software compilers used in program development, and the original code to be compiled is written in a specific programming language, which is called a hardware description language (HDL), and there are many such languages, 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., and the most commonly used are VHDL (Very-High-Speed Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should be aware that, as long as the method flow is logically programmed in the above-mentioned hardware description languages and programmed into an integrated circuit, a hardware circuit implementing the logical method flow can be easily obtained.

[0084] The controller can be implemented in any suitable way, for example, the controller can take the form of, for example, a microprocessor or processor and a computer readable medium storing computer readable program code, such as software or firmware, executable by the (micro)processor, logic gates, switches, an application specific integrated circuit (ASIC), a programmable logic controller and an embedded microcontroller, examples of which 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. The skilled person will also appreciate that, in addition to implementing the controller in pure computer readable program code, it is possible to implement the controller in the form of logic gates, switches, an application specific integrated circuit, a programmable logic controller and an embedded microcontroller, etc. to perform the same functions by logically programming the method steps. Such a controller can therefore be considered to be a hardware component, and the means included therein to perform the various functions can also be considered to be structures within the hardware component. Alternatively, or even additionally, the means to perform the various functions can be considered to be both a software module implementing the method and a structure within a hardware component.

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

[0086] Although the method operations of the embodiments of the present disclosure are described in a particular, sequential order, one or more of the method operations can be omitted, or the method operations can be performed in an order other than the described order. Additionally, one or more of the method operations can be performed concurrently, or with partial concurrence. Furthermore, one or more of the method operations can be performed by different entities, or over different time periods. The term "including" as used herein is intended to mean "comprising," such that the process, method, article, or apparatus that includes elements in addition to those specified. As used in this description, the term "coupled" means a direct or indirect connection, which can be physical or logical. The term "coupled" does not relate to a direct connection or wiring.

[0087] For the sake of description, the above-described apparatus is described as various modules to describe the apparatus in functional groups. Of course, when implementing one or more embodiments of the present disclosure, the functions of the modules can be implemented in one or more software and / or hardware, or the modules that implement the same function can be implemented by a combination of a plurality of sub-modules or sub-units. The above-described apparatus embodiments are merely illustrative, for example, the division of the units is merely a logical function division, and actual implementation can have another division manner, for example, a plurality of units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the coupling or direct coupling or communication connection between the displayed or discussed units can be indirect coupling or communication connection through some interfaces, devices or units, and can be electrical, mechanical or other forms.

[0088] The present disclosure is described with reference to the flowcharts and / or block diagrams of the methods, apparatus (systems) and computer program products according to embodiments of the present disclosure. It should be understood that each flow and / or block in the flowcharts and / or block diagrams, and the combination of the flows 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 apparatus to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing apparatus generate a means for implementing the functions specified in the flowcharts and / or block diagrams. Figure 1 The functions of one or more flows and / or blocks Figure 1 The apparatus that implements the functions specified in one or more flows and / or blocks.

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

[0090] These computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the Figure 1 function specified in the flow or flows and / or blocks Figure 1 of the block or blocks.

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

[0092] The memory can include non-persistent memory and / or volatile memory, such as random access memory (RAM) and / or cache memory, non-volatile memory, such as read-only memory (ROM), EPROM, and / or flash memory. The memory is an example of computer-readable media.

[0093] Computer-readable media includes permanent and non-permanent, moveable and non- moveable media that can be implemented in any method or technology for storage of information such as 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 discs (DVDs) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, graphene storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information accessible to computing devices. According to the definition herein, computer-readable media does not include transitory media, such as modulated data signals and carrier waves.

[0094] Those skilled in the art will appreciate that the one or more embodiments described herein can be provided as a method, a system or a computer program product. Accordingly, the one or more embodiments described herein can take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the one or more embodiments described herein can take the form of a computer program product on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROMs, optical storage devices, etc.) embodying computer readable code.

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

[0096] The various embodiments described in this specification are described in the context of progressive embodiments, with each embodiment building on the previous one. The same or similar parts between embodiments are cross-referenced as appropriate. Each embodiment focuses on the differences between that embodiment and the previous one. In particular, the system embodiments are described relatively simply, as they are substantially similar to the method embodiments. In the description of the specification, the use of the terms "one embodiment", "some embodiments", "example", "specific example" or "some examples" means that the particular feature, structure, material or characteristic being described is included in at least one embodiment or example of the specification. Illustrative descriptions of the above terms do not necessarily refer to the same embodiment or example in this specification. Moreover, the particular features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples. Furthermore, the skilled person can combine and combine the features of different embodiments or examples and characteristics of different embodiments or examples, without contradiction.

[0097] The above description merely provides examples of the one or more embodiments described in this specification and does not limit the one or more embodiments described in this specification. The one or more embodiments described in this specification can have various modifications and changes. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the one or more embodiments described in this specification should be included in the scope of the claims.

Claims

1. A method for transaction execution in a blockchain system, the blockchain system comprising a plurality of blockchain nodes, each of the blockchain nodes being configured with a trusted execution environment (TEE), the TEEs of the plurality of blockchain nodes being configured with a same pair of public and private keys, the method being performed by a first blockchain node of the plurality of blockchain nodes, the method comprising: receiving, from a user device, a first transaction request, the first transaction request comprising transaction ciphertext obtained by symmetrically encrypting a first transaction with a first key and first key ciphertext obtained by asymmetrically encrypting the first key with a public key of the pair of public and private keys; in the TEE of the blockchain node, asymmetrically decrypting the first key ciphertext with a private key of the pair of public and private keys to obtain the first key, symmetrically encrypting target information with a second key to obtain second key ciphertext, the target information comprising at least the first key, and providing, to outside of the TEE, a second transaction request, the second transaction request being obtained by replacing the first key ciphertext in the first transaction request with the second key ciphertext, such that each of the blockchain nodes, in its TEE, symmetrically decrypts the second key ciphertext with the second key to obtain the first key, symmetrically decrypts the transaction ciphertext with the first key to obtain the first transaction, and executes the first transaction. 2.The method of claim 1, wherein the second key is pre-stored in the TEE, or the second key is calculated based on the private key of the pair of public and private keys and the transaction ciphertext. 3.The method of claim 1, wherein the target information further comprises a random number. sending, to a consensus proposal node of the plurality of blockchain nodes, the second transaction request. 5.A method for transaction execution in a blockchain system, the blockchain system comprising a plurality of blockchain nodes, each of the blockchain nodes being configured with a trusted execution environment (TEE), the TEEs of the plurality of blockchain nodes being configured with a same pair of public and private keys, the method being performed by a second blockchain node of the plurality of blockchain nodes, the method comprising: obtaining a second transaction request provided by a target node, the target node being a blockchain node that receives a first transaction request from a user device, the first transaction request comprising transaction ciphertext obtained by symmetrically encrypting a first transaction with a first key and first key ciphertext obtained by asymmetrically encrypting the first key with a public key of the pair of public and private keys, the second transaction request being obtained by replacing the first key ciphertext in the first transaction request with second key ciphertext, the second key ciphertext being obtained by the target node, in its TEE, encrypting target information with a second key, the target information comprising the first key.

4. The method of any one of claims 1-3, further comprising: ​ ​ ​ In the TEE of the second blockchain node, the second key is symmetrically decrypted according to the second key ciphertext to obtain the first key, the transaction ciphertext is symmetrically decrypted by using the first key to obtain the first transaction, and the first transaction is executed.

6. The method of claim 5, wherein the obtaining the second transaction request provided by the TEE of the target node comprises: Obtaining the second transaction request from a consensus proposal.

7. The method of claim 5, further comprising: In the TEE of the consensus node, the second key is calculated according to the private key in the public-private key pair and the transaction ciphertext.

8. The method of any one of claims 5-7, further comprising: Receiving the second transaction request from the target node; And generating a consensus proposal including the second transaction request.

9. A blockchain node in a blockchain system, the blockchain system comprising a plurality of blockchain nodes, 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 blockchain node comprising: a communication processing unit configured to receive a first transaction request from a user device, the first transaction request including a transaction ciphertext obtained by symmetrically encrypting a first transaction by using a first key, and a first key ciphertext obtained by asymmetrically encrypting the first key by using a public key in the public-private key pair; a TEE configured to asymmetrically decrypt the first key ciphertext by using a private key in the public-private key pair to obtain the first key, symmetrically encrypt target information by using a second key to obtain a second key ciphertext, the target information at least including the first key, and provide a second transaction request outside the TEE, the second transaction request being obtained by replacing the first key ciphertext in the first transaction request with the second key ciphertext, so that each of the blockchain nodes, in its TEE, symmetrically decrypts the second key ciphertext by using the second key to obtain the first key, symmetrically decrypts the transaction ciphertext by using the first key to obtain the first transaction, and executes the first transaction.

10. The blockchain node of claim 9, wherein the second key is pre-stored in the TEE; or the second key is calculated based on the private key in the public-private key pair and the transaction ciphertext.

11. The blockchain node of claim 9, wherein the target information further includes a random number.

12. The blockchain node of any one of claims 9-11, wherein the communication processing unit is further configured to send the second transaction request to a consensus proposal node in the plurality of blockchain nodes.

13. A blockchain node in a blockchain system, the blockchain system comprising a plurality of blockchain nodes, 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 blockchain node comprising: The transaction obtaining unit is configured to obtain a second transaction request provided by a TEE of a target node, the target node being a blockchain node that receives the first transaction request from the user device, the first transaction request including transaction ciphertext obtained by symmetrically encrypting a first transaction by using a first key, and first key ciphertext obtained by asymmetrically encrypting the first key by using a public key in the public-private key pair, the second transaction request being obtained by replacing the first key ciphertext in the first transaction request with second key ciphertext obtained by encrypting target information by using a second key in the TEE of the target node, the target information including the first key. The TEE is configured to symmetrically decrypt the second key ciphertext by using the second key to obtain the first key, symmetrically decrypt the transaction ciphertext by using the first key to obtain the first transaction, and execute the first transaction.

14. The blockchain node of claim 13, wherein the transaction obtaining unit is specifically configured to obtain the second transaction request from a consensus proposal.

15. The blockchain node of claim 13, wherein the TEE of the consensus node is further configured to calculate the second key according to a private key in the public-private key pair and the transaction ciphertext.

16. The blockchain node of any one of claims 13-15, further comprising: a communication processing unit configured to receive the second transaction request from the target node; a consensus processing unit configured to generate a consensus proposal including the second transaction request.

Images