WO2021103794A1 - Method for realizing highly efficient privacy-preserving transaction in blockchain, and device - Google Patents

Abstract

Provided in one or more embodiments of the present invention are a method for realizing a highly efficient privacy-preserving transaction in a blockchain, and a device. The method can comprise: a blockchain node transferring a private transaction submitted by a client to a trusted execution environment so as to subject the private transaction to pre-consensus validation, and buffering at least a portion of data used in the process of pre-consensus validation; if the private transaction passes the pre-consensus validation, the blockchain node and other blockchain nodes performing consensus processing on the private transaction; and the blockchain node transferring the private transaction that has undergone the consensus processing to the trusted execution environment to be executed, and using the at least one portion of buffered data in the process of executing the private transaction.

Description

High-efficiency transaction method and device for realizing privacy protection in blockchain Technical field

One or more embodiments of this specification relate to the field of terminal technology, and in particular to an efficient transaction method and device for realizing privacy protection in a blockchain.

Background technique

Blockchain technology is built on a transmission network (such as a peer-to-peer network). The network nodes in the transmission network use chained data structures to verify and store data, and use distributed node consensus algorithms to generate and update data.

At present, the two biggest challenges in enterprise-level blockchain platform technology are privacy and performance, and it is often difficult to solve these two challenges at the same time. Most of the solutions are to lose performance in exchange for privacy, or do not consider privacy to pursue performance. Common encryption technologies to solve privacy problems, such as Homomorphic encryption and Zero-knowledge proof, are highly complex, have poor versatility, and may also cause serious performance losses.

Trusted Execution Environment (TEE) is another way to solve privacy issues. TEE can play the role of a black box in the hardware. Neither the code executed in the TEE nor the data operating system layer can be peeped, and only the pre-defined interface in the code can operate on it. In terms of efficiency, due to the black-box nature of TEE, what is calculated in TEE is plaintext data, rather than complex cryptographic operations in homomorphic encryption. There is no loss of efficiency in the calculation process. Therefore, the combination with TEE can achieve less performance loss. Under the premise, the security and privacy of the blockchain are greatly improved. At present, the industry is very concerned about the TEE solution. Almost all mainstream chip and software alliances have their own TEE solutions, including TPM (Trusted Platform Module) in software and Intel SGX (Software Guard Extensions) , Software Protection Extension), ARM Trustzone (trust zone) and AMD PSP (Platform Security Processor, platform security processor).

Summary of the invention

In view of this, one or more embodiments of this specification provide an efficient transaction method and device for realizing privacy protection in the blockchain.

In order to achieve the foregoing objectives, one or more embodiments of the present specification provide the following technical solutions.

According to the first aspect of one or more embodiments of this specification, an efficient transaction method for realizing privacy protection in the blockchain is proposed, including: the blockchain node transmits the private transaction submitted by the client to the trusted execution environment China and Israel perform pre-consensus verification on the private transaction, and cache at least part of the data used in the pre-consensus verification process; in the case that the private transaction passes the pre-consensus verification, the blockchain node Perform consensus processing on the privacy transaction with other blockchain nodes; the blockchain node transfers the consensus privacy transaction into the trusted execution environment for execution, and uses the cache in the transaction execution process At least part of the data.

According to the second aspect of one or more embodiments of this specification, an efficient transaction method for realizing privacy protection in the blockchain is proposed, including: the blockchain node transmits the private transaction submitted by the client to the trusted execution environment China Israel performs pre-consensus verification on the private transaction, and associates the information of the private transaction with the verification result of the pre-consensus verification; in the case that the private transaction passes the pre-consensus verification, the The blockchain node and other blockchain nodes conduct consensus processing on the privacy transaction; the blockchain node queries and records the school for any private transaction that is received through consensus. Verification result; in the case that the verification result obtained is passed verification, the blockchain node transmits any of the privacy transactions to the trusted execution environment for execution; in the verification result obtained In the case that the verification fails or the verification result is not queried, the blockchain node transmits any one of the privacy transactions to the trusted execution environment for execution-time verification, and performs verification on any one of the Any one of the above-mentioned private transactions is executed when the private transaction passes the execution-time verification.

According to the third aspect of one or more embodiments of this specification, an efficient transaction device for realizing privacy protection in the blockchain is proposed, including: a pre-consensus verification unit, which enables the blockchain node to submit the privacy of the client The transaction is passed into the trusted execution environment to perform pre-consensus verification on the private transaction; the cache unit enables the blockchain node to cache at least part of the data used in the pre-consensus verification process; the consensus unit enables The blockchain node performs consensus processing on the privacy transaction with other blockchain nodes in the case that the privacy transaction passes the consensus verification; the execution unit enables the blockchain node to pass the consensus process The private transaction is transferred to the trusted execution environment for execution, and the at least a part of the cached data is used during the execution of the transaction.

According to the fourth aspect of one or more embodiments of this specification, an efficient transaction device for implementing privacy protection in the blockchain is proposed, which includes: a pre-consensus verification unit that enables the blockchain node to submit the privacy of the client The transaction is passed into the trusted execution environment to perform pre-consensus verification on the private transaction; the recording unit enables the blockchain node to associate the information of the private transaction with the verification result of the pre-consensus verification; The consensus unit enables the blockchain node to perform consensus processing on the private transaction with other blockchain nodes when the private transaction passes the consensus verification; the query unit enables the blockchain node to target For any private transaction received through consensus, the query record corresponds to the verification result of any private transaction; the execution unit, in the case that the queried verification result is passed verification, makes the block The chain node transmits any of the privacy transactions to the trusted execution environment for execution; in the case that the checked verification result is not passed or the verification result is not checked, the blockchain The node transmits any one of the privacy transactions to the trusted execution environment for execution time verification, and executes any one of the privacy transactions in the case where the any one privacy transaction passes the execution time verification.

According to a fifth aspect of one or more embodiments of this specification, an electronic device is proposed, including: a processor; a memory for storing executable instructions of the processor; wherein the processor runs the executable instructions In order to realize the method as described in the first aspect or the second aspect.

According to a sixth aspect of one or more embodiments of this specification, a computer-readable storage medium is provided, which stores computer instructions, which when executed by a processor, implements the method described in the first or second aspect A step of.

According to a seventh aspect of one or more embodiments of this specification, an electronic device is proposed, including: a processor; a memory for storing executable instructions of the processor; wherein the processor runs the executable instructions To achieve the method described in the third aspect or the fourth aspect.

According to the eighth aspect of one or more embodiments of the present specification, a computer-readable storage medium is provided with computer instructions stored thereon, and when the instructions are executed by a processor, the method described in the third aspect or the fourth aspect is implemented A step of.

Description of the drawings

Fig. 1 is a schematic diagram of a blockchain node processing a transaction according to an exemplary embodiment.

Fig. 2 is a flowchart of an efficient transaction method for realizing privacy protection in a blockchain according to an exemplary embodiment.

Fig. 3 is a schematic diagram of creating a smart contract according to an exemplary embodiment.

Fig. 4 is a schematic diagram of invoking a smart contract provided by an exemplary embodiment.

Fig. 5 is a flowchart of another efficient transaction method for implementing privacy protection in a blockchain provided by an exemplary embodiment.

Fig. 6 is a schematic structural diagram of a device provided by an exemplary embodiment.

Fig. 7 is a block diagram of an efficient transaction device for realizing privacy protection in a blockchain according to an exemplary embodiment.

Fig. 8 is a schematic structural diagram of another device provided by an exemplary embodiment.

Fig. 9 is a block diagram of another high-efficiency transaction device for implementing privacy protection in a blockchain according to an exemplary embodiment.

Detailed ways

The exemplary embodiments will be described in detail here, and examples thereof are shown in the accompanying drawings. When the following description refers to the accompanying drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The implementation manners described in the following exemplary embodiments do not represent all implementation manners consistent with one or more embodiments of this specification. Rather, they are merely examples of devices and methods consistent with some aspects of one or more embodiments of this specification as detailed in the appended claims.

It should be noted that in other embodiments, the steps of the corresponding method may not be executed in the order shown and described in this specification. In some other embodiments, the method may include more or fewer steps than described in this specification. In addition, a single step described in this specification may be decomposed into multiple steps for description in other embodiments; and multiple steps described in this specification may also be combined into a single step in other embodiments. description.

Blockchain is generally divided into three types: Public Blockchain, Private Blockchain and Consortium Blockchain. In addition, there are many types of combinations, such as private chain + alliance chain, alliance chain + public chain and other different combinations. Among them, the most decentralized one is the public chain. The public chain is represented by Bitcoin and Ethereum. Participants who join the public chain can read the data records on the chain, participate in transactions, and compete for the accounting rights of new blocks. Moreover, each participant (ie, node) can freely join and exit the network, and perform related operations. The private chain is the opposite. The write permission of the network is controlled by an organization or institution, and the data read permission is regulated by the organization. In simple terms, the private chain can be a weakly centralized system with strict restrictions and few participating nodes. This type of blockchain is more suitable for internal use by specific institutions. Consortium chain is a block chain between public chain and private chain, which can realize "partial decentralization". Each node in the alliance chain usually has a corresponding entity or organization; participants are authorized to join the network and form a stakeholder alliance to jointly maintain the operation of the blockchain.

Regardless of whether it is a public chain, a private chain, or a consortium chain, for the purpose of privacy protection, the nodes in the blockchain network may use a solution that combines the blockchain and TEE (Trusted Execution Environment). Execute received transactions within TEE. For example, as shown in Figure 1, the blockchain node includes the conventional execution environment on the left and the trusted execution environment (hereinafter referred to as TEE) on the right. The transaction submitted by the client (or other sources) first enters the "transaction" in the conventional execution environment. The "Scheduling" interface performs type identification, leaving the identified plaintext transactions in the regular execution environment for processing (corresponding to the "transaction execution" link on the left), and passing the identified private transactions to the TEE for processing (corresponding to The "transaction execution" link on the right).

TEE is a secure extension based on CPU hardware and a trusted execution environment that is completely isolated from the outside. TEE was first proposed by Global Platform to solve the security isolation of resources on mobile devices, and parallel to the operating system to provide a trusted and secure execution environment for applications. ARM's Trust Zone technology is the first to realize the real commercial TEE technology. With the rapid development of the Internet, security requirements are getting higher and higher. Not only mobile devices, cloud devices, and data centers have put forward more demands on TEE. The concept of TEE has also been rapidly developed and expanded. Compared with the original concept, the TEE referred to now is a broader TEE. For example, server chip manufacturers Intel, AMD, etc. have successively introduced hardware-assisted TEE and enriched the concept and characteristics of TEE, which has been widely recognized in the industry. The TEE mentioned now usually refers more to this kind of hardware-assisted TEE technology. Unlike the mobile terminal, cloud access requires remote access, and the end user is invisible to the hardware platform. Therefore, the first step in using TEE is to confirm the authenticity of TEE. Therefore, the current TEE technology has introduced a remote certification mechanism, which is endorsed by hardware vendors (mainly CPU vendors) and digital signature technology ensures that users can verify the state of the TEE. At the same time, security needs that cannot be met by only secure resource isolation, further data privacy protection has also been proposed. Commercial TEEs, including Intel SGX and AMD SEV, also provide memory encryption technology to limit trusted hardware to the inside of the CPU. The data on the bus and memory are ciphertexts to prevent malicious users from snooping. For example, TEE technologies such as Intel’s Software Protection Extensions (SGX) isolate code execution, remote attestation, secure configuration, secure storage of data, and trusted paths for code execution. The applications running in the TEE are protected by security and are almost impossible to be accessed by third parties.

Taking Intel SGX technology as an example, SGX provides an enclave (also called an enclave), which is an encrypted trusted execution area in the memory, and the CPU protects data from being stolen. Taking the first blockchain node using a CPU that supports SGX as an example, using the newly added processor instructions, a part of the area EPC (Enclave Page Cache, enclave page cache or enclave page cache) can be allocated in the memory, and through the CPU The encryption engine MEE (Memory Encryption Engine) encrypts the data in it. The encrypted content in the EPC will only be decrypted into plaintext after entering the CPU. Therefore, in SGX, users can distrust the operating system, VMM (Virtual Machine Monitor), and even BIOS (Basic Input Output System). They only need to trust the CPU to ensure that private data will not leakage. In practical applications, the private data can be encrypted and transmitted to the circle in cipher text, and the corresponding secret key can also be transmitted to the circle through remote attestation. Then, use the data to perform operations under the encryption protection of the CPU, and the result will be returned in the form of ciphertext. In this mode, powerful computing power can be used without worrying about data leakage.

After the blockchain node receives the transaction submitted by the client, it needs to verify the transaction before consensus, and send the verified transaction to other blockchain nodes, so that each blockchain node can agree on the transaction . Pre-consensus verification usually includes checking whether the transaction is valid, the format is correct, and whether the signature of the transaction is legal, etc. This manual does not limit this. Transactions that fail the verification may not pass the consensus or cannot be executed correctly after the consensus. Therefore, passing the pre-consensus verification to exclude the transactions that have not passed the verification can reduce the network overhead and other blocks caused by the consensus or execution of these transactions. The running cost of the chain node, etc.

For the aforementioned private transactions, the blockchain node needs to verify the private transaction before consensus in the TEE, and some data needs to be used in the verification process. These data may come from the private transaction or In the blockchain node's own database, and for privacy purposes, these data are often in an encrypted state, so that the blockchain node needs to decrypt the data in the TEE before it can be used for verification before consensus. At the same time, the above data verified before participating in the consensus may also be used in the execution process of the above privacy transaction, but the pre-consensus verification and transaction execution in related technologies are often regarded as mutually independent processes, so the blockchain nodes need to be separated During the pre-consensus check and transaction execution process, the above data is read into the TEE and decryption, processing and other operations are performed, which causes additional operating overhead to the blockchain node and also reduces the transaction execution efficiency.

In the following, in conjunction with embodiments, an efficient transaction scheme for realizing privacy protection in the blockchain provided by this specification is introduced, which can relatively reduce the operating overhead of blockchain nodes and improve transaction execution efficiency.

Fig. 2 is a flowchart of an efficient transaction method for realizing privacy protection in a blockchain according to an exemplary embodiment. As shown in Figure 2, the method is applied to blockchain nodes and can include the following steps.

In step 202, the blockchain node transmits the private transaction submitted by the client to the trusted execution environment to perform pre-consensus verification on the private transaction, and caches at least a part of the data used in the pre-consensus verification process.

Privacy transactions can be understood as transactions that require privacy; in addition to privacy transactions, blockchain nodes may receive plaintext transactions, which are transactions that do not require privacy. Privacy requirements can be expressed in a variety of ways, and this manual does not limit this. For example, each transaction may include a type field, which is used to indicate whether the corresponding transaction is a private transaction or a plaintext transaction. As mentioned earlier, the blockchain node can identify the transaction type in the "transaction scheduling" interface in the conventional execution environment as shown in Figure 1. In related technologies, for example, in the Ethereum network, transactions usually contain fields such as to, value, and data; and this embodiment adds a type field to the transaction on the basis of related technologies, such as the type field, based on The value of this type field indicates the type of the related transaction: for example, when the type field is the first value, it indicates that the related transaction is a clear text transaction, and when the type field is the second value, it indicates that the related transaction is a private transaction. For another example, the user can add an encrypted identifier to the transaction in the process of creating a transaction to express the aforementioned privacy requirements. Then, when it is checked that the transaction contains an encrypted identifier, the blockchain node can determine that the transaction is a private transaction, otherwise it is determined that the transaction is a plaintext transaction. For another example, the blockchain node can identify the type of smart contract called for the transaction, when the smart contract called belongs to the privacy type (for example, the smart contract contains a privacy identifier, or the code of the smart contract includes the contract status marked by the privacy identifier, etc. ), the transaction can be determined to be a private transaction, otherwise the transaction is determined to be a plaintext transaction.

The private transaction received by the blockchain node may come from the client; for example, the user can submit the private transaction to the above-mentioned blockchain node through the client after the private transaction is generated on the client. Alternatively, after the client generates a private transaction, it can be forwarded to the aforementioned blockchain node through other blockchain nodes. The aforementioned private transaction is encrypted when it is generated to ensure that the content contained in the private transaction will not be obtained by unrelated persons.

Before the blockchain node performs the pre-consensus verification on the above-mentioned private transaction, it needs to read the private transaction into the TEE for decryption, and then perform the pre-consensus verification on the decrypted plaintext content. The pre-consensus verification should be performed within the TEE to prevent the plaintext content obtained by the above decryption from being exposed to the outside of the TEE to avoid security risks. Blockchain nodes can sequentially perform pre-consensus verification on received private transactions, that is, perform pre-consensus verification serially for each private transaction; or, blockchain nodes can perform parallel verification on received private transactions, That is, the blockchain node can implement the pre-consensus verification on the above-mentioned private transaction and at least one other private transaction in parallel, so as to improve the execution efficiency of the blockchain node's pre-consensus verification on the private transaction. In order to be able to perform the pre-consensus verification of the above-mentioned private transaction and at least one other private transaction in parallel, the pre-consensus verification process should avoid conflicts between different private transactions, such as avoiding involvement in the pre-consensus verification process The smart contract's contract code and contract storage, etc., so that different privacy transactions will not cause conflicts due to the contract code or contract storage involving the same smart contract; of course, this does not mean that the pre-consensus verification does not necessarily involve the contract code or Contract storage, for example, when different privacy transactions involve different smart contracts or different contract storage of the same smart contract, even if the pre-consensus verification is performed in parallel, there will be no conflicts.

The blockchain node caches at least part of the data used in the pre-consensus verification process. Blockchain nodes can cache related data in the TEE, or cache related data in an external storage space outside the TEE. By caching in the TEE, the blockchain node can directly read the cached data from the TEE during the subsequent transaction execution process. Compared with storing to the external storage space, on the one hand, it can eliminate the TEE and external storage. Interactive operations between spaces, on the other hand, because data is cached in plain text in TEE, and cipher text must be cached in external storage space, caching data in TEE can eliminate the need for encryption and decryption of these data. process. However, the memory space allocated to TEE may be relatively small. In the case where the blockchain node receives a large number of private transactions, especially in the case of multiple private transactions in parallel before consensus verification, if All data involved in private transactions are cached in the TEE. The memory space of the TEE may not meet the requirements, and may even affect the normal operation of the TEE. Therefore, the blockchain node can cache all or part of the above-mentioned related data to external storage The data should be encrypted in the TEE in advance, and then cached in the external storage space.

At least a part of the data used in the process of pre-consensus verification of the private transaction by the blockchain node may include data extracted from the above-mentioned private transaction, that is, the data is included in the private transaction. Blockchain nodes can encrypt the above-mentioned data extracted from private transactions and cache them outside of the TEE, such as in the above-mentioned external storage space, to avoid affecting the normal operation of the TEE and to meet the storage space requirements of a large number of private transactions.

For example, a private transaction may include encrypted transaction content and an encrypted key. The encrypted transaction content is obtained by encrypting the plaintext transaction content with the first symmetric key maintained by the transaction initiator, and the encrypted key is paired by the node public key. The above-mentioned first symmetric key is obtained through encryption. Among them, the first symmetric key is maintained by the transaction initiator, the node public key and the node private key are a set of keys based on an asymmetric encryption algorithm, and the node private key is maintained by the blockchain node to avoid the transaction initiator or client The transaction initiator or the client can obtain the public key of the node; accordingly, the transaction initiator can encrypt the content of the transaction in plaintext with the first symmetric key at the client to obtain the encrypted transaction content, and the transaction content can be obtained through the node public key pair The first symmetric key is encrypted to obtain the encrypted key, that is, the encryption method of the digital envelope, and the above-mentioned private transaction includes both the above-mentioned encrypted transaction content and the encrypted key. Since the encryption and decryption efficiency of the symmetric encryption algorithm is relatively higher, and the security of the asymmetric encryption algorithm is relatively higher, in the encryption method of the digital envelope, the content of the plaintext transaction is symmetrically encrypted through the first symmetric key (and subsequently passed The first symmetric key decrypts the encrypted transaction content), which can achieve relatively higher efficiency. The first symmetric key is encrypted by the node public key (and the first symmetric key is subsequently decrypted by the node private key). To achieve relatively higher security, so as to take into account the efficiency and security of encryption and decryption.

Correspondingly, after the blockchain node reads the above-mentioned private transaction into the TEE, the node's private key can be used to decrypt the encrypted key to obtain the first symmetric key, and the encrypted transaction content can be performed through the first symmetric key. The above-mentioned plaintext transaction content is obtained by decryption, so as to verify the plaintext transaction content. In the transaction execution process, the blockchain node still needs to read the private transaction into the TEE for decryption, and the asymmetric encryption algorithm described above has relatively lower encryption and decryption efficiency, so the blockchain node can agree on the consensus The first symmetric key obtained in the pre-verification process is cached to avoid decryption by the asymmetric encryption algorithm again in the transaction execution process. Of course, when the blockchain node caches the above-mentioned first symmetric key in the external storage space, the first symmetric key needs to be encrypted and stored, so the blockchain node can use the second symmetric key maintained in the TEE The first symmetric key is encrypted and then cached in the external storage space. Since the second symmetric key is used to encrypt the first symmetric key, compared to the use of the node public key to encrypt the first symmetric key, the blockchain node subsequently implements the decryption operation in the TEE to obtain the first symmetric key. In the process of a symmetric key, the decryption time is relatively shorter (the time consuming of the symmetric encryption algorithm is shorter than that of the asymmetric encryption algorithm).

At least part of the data used in the process of pre-consensus verification by the blockchain node on the privacy transaction may include the decrypted data obtained by the blockchain node reading the encrypted data into the TEE for decryption. The encrypted data is obtained by pre-encrypting the above-mentioned decrypted data in the TEE by the blockchain node, and is transmitted from the TEE and stored in the external storage space. For example, the above-mentioned decrypted data may include at least one of the following: status data of an external account, status data of a contract account, contract code corresponding to the contract account, contract storage corresponding to the contract code, etc. This specification does not limit this . When the blockchain node encrypts the above-mentioned decrypted data in the TEE, it can use the symmetric key maintained in the TEE for encryption. The symmetric key can be, for example, the above-mentioned second symmetric key or other symmetric keys. The instructions do not limit this. The above-mentioned encrypted data is stored in the external storage space on the blockchain node, and the encrypted data is decrypted into the corresponding decrypted data in the TEE and is applied to the pre-consensus verification for the above-mentioned private transactions. The chain node can cache the decrypted data in the TEE, so that the blockchain node can directly read and use the decrypted data from the TEE when the private transaction passes consensus and executes the private transaction, without the need Re-searching the encrypted data, reading it into the TEE and decrypting it can improve the subsequent processing efficiency.

The privacy transactions in this manual may be related to smart contracts, and relatively complex processing logic can be implemented based on smart contracts. Of course, the privacy transactions in this manual may also have nothing to do with smart contracts, and are only used to implement relatively simple processing logic, such as transfer logic in related technologies. Taking Ethereum as an example, it supports users to create and/or call some complex logic in the Ethereum network. This is the biggest challenge that distinguishes Ethereum from Bitcoin blockchain technology. The core of Ethereum as a programmable blockchain is the Ethereum Virtual Machine (EVM), and every Ethereum node can run EVM. EVM is a Turing complete virtual machine, which means that various complex logic can be implemented through it. Users who publish and call smart contracts in Ethereum run on the EVM. As shown in Figure 1, by deploying the EVM in the conventional execution environment, the smart contract issued or called by the plaintext transaction can be executed through the EVM to realize the "transaction execution" link in the conventional execution environment; and, by deploying the EVM in the TEE , The smart contract issued or invoked by the private transaction can be executed through the EVM to realize the "transaction execution" link in the TEE.

For example, as shown in Figure 3, after Bob sends a transaction containing the creation of a smart contract to the Ethereum network, the EVM of node 1 can execute the transaction and generate a corresponding contract instance. The data field of the transaction can be the code of the smart contract (such as bytecode), and the to field of the transaction is an empty account. After the nodes reach an agreement through the consensus mechanism, this contract is successfully created, and subsequent users can call this contract. After the contract is created, a contract account corresponding to the smart contract appears on the blockchain and has a specific address. The contract code and account storage will be stored in the contract account. The behavior of the smart contract is controlled by the contract code, and the account storage of the smart contract saves the state of the contract. In other words, the smart contract enables a virtual account containing contract code and account storage (Storage) to be generated on the blockchain. The contract storage mentioned above is usually understood as the contract state and its value related to the contract code (usually in the form of key-value pairs), and all the contract states and their values related to the contract code can form a tree structure (such as Ethereum adopts the MPT tree, namely Merkle Patricia Tree, and records the root hash of the tree structure in the aforementioned account storage.

Further, as shown in Figure 4, still taking Ethereum as an example, after Bob sends a transaction calling a smart contract to the Ethereum network, the EVM of node 1 can execute the transaction and generate a corresponding contract instance. The from field of the transaction in Figure 4 is the address of the account that initiated the call to the smart contract, the "0x692a70d2..." in the to field represents the address of the smart contract being called, and the value field is the value of the ether in Ethereum, the transaction is The method and parameters for calling the smart contract stored in the data field. Smart contracts can be independently executed on each node in the blockchain network in a prescribed manner. All execution records and data are stored on the blockchain, so when such a transaction is completed, the blockchain cannot be saved. A transaction certificate that is tampered with and will not be lost.

Each blockchain node in the blockchain network can use a unified storage scheme to store at least part of the data used in the pre-consensus verification process of private transactions, such as all stored in TEE, all stored in external storage space, or Part of it is stored in TEE, the other part is stored in external storage space, etc. Alternatively, each block chain node in the block chain network can adopt an independent storage scheme, that is, the storage scheme adopted by each block chain node is not necessarily the same, so as to adapt to the storage space allocation and storage space of each block chain node. Possible differences in application requirements, etc.

Step 204: In the case that the privacy transaction passes the pre-consensus verification, the blockchain node and other blockchain nodes perform consensus processing on the privacy transaction.

Blockchain nodes perform pre-consensus verification on private transactions, which can screen out some private transactions that do not meet the requirements, such as illegal transactions. These filtered private transactions will not participate in the consensus and will not be affected by each blockchain node. Execution, and only private transactions that pass the pre-consensus verification can participate in the consensus and execution process, which can reduce the network transmission overhead and the verification overhead of other blockchain nodes.

In a blockchain network that uses consensus algorithms such as Proof of Work (POW), Proof of Stake (POS), and Delegated Proof of Stake (DPOS), the consensus process includes blockchain The competition between nodes for the right to bookkeeping. Taking Ethereum as an example, the nodes in Ethereum are generally nodes competing for the right to bookkeeping. The above-mentioned blockchain nodes can execute the above-mentioned private transactions locally as nodes competing for the right to bookkeeping. If a certain node among all the nodes competing for the bookkeeping right wins in the process of the current round of competing for the bookkeeping right, it becomes the bookkeeping node. Assuming that the above-mentioned blockchain node wins in this round of competition for accounting rights, it becomes an accounting node; of course, if the blockchain node does not win in this round of competition for accounting rights, it is not an accounting node , And other nodes may become accounting nodes. For the above-mentioned blockchain networks competing for accounting rights, the blockchain nodes in this manual perform pre-consensus verification on the received private transactions, and if the verification passes, the private transactions will be broadcast to the blockchain network. Other blockchain nodes, so that no matter which node the billing node of this round is, the billing node can package the private transaction (or package other transactions together) and generate a new block, and add the new The block is sent to the non-booking node for consensus, and the non-booking node can append the new block to the end of the original blockchain if there is no problem in verifying the received new block. , So as to complete the accounting process and reach a consensus. And if the above-mentioned private transaction does not pass the pre-consensus verification at the blockchain node in this manual, then the blockchain node will not broadcast the private transaction to other blockchain nodes.

In a blockchain network that uses mechanisms such as Practical Byzantine Fault Tolerance (PBFT), the nodes with the right to book accounts have been agreed before this round of bookkeeping. Therefore, after the above-mentioned blockchain node receives the aforementioned private transaction, assuming that the private transaction has passed the pre-consensus verification, then: if the blockchain node itself is not the accounting node of the current round, the private transaction Send to the accounting node; in the case that the blockchain node itself is the accounting node of this round, after packaging the private transaction (or including other transactions together) and generating a new block, the new block will be generated. The blocks are sent to non-booking nodes for consensus. And, after the above-mentioned blockchain node receives the aforementioned private transaction, assuming that the private transaction does not pass the pre-consensus verification, the blockchain node will not make the private transaction if it is not the accounting node of the current round. Sent to the accounting node, the blockchain node will not use the private transaction to package and generate a new block if it is the accounting node of the current round. For the new block generated by the above bookkeeping node, the non-bookkeeping node can add the new block to the original blockchain if there is no problem in verifying the received new block. At the end, to complete the bookkeeping process and reach a consensus.

Step 206: The blockchain node transfers the consensus private transaction into the trusted execution environment for execution, and uses the cached at least part of the data during the execution of the transaction.

After the privacy transaction has undergone a consensus, each blockchain node in the blockchain network will execute the privacy transaction. Taking the above-mentioned blockchain node as an example, the blockchain node can pass the private transaction into the TEE, and execute the private transaction in the TEE. By using the above-mentioned at least part of the data cached after the pre-consensus verification in the transaction execution process, it is possible to prevent the blockchain node from repeatedly performing operations for obtaining the at least part of the data, such as data query operations, and sending data from the outside. Reading into TEE internal operations, data decryption operations, etc., can reduce the operating overhead of blockchain nodes and improve the transaction execution efficiency of blockchain nodes. After the execution of the private transaction is completed, the blockchain node can clear at least a part of the above-mentioned cached data to release the corresponding storage space.

As mentioned earlier, private transactions can include encrypted transaction content and encrypted keys. According to the processing flow in the related technology, the blockchain node needs to first decrypt the encrypted key based on the node's private key to obtain the first symmetric key, and then decrypt the encrypted transaction content based on the first symmetric key to obtain the plaintext Transaction content. Based on the technical solution of this specification, since the blockchain node caches the first symmetric key after the aforementioned pre-consensus verification, there is no need to decrypt the encrypted key again based on the node’s private key to obtain the first symmetric key. key. Among them, if the blockchain node caches the first symmetric key in the TEE, then the first symmetric key can be in a plaintext state, and the blockchain node can directly read and use the first symmetric key from the TEE , To decrypt the encrypted transaction content to obtain the corresponding plaintext transaction content; if the blockchain node caches the first symmetric key in an external storage space outside the TEE, for example, the second symmetric key described above is used The key encrypts the first symmetric key and stores it in the external storage space, then the blockchain node can read the encrypted first symmetric key from the external storage space into the TEE, and use the second symmetric key to perform The first symmetric key is obtained by decryption. Although the decryption operation is also involved, the symmetric encryption algorithm is used here. Compared with the decryption operation implemented by the node private key and the asymmetric encryption algorithm in the related technology, the result is The operating cost is relatively lower and the efficiency is relatively higher.

The execution process of a private transaction by a blockchain node may include: verification operations during execution and transaction execution operations. The blockchain node first transfers the private transaction to the TEE for verification, that is, the execution-time verification operation; and, the blockchain node can execute the private transaction (that is, when the private transaction passes the execution-time verification) Transaction execution operation), otherwise refuse to execute the private transaction or determine that the execution of the private transaction fails. The execution-time verification is similar to the aforementioned pre-consensus verification process. For example, the execution-time verification can include checking whether the transaction is valid, the format is correct, and verifying whether the transaction signature is legal, etc. The execution verification can involve the contract code of the smart contract. And contract storage, etc., this manual does not limit this. Since execution-time verification is part of the execution process of private transactions, and different transactions are usually difficult to implement in parallel, the execution-time verification of different transactions is usually executed in series. If the blockchain node can realize the parallel execution of multiple transactions, then the possible conflicts between the verifications during the execution of different transactions should be considered, especially when the verification during execution involves contract code or contract storage.

In some cases, the blockchain node can record the verification result of the pre-consensus verification of each transaction. For example, after the blockchain node determines that the above-mentioned private transaction has passed the consensus, the verification result of the pre-consensus verification corresponding to the private transaction can be queried. If the verification result is passed, the verification operation during execution can be skipped , And execute the privacy transaction directly; if the verification result is that the verification is not passed or the verification result is not found, the execution-time verification is required. Generally, blockchain nodes should avoid skipping the verification operation during execution, because the transaction result of the previous transaction may have a certain impact on the subsequent transaction during the execution of each transaction by the blockchain node. For example, if the previous transaction is If the accounts involved in the subsequent transactions are frozen, the subsequent transactions will inevitably fail, but this cannot be verified during the pre-consensus verification process. Therefore, the blockchain node performs verification during the execution of the private transaction such as the above. In addition to the legality of the transaction mentioned above, the verification process can also involve the external involved in the private transaction in the transaction process. The status data of the account, contract account, etc., such as the aforementioned abnormal status such as the account being frozen, will cause the verification result of the verification to be failed during execution.

In the case that the private transaction passes the execution-time verification, the blockchain node can execute the private transaction. Specifically, if the private transaction involves a smart contract, the execution of the private transaction is specifically executed in a virtual machine running in the TEE. For example, a virtual machine (Ethereum Virtual Machine, EVM) is used in Ethereum. Generally, EVM executes smart contracts in the form of bytecodes. Among them, if a private transaction is used to deploy a smart contract, the blockchain node decrypts the encrypted transaction content contained in the privacy transaction and obtains the plaintext transaction content, and can obtain the contract code to be deployed from the plaintext transaction content; If a private transaction is used to call a smart contract, then the blockchain node can obtain the contract address of the target smart contract from the above plaintext transaction content, so that the blockchain node can read the deployed contract code locally based on the contract address (if Deployed in the TEE, the contract code is in plaintext state; if deployed in an external storage space, the contract code is in ciphertext state and needs to be read into the TEE for decryption before it can be executed in the virtual machine). In addition, the plaintext transaction content may also include variables and their values required to execute the contract code. Blockchain nodes can pass the variables and their values to the virtual machine to cooperate with the execution of the contract code.

The contract code has corresponding one or more contract states. After the blockchain node executes the contract code, the value of the contract state may change. Blockchain nodes can store these contract states in TEE in plaintext; or, blockchain nodes can encrypt these contract states in TEE and store them in external storage space. The blockchain node can use the aforementioned second symmetric key to encrypt the state of the contract; or, the blockchain node can use other symmetric keys to encrypt the state of the contract, which is not limited in this specification.

Several keys are involved in this manual. The above-mentioned node private key can be issued to the blockchain node by the KMS (Key Management Service) server after confirming that the TEE on the blockchain node has passed the remote certification, so that the blockchain node can use the node private key Maintained in TEE. The node public key corresponding to the node private key can be issued to the client by the KMS server, or can be disclosed to the client in other ways. Similarly, the above-mentioned second symmetric key (or other symmetric key) can also be issued to the blockchain node by the KMS server after confirming that the TEE on the blockchain node is remotely certified, so that the blockchain node Maintain the second symmetric key in the TEE. Alternatively, the KMS server can issue a security key to the blockchain node after confirming that the TEE on the blockchain node passes remote certification, so that the blockchain node maintains the security key in the TEE, and the second The symmetric key can be the security key or be derived from the security key. In addition, the node's public and private key pair, the second symmetric key, etc. can also be obtained through negotiation between the above-mentioned blockchain node and other blockchain nodes, or obtained in other ways, and this specification does not limit this. Among them, the encryption algorithm used in symmetric encryption, such as DES algorithm, 3DES algorithm, TDEA algorithm, Blowfish algorithm, RC5 algorithm, IDEA algorithm, etc.; asymmetric encryption algorithm, such as RSA, Elgamal, knapsack algorithm, Rabin, DH, ECC ( Elliptic curve encryption algorithm) and so on.

Fig. 5 is a flowchart of another efficient transaction method for realizing privacy protection in the blockchain provided by an exemplary embodiment. As shown in Figure 5, this method is applied to a blockchain node and can include the following steps.

Step 502: The blockchain node transmits the private transaction submitted by the client to the trusted execution environment to perform pre-consensus verification on the private transaction, and compares the information of the private transaction with the verification result of the pre-consensus verification Make associated records.

As mentioned earlier, privacy transactions can be understood as transactions that require privacy; in addition to privacy transactions, blockchain nodes may receive plaintext transactions, which are transactions that do not require privacy. In this manual, you can add a type field to the transaction to indicate the type of transaction; or, you can add or not add a preset encryption identifier to the transaction to indicate that the transaction is a private transaction or a clear text transaction; or, The type of transaction can be determined based on the type of smart contract called by the transaction.

As mentioned above, the private transaction received by the blockchain node can come from the client; for example, the user can submit the private transaction to the above-mentioned blockchain node through the client after the private transaction is generated on the client. Alternatively, after the client generates a private transaction, it can be forwarded to the aforementioned blockchain node through other blockchain nodes. The aforementioned private transaction is encrypted when it is generated to ensure that the content contained in the private transaction will not be obtained by unrelated persons.

As mentioned above, before the blockchain node performs the pre-consensus verification on the above-mentioned private transaction, it needs to read the private transaction into the TEE for decryption, and then perform the pre-consensus verification on the decrypted plaintext content. The pre-consensus verification should be performed within the TEE to prevent the plaintext content obtained by the above decryption from being exposed to the outside of the TEE to avoid security risks. Blockchain nodes can sequentially perform pre-consensus verification on received private transactions, that is, perform pre-consensus verification serially for each private transaction; or, blockchain nodes can perform parallel verification on received private transactions, That is, the blockchain node can implement the pre-consensus verification on the above-mentioned private transaction and at least one other private transaction in parallel, so as to improve the execution efficiency of the blockchain node's pre-consensus verification on the private transaction. In order to be able to perform the pre-consensus verification of the above-mentioned private transaction and at least one other private transaction in parallel, the pre-consensus verification process should avoid conflicts between different private transactions, such as avoiding involvement in the pre-consensus verification process The smart contract's contract code and contract storage, etc., so that different privacy transactions will not cause conflicts due to the contract code or contract storage involving the same smart contract; of course, this does not mean that the pre-consensus verification does not necessarily involve the contract code or Contract storage, for example, when different privacy transactions involve different smart contracts or different contract storage of the same smart contract, even if the pre-consensus verification is performed in parallel, there will be no conflicts.

As mentioned earlier, a private transaction can include encrypted transaction content and an encrypted key. The encrypted transaction content is obtained by encrypting the plaintext transaction content by the first symmetric key maintained by the transaction initiator, and the encrypted key is obtained by the node The public key is obtained by encrypting the above-mentioned first symmetric key. Among them, the first symmetric key is maintained by the transaction initiator, the node public key and the node private key are a set of keys based on an asymmetric encryption algorithm, and the node private key is maintained by the blockchain node to avoid the transaction initiator or client The transaction initiator or the client can obtain the public key of the node; accordingly, the transaction initiator can encrypt the content of the transaction in plaintext with the first symmetric key at the client to obtain the encrypted transaction content, and the transaction content can be obtained through the node public key pair The first symmetric key is encrypted to obtain the encrypted key, that is, the encryption method of the digital envelope, and the above-mentioned private transaction includes both the above-mentioned encrypted transaction content and the encrypted key. Since the encryption and decryption efficiency of the symmetric encryption algorithm is relatively higher, and the security of the asymmetric encryption algorithm is relatively higher, in the encryption method of the digital envelope, the content of the plaintext transaction is symmetrically encrypted through the first symmetric key (and subsequently passed The first symmetric key decrypts the encrypted transaction content), which can achieve relatively higher efficiency. The first symmetric key is encrypted by the node public key (and the first symmetric key is subsequently decrypted by the node private key). To achieve relatively higher security, so as to take into account the efficiency and security of encryption and decryption.

Correspondingly, after the blockchain node reads the above-mentioned private transaction into the TEE, the node's private key can be used to decrypt the encrypted key to obtain the first symmetric key, and the encrypted transaction content can be performed through the first symmetric key. The above-mentioned plaintext transaction content is obtained by decryption, so as to verify the plaintext transaction content.

Step 504: In the case where the privacy transaction passes the pre-consensus verification, the blockchain node and other blockchain nodes perform consensus processing on the privacy transaction.

As mentioned earlier, blockchain nodes perform pre-consensus verification on private transactions, which can screen out some private transactions that do not meet the requirements, such as illegal transactions. These screened out private transactions will not participate in the consensus and will not be Each blockchain node executes, and only private transactions that pass the pre-consensus verification can participate in the consensus and execution process, which can reduce the network transmission overhead and the verification overhead of other blockchain nodes.

As mentioned earlier, in a blockchain network that adopts consensus algorithms such as proof of work, equity proof, and appointed equity proof, the consensus process includes the struggle for bookkeeping rights between blockchain nodes. Taking Ethereum as an example, the nodes in Ethereum are generally nodes competing for the right to bookkeeping. The above-mentioned blockchain nodes can execute the above-mentioned private transactions locally as nodes competing for the right to bookkeeping. If a certain node among all the nodes competing for the bookkeeping right wins in the process of the current round of competing for the bookkeeping right, it becomes the bookkeeping node. Assuming that the above-mentioned blockchain node wins in this round of competition for accounting rights, it becomes an accounting node; of course, if the blockchain node does not win in this round of competition for accounting rights, it is not an accounting node , And other nodes may become accounting nodes. For the above-mentioned blockchain networks competing for accounting rights, the blockchain nodes in this manual perform pre-consensus verification on the received private transactions, and if the verification passes, the private transactions will be broadcast to the blockchain network. Other blockchain nodes, so that no matter which node the billing node of this round is, the billing node can package the private transaction (or package other transactions together) and generate a new block, and add the new The block is sent to the non-booking node for consensus, and the non-booking node can append the new block to the end of the original blockchain if there is no problem in verifying the received new block. , So as to complete the accounting process and reach a consensus. And if the above-mentioned private transaction does not pass the pre-consensus verification at the blockchain node in this manual, then the blockchain node will not broadcast the private transaction to other blockchain nodes.

As mentioned earlier, in a blockchain network that uses mechanisms such as practical Byzantine fault tolerance, the nodes with the right to book accounts have been agreed before this round of bookkeeping. Therefore, after the above-mentioned blockchain node receives the aforementioned private transaction, assuming that the private transaction has passed the pre-consensus verification, then: if the blockchain node itself is not the accounting node of the current round, the private transaction Send to the accounting node; in the case that the blockchain node itself is the accounting node of this round, after packaging the private transaction (or including other transactions together) and generating a new block, the new block will be generated. The blocks are sent to non-booking nodes for consensus. And, after the above-mentioned blockchain node receives the aforementioned private transaction, assuming that the private transaction does not pass the pre-consensus verification, the blockchain node will not make the private transaction if it is not the accounting node of the current round. Sent to the accounting node, the blockchain node will not use the private transaction to package and generate a new block if it is the accounting node of the current round. For the new block generated by the above bookkeeping node, the non-bookkeeping node can add the new block to the original blockchain if there is no problem in verifying the received new block. At the end, to complete the bookkeeping process and reach a consensus.

In step 506, the blockchain node queries the recorded verification result corresponding to any private transaction that is received through consensus.

As mentioned earlier, the blockchain node can record the verification result of the pre-consensus verification of each transaction. For example, after the blockchain node determines that the above-mentioned private transaction has passed the consensus, the verification result of the pre-consensus verification corresponding to the private transaction can be queried. If the verification result is passed, the verification operation during execution can be skipped , And execute the privacy transaction directly; if the verification result is that the verification is not passed or the verification result is not found, the execution-time verification is required.

As mentioned above, the blockchain node needs to read any private transaction into the TEE, and decrypt any private transaction in the manner described above to obtain the plaintext transaction content, thereby determining the above-mentioned verification result . Of course, if the blockchain node associates the verification result with the corresponding private transaction information (such as the hash value of the private transaction), then the blockchain node can even store the private transaction without decrypting the private transaction. Query the corresponding verification result.

Step 508a: In the case where the queried verification result is a pass, the blockchain node transmits any of the privacy transactions to the trusted execution environment for execution.

As mentioned earlier, the privacy transactions in this manual may be related to smart contracts, and relatively complex processing logic can be implemented based on smart contracts. Of course, the privacy transactions in this manual may also have nothing to do with smart contracts, and are only used to implement relatively simple processing logic, such as transfer logic in related technologies.

If the private transaction involves a smart contract, the execution of the private transaction is specifically executed in a virtual machine running in the TEE. For example, a virtual machine (Ethereum Virtual Machine, EVM) is used in Ethereum. Generally, EVM executes smart contracts in the form of bytecodes. Among them, if a private transaction is used to deploy a smart contract, the blockchain node decrypts the encrypted transaction content contained in the privacy transaction and obtains the plaintext transaction content, and can obtain the contract code to be deployed from the plaintext transaction content; If a private transaction is used to call a smart contract, then the blockchain node can obtain the contract address of the target smart contract from the above plaintext transaction content, so that the blockchain node can read the deployed contract code locally based on the contract address (if Deployed in the TEE, the contract code is in plaintext state; if deployed in an external storage space, the contract code is in ciphertext state and needs to be read into the TEE for decryption before it can be executed in the virtual machine). In addition, the plaintext transaction content may also include variables and their values required to execute the contract code. Blockchain nodes can pass the variables and their values to the virtual machine to cooperate with the execution of the contract code.

The contract code has corresponding one or more contract states. After the blockchain node executes the contract code, the value of the contract state may change. Blockchain nodes can store these contract states in TEE in plaintext; or, blockchain nodes can encrypt these contract states in TEE and store them in external storage space. The blockchain node can use the aforementioned second symmetric key to encrypt the state of the contract; or, the blockchain node can use other symmetric keys to encrypt the state of the contract, which is not limited in this specification.

Step 508b, in the case that the queried verification result is not passed the verification or the verification result is not queried, the blockchain node transmits any of the privacy transactions to the trusted execution environment for execution Time verification, and execute any privacy transaction in the case that any privacy transaction passes the execution time verification.

As mentioned above, the execution process of a private transaction by a blockchain node may include: verification operations during execution and transaction execution operations. The blockchain node first transfers the private transaction to the TEE for verification, that is, the execution-time verification operation; and, the blockchain node can execute the private transaction (that is, when the private transaction passes the execution-time verification) Transaction execution operation), otherwise refuse to execute the private transaction or determine that the execution of the private transaction fails. The execution-time verification is similar to the aforementioned pre-consensus verification process. For example, the execution-time verification can include checking whether the transaction is valid, the format is correct, and verifying whether the transaction signature is legal, etc. The execution verification can involve the contract code of the smart contract. And contract storage, etc., this manual does not limit this. Since execution-time verification is part of the execution process of private transactions, and different transactions are usually difficult to implement in parallel, the execution-time verification of different transactions is usually executed in series. If the blockchain node can realize the parallel execution of multiple transactions, then the possible conflicts between the verifications during the execution of different transactions should be considered, especially when the verification during execution involves contract code or contract storage.

In the case that the private transaction passes the execution-time verification, the blockchain node can execute the private transaction. For the execution process, refer to the related description of step 508a, which will not be repeated here.

Fig. 6 is a schematic structural diagram of a device provided by an exemplary embodiment. Please refer to FIG. 6, at the hardware level, the device includes a processor 602, an internal bus 604, a network interface 606, a memory 608, and a non-volatile memory 610. Of course, it may also include hardware required for other services. The processor 602 reads the corresponding computer program from the non-volatile memory 610 to the memory 608 and then runs it to form an efficient transaction device that realizes privacy protection in the blockchain at the logical level. Of course, in addition to software implementation, one or more embodiments of this specification do not exclude other implementations, such as logic devices or a combination of software and hardware, and so on. That is to say, the execution subject of the following processing flow is not limited to each The logic unit can also be a hardware or a logic device.

Please refer to FIG. 7. In the software implementation, the high-efficiency transaction device for implementing privacy protection in the blockchain may include the following units.

The pre-consensus verification unit 701 enables the blockchain node to transfer the private transaction submitted by the client to the trusted execution environment to perform pre-consensus verification on the private transaction.

The cache unit 702 enables the blockchain node to cache at least part of the data used in the pre-consensus verification process.

The consensus unit 703 enables the blockchain node to perform consensus processing on the private transaction with other blockchain nodes when the private transaction passes the pre-consensus verification.

The execution unit 704 is configured to enable the blockchain node to transfer the consensus private transaction into the trusted execution environment for execution, and use the cached at least part of the data during the execution of the transaction.

Optionally, the pre-consensus verification unit 701 is specifically configured to: enable the blockchain node to perform pre-consensus verification on the private transaction and at least one other private transaction in parallel.

Optionally, the caching unit 702 is specifically configured to: enable the blockchain node to encrypt the data extracted from the private transaction and cache it outside the trusted execution environment.

Optionally, the private transaction includes encrypted transaction content and an encrypted key, where the encrypted transaction content is obtained by encrypting the plaintext transaction content with a first symmetric key maintained by the transaction initiator, and the encrypted key The first symmetric key is obtained by encrypting the node public key; the data extracted from the private transaction includes: the first symmetric key obtained by using the node private key to decrypt the encrypted key.

Optionally, the caching unit 702 is specifically configured to: enable the blockchain node to use a second symmetric key maintained in the trusted execution environment to encrypt the first symmetric key, and then cache it to the Outside the trusted execution environment.

Optionally, the caching unit 702 is specifically configured to: enable the blockchain node to read the encrypted data into the trusted execution environment for decryption and cache the decrypted data obtained in the trusted execution environment, The encrypted data is stored by the blockchain node in an external storage space outside the trusted execution environment.

Optionally, the decrypted data includes at least one of the following: status data of an external account, status data of a contract account, contract code corresponding to the contract account, and contract storage corresponding to the contract code.

Optionally, the execution unit 704 is specifically configured to: enable the blockchain node to transfer the consensus-based privacy transaction to the trusted execution environment for execution time verification.

In the case where the privacy transaction passes the execution-time verification, the blockchain node is caused to execute the privacy transaction.

Optionally, it further includes: a clearing unit 705, configured to enable the blockchain node to clear the at least a part of the cached data after the execution of the private transaction is completed.

Fig. 8 is a schematic structural diagram of a device provided by an exemplary embodiment. Please refer to FIG. 8. At the hardware level, the device includes a processor 802, an internal bus 804, a network interface 806, a memory 808, and a non-volatile memory 810. Of course, it may also include hardware required for other services. The processor 802 reads the corresponding computer program from the non-volatile memory 810 to the memory 808 and then runs it to form an efficient transaction device that realizes privacy protection in the blockchain at the logical level. Of course, in addition to software implementation, one or more embodiments of this specification do not exclude other implementations, such as logic devices or a combination of software and hardware, and so on. That is to say, the execution subject of the following processing flow is not limited to each The logic unit can also be a hardware or a logic device.

Please refer to FIG. 9, in the software implementation, the high-efficiency transaction device for implementing privacy protection in the blockchain may include the following units.

The pre-consensus verification unit 901 enables the blockchain node to transfer the private transaction submitted by the client to the trusted execution environment to perform pre-consensus verification on the private transaction.

The recording unit 902 enables the blockchain node to associate and record the information of the private transaction and the verification result of the pre-consensus verification.

The consensus unit 903 enables the blockchain node to perform consensus processing on the private transaction with other blockchain nodes when the private transaction passes the verification before the consensus.

The query unit 904 is configured to enable the blockchain node to query the recorded verification result corresponding to any private transaction that is received through consensus for any private transaction.

The execution unit 905, when the queried verification result is passed the verification, causes the blockchain node to pass any of the privacy transactions into the trusted execution environment for execution; If the verification result is that the verification is not passed or the verification result is not queried, the blockchain node is caused to pass any of the privacy transactions into the trusted execution environment for execution-time verification, and check it at all Any one of the aforementioned private transactions is executed in a case where the execution-time verification is passed.

Optionally, the pre-consensus verification unit 901 is specifically configured to enable the blockchain node to perform a pre-consensus verification on the private transaction and at least one other private transaction in parallel.

The systems, devices, modules, or units illustrated in the above embodiments may be specifically implemented by computer chips or entities, or implemented by products with certain functions. A typical implementation device is a computer. The specific form of the computer can be a personal computer, a laptop computer, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email receiving and sending device, and a game control A console, a tablet computer, a wearable device, or a combination of any of these devices.

In a typical configuration, the computer includes one or more processors (CPU), input/output interfaces, network interfaces, and memory.

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

Computer-readable media include permanent and non-permanent, removable and non-removable media, and information storage can be realized by any method or technology. The information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, CD-ROM, digital versatile disc (DVD) or other optical storage, Magnetic cassettes, disk storage, quantum memory, graphene-based storage media or other magnetic storage devices, or any other non-transmission media, can be used to store information that can be accessed by computing devices. According to the definition in this article, computer-readable media does not include transitory media, such as modulated data signals and carrier waves.

It should also be noted that the terms "include", "include" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, product or equipment including a series of elements not only includes those elements, but also includes Other elements that are not explicitly listed, or also include elements inherent to such processes, methods, commodities, or equipment. If there are no more restrictions, the element defined by the sentence "including a..." does not exclude the existence of other identical elements in the process, method, commodity, or equipment that includes the element.

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

The terms used in one or more embodiments of this specification are only for the purpose of describing specific embodiments, and are not intended to limit one or more embodiments of this specification. The singular forms of "a", "said" and "the" used in one or more embodiments of this specification and the appended claims are also intended to include plural forms, unless the context clearly indicates other meanings. It should also be understood that the term "and/or" as used herein refers to and includes any or all possible combinations of one or more associated listed items.

It should be understood that although the terms first, second, third, etc. may be used to describe various information in one or more embodiments of this specification, the information should not be limited to these terms. These terms are only used to distinguish the same type of information from each other. For example, without departing from the scope of one or more embodiments of this specification, the first information may also be referred to as second information, and similarly, the second information may also be referred to as first information. Depending on the context, the word "if" as used herein can be interpreted as "when" or "when" or "in response to determination".

The above descriptions are only preferred embodiments of one or more embodiments of this specification, and are not intended to limit one or more embodiments of this specification. All within the spirit and principle of one or more embodiments of this specification, Any modification, equivalent replacement, improvement, etc. made should be included in the protection scope of one or more embodiments of this specification.

Claims (17)

1. An efficient transaction method that realizes privacy protection in the blockchain, including:

   The blockchain node transmits the private transaction submitted by the client to the trusted execution environment to perform pre-consensus verification on the private transaction, and caches at least a part of the data used in the pre-consensus verification process;

   In the case that the privacy transaction passes the pre-consensus verification, the blockchain node and other blockchain nodes perform consensus processing on the privacy transaction;

   The blockchain node transfers the consensus private transaction into the trusted execution environment for execution, and uses the at least a part of the cached data during the execution of the transaction.
2. The method according to claim 1, wherein the blockchain node performs a pre-consensus verification on the private transaction, comprising:

   The blockchain node performs pre-consensus verification on the private transaction and at least one other private transaction in parallel.
3. The method according to claim 1, wherein the caching of at least a part of the data used in the pre-consensus verification process comprises:

   The blockchain node encrypts the data extracted from the private transaction and caches it outside the trusted execution environment.
4. The method according to claim 3, wherein the private transaction includes encrypted transaction content and an encrypted key, and the encrypted transaction content is obtained by encrypting the plaintext transaction content by a first symmetric key maintained by the transaction initiator, so The encrypted key is obtained by encrypting the first symmetric key with the node public key; the data extracted from the private transaction includes: the first symmetric key obtained by decrypting the encrypted key with the node private key A symmetric key.
5. The method according to claim 4, wherein the caching of at least a part of the data used in the pre-consensus verification process comprises:

   The blockchain node uses the second symmetric key maintained in the trusted execution environment to encrypt the first symmetric key and caches the first symmetric key outside the trusted execution environment.
6. The method according to claim 1, wherein the caching of at least a part of the data used in the pre-consensus verification process comprises:

   The blockchain node reads the encrypted data into the trusted execution environment for decryption. The decrypted data is cached in the trusted execution environment, where the encrypted data is stored by the blockchain node External storage space outside the trusted execution environment.
7. The method according to claim 6, wherein the decrypted data includes at least one of the following: status data of an external account, status data of a contract account, contract code corresponding to the contract account, and contract storage corresponding to the contract code.
8. The method according to claim 1, wherein the blockchain node transferring the consensus-based private transaction into the trusted execution environment for execution includes:

   The blockchain node transmits the consensus-based privacy transaction to the trusted execution environment for execution-time verification;

   In the case where the privacy transaction passes the execution-time verification, the blockchain node executes the privacy transaction.
9. The method according to claim 1, further comprising:

   The blockchain node clears the at least part of the cached data after the execution of the privacy transaction is completed.
10. An efficient transaction method that realizes privacy protection in the blockchain, including:

    The blockchain node transmits the private transaction submitted by the client to the trusted execution environment to perform pre-consensus verification on the private transaction, and associates the information of the private transaction with the verification result of the pre-consensus verification. ；

    In the case that the privacy transaction passes the pre-consensus verification, the blockchain node and other blockchain nodes perform consensus processing on the privacy transaction;

    The blockchain node queries and records the verification result corresponding to the any private transaction that is received through consensus;

    In the case where the queried verification result is passed verification, the blockchain node transmits any of the privacy transactions to the trusted execution environment for execution;

    In the case that the queried verification result is not passed the verification or the verification result is not queried, the blockchain node transmits any of the privacy transactions to the trusted execution environment for execution-time verification , And execute any private transaction in the case where the any private transaction passes the execution-time verification.
11. The method according to claim 10, wherein the blockchain node performs a pre-consensus verification on the private transaction, comprising:

    The blockchain node performs pre-consensus verification on the private transaction and at least one other private transaction in parallel.
12. An efficient transaction device that realizes privacy protection in the blockchain, including:

    The pre-consensus verification unit enables the blockchain node to pass the private transaction submitted by the client to the trusted execution environment to perform pre-consensus verification on the private transaction;

    A cache unit, which enables the blockchain node to cache at least a part of the data used in the pre-consensus verification process;

    The consensus unit enables the blockchain node to perform consensus processing on the private transaction with other blockchain nodes when the private transaction passes the verification before consensus;

    The execution unit is configured to enable the blockchain node to transfer the consensus private transaction into the trusted execution environment for execution, and use the cached at least part of the data during the execution of the transaction.
13. An efficient transaction device that realizes privacy protection in the blockchain, including:

    The pre-consensus verification unit enables the blockchain node to pass the private transaction submitted by the client to the trusted execution environment to perform pre-consensus verification on the private transaction;

    A recording unit to enable the blockchain node to associate the information of the private transaction with the verification result of the pre-consensus verification;

    The consensus unit enables the blockchain node to perform consensus processing on the private transaction with other blockchain nodes when the private transaction passes the verification before consensus;

    The query unit is configured to enable the blockchain node to query and record the verification result corresponding to any private transaction that is received through consensus;

    The execution unit, in the case that the queried verification result is passed the verification, causes the blockchain node to pass any of the privacy transactions into the trusted execution environment for execution; in the case of the queried verification If the result is that the verification is not passed or the verification result is not queried, the blockchain node is caused to pass any of the privacy transactions into the trusted execution environment for execution-time verification, and perform the verification in the If any private transaction passes the execution time verification, the any private transaction is executed.
14. An electronic device including:

    processor;

    A memory for storing processor executable instructions;

    Wherein, the processor executes the executable instruction to implement the method according to any one of claims 1-9.
15. A computer-readable storage medium having computer instructions stored thereon, which, when executed by a processor, implements the steps of the method according to any one of claims 1-9.
16. An electronic device including:

    processor;

    A memory for storing processor executable instructions;

    Wherein, the processor implements the method according to claim 10 or 11 by running the executable instruction.
17. A computer-readable storage medium having computer instructions stored thereon, which, when executed by a processor, implements the steps of the method according to claim 10 or 11.

Images