WO2020233612A1

WO2020233612A1 - Receipt storage method and node combining code annotation with transaction and event types

Info

Publication number: WO2020233612A1
Application number: PCT/CN2020/091370
Authority: WO
Inventors: 刘琦; 闫莺; 魏长征
Original assignee: 创新先进技术有限公司
Priority date: 2019-05-20
Filing date: 2020-05-20
Publication date: 2020-11-26
Also published as: CN110278193A; CN110278193B

Abstract

One or more embodiments of the description provide a receipt storage method and node combining code annotation with transaction and event types. The method may comprise: a first blockchain node receives an encrypted transaction corresponding to a smart contract, the code of the smart contract comprising a field indicated by an expose identifier; the first blockchain node decrypts the transaction in a trusted execution environment to obtain the smart contract, the smart contract comprising a special event function; the first blockchain node executes the smart contract in the trusted execution environment to obtain receipt data, the receipt data comprising a log corresponding to the special event function; the first blockchain node determines a corresponding expose field according to the transaction type of the transaction; the first blockchain node stores the receipt data, so that at least part of the receipt content in the log corresponding to the special event function is stored in plain text and the rest of the receipt data is stored in cipher text, the at least part of the receipt content comprising an expose field identified by the expose identifier.

Description

Receipt storage method and node combining code annotation with transaction and event type

Technical field

One or more embodiments of this specification relate to the field of blockchain technology, and in particular to a receipt storage method and node combining code labeling with transaction and event types.

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 of enterprise-level blockchain platform technology are privacy and performance. 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 that solve privacy problems, such as Homomorphic encryption and Zero-knowledge proof, are highly complex, poor in 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. Only the pre-defined interface in the code can operate on it. In terms of efficiency, due to the black-box nature of TEE, plaintext data is calculated in TEE instead of 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 TEE solutions. Almost all mainstream chip and software alliances have their own TEE solutions, including TPM (Trusted Platform Module) for software and Intel SGX (Software Guard Extensions) for hardware. , 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 a receipt storage method and node that combine code labeling with transaction and event types.

To achieve the foregoing objectives, one or more embodiments of this specification provide technical solutions as follows:

According to the first aspect of one or more embodiments of this specification, a receipt storage method combining code labeling with transaction and event types is proposed, including:

The first blockchain node receives an encrypted transaction corresponding to a smart contract, and the code of the smart contract includes a field marked by an exposed identifier;

The first blockchain node decrypts the transaction in a trusted execution environment to obtain the smart contract, and the smart contract includes a special event function;

The first blockchain node executes the smart contract in the trusted execution environment to obtain receipt data, where the receipt data includes a log corresponding to the special event function;

The first blockchain node determines the corresponding exposed field according to the transaction type of the transaction;

The first blockchain node stores the receipt data, so that at least part of the receipt content in the log corresponding to the special event function is stored in plain text, and the remaining content of the receipt data is stored in cipher text. The content of the receipt includes the exposed field indicated by the exposed identifier.

According to the second aspect of one or more embodiments of this specification, a receipt storage node that combines code labeling with transaction and event types is proposed, including:

The receiving unit receives an encrypted transaction corresponding to a smart contract, the code of the smart contract includes a field marked by an exposed identifier;

A decryption unit, decrypting the transaction in a trusted execution environment to obtain the smart contract, the smart contract including a special event function;

An execution unit to execute the smart contract in the trusted execution environment to obtain receipt data, where the receipt data includes a log corresponding to the special event function;

The determining unit determines the corresponding exposed field according to the transaction type of the transaction;

The storage unit stores the receipt data so that at least part of the receipt content in the log corresponding to the special event function is stored in plain text, and the rest of the receipt data is stored in cipher text, and the at least part of the receipt content includes The exposed field indicated by the exposed identifier.

According to a third aspect of one or more embodiments of this specification, an electronic device is proposed, including:

processor;

A memory for storing processor executable instructions;

Wherein, the processor implements the method according to the first aspect by running the executable instruction.

According to the fourth aspect of one or more embodiments of the present specification, a computer-readable storage medium is provided, and computer instructions are stored thereon, which, when executed by a processor, implement the steps of the method described in the first aspect.

Description of the drawings

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

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

Fig. 3 is a flowchart of a method for storing receipts combining code labeling with transaction and event types according to an exemplary embodiment.

Fig. 4 is a schematic diagram of implementing privacy protection on blockchain nodes according to an exemplary embodiment.

Fig. 5 is a schematic diagram of the functional logic of implementing a blockchain network through a system contract and a chain code provided by an exemplary embodiment.

Fig. 6 is a block diagram of a receipt storage node combining code labeling with transaction and event types provided by an exemplary embodiment.

Detailed ways

Here, exemplary embodiments will be described in detail, and examples thereof are shown in the accompanying drawings. When the following description refers to the drawings, unless otherwise indicated, the same numbers in different drawings indicate 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. On the contrary, 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 includes 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. 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. The alliance chain is a block chain between the public chain and the private chain, which can achieve "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.

Whether it is a public chain, a private chain or a consortium chain, it is possible to provide the function of a smart contract. A smart contract on the blockchain is a contract that can be triggered and executed by a transaction on the blockchain system. Smart contracts can be defined in the form of codes.

Taking Ethereum as an example, it supports users to create and 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 each Ethereum node can run EVM. EVM is a Turing complete virtual machine, which means that various complex logic can be implemented through it. Users publish and call smart contracts in Ethereum run on the EVM. In fact, the virtual machine directly runs virtual machine code (virtual machine bytecode, hereinafter referred to as "bytecode"). The smart contract deployed on the blockchain can be in the form of bytecode.

For example, as shown in Figure 1, 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. "0x6f8ae93..." in the figure 1 represents the address of this contract, the data field of the transaction can be stored in bytecode, and the to field of the transaction is empty. After the nodes reach an agreement through the consensus mechanism, the contract is successfully created and can be called in the subsequent process. After the contract is created, a contract account corresponding to the smart contract appears on the blockchain and has a specific address, and the contract code will be stored in the contract account. The behavior of the smart contract is controlled by the contract code. In other words, smart contracts enable virtual accounts containing contract codes and account storage (Storage) to be generated on the blockchain.

As shown in Figure 2, still taking Ethereum as an example, after Bob sends a transaction for invoking a smart contract to the Ethereum network, the EVM of a certain node can execute the transaction and generate a corresponding contract instance. The from field of the transaction in Figure 2 is the address of the account of the transaction initiator (ie Bob), the "0x6f8ae93..." in the to field represents the address of the called smart contract, and the value field in Ethereum is the value of Ether , The method and parameters of calling the smart contract are stored in the data field of the transaction. Smart contracts are executed independently on each node in the blockchain network in a prescribed manner. All execution records and data are stored on the blockchain, so when the transaction is completed, the blockchain will be stored on the blockchain that cannot be tampered with. Lost transaction certificate.

After the nodes in the blockchain network execute the transaction initiated by Bob, they will generate corresponding receipt data to record the receipt information related to the transaction. Taking Ethereum as an example, the receipt data obtained by a node executing a transaction can include the following:

The Result field indicates the execution result of the transaction;

The Gas used field indicates the gas value consumed by the transaction;

The Logs field indicates the log generated by the transaction. The log can further include the From field, To field, Topic field, and Log data field, among which the From field indicates the account address of the initiator of the call, and the To field indicates the called object (such as a smart contract) The account address and Topic field indicate the subject of the log, and the Log data field indicates the log data;

The Output field indicates the output of the transaction.

Generally, the receipt data generated after the transaction is executed is stored in plain text, and anyone can see the contents of the above-mentioned receipt fields contained in the receipt data, without privacy protection settings and capabilities. In some solutions that combine blockchain and TEE, in order to achieve privacy protection, the entire content of the receipt data is stored on the blockchain as data that requires privacy protection. The block chain is a data set stored in a database of a node and organized by a specific logic. The database, as described later, may be a storage medium, such as a persistent storage medium, on a physical carrier. In fact, only part of the content of the receipt data may be sensitive, while other content is not sensitive. Only sensitive content needs to be protected for privacy, other content can be disclosed, and in some cases it may even be necessary to retrieve some content to drive Implementation of related operations, the implementation of privacy protection for this part of the content will affect the implementation of retrieval operations.

The following describes the implementation process of an embodiment of a receipt storage method combining code labeling and transaction and event types of this application with reference to FIG. 3:

In step 302, the first blockchain node receives an encrypted transaction corresponding to a smart contract, and the code of the smart contract includes a field marked by an exposed identifier.

The exposed identifier is a global identifier defined in the programming language of the smart contract and is applicable to all smart contracts written in this programming language. Therefore, by defining the exposure identifier in a programming language, so that the code of any smart contract uses the exposure identifier, the storage control of the receipt data can be realized. For example, when a user writes the code of a smart contract, he can add an exposed identifier to the code to indicate one or more fields to indicate that the user wants the receipt content corresponding to this part of the field in the receipt data to be stored in plain text, and the remaining The content of the receipt corresponding to the field marked with the exposed identifier is not allowed to be stored in plain text, but must be stored in cipher text to achieve corresponding privacy protection.

In other words, for the fields marked by the exposed identifier, from the perspective of the programming language, the corresponding receipt content is allowed to be stored in plain text; however, this manual can further consider the transaction type and the event function contained in the smart contract, and Comprehensive consideration is achieved from the dimensions of programming language, transaction type, and event function to determine whether to store the content of the receipt corresponding to the field indicated by the exposure identifier in plain text. Information related to transaction types and event functions will be described below, so I won’t repeat them here.

As mentioned above, in a transaction used to create a smart contract, the data field can store the bytecode of the smart contract. The bytecode consists of a series of bytes, and each byte can identify an operation. Based on many considerations such as development efficiency and readability, developers can choose a high-level language to write smart contract code instead of directly writing bytecode. The code of a smart contract written in a high-level language is compiled by a compiler to generate bytecode, and then the bytecode can be deployed on the blockchain. There are many high-level languages supported by Ethereum, such as Solidity, Serpent, and LLL languages.

Taking the Solidity language as an example, the contract written in it is very similar to the class in the object-oriented programming language. A variety of members can be declared in a contract, including state variables, functions, function modifiers, and events. The following is a simple smart contract code example 1 written in Solidity language:

In the code of the smart contract written in Solidity language, one or more fields can be marked by exposing identifiers, so that the receipt content corresponding to this part of the field in the receipt data is allowed to be stored in clear text (need to further combine the transaction type and The dimensions of the event function determine whether to actually use plaintext storage), and the rest of the receipt content should be stored in ciphertext. Similarly, in the code of a smart contract written based on Serpent, LLL languages, etc., one or more fields can also be marked by exposing identifiers to realize the plaintext storage of the relevant receipt content.

The exposure identifier may be a receipt field dedicated to indicating that plain text storage is allowed. For example, the keyword plain may be used to characterize the exposure identifier. Then, for the receipt content that you want to store in plain text, you can add plain before the corresponding field (or, you can also associate with the corresponding field in other ways).

The fields indicated by the exposure identifier may include receipt fields, such as the Result field, Gas used field, Logs field, Output field, etc., as described above, or the From field, To field, Topic field, and Log data field further contained in the Logs field Wait. For example, the code sample 1 above can be adjusted to the following code sample 2:

In the above code example 2, the exposed identifier plain is added to the front of the code of the smart contract. From the perspective of the programming language, the exposed identifier plain indicates: the receipt data generated after the code of the smart contract is executed All fields in are allowed to be stored in plain text, so subsequent retrieval operations can be performed on the receipt content in these fields. For example, the From field can be used to count the transaction volume initiated by an account. However, by further combining dimensions such as transaction types and event functions, there may be different storage schemes for receipt data, which can be seen below.

In an embodiment, the smart contract corresponding to the transaction received by the first blockchain node may be a smart contract written in a high-level language, or may be a smart contract in the form of bytecode. Among them, when the smart contract is a smart contract written in a high-level language, the first blockchain node also compiles the smart contract written in the high-level language through a compiler to generate a smart contract in the form of bytecode to be used in a trusted execution environment In execution. When the smart contract corresponding to the transaction received by the first blockchain node is a smart contract in bytecode form, the smart contract in bytecode form can be obtained by compiling the smart contract written in high-level language by the client through the compiler , And the smart contract written in this high-level language is written by the user on the client.

The smart contract corresponding to the transaction received by the first blockchain node may be a smart contract generated by the user on the first blockchain node. When the user writes the above-mentioned smart contract in a high-level language, the first blockchain node also uses a compiler to compile the smart contract written in the high-level language into a smart contract in the form of bytecode; or, the user may also be in the first area Smart contracts in bytecode form are directly written on the blockchain nodes.

The smart contract corresponding to the transaction received by the first blockchain node may be a smart contract generated by the user on the client. For example, after the user generates the transaction on the client through the corresponding account, the client submits the transaction to the first blockchain node. Taking FIG. 4 as an example, the first blockchain node includes a transaction/query interface, which can be connected with the client, so that the client can submit the above-mentioned transaction to the first blockchain node. For example, as mentioned above, the user can use a high-level language to write a smart contract on the client, and then the client uses a compiler to compile the smart contract in the high-level language to obtain the corresponding smart contract in bytecode form. Of course, the client can directly send a smart contract written in a high-level language to the first blockchain node, so that the first blockchain node is compiled into a bytecode smart contract by a compiler.

For the smart contract corresponding to the transaction received by the first blockchain node, it can be the smart contract in the transaction sent by the client through the second blockchain node. The smart contract is usually in the form of bytecode; of course, the smart contract It can also be a smart contract written in a high-level language, and the first blockchain node can be compiled into a bytecode smart contract by a compiler.

In an embodiment, when the code of the smart contract includes an exposure identifier, the smart contract written in a high-level language and the smart contract in the form of bytecode may have the same exposure identifier. Those skilled in the art should understand that the bytecode can use an exposed identifier different from a high-level language. For example, the code of a smart contract written in a high-level language contains the first identifier and the code of the smart contract in the form of bytecode. If the second identifier is included, there is a corresponding relationship between the first identifier and the second identifier to ensure that after being compiled into bytecode by a high-level language, the function of exposing the identifier will not be affected.

In step 304A, the first blockchain node decrypts the transaction in a trusted execution environment to obtain the smart contract, and the smart contract includes a special event function.

In an embodiment, the smart contract may include one or more events, and each event is used to implement predefined related processing logic. After each event contained in the smart contract is called and executed, the corresponding Logs field will be generated. For example, when the smart contract contains event 1 and event 2, event 1 can generate the corresponding Logs field, and event 2 can generate the corresponding Logs field. , So that the receipt data corresponding to the smart contract contains multiple Logs fields at the same time.

In one embodiment, the events contained in the smart contract can be divided into special event functions and ordinary event functions. The logs generated by the ordinary event functions are stored in cipher text to achieve privacy protection; the special event functions generated The log allows at least part of the log fields to be stored in clear text on the premise of meeting the privacy protection requirements (specifically, the dimensions of the programming language and transaction type must be combined to determine whether to store in clear text), so that this part of the log fields can be stored The content is searched to drive the implementation of related operations.

In one embodiment, the event function belonging to the "special event function" can be recorded in the chain code of the blockchain network or the system contract, for example, can be recorded in the special event function list; accordingly, by adding the Comparing the event function with the above special event function list can determine whether the event function included in the smart contract is the above special event function.

In an embodiment, the special event function can be any function defined in the smart contract, and by adding a type identifier for the event function in the smart contract, the event function can be marked as a special event function. Taking the Solidity language as an example, the code example of the event function in the above code example 1 is as follows:

event currentPrice(int price);

In the above code example, the smart contract defines an event: the event currentPrice. However, the event does not contain any type identifier, so the corresponding event function is a normal event function. After adjusting the event function in Code Example 1, the code example of the event function can be obtained as follows:

event currentPrice expose(int price);

In the above modified code example, the smart contract defines an event: event currentPrice. By adding the type identifier "expose" to the event currentPrice, the event currentPrice can be marked as the above-mentioned special event function.

Many high-level languages supported by Ethereum, such as Solidity, Serpent, and LLL languages, can contain the above type identifiers. A smart contract written in a high-level language can be compiled into a corresponding bytecode through a compiler, and the first blockchain node will finally execute the smart contract in the form of bytecode in the EVM virtual machine. Then, the above-mentioned type identifier can be the same in high-level language and bytecode smart contract code, or the first type identifier in high-level language smart contract code, and the second type in bytecode smart contract code Type identifier, the first type identifier and the second type identifier can correspond to each other.

In one embodiment, by encrypting the transaction content, the encrypted transaction can be kept in a state of privacy protection, and the transaction content can be prevented from being exposed. For example, the transaction content may contain information such as the account address of the transaction initiator and the account address of the transaction target. Encryption processing can ensure that these transaction contents cannot be directly read.

In an embodiment, the foregoing transaction may be encrypted by a symmetric encryption algorithm, or may be encrypted by an asymmetric algorithm. The encryption algorithm used by symmetric encryption, such as DES algorithm, 3DES algorithm, TDEA algorithm, Blowfish algorithm, RC5 algorithm, IDEA algorithm, etc. Asymmetric encryption algorithms, such as RSA, Elgamal, knapsack algorithm, Rabin, D-H, ECC (elliptic curve encryption algorithm), etc.

In one embodiment, the foregoing transaction may be encrypted by a combination of a symmetric encryption algorithm and an asymmetric encryption algorithm. Taking the client submitting the above transaction to the first blockchain node as an example, the client can use a symmetric encryption algorithm to encrypt the transaction content, that is, use the symmetric encryption algorithm key to encrypt the transaction content, and use an asymmetric encryption algorithm to encrypt the symmetric encryption algorithm The key used, for example, the key used in the public key encryption symmetric encryption algorithm using an asymmetric encryption algorithm. In this way, after the first blockchain node receives the encrypted transaction, it can first decrypt it with the private key of the asymmetric encryption algorithm to obtain the key of the symmetric encryption algorithm, and then decrypt it with the key of the symmetric encryption algorithm to obtain the transaction content.

When a transaction is used to call a smart contract, it can be a call of multiple nested structures. For example, the transaction directly calls smart contract 1, and the code of smart contract 1 calls smart contract 2, and the code in smart contract 2 points to the contract address of smart contract 3, so that the transaction actually calls the code of smart contract 3 indirectly , And smart contract 3 includes a certain event function. In this way, it is equivalent to the event function included in smart contract 1. The specific implementation process is similar to the above process, and will not be repeated here.

In step 306A, the first blockchain node executes the smart contract in the trusted execution environment to obtain receipt data, where the receipt data includes a log corresponding to the special event function.

As mentioned above, when the first blockchain node executes the code of the smart contract, for each event function contained in the code, a corresponding Logs field will be generated, that is, a log corresponding to each event function will be generated. By determining the special event function, the log corresponding to the special event function can be further determined, so that at least a part of the log field corresponding to the special event function is stored in plain text.

In an embodiment, such as in Ethereum, after receiving a transaction invoking a smart contract from a client, the first blockchain node can check whether the transaction is valid, the format is correct, and the signature of the transaction is legal.

Generally speaking, the nodes in Ethereum are generally nodes that compete for the right to bookkeeping. Therefore, the first blockchain node as the node that competes for the right to bookkeeping can execute the transaction locally. If one of the nodes competing for the accounting right wins in the current round of the accounting right, it becomes the accounting node. If the first blockchain node wins this round of competition for accounting rights, it becomes the accounting node; of course, if the first blockchain node does not win in this round of competition for accounting rights, it is not Accounting nodes, and other nodes may become accounting nodes.

A smart contract is similar to a class in object-oriented programming. The result of execution generates a contract instance corresponding to the smart contract, similar to the object corresponding to the generated class. The process of executing the code used to create a smart contract in a transaction will create a contract account and deploy the contract in the account space. In Ethereum, the address of the smart contract account is generated from the sender's address ("0xf5e..." in Figure 1-2) and the transaction nonce (nonce) as input, and is generated by an encryption algorithm, such as in Figure 1-2 The contract address "0x6f8ae93..." is generated from the sender's address "0xf5e..." and the nonce in the transaction through an encryption algorithm.

Generally, consensus algorithms such as Proof of Work (POW), Proof of Stake (POS), and Delegated Proof of Stake (DPOS) are adopted in blockchain networks that support smart contracts. All nodes competing for the right to account can execute the transaction after receiving the transaction including the creation of a smart contract. One of the nodes competing for the right to bookkeeping may win this round and become the bookkeeping node. The accounting node can package the transaction containing the smart contract with other transactions and generate a new block, and send the generated new block to other nodes for consensus.

For a blockchain network supporting smart contracts that adopts 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 first blockchain node receives the above transaction, if it is not the accounting node of this round, it can send the transaction to the accounting node. For this round of accounting nodes (which can be the first blockchain node), during or before packaging the transaction and generating a new block, or during the process of packaging the transaction together with other transactions and generating a new block Or before, the transaction can be executed. After the accounting node packages the transaction (or other transactions together) and generates a new block, the generated new block or block header is sent to other nodes for consensus.

As mentioned above, in the blockchain network that supports smart contracts using the POW mechanism, or in the blockchain network that supports smart contracts using the POS, DPOS, and PBFT mechanisms, the accounting nodes in this round can package and package the transaction. Generate a new block, and send the header of the generated new block to other nodes for consensus. If other nodes receive the block and verify that there is no problem, they can append the new block to the end of the original block chain to complete the accounting process and reach a consensus; if the transaction is used to create a smart contract, then The deployment of the smart contract on the blockchain network is completed. If the transaction is used to call the smart contract, the call and execution of the smart contract are completed. In the process of verifying the new block or block header sent by the accounting node, other nodes may also execute the transaction in the block.

The execution process can generally be executed by a virtual machine. 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 publish and call smart contracts in Ethereum run on the EVM.

In this embodiment, the first blockchain node can execute the decrypted smart contract code in a Trusted Execution Environment (TEE). For example, as shown in Figure 4, the first blockchain node can be divided into a regular execution environment (on the left in the figure) and TEE, and transactions submitted by the client (as described above, transactions can have other sources; here, the client submits Take the transaction as an example to illustrate) First, enter the "transaction/query interface" in the regular execution environment for identification. Transactions that do not require privacy processing can be left in the regular execution environment for processing (here can be based on the user type of the transaction initiator , Transaction type, identifier contained in the exchange, etc. to identify whether there is a privacy processing requirement), and the transaction that has a privacy processing requirement is passed to the TEE for processing. TEE is isolated from the conventional execution environment. The transaction is encrypted before entering the TEE, and it is decrypted into the transaction content in the clear in the trusted execution environment, so that the transaction content in the clear text can be efficiently processed in the TEE and in the TEE under the premise of ensuring data security. The receipt data in plaintext is generated in.

TEE is a secure extension based on CPU hardware and a trusted execution environment 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 needs for TEE. The concept of TEE has also been rapidly developed and expanded. Compared with the originally proposed concept, TEE 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 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 requirements that cannot be met by only secure resource isolation, further data privacy protection are also 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 ciphertext to prevent malicious users from snooping. For example, Intel’s Software Protection Extensions (SGX) and other TEE technologies 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 through the CPU. The encryption engine MEE (Memory Encryption Engine) encrypts the data in it. The encrypted content in EPC will be decrypted into plaintext only 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 certification. Then, the data is used for calculation under the encryption protection of the CPU, and the result will be returned in cipher text. In this mode, you can use powerful computing power without worrying about data leakage.

As mentioned above, by executing the decrypted transaction content in the TEE, it can be ensured that the execution process is completed in a trusted environment to ensure that private information will not be leaked. When the above transaction with privacy processing requirements is used to create a smart contract, the transaction contains the code of the smart contract, and the first blockchain node can decrypt the transaction in the TEE to obtain the code of the smart contract contained therein, and then Execute this code in TEE. When the above transaction with privacy processing requirements is used to call a smart contract, the first blockchain node can execute the code in the TEE (if the called smart contract handles the encryption state, the smart contract needs to be executed in the TEE first. Decrypt to get the corresponding code). Specifically, the first blockchain node may use the newly added processor instructions in the CPU to allocate a part of the area EPC in the memory, and encrypt the above-mentioned plaintext code and store it in the EPC through the encryption engine MEE in the CPU. The encrypted content in EPC is decrypted into plain text after entering the CPU. In the CPU, perform operations on the plaintext code to complete the execution process. For example, in SGX technology, the plaintext code for executing smart contracts can load the EVM into the enclosure. During the remote certification process, the key management server can calculate the hash value of the local EVM code and compare it with the hash value of the EVM code loaded in the first blockchain node. The correct comparison result is a necessary condition for passing remote certification. , So as to complete the measurement of the code loaded in the SGX circle of the first blockchain node. After measurement, the correct EVM can execute the above smart contract code in SGX.

Step 304B: The first blockchain node determines the corresponding exposed field according to the transaction type of the transaction.

In an embodiment, the transaction may include a type field (such as a Type field), and the value of the type field is used to indicate the corresponding transaction type. Therefore, by reading the value of the type field in the exchange, the transaction type can be determined, such as the type of deposit certificate, the type of asset transfer (such as transfer), the type of contract creation, and the type of contract invocation. This manual does not limit this.

In an embodiment, different types of transactions may respectively have corresponding exposed fields. The exposed field is one or more fields specified in the receipt data. Under the premise that the receipt data needs to be stored in cipher text to protect privacy, it can be combined with the field indicated by the aforementioned exposure identifier, and the log corresponding to the special event function and the exposed field Selectively store the exposed fields marked by the exposed identifier in the log corresponding to the special event function in plain text, instead of storing all fields marked by the exposed identifier or all exposed fields in plain text , While meeting the privacy protection requirements, subsequent retrieval and other operations can be performed on the content of the receipt stored in plaintext.

In an embodiment, the mapping relationship between each transaction type and the exposed field may be predefined, and the mapping relationship may be recorded in the blockchain, so that the first blockchain node can obtain the predefined mapping relationship, And further determine the exposed fields in the receipt data according to the transaction type of the above-mentioned transaction and the mapping relationship. For example, the exposed field corresponding to the attestation type may include all fields except the above-mentioned From field, the exposed field corresponding to the asset transfer type may include the above-mentioned To field, and the exposed field corresponding to the contract creation type and contract invocation type may include the above-mentioned From field. All the fields except for the other transaction types will not be repeated here.

Among them, the above-mentioned mapping relationship can be specifically recorded in the system contract. The mapping relationship can also be recorded in the chain code of the blockchain network. By recording the mapping relationship in the system contract, it is convenient to update and upgrade the mapping relationship later, while the mapping relationship recorded in the chain code is relatively difficult to update and upgrade. The differences between the two will be described later, and I will not temporarily Repeat.

Step 308: The first blockchain node stores the receipt data, so that at least a part of the receipt content in the log corresponding to the special event function is stored in plain text, and the rest of the receipt data is stored in cipher text. The at least part of the receipt content includes an exposed field marked by the exposure identifier.

In the code of the smart contract, the exposed identifier can indicate one or more fields, and these fields have corresponding receipt content in the receipt data. Different types of transactions often have different privacy protection requirements, and the corresponding exposed fields can be allowed to be stored in plain text. After the special event function is executed, the receipt data contains a log corresponding to the special event function, which is actually part of the receipt content in the receipt data. In this manual, by comprehensively considering the exposure identifier, transaction type, and special event function, the cross content of the above three parts of receipt content can be filtered out, and the cross content can be stored in plain text. The rest of the receipt data is in cipher text. storage.

Since the exposed identifier is a global identifier defined in the programming language of the smart contract, it is difficult to modify the fields marked by the exposed identifier as long as the exposed identifier is written in the smart contract. The transaction type has nothing to do with the programming language and can be selected by the user according to the actual needs. At the same time, the definition of the special event function is not necessarily based on the programming language. For example, when recording the special event function based on the special event function list, even in the smart contract A certain event function included is originally a special event function. You can also update the original special event function to a normal event function by changing the list of special event functions, so as to prevent the log generated by the event function from being stored in plain text , Or update the original ordinary event function to a special event function, so that at least part of the content in the log generated by the event function is stored in plain text.

Take the above code example 2 as an example: assuming that the event currentPrice was not originally recorded in the special event function list, that is, the event currentPrice corresponds to a normal event function, then even if the exposed identifier plain is added to the smart contract code, the event currentPrice is generated All fields in the log (including exposed fields) are still stored in ciphertext. However, if the event currentPrice is added to the list of special event functions, then the exposed fields in the log corresponding to the event currentPrice can be stored in plain text without the need to adjust the code example 2; for example, when the From field and the To field To expose fields, the From field and To field in the log generated by the event currentPrice will be stored in plain text, while the remaining fields will be stored in cipher text.

It should be pointed out that: in the code example 2 above, by declaring "plain" at the front of the code, the fields marked by the exposed identifier "plain" are all fields in the receipt data, and these fields are contract-level fields , So that when the first blockchain node stores the receipt data, all the receipt contents corresponding to the contract-level field in the receipt data are allowed to be stored in plain text. Of course, if the From field is marked with the exposed identifier in Code Example 2, then the From field is the contract-level field mentioned above. When the From field is further an exposed field corresponding to the transaction type, the first blockchain node can be used When storing receipt data, all the receipt contents corresponding to the From field in the receipt data are allowed to be stored in plain text.

When the code of a smart contract contains multiple event functions, in the respective Logs fields generated by the multiple event functions, there may be exposed fields belonging to contract-level fields; further, the type of each event function can be identified It is a normal event function or a special event function, so that the exposed fields belonging to the contract-level fields in the logs generated by all special event functions are stored in plaintext. For example, a smart contract can include the following code example 3:

plain Contract Example{

Int price;

Int price1;

Event currentPrice1(int price);

Event currentPrice2(int price1);

…

In the above code example 3, similar to the code example 2, the exposed identifier "plain" is located at the forefront of the code of the smart contract, so that all fields in the receipt data are marked as contract-level fields; at the same time, in the smart contract Contains events currentPrice1 and event currentPrice2: Assuming that the From field is the exposed field corresponding to the transaction type, and the event currentPrice1 corresponds to the special event function defined in the special event function list, and the event currentPrice2 corresponds to the normal event function, then in the event currentPrice1 and event currentPrice2 In the generated logs Log1 and Log2, the From field contained in log Log1 is stored in plain text, and the From field contained in log Log2 is stored in cipher text; similarly, other fields in log Log1 that are exposed fields are also stored in plain text. Non-exposed fields are stored in cipher text, while all fields of log Log2 are stored in cipher text. Moreover, if the event currentPrice2 is updated to correspond to the special event function after updating the list of special event functions, all fields belonging to the exposed fields contained in the log Log2 will be stored in plain text, without the need to do anything to the smart contract code change.

For the aforementioned contract-level fields, the aforementioned type identifier can be used to indicate whether the event function included in the smart contract is a special event function. For example, the above code sample 3 can be adjusted to the following code sample 4:

plain Contract Example{

Int price;

Int price1;

Event currentPrice1expose(int price);

Event currentPrice2(int price1);

…

In the above code example 4, similar to the code example 2, the contract-level fields include all fields in the receipt data; at the same time, the smart contract contains the event currentPrice1 and the event currentPrice2: because the event currentPrice1 contains the above mentioned The type identifier expose causes the event currentPrice1 to be marked as corresponding to the special event function, while the event currentPrice2 does not contain the type identifier expose, so that the event currentPrice2 is marked as corresponding to the normal event function, then the event currentPrice1 and event currentPrice2 are generated respectively In the logs Log1 and Log2, all the exposed fields corresponding to the transaction type in the log Log1 are stored in plain text, and all the fields contained in the log Log2 are stored in cipher text.

Although the type identifier and the exposed identifier are similar, they are both global identifiers defined in the programming language of the smart contract, but the exposed identifier acts on the contract-level fields and the type identifier acts on the event function, so that by In conjunction with the type identifier, you only need to add a single exposure identifier to set the contract-level fields mentioned above, and then you can flexibly mark the event functions that you want to store the contract-level fields in plaintext, especially when smart contracts When there are a large number of event functions included in the event function and the number of fields involved in the event function is large, you only need to add a "plain" similar to the above. There is no need to implement settings for each event function separately, which can simplify the code logic , Prevent mislabeling or missing labels.

In addition to the contract-level fields, the fields marked by the exposure identifier may include: event-level fields corresponding to at least one event defined in the smart contract, so that the first blockchain node can determine the at least one event when storing the receipt data. A log generated by a special event function corresponding to an event, and the determined exposed fields belonging to the event-level field in the log are stored in plain text. In particular, when the smart contract contains multiple events, the above event-level fields can be set for at least some of the events, so that the exposed fields belonging to the event-level fields in the logs corresponding to these events are stored in plain text, and this part of the events Other fields in the corresponding log and the contents of receipts corresponding to other events are stored in cipher text. Taking the From field as an example, the above code example 4 can be adjusted to the following code example 5:

Contract Example{

int price;

int price1;

event currentPrice1("from",int price);

event currentPrice2(int price1);

…

In the above code example 5, although the event currentPrice1 does not add the exposed identifier "plain", it contains the content "from". The content "from" corresponds to the From field and is used to indicate the From field in the log generated by the event currentPrice1 It needs to be stored in plain text, so the content "from" not only belongs to the above exposed identifier, but also indicates the From field that needs to be stored in plain text. Moreover, since the content "from" is in the event currentPrice1, the From field is an event-level field, so that when the From field is an exposed field corresponding to the transaction type and the event currentPrice1 corresponds to a special event function, the log generated in the event currentPrice1 corresponds to In Logs, the From field will be stored in plain text, and other fields will be stored in cipher text. As for the other event currentPrice2 contained in code example 5, since no exposure identifier is added for the event currentPrice2, regardless of whether the event currentPrice2 corresponds to a special event function or a normal event function, the generated log Logs are in the form of ciphertext storage.

The above keyword "from" indicates that the From field is set as an event-level field; however, in other embodiments, the specific field may not be specified. For example, the above code sample 4 can be adjusted to the following code sample 6:

Contract Example{

int price;

int price1;

plain event currentPrice1(int price);

event currentPrice2(int price1);

…

In the above code example 6, by adding the exposure identifier "plain" before the event currentPrice1, all the fields in the log generated by the event currentPrice1 can be used as the aforementioned event-level fields, such as the aforementioned From field and To field. , Topic field, Log Data field, etc. Then, when the event currentPrice1 corresponds to a special event function, the log field that belongs to both the above event-level field and the exposed field corresponding to the transaction type can be determined from the log generated by the event currentPrice1, and stored in plain text; If the above-mentioned From field, To field, Topic field, Log Data field, etc. are all exposed fields, it is equivalent to storing all receipt content (such as the generated log) corresponding to the event currentPrice1 in plain text.

In the embodiment corresponding to the above code examples 5-6, that is, for the event-level field, it can be recognized whether the event function contained in the smart contract is a special event function by means of a special event function list or type identifier. Do not repeat them one by one.

This manual exposes the content of the receipt to a certain extent to realize the driver of the DAPP client or other function extensions. In addition, this manual comprehensively considers the fields indicated by the exposed identifier, the exposed fields corresponding to the transaction type, and the logs generated by the special event function, and can accurately select the fields for plaintext storage, that is, at the same time satisfying "matches to the fields indicated by the exposed identifiers" "," "matching transaction type" and "belonging to a log generated by a special event function", so as to meet the above-mentioned function expansion requirements while ensuring that most of the user privacy can be protected. In particular, when the first blockchain node recognizes the special event function based on the information recorded on the blockchain network (such as the list of special event functions), it can perform the "special event function" after the smart contract has been created. Update to adjust the storage method of receipt data, such as changing the original receipt content stored in plain text to cipher text storage, or changing the original receipt content stored in cipher text to plain text storage.

By running the program code of the blockchain (hereinafter referred to as the chain code) on the computing device (physical machine or virtual machine), the computing device can be configured as a blockchain node in the blockchain network, such as the first Blockchain nodes, etc. In other words, the first blockchain node runs the above chain code to realize the corresponding functional logic. Therefore, when the blockchain network is created, the receipt data storage logic related to the exposed identifier, transaction type, and event function described above can be written into the chain code, so that each blockchain node can implement the receipt Data storage logic; taking the first blockchain node as an example, the receipt data storage logic related to the exposure identifier, transaction type, and event function may include: transaction type recognition logic, event function recognition logic, and exposure-based The identifier stores the logic of the receipt content.

The identification logic of the transaction type is used to instruct the first blockchain node: to identify the type of transaction initiated by the transaction initiator. For example, according to the value of the type field contained in the exchange, determine the transaction type corresponding to the transaction. For details, please refer to the relevant description of identifying transaction types above, which will not be repeated here.

The identification logic of the event function is used to instruct the first blockchain node to identify the type of event function contained in the smart contract corresponding to the transaction. For example: according to the type identifier contained in the event function, or according to the list of special event functions recorded in the blockchain network. For details, please refer to the relevant description of identifying special event functions above, which will not be repeated here.

The logic of storing the content of the receipt based on the exposed identifier is used to instruct the first blockchain node: for the fields marked by the exposed identifier, the fields not marked by the exposed identifier, etc., how to store the corresponding receipt content. For example: for the identified special event function, the exposed field marked by the exposure identifier in the log generated by the special event function is stored in plain text, the rest is stored in cipher text, and the other receipt content in the receipt data All are stored in ciphertext form.

However, it is relatively difficult to upgrade the chain code, which makes the storage of receipt data using the chain code have the problems of low flexibility and insufficient scalability. In order to realize the function expansion of the chain code, as shown in Figure 5, a combination of chain code and system contract can be used: chain code is used to realize the basic functions of the blockchain network, and the function expansion during operation can be achieved through the system Realized by way of contract. Similar to the above-mentioned smart contract, the system contract includes code in the form of bytecode, for example, the first blockchain node can run the system contract code (for example, according to the unique corresponding address "0x53a98..." to read the system The code in the contract) to realize the functional supplement of the chain code. Correspondingly, the first blockchain node can read the code of the system contract, which defines the receipt data storage logic related to the exposure identifier, transaction type, and event function; then, the first blockchain node The code of the system contract can be executed, and based on the receipt data storage logic related to the exposure identifier, transaction type, and event function, at least part of the receipt content in the log corresponding to the special event function is stored in clear text. The remaining content of the data is stored in a ciphertext form, and the at least a part of the receipt content includes the exposed field indicated by the exposure identifier.

Different from the above-mentioned smart contracts issued by users to the blockchain, system contracts cannot be freely issued by users. The system contract read by the first blockchain node may include a preset system contract configured in the genesis block of the blockchain network; and, the administrator in the blockchain network (ie, the above-mentioned management user) may have The update authority of the system contract, so as to update the preset system contract such as the above, the system contract read by the first blockchain node may also include the corresponding updated system contract. Of course, the updated system contract can be obtained by the administrator after one update of the preset system contract; or, the updated system contract can be obtained by the administrator after multiple iterations of the preset system contract, such as the preset system contract Update the system contract 1, update the system contract 1 to obtain the system contract 2, update the system contract 2 to obtain the system contract 3. The system contract 1, the system contract 2, and the system contract 3 can all be regarded as the updated system contract, but the first Blockchain nodes usually follow the latest version of the system contract. For example, the first blockchain node will follow the code in system contract 3 instead of the code in system contract 1 or system contract 2.

In addition to the preset system contracts included in the genesis block, the administrator can also publish system contracts in subsequent blocks and update the published system contracts. In short, a certain degree of restrictions should be imposed on the issuance and update of system contracts through methods such as authority management to ensure that the functional logic of the blockchain network can operate normally and avoid unnecessary losses to any users.

The first blockchain node encrypts at least a part of the receipt content through the key. The encryption may be symmetric encryption or asymmetric encryption. If the first blockchain node uses symmetric encryption, that is, the symmetric key of the symmetric encryption algorithm is used to encrypt the content of the receipt, the client (or other object holding the key) can use the symmetric key pair of the symmetric encryption algorithm The encrypted receipt content is decrypted.

When the first blockchain node uses the symmetric key of the symmetric encryption algorithm to encrypt the content of the receipt, the symmetric key may be provided to the first blockchain node in advance by the client. Then, since only the client (actually the user corresponding to the logged-in account on the client) and the first blockchain node have the symmetric key, only the client can decrypt the corresponding encrypted receipt content, avoiding Irrelevant users and even criminals decrypt the encrypted receipt content.

For example, when the client initiates a transaction to the first blockchain node, the client can use the initial key of the symmetric encryption algorithm to encrypt the transaction content to obtain the transaction; accordingly, the first blockchain node can obtain The initial key is used to directly or indirectly encrypt the content of the receipt. For example, the initial key can be negotiated in advance by the client and the first blockchain node, or sent by the key management server to the client and the first blockchain node, or sent by the client to the first blockchain node. When the initial key is sent by the client to the first blockchain node, the client can encrypt the initial key with the public key of the asymmetric encryption algorithm, and then send the encrypted initial key to the first block The chain node, and the first blockchain node decrypts the encrypted initial key through the private key of the asymmetric encryption algorithm to obtain the initial key, which is the digital envelope encryption described above, which will not be repeated here.

The first blockchain node can use the aforementioned initial key to encrypt the content of the receipt. Different transactions can use the same initial key, so that all transactions submitted by the same user are encrypted with this initial key, or different transactions can use different initial keys. For example, the client can randomly generate an initial key for each transaction. Key to improve security.

The first blockchain node can generate a derived key according to the initial key and the impact factor, and encrypt the content of the receipt through the derived key. Compared with directly using the initial key for encryption, the derived key can increase the degree of randomness, thereby increasing the difficulty of being compromised and helping to optimize the security protection of data. The impact factor can be related to the transaction; for example, the impact factor can include the specified bits of the transaction hash value. For example, the first blockchain node can associate the initial key with the first 16 bits (or the first 32 bits, the last 16 bits) of the transaction hash value. Bits, last 32 bits, or other bits) are spliced, and the spliced string is hashed to generate a derived key.

The first blockchain node can also use an asymmetric encryption method, that is, use the public key of the asymmetric encryption algorithm to encrypt the content of the receipt, and accordingly, the client can use the private key of the asymmetric encryption algorithm to decrypt the encrypted The contents of the receipt. The key of an asymmetric encryption algorithm, for example, can be that the client generates a pair of public and private keys, and sends the public key to the first blockchain node in advance, so that the first blockchain node can use the receipt content Public key encryption.

The first blockchain node realizes the function by running the code used to realize the function. Therefore, for the functions that need to be implemented in the TEE, the relevant code also needs to be executed. For the code executed in the TEE, it needs to comply with the relevant specifications and requirements of the TEE; accordingly, for the code used to implement a certain function in the related technology, the code needs to be rewritten in combination with the specifications and requirements of the TEE. Large amount of development, and easy to produce loopholes (bugs) in the process of rewriting, affecting the reliability and stability of function implementation.

Therefore, the first blockchain node can execute the storage function code outside the TEE to store the receipt data generated in the TEE (including the receipt content in plain text that needs to be stored in plain text, and the receipt content in cipher text that needs to be stored in cipher text. ) Is stored in an external storage space outside the TEE, so that the storage function code can be the code used to implement the storage function in the related technology, and does not need to be rewritten in conjunction with the specifications and requirements of the TEE to achieve safe and reliable receipt data The storage of TEE can not only reduce the amount of related code development without affecting security and reliability, but also reduce TCB (Trusted Computing Base) by reducing the related code of TEE, making TEE technology and regional In the process of combining block chain technology, the additional security risks caused are in a controllable range.

In an embodiment, the first blockchain node may execute the write cache function code in the TEE to store the above-mentioned receipt data in the write cache in the TEE. For example, the write cache may correspond to the one shown in FIG. 2 "Cache". Further, the first blockchain node outputs the data in the write cache from the trusted execution environment to be stored in the external storage space. Among them, the write cache function code can be stored in the TEE in plain text, and the cache function code in the plain text can be directly executed in the TEE; or, the write cache function code can be stored outside the TEE in cipher text, such as the above External storage space (such as the "package + storage" shown in Figure 2, where "package" means that the first blockchain node packs the transaction into blocks outside the trusted execution environment), the ciphertext form The write cache function code is read into the TEE, decrypted into the plaintext code in the TEE, and the plaintext code is executed.

Write cache refers to a "buffer" mechanism provided to avoid "impact" to the external storage space when data is written to the external storage space. For example, the above-mentioned write cache can be implemented by using buffer; of course, the write cache can also be implemented by using cache, which is not limited in this specification. In fact, because the TEE is an isolated security environment and the external storage space is outside the TEE, the write cache mechanism can be used to write the data in the cache to the external storage space in batches, thereby reducing the gap between the TEE and the external storage space. The number of interactions increases the efficiency of data storage. At the same time, in the process of continuously executing each transaction, TEE may need to retrieve the generated data. If the data to be called happens to be in the write cache, the data can be read directly from the write cache. The interaction between the external storage space, on the other hand, eliminates the decryption process of the data read from the external storage space, thereby improving the data processing efficiency in the TEE.

Of course, the write cache can also be established outside the TEE. For example, the first blockchain node can execute the write cache function code outside the TEE, so as to store the above receipt data in the write cache outside the TEE, and further write The data in the cache is stored in an external storage space.

The following describes an embodiment of a receipt storage node combining code labeling and transaction and event types in this specification with reference to FIG. 6, including:

The receiving unit 61 receives an encrypted transaction corresponding to a smart contract, the code of the smart contract includes a field marked by an exposed identifier;

A decryption unit 62, decrypting the transaction in a trusted execution environment to obtain the smart contract, the smart contract including a special event function;

The execution unit 63 executes the smart contract in the trusted execution environment to obtain receipt data, where the receipt data includes a log corresponding to the special event function;

The determining unit 64 determines the corresponding exposed field according to the transaction type of the transaction;

The storage unit 65 stores the receipt data so that at least part of the receipt content in the log corresponding to the special event function is stored in plain text, and the rest of the receipt data is stored in cipher text, and the at least part of the receipt content Including the exposed field indicated by the exposed identifier.

Optionally, the smart contract corresponding to the transaction received by the first blockchain node includes:

Smart contracts written in high-level languages; or,

Smart contract in bytecode form.

Optionally, when the smart contract corresponding to the transaction received by the first blockchain node is a smart contract written in a high-level language, the node further includes:

The compiling unit 66 compiles the smart contract written in the high-level language through a compiler, and generates the smart contract in bytecode form for execution in the trusted execution environment.

Optionally, when the smart contract corresponding to the transaction received by the first blockchain node is a smart contract in the form of bytecode, the smart contract in the form of bytecode is a smart contract written in a high-level language by the client through a compiler It is obtained by compiling, and the smart contract written in the high-level language is written by the user on the client.

Optionally, the smart contract written in the high-level language and the smart contract in bytecode form have the same or corresponding exposure identifier.

The smart contract generated by the user on the first blockchain node; or,

The smart contract generated by the user on the client; or,

The smart contract in the transaction sent by the client through the second blockchain node.

Optionally, the fields marked by the exposure identifier include: contract-level fields; the storage unit 65 is specifically used for:

When storing the receipt data, the exposed fields belonging to the contract-level fields in the logs generated by all special event functions are stored in plain text.

Optionally, the field marked by the exposure identifier includes: an event-level field corresponding to at least one event defined in the smart contract; the storage unit 65 is specifically configured to:

When storing the receipt data, the log generated by the special event function corresponding to the at least one event is determined, and the exposed fields belonging to the event-level field in the determined log are stored in plain text.

Optionally, the transaction includes a type field, and the value of the type field is used to indicate the corresponding transaction type.

Optionally, the transaction type of the transaction includes: deposit certificate type, asset transfer type, contract creation type, contract call type.

Optionally, a predefined mapping relationship between the transaction type and the exposed field is stored in the blockchain, and the mapping relationship is used to determine the exposed field corresponding to the transaction type of the transaction.

Optionally, the event function in the smart contract includes a type identifier, and the type identifier is used to mark the event function as a special event function.

Optionally, when the event function included in the smart contract is in the special function list recorded on the blockchain, the event function included in the smart contract is determined to be a special event function.

Optionally, the storage unit 65 is specifically used for:

Reading the code of the system contract, the code of the system contract defines the receipt data storage logic related to the exposure identifier, transaction type and special event function;

The code of the system contract is executed to store at least part of the receipt content in the log corresponding to the special event function in plain text, and the rest of the receipt data in cipher text, and the at least part of the receipt content includes The exposed field indicated by the exposed identifier.

Optionally, the system contract includes: a preset system contract recorded in the genesis block, or an updated system contract corresponding to the preset system contract.

Optionally, the storage unit 65 is specifically used for:

The storage function code is executed outside the trusted execution environment to store the receipt data in an external storage space outside the trusted execution environment.

Optionally, the key used by the first blockchain node to encrypt the receipt data includes: a key of a symmetric encryption algorithm or a key of an asymmetric encryption algorithm.

Optionally, the key of the symmetric encryption algorithm includes an initial key provided by the client; or, the key of the symmetric encryption algorithm includes a derived key generated by the initial key and an influence factor.

Optionally, the transaction is encrypted by the initial key, and the initial key is encrypted by the public key of an asymmetric encryption algorithm; the decryption unit 62 is specifically configured to:

Decryption with the private key of the asymmetric encryption algorithm to obtain the initial key, and decrypt the transaction with the initial key to obtain the transaction content.

Optionally, the initial key is generated by the client; or, the initial key is sent to the client by the key management server.

Optionally, the impact factor is related to the transaction.

Optionally, the impact factor includes: a designated bit of the hash value of the transaction.

In the 1990s, the improvement of a technology can be clearly distinguished between hardware improvements (for example, improvements in circuit structures such as diodes, transistors, switches, etc.) or software improvements (improvements in method flow). However, with the development of technology, the improvement of many methods and procedures of today can be regarded as a direct improvement of the hardware circuit structure. Designers almost always get the corresponding hardware circuit structure by programming the improved method flow into the hardware circuit. Therefore, it cannot be said that the improvement of a method flow cannot be realized by hardware entity modules. For example, a programmable logic device (Programmable Logic Device, PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user's programming of the device. It is programmed by the designer to "integrate" a digital system on a PLD without requiring the chip manufacturer to design and manufacture a dedicated integrated circuit chip. Moreover, nowadays, instead of manually making integrated circuit chips, this kind of programming is mostly realized by "logic compiler" software, which is similar to the software compiler used in program development and writing. The original code must also be written in a specific programming language, which is called Hardware Description Language (HDL), and there is not only one type of HDL, but many types, 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), etc., currently most commonly used The ones are VHDL (Very-High-Speed Integrated Circuit Hardware Description Language) and Verilog. It should also be clear to those skilled in the art that only a little logic programming of the method flow in the above hardware description languages and programming into an integrated circuit can easily obtain the hardware circuit that implements the logic method flow.

The controller can be implemented in any suitable manner. For example, the controller can take the form of, for example, a microprocessor or a processor and a computer-readable medium storing computer-readable program codes (such as software or firmware) executable by the (micro)processor. , Logic gates, switches, application specific integrated circuits (ASICs), programmable logic controllers and embedded microcontrollers. Examples of controllers include but are not limited to the following microcontrollers: ARC625D, Atmel AT91SAM, Microchip PIC18F26K20 and Silicon Labs C8051F320, the memory controller can also be implemented as part of the memory control logic. Those skilled in the art also know that in addition to implementing the controller in a purely computer-readable program code manner, it is entirely possible to program the method steps to make the controller use logic gates, switches, application specific integrated circuits, programmable logic controllers and embedded The same function can be realized in the form of a microcontroller, etc. Therefore, such a controller can be regarded as a hardware component, and the devices included in it for implementing various functions can also be regarded as a structure within the hardware component. Or even, the device for realizing various functions can be regarded as both a software module for realizing the method and a structure within a hardware component.

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. Specifically, the computer may be, for example, a personal computer, a laptop computer, a cell phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or Any combination of these devices.

For the convenience of description, when describing the above device, the functions are divided into various units and described separately. Of course, when implementing this specification, the functions of each unit can be implemented in the same or multiple software and/or hardware.

Those skilled in the art should understand that the embodiments of the present invention may be provided as methods, systems, or computer program products. Therefore, the present invention may adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Moreover, the present invention may adopt the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program codes.

The present invention is described with reference to flowcharts and/or block diagrams of methods, devices (systems), and computer program products according to embodiments of the present invention. It should be understood that each process and/or block in the flowchart and/or block diagram, and the combination of processes and/or blocks in the flowchart and/or block diagram can be implemented by computer program instructions. These computer program instructions can be provided to the processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing equipment to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing equipment are generated It is a device that realizes the functions specified in one process or multiple processes in the flowchart and/or one block or multiple blocks in the block diagram.

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

These computer program instructions can also be stored in a computer-readable memory that can guide a computer or other programmable data processing equipment to work in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture including the instruction device. The device implements the functions specified in one process or multiple processes in the flowchart and/or one block or multiple blocks in the block diagram.

These computer program instructions can also be loaded on a computer or other programmable data processing equipment, so that a series of operation steps are executed on the computer or other programmable equipment to produce computer-implemented processing, so as to execute on the computer or other programmable equipment. The instructions provide steps for implementing functions specified in a flow or multiple flows in the flowchart and/or a block or multiple blocks in the block diagram. 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 a computer readable medium, random access memory (RAM) and/or non-volatile memory, such as read-only memory (ROM) or flash memory (flash RAM). Memory is an example of 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, magnetic 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 include elements inherent to this process, method, commodity, 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 to achieve the desired result. 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" 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 in one or more embodiments of this specification to describe various information, 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 certainty".

The above descriptions are only preferred embodiments of one or more embodiments of this specification, and are not used 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

A receipt storage method that combines code labeling with transaction and event types, including:

The first blockchain node receives an encrypted transaction corresponding to a smart contract, and the code of the smart contract includes a field marked by an exposed identifier;

The first blockchain node decrypts the transaction in a trusted execution environment to obtain the smart contract, and the smart contract includes a special event function;

The first blockchain node executes the smart contract in the trusted execution environment to obtain receipt data, where the receipt data includes a log corresponding to the special event function;

The first blockchain node determines the corresponding exposed field according to the transaction type of the transaction;

The first blockchain node stores the receipt data, so that at least part of the receipt content in the log corresponding to the special event function is stored in plain text, and the remaining content of the receipt data is stored in cipher text. The content of the receipt includes the exposed field indicated by the exposed identifier.
According to the method of claim 1, the smart contract corresponding to the transaction received by the first blockchain node includes:

Smart contracts written in high-level languages; or,

Smart contract in bytecode form.
The method according to claim 2, when the smart contract corresponding to the transaction received by the first blockchain node is a smart contract written in a high-level language, the method further comprises:

The first blockchain node compiles the smart contract written in the high-level language through the compiler, and generates the smart contract in the form of bytecode for execution in the trusted execution environment.
According to the method of claim 2, when the smart contract corresponding to the transaction received by the first blockchain node is a smart contract in the form of bytecode, the smart contract in the form of bytecode is checked by the client through a compiler. The smart contract written in the language is compiled and obtained, and the smart contract written in the high-level language is written by the user on the client.
According to the method of claim 2, the smart contract written in the high-level language and the smart contract in the bytecode form have the same or corresponding exposure identifier.
According to the method of claim 1, the smart contract corresponding to the transaction received by the first blockchain node includes:

The smart contract generated by the user on the first blockchain node; or,

The smart contract generated by the user on the client; or,

The smart contract in the transaction sent by the client through the second blockchain node.
The method according to claim 1, wherein the fields indicated by the exposure identifier include: contract-level fields; and storing the receipt data by the first blockchain node includes:

When storing the receipt data, the first blockchain node stores the exposed fields belonging to the contract-level fields in the logs generated by all special event functions in plain text.
The method according to claim 1, wherein the field indicated by the exposure identifier includes: an event-level field corresponding to at least one event defined in the smart contract; and storing the receipt data by the first blockchain node includes:

When storing the receipt data, the first blockchain node determines the log generated by the special event function corresponding to the at least one event, and stores the exposed fields belonging to the event-level field in the determined log in plain text .
The method according to claim 1, wherein the transaction includes a type field, and the value of the type field is used to indicate the corresponding transaction type.
The method according to claim 1, wherein the transaction type of the transaction includes: deposit certificate type, asset transfer type, contract creation type, contract call type.
The method according to claim 1, wherein a predefined mapping relationship between a transaction type and an exposed field is stored in the blockchain, and the mapping relationship is used to determine the exposed field corresponding to the transaction type of the transaction.
The method according to claim 1, wherein the event function in the smart contract includes a type identifier, and the type identifier is used to mark the event function as a special event function.
According to the method of claim 1, when the event function included in the smart contract is in a special function list recorded on the blockchain, the event function included in the smart contract is determined to be a special event function.
The method according to claim 1, wherein the first blockchain node storing the receipt data includes:

The first blockchain node reads the code of the system contract, and the code of the system contract defines the receipt data storage logic related to the exposure identifier, transaction type, and special event function;

The first blockchain node executes the code of the system contract to store at least a part of the receipt content in the log corresponding to the special event function in plain text, and the rest of the receipt data in cipher text, so The at least part of the receipt content includes an exposed field marked by the exposure identifier.
The method according to claim 14, wherein the system contract comprises: a preset system contract recorded in the genesis block, or an updated system contract corresponding to the preset system contract.
The method according to claim 1, wherein the first blockchain node storing the receipt data includes:

The first blockchain node executes the storage function code outside the trusted execution environment to store the receipt data in an external storage space outside the trusted execution environment.
According to the method of claim 1, the key used by the first blockchain node to encrypt the receipt data comprises: a key of a symmetric encryption algorithm or a key of an asymmetric encryption algorithm.
The method according to claim 17, wherein the key of the symmetric encryption algorithm comprises an initial key provided by the client; or, the key of the symmetric encryption algorithm comprises a derivative generated by the initial key and an impact factor Key.
The method according to claim 18, wherein the transaction is encrypted by the initial key, and the initial key is encrypted by the public key of an asymmetric encryption algorithm; the first blockchain node is in a trusted execution environment Decrypt the transaction, including:

The first blockchain node decrypts the private key of the asymmetric encryption algorithm to obtain the initial key, and uses the initial key to decrypt the transaction to obtain the transaction content.
According to the method of claim 18, the initial key is generated by a client; or, the initial key is sent to the client by a key management server.
The method of claim 18, wherein the impact factor is related to the transaction.
The method according to claim 21, wherein the impact factor comprises: a designated bit of a hash value of the transaction.
A receipt storage node that combines code labeling with transaction and event types, including:

The receiving unit receives an encrypted transaction corresponding to a smart contract, the code of the smart contract includes a field marked by an exposed identifier;

A decryption unit, decrypting the transaction in a trusted execution environment to obtain the smart contract, the smart contract including a special event function;

An execution unit to execute the smart contract in the trusted execution environment to obtain receipt data, where the receipt data includes a log corresponding to the special event function;

The determining unit determines the corresponding exposed field according to the transaction type of the transaction;

The storage unit stores the receipt data so that at least part of the receipt content in the log corresponding to the special event function is stored in plain text, and the rest of the receipt data is stored in cipher text, and the at least part of the receipt content includes The exposed field indicated by the exposed identifier.
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-22.
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-22.