WO2020233423A1 - Receipt storage method and node based on transaction type - Google Patents

Abstract

Provided are a receipt storage method and node based on a transaction type. The method may comprise: a first blockchain node receiving an encrypted transaction; the first blockchain node decrypting the transaction in a trusted execution environment, and executing the obtained transaction content to obtain receipt data; the first blockchain node determining, according to the transaction type of the transaction, an exposed field in the receipt data; and the first blockchain node storing the receipt data, wherein at least some of the receipt content corresponding to the exposed field is stored in the form of plaintext, and the remaining receipt content is stored in the form of ciphertext.

Description

Receipt storage method and node based on transaction type Technical field

One or more embodiments of this specification relate to the field of blockchain technology, and in particular to a method and node for storing receipts based on transaction 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 based on transaction type.

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 method for storing receipts based on transaction types is proposed, including:

The first blockchain node receives the encrypted transaction;

The first blockchain node decrypts the transaction in the trusted execution environment and executes the obtained transaction content to obtain receipt data;

The first blockchain node determines the exposed field in the receipt data 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 corresponding to the exposed field is stored in plain text, and the rest of the receipt content is stored in cipher text.

According to the second aspect of one or more embodiments of this specification, a receipt storage node based on transaction type is proposed, including:

The receiving unit receives encrypted transactions;

The decryption unit decrypts the transaction in a trusted execution environment to obtain transaction content;

The execution unit executes the transaction content in the trusted execution environment to obtain receipt data;

The determining unit determines the exposed fields in the receipt data according to the transaction type of the transaction;

The storage unit stores the receipt data so that at least part of the receipt content corresponding to the exposed field is stored in plain text, and the rest of the receipt content is stored in cipher text.

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 implementing privacy protection on blockchain nodes according to an exemplary embodiment.

Fig. 2 is a flowchart of a method for storing receipts based on transaction types according to an exemplary embodiment.

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

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

Fig. 5 is a 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 device based on transaction type according to 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.

Regardless of whether it is a public chain, a private chain, or a consortium chain, after the nodes in the blockchain network execute the received transaction, 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.

When a node executes each transaction contained in a block, the corresponding receipt data will be generated after each transaction is executed, and the node can organize the corresponding transactions contained in the block according to a predefined tree structure and processing logic The receipt data forms a receipt tree. The receipt tree is generated through organization, so that when querying or verifying receipt data, the corresponding query or verification efficiency can be greatly improved. For example, in Ethereum, the MPT (Merkle Patricia Tree) structure is used to organize the above-mentioned receipt tree. The leaf of the receipt tree is the hash value of the receipt data corresponding to each transaction contained in the block, and the receiptRoot is Root hashes generated sequentially upwards according to the hash value of the receipt data at the leaf. Of course, other types of tree structures can also be used in other blockchain networks.

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 (Trusted Execution Environment), for the purpose of privacy protection, the receipt data needs to be stored in cipher text.

For example, as shown in Figure 1, the first blockchain node includes the conventional environment on the left (on the left in the figure) and TEE. The transaction submitted by the client (or other sources) first enters the "transaction/query interface" in the conventional environment , And then pass the transaction to the TEE for processing. TEE is isolated from the normal environment. For example, when a transaction is encrypted, the transaction needs to be transferred to the TEE for decryption as the transaction content in clear text, 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 ciphertext. In this mode, you can use powerful computing power without worrying about data leakage.

In related technologies, all the contents of the receipt data generated in the TEE are treated as data requiring privacy protection and stored on the blockchain. 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, for different types of transactions, the privacy protection requirements for receipt data are not the same. For example, deposit certificate transactions focus on the privacy protection of the identity of the transaction initiator, transfer transactions focus on the privacy protection of the identities of both parties to the transfer, and transactions related to smart contracts focus on the privacy protection of the identity of the transaction initiator.

The following describes the implementation process of an embodiment of a method for storing receipts based on transaction types in this application with reference to FIG. 2:

In step 202, the first blockchain node receives the encrypted transaction.

In an embodiment, the user can directly generate a transaction on the first blockchain node; or, the user can generate a transaction on the client, and send the transaction to the first blockchain node through the client; or, the client The terminal can send the above transaction to the second blockchain node, and the second blockchain node sends the transaction to the first blockchain node.

The transactions in this manual can be used to implement relatively simple processing logic, such as similar to the deposit logic and transfer logic in related technologies, that is, the relevant transactions are deposit transactions, transfer transactions, etc. At this time, the above transaction may not be related to the smart contract.

The transactions in this specification can also be used to implement relatively complex processing logic, which can be implemented here with the help of the above-mentioned 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 3, after Bob sends a transaction containing the creation of a smart contract to the Ethereum network, the EVM of node 1 can execute the transaction and generate a corresponding contract instance. "0x6f8ae93..." in the figure 3 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 4, 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.

It can be seen that when a transaction is used to create a smart contract, the transaction content can include the code of the smart contract that needs to be created; when the transaction is used to call a smart contract, the transaction content can include the account address of the smart contract that is called, and the required input Methods and parameters, etc.

Step 204: The first blockchain node decrypts the transaction in the trusted execution environment and executes the obtained transaction content to obtain receipt data.

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 . The specific implementation process is similar to the above process, and will not be repeated here.

As mentioned above, the transaction received by the first blockchain node may be, for example, a transaction for creating and/or invoking a smart contract. For example, in Ethereum, after the first blockchain node receives the transaction to create and/or call the smart contract from the client, it 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 3-4) and the transaction nonce (nonce) as input, and is generated by an encryption algorithm, such as in Figure 3-4 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.

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 206: The first blockchain node determines the exposed field in the receipt data according to the transaction type of the transaction.

In an embodiment, the transaction may include a transaction type field (such as a TransType field), and the value of the transaction type field is used to indicate the corresponding transaction type. Therefore, by reading the value of the transaction 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, the content of the receipt corresponding to the exposed field is allowed to be stored in plain text for subsequent receipts stored in plain text. Content implementation search and other operations.

In an embodiment, the mapping relationship between each transaction type and the exposed field may be predefined, so that the first blockchain node can obtain the predefined mapping relationship, and further based on the transaction type of the transaction and the mapping relationship, Identify the exposed fields in the receipt data. 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.

It can be seen that under the premise of protecting user privacy, by identifying transaction types, different transaction types can have differentiated requirements for privacy protection, so that the receipt fields contained in receipt data can achieve differentiated storage operations, compared to All receipt data is completely stored in cipher text, which has relatively higher flexibility, and the receipt content stored in plain text can directly implement subsequent retrieval and other operations, thereby satisfying more abundant application scenarios, such as driving such as DAPP (Decentralized Application, distribution) Application) The client performs related processing operations and so on.

In an embodiment, the above-mentioned mapping relationship may be recorded in the system contract. If there is no upgrade requirement for the above mapping relationship, the mapping relationship can also be recorded in the chain code of the blockchain network.

Step 208: The first blockchain node stores the receipt data so that at least part of the receipt content corresponding to the exposed field is stored in plain text, and the rest of the receipt content is stored in cipher text.

In one embodiment, the first blockchain node reads the code of the system contract. The code of the system contract defines the receipt data storage logic related to the transaction type, that is, the exposed field corresponding to each transaction type (similar to The above-mentioned mapping relationship), the logic of implementing plaintext storage for exposed fields, the logic of implementing ciphertext storage for non-exposed fields, etc.; accordingly, the first blockchain node can execute the code of the system contract to correspond to the exposed fields At least part of the receipt content is stored in plain text, and the rest of the receipt content is stored in cipher text.

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 transaction type described above can be written into the chain code, so that each blockchain node can implement the receipt data storage logic; Take the blockchain node as an example. The receipt data storage logic is as described above: the receipt data storage logic can specifically define the exposed fields corresponding to each transaction type, so that the first blockchain node can determine according to the transaction type Which receipt content in the receipt data generated by the transaction needs to be stored in plain text, and which receipt content needs to be stored in cipher text.

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 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 address "0x53a98..." to read the system The code in the contract) to realize the functional supplement of the chain code.

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.

Therefore, the first blockchain node can read the code of the system contract, and the code of the system contract defines the receipt data storage logic related to the preset transaction type; then, the first blockchain node can execute the system contract Code to determine the corresponding exposed field according to the transaction type, and store the corresponding receipt content in the receipt data in plain text, and store the remaining receipt content in cipher text.

In an embodiment, the first blockchain node encrypts the content of the receipt (the content of the receipt corresponding to the non-exposed field, and may also include part of the content of the receipt corresponding to the exposed field) using a 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.

In an embodiment, when the first blockchain node encrypts the receipt content with a symmetric key of a symmetric encryption algorithm, 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.

In an embodiment, the first blockchain node may 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.

In an embodiment, the first blockchain node may 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 and 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.

In an embodiment, the first blockchain node may 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 may use the private key of the asymmetric encryption algorithm. The key decrypts the encrypted receipt content. 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. 1 "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 1, where "package" means that the first blockchain node packages the transaction into blocks outside of the trusted execution environment), the cipher text 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.

On the basis of the embodiment shown in Figure 2, this specification can further identify the exposed identifier contained in the code of the smart contract corresponding to the transaction, so as to determine the receipt according to the exposed field corresponding to the transaction type and the field marked by the exposed identifier. How the data is stored. Therefore, the above step 208 can be improved as: the first blockchain node stores the receipt data so that the exposed fields in the receipt data indicated by the exposure identifier are stored in plain text, and the remaining receipt fields are stored in cipher text. storage.

When writing the code of the smart contract, the user can add an exposed identifier to the code to indicate one or more fields, so as to express the following meaning in the code dimension of the smart contract: For the fields marked by the exposed identifier, they hope that the receipt The corresponding receipt content in the data is stored in plain text, and the receipt content corresponding to the remaining fields is stored in cipher text. Of course, whether to store the fields indicated by the exposed identifiers in plain text in the end also needs to be combined with the relevant information of the transaction types described below, which is not repeated 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. The meaning of the expression is: I hope to store the contents of the receipt corresponding to this part of the field in the receipt data in plain text, and Store the rest of the receipt content in cipher text. 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 indicate similar meanings.

The exposure identifier can be dedicated to indicating receipt fields that need to be stored in plain text. For example, the keyword plain can be used to characterize the exposure identifier. Then, for the fields 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), such as the Result field, Gas used field, and Logs field described above. , Output field, etc., or the From field, To field, Topic field, Log data field, etc. further included in the Logs field. For example, the code sample 1 above can be adjusted to the following code sample 2:

In the above code example 2, by adding the exposing identifier plain to the front of the smart contract code, after the smart contract code is executed, for the exposed fields corresponding to the transaction type of the smart contract to which the transaction belongs, the generated receipt data The contents of the receipt corresponding to the above exposed fields are all stored in plain text.

Of course, in other embodiments, the fields that need to be stored in plaintext can also be specified. For example, when annotating the From field with an exposed identifier, only the From field can be judged: if the From field is the exposed field corresponding to the transaction type of the transaction to which the smart contract belongs, then after the code of the smart contract is executed, it will be generated The receipt content corresponding to the From field in the receipt data is stored in plain text, and subsequent retrieval operations can be performed on the receipt content in the From field, such as counting the transaction volume initiated by an account, etc.; and before the From field All other fields are stored in cipher text.

It should be pointed out that in the above code example 2 and related embodiments, the fields (all fields or From fields) marked by the exposed identifier "plain" are contract-level fields, so that the first blockchain node is storing When receiving the receipt data, if the contract-level field is an exposed field, the first blockchain node will store all receipt contents corresponding to the contract-level field in the receipt data in plain text. In particular, when the code of a smart contract contains multiple events, the contract-level field can be applied to all events in the smart contract. Take the From field as an example: when the From field is a contract-level field and the exposed field corresponding to the transaction type , For multiple events to generate their corresponding Logs fields, the From field contained in each Logs field will be stored in plain text, without the need to add an exposure identifier for each event.

In addition to the contract-level fields, the fields indicated by the exposure identifier may include: event-level fields corresponding to at least one event defined in the smart contract, so that when the first blockchain node stores the receipt data, if the event-level field belongs to the transaction The exposed field corresponding to the type can determine the receipt content corresponding to the at least one event in the receipt data, and store the determined portion of the receipt content corresponding to the event-level field 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 part of the receipt content corresponding to these events that corresponds to the event-level field is stored in plain text, and this part The remaining part of the receipt content corresponding to the event and the receipt content corresponding to the remaining events are stored in cipher text. Taking the From field as an example, the above code example 1 can be adjusted to the following code example 3:

In the above code example 3, by adding the character from corresponding to the From field in the event function "event currentPrice(int price)" corresponding to the event currentPrice, and the exposure identifier used by the character from is different from the aforementioned plain, and The character from is modified by quotation marks. The quotation marks in code example 3 are equivalent to the aforementioned exposure identifier, and the From field is configured as an event-level field, so that when the From field belongs to the exposed field corresponding to the transaction type, in the event Corresponding to the generated Logs field, the From field will be stored in plain text. In addition to the above event currentPrice, if the code of the smart contract also contains another event, then the above character from will not affect the other event, and the receipt content corresponding to the other event will be stored in ciphertext unless there is a "From" added for this other event.

Or, you can adjust the above code example 1 to the following code example 4:

In the above code example 4, by adding the exposure identifier "plain" before the event function "event currentPrice(int price)" corresponding to the event currentPrice, it is different from the "from" added in code example 3, so that If the event-level field is not specified as the From field, then all the fields in the log generated by the event currentPrice can be used as the above-mentioned event-level fields, such as the aforementioned From field, To field, Topic field, Log Data field, etc., which is equivalent to changing The contents of all receipts corresponding to the event currentPrice are stored in plain text.

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.

Based on the embodiment shown in FIG. 2, this specification can further identify the user type of the transaction initiator, so as to determine the storage method of the receipt data according to the exposed fields corresponding to the transaction type and the user type of the transaction initiator at the same time. Therefore, the above step 208 can be improved to: the first blockchain node stores the receipt data, and when the transaction initiator belongs to the preset user type, the exposed field is stored in plain text, and the remaining receipt fields are stored in cipher text. When the transaction initiator does not belong to the preset user type, the receipt data is stored in cipher text. Under the premise of protecting user privacy, by identifying user types, different users can implement differentiated storage operations for the exposed fields in the generated receipt data according to the differentiated needs of different users for the degree of privacy protection, which has high flexibility Sex. For example, ordinary users have relatively lower requirements for privacy protection and higher requirements for triggering operations based on receipt data. For receipt data generated by transactions initiated by ordinary users, the contents of the receipt corresponding to the exposed fields can be stored in plain text. , In order to retrieve the contents of the receipt stored in plaintext and trigger relatively more types of associated operations. For another example, the privacy protection requirements of advanced users are relatively higher, and the requirements for triggering operations based on receipt data are relatively lower. For the receipt data generated by transactions initiated by advanced users, the content of the receipt corresponding to the exposed field can be ciphered Form storage to ensure that the receipt content in ciphertext form can be stored safely while supporting some types of associated operations. In summary, under the premise of protecting user privacy, by separately identifying transaction type and user type, even for the same type of transaction, it is possible to make receipts based on the differentiated needs of different types of users for privacy protection. The exposed fields contained in the data can achieve differentiated storage operations. Compared with all receipt data stored in ciphertext form, it has relatively higher flexibility, and the content of the receipt stored in plaintext can directly implement subsequent retrieval and other operations. So as to meet more abundant application scenarios.

In an embodiment, the user has a corresponding external account on the blockchain, and initiates transactions or performs other operations based on the external account. Then, the preset user type to which the transaction initiator belongs, that is, the preset user type to which the external account belongs. Therefore, the first blockchain node can determine the external account corresponding to the transaction initiator, and query the user type corresponding to the external account recorded on the blockchain as the user type to which the transaction initiator belongs.

In an embodiment, the external account may include a user type field (such as a UserType field) recorded on the blockchain, and the value of the user type field corresponds to the user type. For example, when the value of the user type field is 00, the user type is ordinary user, when the value of the user type field is 01, the user type is advanced user, and when the value of the user type field is 11, the user type is Manage users, etc. Therefore, the first blockchain node can determine the corresponding user type based on the value by reading the user type field of the external account mentioned above.

In one embodiment, when creating the above-mentioned external account, the user type can be configured to be associated with the external account, so that the association relationship between the user type and the external account is recorded in the blockchain, such as through the user type and The account address of the external account is used to establish the above-mentioned association relationship, so that the data structure of the external account does not need to be changed, that is, the external account does not need to include the above-mentioned user type field. Therefore, the first blockchain node can determine the above-mentioned preset user type corresponding to the external account by reading the association relationship recorded on the blockchain and based on the external account corresponding to the transaction initiator.

In an embodiment, the user type of the external account can be modified under certain conditions. For example, the management user may have a modification right item, so that the first blockchain node can change the user type corresponding to the above-mentioned external account according to the change request initiated by the management user. The management user can correspond to the external account preset in the genesis block with management authority, so that the management user can make type changes to other ordinary users, advanced users, etc., such as changing ordinary users to advanced users, and changing advanced users For ordinary users, etc.

On the basis of the embodiment shown in Figure 2, this specification can further identify the event functions contained in the smart contract, so as to determine the storage method of the receipt data according to the exposed fields corresponding to the transaction type and the special event functions contained in the smart contract at the same time . Therefore, the above step 208 can be improved as: the first blockchain node stores the receipt data, so that the exposed fields in the log corresponding to the special event function are stored in plain text, and the rest of the receipt data is stored in encrypted form. Document storage. Under the premise of protecting user privacy, by identifying transaction types, the exposed fields that can be stored in plaintext can be determined according to the differentiated needs of different types of transactions for privacy protection, and further based on the events contained in the smart contract called by the transaction Function, which reflects the differentiated requirements of different types of event functions for privacy protection in the storage process, and has high flexibility. For example, the exposed fields involved in the special event function are stored in plain text, while the non-exposed fields involved in the special event function and all receipt fields involved in the normal event function are stored in cipher text.

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 Logs need to store at least part of the log fields (such as the exposed fields described above) in plain text on the premise of meeting the privacy protection requirements, so that the content of this part of the log fields can be retrieved to drive related operations. Implement.

In an embodiment, the special event function may be a predefined global event function in the blockchain network. For example, in the chain code or system contract of the blockchain network, the event function belonging to the "special event function" can be recorded, for example, it can be recorded in the special event function list; accordingly, by combining the event function contained in the smart contract with By comparing the above special event function list, it can be determined 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 Solidity language as an example, the code example of the event function included in the smart contract is as follows:

Event buy_candy1 expose(who,candy_num);

Event buy_candy2(who,candy_num);

In the above code example, the smart contract defines 2 events: event buy_candy1 and event buy_candy2. By adding the type identifier "expose" to the event buy_candy1, the event buy_candy1 can be marked as the above special event function; correspondingly, since the event buy_candy2 does not contain the type identifier "expose", the event buy_candy2 is a normal event function Instead of the special event function mentioned above.

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.

On the basis of the embodiment shown in Figure 2, this specification can further identify the receipt content in the receipt data that meets the preset conditions, so as to determine the receipt according to the user type of the transaction initiator and the satisfaction of the receipt content to the preset conditions. How the data is stored. Therefore, the above step 208 can be improved as follows: the first blockchain node stores the receipt data, so that the exposed fields in the receipt data that meet the preset conditions are stored in plain text, and the remaining receipt fields are stored in cipher text.

By comparing the exposed fields in the receipt data with the preset conditions, the exposed fields that meet the preset conditions can be stored in plain text, while the exposed fields or other receipt fields that do not meet the preset conditions must be stored in cipher text. . The content of the preset condition may include at least one of the following: the corresponding receipt field contains the preset content, the value of the corresponding receipt field belongs to a preset numerical interval, and so on.

The preset content may include: one or more specified keywords. For example, the keywords may include predefined state variables, predefined event functions, information used to indicate the result of transaction execution, etc., so that when an exposed field contains When the state variable, event function, or transaction execution result is used as a keyword, it can be determined that the exposed field meets the preset conditions. Take the transaction execution result as an example, the transaction execution result can include: "success" means the transaction is successful, "fail" means the transaction failed; when the keyword is "success", the exposed fields containing "success" will be stored in plain text, and Exposed fields containing "fail" and other types of receipt fields are not allowed to be stored in plain text, ensuring that successful transactions will be viewed and subsequent operations will be triggered.

The preset content may include: preset values. For example, the preset value can be a numeric value, which can be compared with the value of a state variable, etc., to determine whether the value of the state variable meets expectations; for another example, the preset value can be composed of numeric values, letters, special symbols, etc. String, which can be compared with the account address of the transaction initiator, the account address of the transaction target, the content of the event function, etc. to identify the specific transaction initiator, specific transaction target or specific event function, etc. . Taking the default content as a string as an example, assuming that the string is the account address of the transaction target, the user can use the To field when the user initiates a transaction for a specific transaction target and the exposed field corresponding to the transaction type includes the To field. It is stored in plain text, and when a transaction is initiated for other transaction targets, the To field is not allowed to be stored in plain text to avoid privacy leakage.

The preset value range can indicate the privacy protection requirements of the relevant receipt fields. For example, in a transfer scenario, the preset value range can be a value range with a smaller value and a lower privacy protection requirement, so that even if the relevant receipt field is disclosed, it will not cause Serious user privacy leakage, but it can be used to automatically trigger related operations such as DAPP client, so as to achieve a certain balance between privacy protection and convenience. Therefore, when the value of the exposed field is within the preset numerical range, the exposed field can be stored in plain text.

In an embodiment, the preset condition may include a general condition corresponding to all receipt fields in the receipt data, that is, when any receipt field in the receipt data is identified as an exposed field, it is used for comparison with the preset condition. For example, when the preset condition is "Contains preset keywords", all the exposed fields in the receipt data can be compared with the keywords contained in the preset conditions to determine the exposed fields containing the keywords, as The exposed fields that meet the above preset conditions.

In an embodiment, the preset condition may include a dedicated condition corresponding to each receipt field in the receipt data, that is, each receipt field in the receipt data has a corresponding preset condition, so that each determined exposed field is Used to compare with the corresponding preset conditions. The preset conditions corresponding to different receipt fields are independent of each other, but may be the same or different. For example, the preset condition corresponding to the From field and the To field may be "whether the preset content is included", and the preset content may be a preset account address, indicating a transaction initiated by or directed to the account address. It is allowed to store the From field or To field in plain text (it can be stored in plain text when the From field or To field is an exposed field). For another example, the preset condition corresponding to the Topic field can be "whether it belongs to the preset value range", and the value of the state variable referenced by the related event can be recorded in the Topic field. For example, in a transfer scenario, it can include a value representing "transfer amount" State variable, indicating that the transfer amount is in the preset value range (usually the small value range corresponding to the smaller amount), the transfer amount is allowed to be stored in clear text (it can be stored in clear text when the Topic field is an exposed field) ).

In an embodiment, the preset conditions may be located in the transaction, so that the preset conditions adopted by different exchanges may be different to meet the differences in demand faced by different exchanges; of course, different transactions may also use the same preset conditions. The difference in the preset conditions can be expressed as: differences in at least one dimension in the content of the preset conditions, the receipt fields to which the preset conditions apply, and the processing logic for determining whether the exposed fields meet the preset conditions.

In one embodiment, the preset condition may be located in the smart contract called by the transaction, or the preset condition may be located in another smart contract called by the smart contract called by the transaction, so that the transaction can be selected by selecting the called smart contract to Determine whether to use the corresponding preset conditions. The smart contract can be pre-created by the transaction initiator or any other user; of course, if the smart contract has a corresponding calling condition, then the above-mentioned transaction can call the smart contract only when the calling condition is met. For example, the calling condition may include : The transaction initiator belongs to the preset whitelist, the transaction initiator does not belong to the preset blacklist or other conditions.

In an embodiment, the preset condition may be located in the system contract or chain code, so that the preset condition is a global condition applicable to all transactions on the blockchain, and is different from the foregoing transaction or the preset contained in the smart contract. Set conditions so that even if the smart contract invoked by the transaction or transaction does not contain preset conditions, the storage of the receipt field can be determined based on the preset conditions defined in the system contract or chain code and combined with the user type of the transaction initiator the way.

It should be pointed out that there is no contradiction between the preset conditions contained in the transaction or smart contract and the preset conditions contained in the chain code or system contract: the two can contain preset conditions of different dimensions, such as preset conditions. The applicable receipt fields are different; or, when there is a conflict between the preset conditions contained in the two, the preset conditions contained in the transaction or smart contract may be used by default, or the preset conditions contained in the chain code or system contract may be preferred. Set conditions, which depend on the predefined selection logic.

On the basis of the embodiment shown in Figure 2, this specification can further identify the exposed identifier contained in the smart contract code and the user type of the transaction initiator, thereby simultaneously according to the exposed fields corresponding to the transaction type and the fields indicated by the exposed identifier And the user type of the transaction initiator determines the storage method of the receipt data. Therefore, the above step 208 can be improved to: the first blockchain node stores the receipt data, and when the transaction initiator belongs to the preset user type, the exposed field in the receipt data marked by the exposure identifier is changed to Stored in plain text, and the rest of the receipt fields are stored in cipher text.

The foregoing code example can be improved based on the user type of the transaction initiator. In the code example 2 above, by adding the exposed identifier "plain" to the front of the smart contract code, all fields in the receipt data are allowed to be stored in plain text. Therefore, if the transaction initiator belongs to the preset user type, Then for the exposed fields corresponding to the transaction type of the transaction to which the smart contract belongs, after the code of the smart contract is executed, the corresponding receipt content in the generated receipt data will be stored in plain text, and subsequent retrieval operations can be performed on the receipt content ; For example, when the From field belongs to the above-mentioned exposed field, the From field can be used to count the transaction volume initiated by a certain account after being stored in plain text.

The above-mentioned exposure identifier plain corresponds to all the fields in the receipt data; in other embodiments, the fields that need to be stored in plain text can also be specified. For example, when annotating the From field with an exposed identifier, only the From field needs to be judged: when the From field is the above-mentioned exposed field, when the transaction initiator belongs to the preset user type, for the smart contract The receipt data generated after the code is executed can store the contents of the receipt corresponding to the From field in plain text, and the contents of other receipts are stored in cipher text.

It should be pointed out that in the above code example 2 and related embodiments, the fields (all fields or From fields) marked by the exposed identifier "plain" are contract-level fields, so that the first blockchain node is storing When receiving the receipt data, if the transaction initiator belongs to the preset user type and the From field is an exposed field, the first blockchain node will store all the receipt contents corresponding to the contract-level field in the receipt data in plain text. In particular, when the code of a smart contract contains multiple events, the contract-level field can be applied to all events in the smart contract. Take the From field as an example: when the transaction initiator belongs to the preset user type and the From field is the transaction type When corresponding exposed fields are generated for multiple events, the corresponding Logs fields are generated separately, and the From field contained in each Logs field will be stored in plain text, without the need to add an exposure identifier for each event.

In addition to the contract-level fields, the fields indicated by the exposure identifier may include: event-level fields corresponding to at least one event defined in the smart contract, so that when the first blockchain node stores the receipt data, if the transaction initiator belongs to the pre- Assuming that the user type and the event-level field belong to the exposed field corresponding to the transaction type, the receipt content corresponding to the at least one event in the receipt data can be determined, and the part of the determined receipt content corresponding to the above-mentioned event-level field can be in plaintext form storage. 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 part of the receipt content corresponding to these events that corresponds to the event-level field is stored in plain text, and this part The remaining part of the receipt content corresponding to the event and the receipt content corresponding to the remaining events are stored in cipher text. Take the From field as an example. In the above code example 3, the character from corresponding to the From field is added to the event function "event currentPrice(int price)" corresponding to the event currentPrice, and the exposed identifier used by the character from is different For the aforementioned plain, the character from is modified by quotation marks. The quotation marks in code example 3 are equivalent to the aforementioned exposed identifier, so that the From field is marked as an event-level field. Therefore, when the transaction initiator belongs to the default user When the type and the From field belongs to the exposed field corresponding to the transaction type, the From field will be stored in plain text in the Logs field corresponding to the event. In addition to the aforementioned event currentPrice, if the code of the smart contract also contains another event, the aforementioned event-level field will not affect the other event, and the content of the receipt corresponding to the other event will be stored in ciphertext. In the above code example 4, by adding the exposure identifier "plain" before the event function "event currentPrice(int price)" corresponding to the event currentPrice, the event-level fields include all the fields in the log Logs corresponding to the event currentPrice For example, the aforementioned From field, To field, Topic field, Log Data field, etc., when the transaction initiator belongs to the preset user type, the exposed fields in these fields can be determined according to the transaction type, and the determined exposed fields are Stored in clear text.

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. Therefore, by combining the consideration of user type and transaction type, it is possible to more accurately select the fields stored in plain text based on the user type of the transaction initiator and the exposed fields corresponding to the transaction type, rather than just based on the exposed identifier. Determined, so that when different users call the same smart contract or call the same smart contract through different types of transactions, the fields stored in plaintext are matched to the user type and transaction type, so that the storage method of receipt data can meet the actual needs in different situations , Can take into account privacy protection and function expansion.

On the basis of the embodiment shown in Figure 2, this specification can further identify the exposure identifier contained in the code of the smart contract and the event function contained in the smart contract, so that at the same time, according to the exposed field corresponding to the transaction type, the exposure identifier marked Fields and special event functions included in the smart contract determine how to store receipt data. Therefore, the above step 208 can be improved as: 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 plaintext, and the rest of the receipt data It is stored in a ciphertext form, and the at least a part of the receipt content includes an exposed field indicated by the exposure 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.

The aforementioned code example can be improved based on the event function contained in the smart contract. 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. By further combining dimensions such as transaction types and event functions, there may be differences in storage solutions for receipt data.

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 5:

plain Contract Example{

int price;

int price1;

event currentPrice1(int price);

event currentPrice2(int price1);

…

In the above code example 5, 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, and all fields of log Log2 are stored in cipher text. Moreover, if the event currentPrice2 is updated to correspond to the special event function by updating the list of special event functions, all the fields that belong 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 5 can be adjusted to the following code sample 6:

plain Contract Example{

int price;

int price1;

event currentPrice1 expose(int price);

event currentPrice2(int price1);

…

In the above code example 6, 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 6 can be adjusted to the following code example 7:

Contract Example{

int price;

int price1;

event currentPrice1("from",int price);

event currentPrice2(int price1);

…

In the above code example 7, 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 7, 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 ciphertext form 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 example 6 can be adjusted to the following code example 8:

Contract Example{

int price;

int price1;

plain event currentPrice1(int price);

event currentPrice2(int price1);

…

In the above code example 8, 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 7-8, that is, for event-level fields, whether the event function contained in the smart contract is a special event function can be identified by means of a special event function list or type identifier. Do not repeat them one by one.

On the basis of the embodiment shown in Figure 2, this specification can further identify the exposure identifier contained in the smart contract code and the receipt content in the receipt data that meets the preset conditions, thereby simultaneously according to the exposure field and exposure identifier corresponding to the transaction type The fields marked by the symbol and the content of the receipt meet the preset conditions and determine the storage method of the receipt data. Therefore, the above step 208 can be improved to: the first blockchain node stores the receipt data, so that the exposed fields in the receipt data that are marked by the exposure identifier and meet the preset conditions are stored in plain text, and the remaining receipts The fields are stored in cipher text.

The foregoing code example can be improved based on the receipt content that meets the preset conditions in the receipt data. In the above code example 2, by adding the exposing identifier plain to the front of the smart contract code, after the smart contract code is executed, for the exposed fields corresponding to the transaction type of the smart contract to which the transaction belongs, the generated receipt data The contents of the receipt corresponding to the above exposed fields and meeting the preset conditions are all stored in plain text.

Of course, in other embodiments, the fields that need to be stored in plaintext can also be specified. For example, when annotating the From field with an exposed identifier, only the From field can be judged: if the From field is the exposed field corresponding to the transaction type of the transaction to which the smart contract belongs, then after the code of the smart contract is executed, it will be generated The content of the receipt corresponding to the From field that meets the preset conditions in the receipt data is stored in plain text, and subsequent retrieval operations can be performed on the content of the receipt in the From field stored in plain text, for example, the transaction volume initiated by a certain account can be counted And so on; except for the other fields before the From field, they are all stored in cipher text.

It should be pointed out that in the above code example 2 and related embodiments, the fields (all fields or From fields) marked by the exposed identifier "plain" are contract-level fields, so that the first blockchain node is storing When receiving the receipt data, if the contract-level field is an exposed field, the first blockchain node will store all the receipt contents in the receipt data that correspond to the contract-level field and meet the preset conditions in plain text. In particular, when the code of a smart contract contains multiple events, the contract-level field can be applied to all events in the smart contract. Take the From field as an example: when the From field is a contract-level field and the exposed field corresponding to the transaction type For multiple events to generate their corresponding Logs fields, the From field contained in each Logs field can be compared with preset conditions, so that the From field that meets the preset conditions is stored in plain text without Add an exposure identifier for each event.

In addition to the contract-level fields, the fields indicated by the exposure identifier may include: event-level fields corresponding to at least one event defined in the smart contract, so that when the first blockchain node stores the receipt data, if the event-level field belongs to the transaction The exposed field corresponding to the type can determine the receipt content corresponding to the at least one event in the receipt data, and store the determined part of the receipt content corresponding to the event-level field and meeting preset conditions 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 part of the receipt content corresponding to these events that corresponds to the event-level field and meets the preset conditions is in plain text Store, and the remaining part of the receipt content corresponding to this part of the event and the receipt content corresponding to the remaining events are stored in cipher text. Take the From field as an example. In the above code example 3, the character from corresponding to the From field is added to the event function "event currentPrice(int price)" corresponding to the event currentPrice, and the exposed identifier used by the character from is different For the aforementioned plain, the character from is modified by quotation marks. The quotation marks in code example 3 are equivalent to the aforementioned exposure identifier, and the From field is configured as an event-level field, so that when the From field belongs to the exposure corresponding to the transaction type In the Logs field corresponding to the event, the From field can be stored in plain text when the preset conditions are met, otherwise the From field will still be stored in cipher text. In addition to the above event currentPrice, if the code of the smart contract also contains another event, then the above “from” will not affect the other event, and the receipt content corresponding to the other event will be stored in ciphertext unless it exists "From" added for this other event. In the above code example 4, the exposure identifier "plain" is added before the event function "event currentPrice(int price)" corresponding to the event currentPrice, which is different from the "from" added in code example 3, so that It is not specified that the event-level field is the From field, so all fields in the log generated by the event currentPrice can be used as the above-mentioned event-level fields, such as the aforementioned From field, To field, Topic field, Log Data field, etc. Are used to compare with preset conditions, so that fields that meet the preset conditions are stored in plain text, and fields that do not meet the preset conditions are stored in cipher text; if the aforementioned From field, To field, Topic field, Log If the Data field meets the preset conditions, these fields are stored in plain text, which is equivalent to storing all the contents of the receipt corresponding to the event currentPrice in plain text.

On the basis of the embodiment shown in Figure 2, this specification can further identify the user type of the transaction initiator and the event function contained in the smart contract, thereby simultaneously according to the exposed fields corresponding to the transaction type, the user type of the transaction initiator, and the smart contract The special event function included determines the storage method of the receipt data. Therefore, the above step 208 can be improved as: the first blockchain node stores the receipt data, and when the transaction initiator belongs to the preset user type, the exposed field in the log corresponding to the special event function is made in plain text The remaining content of the receipt data is stored in cipher text. Under the premise of protecting user privacy, by identifying transaction types, the exposed fields that allow plaintext storage can be determined according to the differentiated needs of different types of transactions for privacy protection; further, the needs of different types of users for privacy protection It is not the same. For example, when the transaction initiator belongs to the preset user type, it is allowed to trigger the DAPP client to implement related follow-up operations by exposing part of the receipt content to improve convenience, while other types of users may not be allowed to expose private information; Furthermore, even for transaction initiators with preset user types, there are still differentiated privacy protection requirements in different scenarios, which can be reflected in the storage process according to the type of event function contained in the smart contract called by the transaction Different types of event functions have differentiated requirements for privacy protection. For example, the exposed fields involved in special event functions are stored in plain text, while the non-exposed fields involved in special event functions and all receipt fields involved in common event functions are all stored in Stored in ciphertext form, with high flexibility.

On the basis of the embodiment shown in Figure 2, this specification can further identify the user type of the transaction initiator and the receipt content in the receipt data that meets the preset conditions, thereby simultaneously according to the exposed fields corresponding to the transaction type and the user type of the transaction initiator And the content of the receipt to meet the preset conditions, determine the storage method of the receipt data. Therefore, the above step 208 can be improved as follows: the first blockchain node stores the receipt data, and when the transaction initiator belongs to the preset user type, the exposed fields in the receipt data that meet the preset conditions are stored in plain text, The remaining receipt fields are stored in cipher text. Under the premise of protecting user privacy, by identifying transaction types, the exposed fields that allow plaintext storage can be determined according to the differentiated needs of different types of transactions for privacy protection; further, the needs of different types of users for privacy protection It is not the same. For example, when the transaction initiator belongs to the preset user type, it is allowed to trigger the DAPP client to implement related follow-up operations by exposing part of the receipt content to improve convenience, while other types of users may not be allowed to expose private information; Furthermore, even for the transaction initiator of the preset user type, there are still differentiated privacy protection requirements in different scenarios. The privacy protection requirements can be reflected in the storage process according to the satisfaction of the preset conditions by the exposed fields. Differentiated requirements and processing for protection, for example: By comparing the exposed fields in the receipt data with preset conditions, the exposed fields that meet the preset conditions can be stored in plain text, and the exposed fields that do not meet the preset conditions or other The receipt field must be stored in ciphertext.

On the basis of the embodiment shown in Figure 2, this specification can further identify the event function contained in the smart contract and the receipt content in the receipt data that meets the preset conditions, so as to at the same time according to the exposed fields corresponding to the transaction type and the content contained in the smart contract. The special event function and the content of the receipt satisfy the preset conditions and determine the storage method of the receipt data. Therefore, the above step 208 can be improved as: the first blockchain node stores the receipt data, so that the exposed fields in the log corresponding to the special event function that meet the preset conditions are stored in plaintext, and the receipt data The rest of the content is stored in cipher text. Under the premise of protecting user privacy, by identifying transaction types, the exposed fields allowed to be stored in plaintext can be determined according to the differentiated requirements of different types of transactions for privacy protection; further, because different event functions often involve different information , So that different event functions correspond to different privacy protection requirements. For example, the privacy protection requirements of event functions related to the transfer amount are relatively high, and the privacy protection requirements of event functions related to evidence are relatively low (here only for example ; In fact, when the transfer amount is low, the privacy protection requirement of the related event function may also be relatively low, and when the deposit content is more important, the privacy protection requirement of the related event function may also be relatively high), therefore The event function with relatively low privacy protection requirements can be configured as the above special event function, and when the above exposed field is included in the log generated by the special event function, the receipt content corresponding to the exposed field is allowed to be exposed; furthermore, even For the exposed fields in the logs generated by the special event function, there are still differentiated privacy protection requirements in different scenarios. The difference in privacy protection can be reflected in the storage process according to the satisfaction of the preset conditions by the exposed fields Modification requirements and processing: By comparing the exposed fields in the receipt data with preset conditions, the exposed fields that meet the preset conditions can be stored in plaintext, while the exposed fields or other receipt fields that do not meet the preset conditions are inevitable Stored in cipher text. For example, assuming that a special event function involves a deposit operation, when the log generated by the special event function contains the above-mentioned exposed fields, and the deposit content in the exposed field contains keywords related to preset conditions, the exposed field can be Store in plain text, otherwise store in cipher text.

On the basis of the embodiment shown in Figure 2, this specification can further identify the user type of the transaction initiator, the event function contained in the smart contract, and the receipt content that meets the preset conditions in the receipt data, thereby simultaneously revealing the corresponding exposure according to the transaction type Fields, the user type of the transaction initiator, the special event functions contained in the smart contract, and the satisfaction of the receipt content to the preset conditions determine the storage method of the receipt data. Therefore, the above step 208 can be improved to: the first blockchain node stores the receipt data, and when the transaction initiator belongs to the preset user type, the log corresponding to the special event function is exposed to the preset condition. The fields are stored in plain text, and the rest of the receipt data is stored in cipher text. Under the premise of protecting user privacy, by identifying transaction types, the exposed fields allowed to be stored in plaintext can be determined according to the differentiated requirements of different types of transactions for privacy protection; further, because different event functions often involve different information , So that different event functions correspond to different privacy protection requirements. For example, the privacy protection requirements of event functions related to the transfer amount are relatively high, and the privacy protection requirements of event functions related to evidence are relatively low (here only for example ; In fact, when the transfer amount is low, the privacy protection requirement of the related event function may also be relatively low, and when the deposit content is more important, the privacy protection requirement of the related event function may also be relatively high), therefore The event function with relatively low privacy protection requirements can be configured as the above special event function, and when the above exposed field is included in the log generated by the special event function, the receipt content corresponding to the exposed field is allowed to be exposed; furthermore, even For the exposed fields in the logs generated by the special event function, there are still differentiated privacy protection requirements in different scenarios. The difference in privacy protection can be reflected in the storage process according to the satisfaction of the preset conditions by the exposed fields Modification requirements and processing: By comparing the exposed fields in the receipt data with preset conditions, the exposed fields that meet the preset conditions can be stored in plaintext, while the exposed fields or other receipt fields that do not meet the preset conditions are inevitable Stored in cipher text. For example, assuming that a special event function involves a deposit operation, when the log generated by the special event function contains the above-mentioned exposed fields, and the deposit content in the exposed field contains keywords related to preset conditions, the exposed field can be Store in plain text, otherwise store in cipher text.

On the basis of the embodiment shown in Figure 2, this specification can further identify the exposure identifier contained in the code of the smart contract, the user type of the transaction initiator, and the event function contained in the smart contract, thereby simultaneously corresponding exposure according to the transaction type The fields, the fields indicated by the exposed identifier, the user type of the transaction initiator, and the special event function contained in the smart contract determine the storage method of the receipt data. Therefore, the above step 208 can be improved to: the first blockchain node stores the receipt data so that when the transaction initiator belongs to the preset user type, at least part of the receipt content in the log corresponding to the special event function It is stored in plain text, and the rest of the receipt data is stored in cipher text, and the at least a part of the receipt content matches the exposed field indicated by the exposure identifier. 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 user type of the transaction initiator, the exposed field corresponding to the transaction type, the field indicated by the exposure identifier, and the log generated by the special event function, and can accurately select the receipt content for plaintext storage, that is, simultaneously satisfy Receipt content of "transaction initiator belongs to the preset user type", "belongs to the exposed field corresponding to the transaction type", "matches the field indicated by the exposure identifier" and "belongs to the log generated by the special event function", thus satisfying the above functions While expanding the demand, ensure that the privacy of most users 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.

The foregoing code example can be improved based on the user type of the transaction initiator and the event function contained in the smart contract. In the code example 2 above, the exposed identifier plain is added to the front of the smart contract code, so that after the smart contract code is executed, when the transaction initiator belongs to the preset user type, the receipt data is generated by the special event function The log of the smart contract allows the contents of the receipt corresponding to the exposed field corresponding to the transaction type of the transaction to which the smart contract belongs to be stored in clear text. For example, when the From field in the log is an exposed field and the To field is not an exposed field, the receipt data can be stored The From field of all logs in the log is stored in plain text, and the To field is stored in cipher text. Then, subsequent retrieval operations can be performed on the receipt content in the From field, for example, the transaction volume initiated by an account can be counted.

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 user type depends on the transaction initiator and has nothing to do with the programming language, so that even when different transaction initiators call the same smart contract, the storage method (ciphertext or plaintext) of the receipt data may be different. The transaction type can also be selected by the transaction initiator according to demand to indicate the actual needs of the transaction initiator. At the same time, the definition of special event functions is not necessarily based on programming languages. For example, when recording special event functions based on a list of special event functions, even if an event function included in the smart contract originally belongs to a special event function, it can be To change the list of special event functions, update the original special event function to a normal event function, so as to avoid storing the log generated by the event function in clear text, or update the original normal 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. Therefore, by invoking smart contracts by different users, or initiating different types of transactions, or adjusting the types of event functions contained in smart contracts, you can escape the restriction of exposing identifiers and adjust the content of receipts that require plaintext or ciphertext storage.

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 exposure identifier plain is added to the smart contract code and the transaction initiator It belongs to a preset user type, and all fields (including exposed fields) in the log generated by the event currentPrice are still stored in cipher text. However, if the event currentPrice is added to the list of special event functions, the code sample 2 does not need to be adjusted, and when the transaction initiator belongs to the preset user type, the exposed fields in the log corresponding to the event currentPrice can be made clear storage.

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 transaction initiator belongs to the preset user type and the contract-level field is an exposed field, the content of the receipt corresponding to the contract-level field in the log generated by the event currentPrice is 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, it can be preset at the transaction initiator In the case of the user type, when the first blockchain node stores the receipt data, all the receipt contents corresponding to the From field in the receipt data are allowed to be stored in plain text.

In particular, when the code of the smart contract contains multiple event functions, in the respective Logs fields generated by the multiple event functions, there may be the receipt content corresponding to the contract-level field; further, the transaction can be identified by The user type to which the initiator belongs, the exposed field corresponding to the transaction type of the transaction, and the type of each event function are ordinary event functions or special event functions, so when the transaction initiator belongs to the preset user type and the contract-level field belongs to the exposed field , Store the receipt content corresponding to the contract-level field in the log generated by all special event functions in plain text. For example, a smart contract can include the following code example 9:

plain Contract Example{

int price;

int price1;

event currentPrice1(int price);

event currentPrice2(int price1);

…

In the above code example 9, similar to the code example 2, the exposed identifier "plain" is located at the forefront of the smart contract code, so that all fields in the receipt data are marked as contract-level fields; at the same time, in the smart contract Contains the event currentPrice1 and the event currentPrice2: assuming that 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 the transaction initiator belongs to the preset user type and the From field is an exposed field. Below, in the logs Log1 and Log2 generated by the event currentPrice1 and event currentPrice2, the From field contained in the log Log1 is stored in plain text, and the From field contained in the log Log2 is stored in cipher text; similarly, the log Log1 belongs to the exposed field. Other fields are also stored in plain text, non-exposed fields are stored in cipher text, and all fields of log Log2 are stored in cipher text. Moreover, if the event currentPrice2 is updated to correspond to the special event function by updating the list of special event functions, all the fields that belong 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 9 can be adjusted to the following code sample 10:

plain Contract Example{

int price;

int price1;

event currentPrice1 expose(int price);

event currentPrice2(int price1);

…

In the above code example 10, similar to the code example 2, the contract-level fields include all the 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 aforementioned The type identifier expose, so that the event currentPrice1 is marked as corresponding to the special event function, and 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 transaction initiator belongs to the default user In the case of type, in the logs Log1 and Log2 respectively generated by the event currentPrice1 and the event currentPrice2, 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.

In addition to the contract-level fields, the fields indicated by the exposure identifier may include: event-level fields corresponding to at least one event defined in the smart contract, so that the transaction initiator belongs to the preset user type and the event-level field belongs to the exposed field In this case, the first blockchain node stores the part of the receipt content generated by the special event function that corresponds to the event-level field 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 contents of the receipts corresponding to the above-mentioned event-level fields in the logs generated by these events are stored in plain text, and this The content of the remaining receipts in the log generated by some events and the content of the receipts corresponding to the remaining events are stored in ciphertext. Taking the From field as an example, the above code sample 10 can be adjusted to the following code sample 11:

Contract Example{

int price;

int price1;

event currentPrice1("from",int price);

event currentPrice2(int price1);

…

In the code example 11 above, 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 transaction initiator belongs to the preset user type and the From field is an exposed field, when the event currentPrice1 corresponds to a special event function In the log Logs generated corresponding to the event currentPrice1, 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 11, 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 ciphertext form storage. In the embodiment corresponding to this code example 11, that is, for event-level fields, it is possible to identify whether the event functions contained in the smart contract are special event functions by means of a special event function list or type identifier. Repeat.

On the basis of the embodiment shown in Figure 2, this specification can further identify the exposure identifier contained in the smart contract code, the user type of the transaction initiator, and the receipt content that meets the preset conditions in the receipt data, thereby simultaneously according to the transaction type The corresponding exposure field, the field indicated by the exposure identifier, the user type of the transaction initiator, and the content of the receipt meet the preset conditions, and the storage method of the receipt data is determined. Therefore, the above step 208 can be improved to: the first blockchain node stores the receipt data, and when the transaction initiator belongs to the preset user type, the receipt data is marked by the exposure identifier and meets the preset requirements. The exposed fields of the conditions are stored in plain text, and the remaining receipt fields are stored in cipher text. 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. Therefore, by combining the consideration of user types, transaction types, and preset conditions, it is possible to more accurately select and use plain text based on the user type of the transaction initiator, the exposure field corresponding to the transaction type, and the satisfaction of the preset conditions by the content of the receipt. The fields stored in the form are not only determined based on the exposed identifier, so that when different users call the same smart contract, or call the same smart contract through different types of transactions, or use differentiated preset conditions, the plaintext stored The fields are matched with user types, transaction types and preset conditions, so that the storage method of receipt data can meet the actual needs in different situations, and can take into account privacy protection and function expansion. It can be seen that by exposing the content of the receipt to a certain extent, this manual can be used to drive the DAPP client or expand other functions. In addition, this manual can accurately select the fields for plaintext storage by comprehensively considering the fields indicated by the exposure identifier, the exposed fields corresponding to the transaction type, the user type of the transaction initiator and the content of the receipt to meet the preset conditions. At the same time, it satisfies the fields of "indicated by the exposed identifier", "matched to the transaction type" and "satisfy the preset conditions", so as to meet the above functional expansion requirements while ensuring that most user privacy can be protected.

The foregoing code example can be improved based on the user type of the transaction initiator and the receipt content that meets the preset conditions in the receipt data. In the above code example 2, by adding the exposed identifier plain to the front of the smart contract code, after the smart contract code is executed, when the transaction initiator belongs to the preset user type, the transaction to which the smart contract belongs The exposed fields corresponding to the transaction types of the generated receipt data corresponding to the above exposed fields and meeting the preset conditions are stored in plain text.

Of course, in other embodiments, the fields that need to be stored in plaintext can also be specified. For example, when annotating the From field with an exposed identifier, you can only judge the From field: if the transaction initiator belongs to the preset user type and the From field is the exposed field corresponding to the transaction type of the transaction to which the smart contract belongs, then After the code of the smart contract is executed, the From field in the generated receipt data is stored in plain text when the preset conditions are met, and subsequent retrieval operations can be performed on the From field above, such as statistics initiated by an account Transaction volume, etc.; except for the other fields before the From field, they are all stored in cipher text.

It should be pointed out that in the above code example 2 and related embodiments, the fields (all fields or From fields) marked by the exposed identifier "plain" are contract-level fields, so that the first blockchain node is storing When receiving receipt data, if the transaction initiator belongs to the preset user type and the contract-level field is an exposed field, then the first blockchain node will use all the receipt contents in the receipt data that correspond to the contract-level field and meet the preset conditions with Stored in clear text. In particular, when the code of a smart contract contains multiple events, the contract-level field can be applied to all events in the smart contract. Take the From field as an example: when the transaction initiator belongs to the preset user type, the From field is at the contract level When the fields and the exposed fields corresponding to the transaction type are generated, the Logs fields corresponding to multiple events are generated separately, and the From field contained in each Logs field will be stored in plain text, without the need to add exposure identifiers for each event. symbol.

In addition to the contract-level fields, the fields indicated by the exposure identifier may include: event-level fields corresponding to at least one event defined in the smart contract, so that when the first blockchain node stores the receipt data, if the transaction initiator belongs to the pre- Assuming that the user type and the event-level field belong to the exposed field corresponding to the transaction type, the log corresponding to the at least one event in the receipt data can be determined, and the content of the receipt corresponding to the event-level field in the determined log and the preset conditions The comparison is performed so that the content of the receipt meeting the preset condition is 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 part of the receipt content corresponding to these events that corresponds to the event-level field and meets the preset conditions is in plain text Store, and the remaining part of the receipt content corresponding to this part of the event and the receipt content corresponding to the remaining events are stored in cipher text. Take the From field as an example. In the above code example 3, the character from corresponding to the From field is added to the event function "event currentPrice(int price)" corresponding to the event currentPrice, and the exposed identifier used by the character from is different For the aforementioned plain, the character from is modified by quotation marks. The quotation marks in Code Example 3 are equivalent to the aforementioned exposed identifier. The From field is configured as an event-level field, so that the From field is marked as an event-level field. Therefore, when the transaction initiator belongs to the preset user type and the From field belongs to the exposed field corresponding to the transaction type, in the Logs field corresponding to the event, the From field will be stored in plain text when the preset conditions are met. In addition to the aforementioned event currentPrice, if the code of the smart contract also contains another event, the aforementioned "from" will not affect the other event, and the content of the receipt corresponding to the other event will be stored in ciphertext. In the above code example 4, by adding the keyword "plain" before the event function "event currentPrice(int price)" corresponding to the event currentPrice, the event-level fields include all the fields in the log Logs corresponding to the event currentPrice. For example, the aforementioned From field, To field, Topic field, Log Data field, etc., when the transaction initiator belongs to the preset user type, the exposed fields in these fields can be determined according to the transaction type, and the determined exposed fields are compared with the preset user types. Set conditions for comparison, so that the exposed fields that meet the preset conditions are stored in plain text. Therefore, if the aforementioned From field, To field, Topic field, Log Data field, etc. all meet the preset conditions, it is equivalent to storing all the contents of the receipt generated by the event currentPrice in plain text.

On the basis of the embodiment shown in Figure 2, this specification can further identify the exposure identifier contained in the code of the smart contract, the event function contained in the smart contract, and the content of the receipt meeting preset conditions in the receipt data, so as to be based on the transaction at the same time. The exposure field corresponding to the type, the field indicated by the exposure identifier, the special event function contained in the smart contract, and the satisfaction of the preset conditions by the receipt content determine the storage method of the receipt data. Therefore, the above step 208 can be improved as: 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 plaintext, and the rest of the receipt data It is stored in a ciphertext form, and the at least a part of the receipt content includes exposed fields that are marked by the exposure identifier and meet a preset condition.

The foregoing code example can be improved based on the event function contained in the smart contract and the receipt content that meets the preset conditions in the receipt data. 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 that after the code of the smart contract is executed, the generated receipt data All fields of are allowed to be stored in plain text, so subsequent retrieval operations can be performed on the receipt content in these fields. For example, for the From field, it can be used to count the transaction volume initiated by an account. By further combining dimensions such as transaction type, event function, and preset conditions, the storage scheme for receipt data may be different. Take the From field as an example: the From field in the receipt data may not all be stored in plain text, but the event currentPrice As an example, when the event currentPrice is a special event function and the From field meets a preset condition, the From field in the log generated by the event currentPrice is stored in plain text, otherwise it is stored in cipher 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 the normal event function, then even if the exposed identifier plain is added to the smart contract code and the From field belongs to Exposed fields, all fields (including exposed fields) in the log generated by the event currentPrice are still stored in cipher text. 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 and meeting preset conditions 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, in the above code example 5, similar to the code example 2, the exposed identifier "plain" is located at the forefront of the smart contract code, so that all fields in the receipt data are marked as contract-level fields; at the same time, smart The contract contains the event currentPrice1 and event currentPrice2: Assume 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 In the logs Log1 and Log2 generated by the event currentPrice2, the From field contained in log Log1 is stored in plain text when the preset conditions are met, and the From field contained in log Log2 is stored in cipher text; similarly, the exposed fields in log Log1 Other fields are also stored in plain text, non-exposed fields are stored in cipher text, and 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 the special event function list is updated, then all the fields contained in the log Log2 that belong to the exposed fields and meet the preset conditions will be stored in plain text, without the need for smart Make any changes to the contract code.

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, in the above code example 6, 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 same as before The type identifier expose mentioned above makes the event currentPrice1 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 In the generated logs Log1 and Log2, all the exposed fields corresponding to the transaction type in the log Log1 are stored in plain text when the preset conditions are met, and all the fields contained in the log Log2 must be stored in cipher text.

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 event-level fields and meeting preset conditions in the determined 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 that belong to the event-level fields and meet the preset conditions in the logs corresponding to this part of the events are stored in plain text , And other fields in the log corresponding to this part of the event, and the content of the receipt corresponding to the remaining events are stored in cipher text. Take the From field as an example. In the above code sample 7, 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 event currentPrice1. The From field in the generated log 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 when the preset conditions are met, and in cipher text when the preset conditions are not met, and other fields must be stored in cipher text. As for the other event currentPrice2 contained in code example 7, 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 ciphertext form 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, in the above code example 8, 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, To field, Topic field, Log Data field, etc. Then, when the event currentPrice1 corresponds to a special event function, it can be determined from the log generated by the event currentPrice1 that it belongs to both the above event-level field and the exposed field corresponding to the transaction type, and the log field is determined in the log When the fields meet the preset conditions, they are stored in plain text; if the above-mentioned From field, To field, Topic field, Log Data field, etc. are all exposed fields and meet the preset conditions, then it is equivalent to the content of all receipts corresponding to the event currentPrice1 ( For example, the generated logs are stored in plain text.

Based on the embodiment shown in Figure 2, this specification can further identify the exposure identifier contained in the code of the smart contract, the user type of the transaction initiator, the event function contained in the smart contract, and the receipt data that meet the preset conditions. Receipt content, so as to determine the receipt data at the same time according to the exposed fields corresponding to the transaction type, the fields indicated by the exposed identifier, the user type of the transaction initiator, the special event function included in the smart contract, and the satisfaction of the receipt content to the preset conditions Storage method. Therefore, the above step 208 can be improved to: the first blockchain node stores the receipt data so that when the transaction initiator belongs to the preset user type, at least part of the receipt content in the log corresponding to the special event function Stored in plain text, and the remaining content of the receipt data is stored in cipher text, and the at least part of the receipt content matches the exposure field indicated by the exposure identifier and meets a preset condition. 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 considers the user type of the transaction initiator, the exposed field corresponding to the transaction type, the field indicated by the exposure identifier, the log generated by the special event function, and the content of the receipt to meet the preset conditions, and can accurately select the application. The content of the receipt stored in plaintext meets the requirements of "transaction initiator belongs to the preset user type", "belongs to the exposed field corresponding to the transaction type", "matches the field indicated by the exposure identifier", and "belongs to the log generated by the special event function" "" and "meeting the preset conditions", 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.

The foregoing code example can be improved based on the user type of the transaction initiator, the event function contained in the smart contract, and the receipt content that meets the preset conditions in the receipt data. In the code example 2 above, the exposed identifier plain is added to the front of the smart contract code, so that after the smart contract code is executed, when the transaction initiator belongs to the preset user type, the receipt data is generated by the special event function The log allows the exposed field corresponding to the transaction type of the transaction to which the smart contract belongs and the content of the receipt meeting preset conditions is stored in clear text. For example, when the From field in the log is an exposed field and the To field is not an exposed field, The From field of all logs in the receipt data can be stored in plain text when the preset conditions are met, and the To field is stored in cipher text. Then, subsequent retrieval operations can be performed on the receipt content in the From field, for example, a certain account can be counted The volume of transactions initiated, etc.

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 user type depends on the transaction initiator and has nothing to do with the programming language, so that even when different transaction initiators call the same smart contract, the storage method (ciphertext or plaintext) of the receipt data may be different. The transaction type can also be selected by the transaction initiator according to demand to indicate the actual needs of the transaction initiator. The preset conditions can be selected by the transaction initiator according to actual needs, regardless of the programming language. At the same time, the definition of special event functions is not necessarily based on programming languages. For example, when recording special event functions based on a list of special event functions, even if an event function included in the smart contract originally belongs to a special event function, it can be To change the list of special event functions, update the original special event function to a normal event function, so as to avoid storing the log generated by the event function in clear text, or update the original normal 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. Therefore, by calling the smart contract by different users, or initiating different types of transactions, or adjusting the type of event function contained in the smart contract, or selecting different preset conditions, you can escape the restriction of exposing identifiers. The adjustment requires clear text Or the content of the receipt stored in ciphertext.

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 exposure identifier plain is added to the smart contract code and the transaction initiator It belongs to a preset user type, and all fields (including exposed fields) in the log generated by the event currentPrice are still stored in cipher text. However, if the event currentPrice is added to the list of special event functions, the code sample 2 does not need to be adjusted, and when the transaction initiator belongs to the preset user type, the exposed field in the log corresponding to the event currentPrice can be made to meet the requirements. If the conditions are set, it will be stored in plain 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 transaction initiator belongs to the preset user type and the contract-level field is an exposed field, the contents of the receipt corresponding to the contract-level field and meeting the preset conditions in the log generated by the event currentPrice 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, it can be preset at the transaction initiator In the case of the user type, when the first blockchain node stores receipt data, all receipt content in the receipt data that corresponds to the From field and meets the preset conditions is allowed to be stored in plain text.

In particular, when the code of the smart contract contains multiple event functions, in the respective Logs fields generated by the multiple event functions, there may be the receipt content corresponding to the contract-level field; further, the transaction can be identified by The user type to which the initiator belongs, the exposed fields corresponding to the transaction type of the transaction, the type of each event function is ordinary event function or special event function, and the content of the receipt meets the preset conditions, so that the transaction initiator belongs to the preset user type And when the contract-level field is an exposed field, the contents of the receipt corresponding to the contract-level field and satisfying the preset conditions in the logs generated by all special event functions are stored in plain text. For example, in the above code example 5, similar to the code example 2, the exposed identifier "plain" is located at the forefront of the smart contract code, so that all fields in the receipt data are marked as contract-level fields; at the same time, smart The contract contains the event currentPrice1 and the event currentPrice2: assuming that 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 the transaction initiator belongs to the preset user type and the From field is an exposed field In the case of the event currentPrice1 and event currentPrice2 generated logs Log1 and Log2, the From field contained in the log Log1 is stored in plain text when the preset conditions are met, and in cipher text when the preset conditions are not met The From field contained in log Log2 must be stored in cipher text; similarly, other fields in log Log1 that are exposed fields are also stored in plain text when the preset conditions are met, and non-exposed fields are stored in cipher text. All the fields of the 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 the fields belonging to the exposed fields contained in the log Log2 can be stored in plain text under the condition that the preset conditions are met. If the preset conditions are not met, it is stored in ciphertext form, without any changes to the code of the smart contract.

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, in the above code example 6, 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 same as before The type identifier expose mentioned above makes the event currentPrice1 be marked as corresponding to the special event function, and 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 currentPrice2 is marked as corresponding to the normal event function. In the case of the user type, in the logs Log1 and Log2 generated by the event currentPrice1 and event currentPrice2 respectively, all the exposed fields in the log Log1 corresponding to the transaction type are stored in clear text when the preset conditions are met. When the conditions are set, it is stored in cipher text, and all fields contained in the log Log2 must be stored in cipher text.

In addition to the contract-level fields, the fields indicated by the exposure identifier may include: event-level fields corresponding to at least one event defined in the smart contract, so that the transaction initiator belongs to the preset user type and the event-level field belongs to the exposed field In this case, the first blockchain node stores the part of the receipt content generated by the special event function that corresponds to the event-level field and meets the preset condition 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 contents of the receipts that correspond to the above-mentioned event-level fields and meet the preset conditions in the logs generated by this part of the events are in plain text The content of the remaining receipts in the log generated by this part of the event and the content of the receipt corresponding to the remaining events are stored in the form of ciphertext. Take the From field as an example. In the above code sample 7, 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 event currentPrice1. The From field in the generated log 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 transaction initiator belongs to the preset user type and the From field is an exposed field, when the event currentPrice1 corresponds to a special event function In the log Logs corresponding to the event currentPrice1, the From field is stored in plain text when the preset conditions are met, and stored in cipher text when the preset conditions are not met, and other fields must be stored in cipher text Form storage. As for the other event currentPrice2 contained in code example 7, 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 ciphertext form storage. In the embodiment corresponding to this code example 7, that is, for event-level fields, it is possible to identify whether the event functions included in the smart contract are special event functions by means of a special event function list or type identifier. Repeat.

Similar to the embodiment shown in FIG. 2, the above-expanded embodiments can also implement corresponding logic functions through chain codes, or adopt a combination of chain codes and system contracts. Among them, the embodiment shown in FIG. 2 adopts the receipt data storage logic related to the transaction type, and the expanded embodiment described above further considers at least one of the following factors: exposing the object indicated by the identifier, The user type of the transaction initiator, the content of the receipt meeting preset conditions in the receipt data, and the event function contained in the smart contract. One or more of the above factors can be combined with the user type to obtain the corresponding receipt data storage logic.

When the receipt data storage logic is related to the object indicated by the exposure identifier, the receipt data storage logic includes logic for storing the content of the receipt based on the exposure identifier, and the logic is used to instruct the first blockchain node: to indicate the exposure identifier The corresponding receipt content should be stored in the fields of, and fields not marked by the exposed identifier.

When the receipt data storage logic is related to the user type of the transaction initiator, the receipt data storage logic includes: identification logic for the user type. The user type identification logic is used to instruct the first blockchain node to identify the user type of the transaction initiator. For example, the system contract can record the association relationship between the predefined external account and the user type, or the system contract can record the correspondence between the value of the user type field and the user type. For details, please refer to the relevant description of identifying user types above, which will not be repeated here.

When the receipt data storage logic is related to the event function contained in the smart contract, the receipt data storage logic includes: identification logic for the event function. 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.

When the receipt data storage logic is related to the receipt content that meets the preset condition in the receipt data, the receipt data storage logic includes: logic for determining the preset condition. The determination logic of the preset condition is used to instruct the first blockchain node to obtain the preset condition applicable to the content of the receipt corresponding to the object indicated by the exposure identifier. For example, obtain general conditions applicable to all receipt fields, or obtain special conditions applicable to the field of the receipt content corresponding to the object indicated by the exposure identifier. For details, please refer to the relevant description of the preset conditions above, which will not be repeated here.

The following describes an embodiment of a receipt storage node based on transaction type in this specification with reference to FIG. 6, including:

The receiving unit 61 receives the encrypted transaction;

The decryption unit 62 decrypts the transaction in a trusted execution environment to obtain transaction content;

The execution unit 63 executes the transaction content in the trusted execution environment to obtain receipt data;

The determining unit 64 determines the exposed fields in the receipt data 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 corresponding to the exposed field is stored in plain text, and the rest of the receipt content is stored in cipher text.

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

Optionally, the determining unit 64 is specifically configured to:

Obtain the mapping relationship between predefined transaction types and exposed fields;

Determine the exposed field in the receipt data according to the transaction type of the transaction and the mapping relationship.

Optionally, the mapping relationship is recorded in a system contract.

Optionally, the storage unit 65 is specifically configured to:

Read the code of the system contract, which defines the receipt data storage logic related to the transaction type;

The code of the system contract is executed to store the exposed fields in plaintext and the remaining receipt fields in ciphertext.

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 transaction type of the transaction includes: deposit certificate type, asset transfer type, contract creation type, contract call type.

Optionally, the storage unit 65 is specifically configured to:

When the receipt data is stored so that the transaction initiator belongs to a preset user type, at least a part of the receipt content corresponding to the exposed field is stored in plain text, and the rest of the receipt content is stored in cipher text.

Optionally, the storage unit 65 determines the user type to which the transaction initiator belongs in the following manner:

Determine the external account corresponding to the transaction initiator;

Query the user type corresponding to the external account recorded on the blockchain as the user type to which the transaction initiator belongs.

Optionally, the external account includes a user type field recorded on the blockchain, and the value of the user type field corresponds to the user type.

Optionally, when the external account is created, the user type is configured to be associated with the external account, so that the association relationship between the user type and the external account is recorded in the blockchain.

Optional, also includes:

The changing unit 66 changes the user type corresponding to the external account according to the change request initiated by the management user.

Optionally, the at least part of the receipt content stored in plaintext meets at least one of the following rules:

The at least part of the receipt content is generated by a special event function included in the smart contract corresponding to the transaction;

The information contained in the at least part of the receipt content meets a preset condition;

The at least a part of the receipt content corresponds to the object indicated by the exposure identifier contained in the code of the smart contract.

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 preset condition includes at least one of the following: the corresponding receipt content includes the preset content, and the value of the corresponding receipt content belongs to the preset numerical interval.

Optional,

The preset conditions include general conditions corresponding to all receipt fields in the receipt data; or,

The preset condition includes a dedicated condition corresponding to each receipt field in the receipt data.

Optional,

The preset condition is in the transaction; or,

The preset condition is located in the smart contract corresponding to the transaction, or in another smart contract called by the smart contract corresponding to the transaction; or,

The preset conditions are located in the system contract or chain code.

Optionally, the smart contract corresponding to the transaction received by the receiving unit 61 includes:

Smart contracts written in high-level languages; or,

Smart contract in bytecode form.

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

Optionally, the objects indicated by the exposure identifier include: receipt fields and/or state variables.

Optionally, the object indicated by the exposure identifier includes at least one of the following: a contract-level object applicable to all events defined in the smart contract, and an event-level object corresponding to at least one event defined in the smart contract Object.

Optionally, the storage unit 65 is specifically configured to:

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 a 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.

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, commodity or equipment including a series of elements not only includes those elements, but also includes Other elements that are not explicitly listed, or they also include elements inherent to such processes, methods, commodities, or equipment. If there are no more restrictions, the element defined by the sentence "including a..." does not exclude the existence of other identical elements in the process, method, commodity, or equipment that includes the element.

The foregoing describes specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps described in the claims may be performed in a different order than in the embodiments and still achieve desired results. In addition, the processes depicted in the drawings do not necessarily require the specific order or sequential order shown 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 determination".

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 (32)

A receipt storage method based on transaction type, including: The first blockchain node receives the encrypted transaction; The first blockchain node decrypts the transaction in the trusted execution environment and executes the obtained transaction content to obtain receipt data; The first blockchain node determines the exposed field in the receipt data 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 corresponding to the exposed field is stored in plain text, and the rest of the receipt content is stored in cipher text. The method according to claim 1, wherein the transaction includes a transaction type field, and the value of the transaction type field is used to indicate the corresponding transaction type. The method according to claim 1, wherein the first blockchain node determines the exposed field in the receipt data according to the transaction type of the transaction, including: The first blockchain node obtains the mapping relationship between the predefined transaction type and the exposed field; The first blockchain node determines the exposed field in the receipt data according to the transaction type of the transaction and the mapping relationship. According to the method of claim 3, the mapping relationship is recorded in a system contract. 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 transaction type; The first blockchain node executes the code of the system contract to store the exposed fields in plain text and the remaining receipt fields in cipher text. The method according to claim 4 or 5, 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 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 the first blockchain node storing the receipt data includes: The first blockchain node stores the receipt data so that when the transaction initiator belongs to a preset user type, at least part of the receipt content corresponding to the exposed field is stored in plain text, and the rest of the receipt content is stored in cipher text. According to the method of claim 8, the first blockchain node determines the user type to which the transaction initiator belongs in the following manner: The first blockchain node determines the external account corresponding to the transaction initiator; The first blockchain node queries the user type corresponding to the external account recorded on the blockchain as the user type to which the transaction initiator belongs. The method according to claim 9, wherein the external account includes a user type field recorded on the blockchain, and the value of the user type field corresponds to the user type. The method according to claim 9, wherein when the external account is created, the user type is configured to be associated with the external account, so that the association relationship between the user type and the external account is recorded in the area Block chain. The method according to claim 11, further comprising: The first blockchain node changes the user type corresponding to the external account according to the change request initiated by the management user. The method according to claim 1, wherein the at least part of the receipt content stored in plaintext meets at least one of the following rules: The at least part of the receipt content is generated by a special event function included in the smart contract corresponding to the transaction; The information contained in the at least part of the receipt content meets a preset condition; The at least a part of the receipt content corresponds to the object indicated by the exposure identifier contained in the code of the smart contract. The method according to claim 13, 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 13, 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. The method according to claim 13, wherein the preset condition includes at least one of the following: the corresponding receipt content contains the preset content, and the value of the corresponding receipt content belongs to the preset numerical interval. According to the method of claim 13, The preset conditions include general conditions corresponding to all receipt fields in the receipt data; or, The preset condition includes a dedicated condition corresponding to each receipt field in the receipt data. According to the method of claim 13, The preset condition is in the transaction; or, The preset condition is located in the smart contract corresponding to the transaction, or in another smart contract called by the smart contract corresponding to the transaction; or, The preset conditions are located in the system contract or chain code. According to the method of claim 13, 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. According to the method of claim 19, the smart contract written in the high-level language and the smart contract in the bytecode form have the same or corresponding exposure identifier. The method according to claim 13, wherein the objects indicated by the exposure identifier include: receipt fields and/or state variables. The method according to claim 13, wherein the object indicated by the exposure identifier includes at least one of the following: a contract-level object applicable to all events defined in the smart contract, corresponding to at least one defined in the smart contract The event-level object of an event. 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 24, wherein 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 derivative generated by the initial key and an impact factor Key. The method according to claim 25, 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 25, 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 25, wherein the impact factor is related to the transaction. The method according to claim 28, wherein the impact factor comprises: a designated bit of a hash value of the transaction. A receipt storage node based on transaction type, including: The receiving unit receives encrypted transactions; The decryption unit decrypts the transaction in a trusted execution environment to obtain transaction content; The execution unit executes the transaction content in the trusted execution environment to obtain receipt data; The determining unit determines the exposed fields in the receipt data according to the transaction type of the transaction; The storage unit stores the receipt data so that at least part of the receipt content corresponding to the exposed field is stored in plain text, and the rest of the receipt content is stored in cipher text. 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-29. A computer-readable storage medium having computer instructions stored thereon, which, when executed by a processor, implement the steps of the method according to any one of claims 1-29.

Images