CN110223172B

CN110223172B - Conditional receipt storage method and node combining code labeling and type dimension

Info

Publication number: CN110223172B
Application number: CN201910419908.9A
Authority: CN
Inventors: 刘琦; 闫莺; 魏长征
Original assignee: Advanced New Technologies Co Ltd
Current assignee: Advanced New Technologies Co Ltd; Advantageous New Technologies Co Ltd
Priority date: 2019-05-20
Filing date: 2019-05-20
Publication date: 2021-04-13
Anticipated expiration: 2039-05-20
Also published as: CN110223172A; WO2020233644A1

Abstract

One or more embodiments of the present specification provide a method and node for conditional receipt storage that combines code annotation with a type dimension, comprising: the first block chain node receives encrypted transaction corresponding to the intelligent contract, and the code of the intelligent contract comprises a field marked by an exposed identifier; the first blockchain node decrypts the transaction in the trusted execution environment to obtain an intelligent contract, wherein the intelligent contract comprises a special event function; executing an intelligent contract in a trusted execution environment by a first blockchain node, wherein the obtained receipt data comprises a log corresponding to a special event function; determining a corresponding exposed field by the first block chain node according to the transaction type of the transaction; the first block chain link point stores the receipt data, so that at least one part of the receipt content in the log corresponding to the special event function is stored in a plaintext form, and the rest of the receipt content in the log is stored in a ciphertext form, wherein at least one part of the receipt content comprises an exposure field which is marked by an exposure identifier and meets a preset condition.

Description

Conditional receipt storage method and node combining code labeling and type dimension

Technical Field

One or more embodiments of the present specification relate to the field of blockchain technology, and more particularly, to a method and node for storing receipts that conditionally combines code labeling with type dimensions.

Background

The blockchain technique is built on top of a transport network, such as a point-to-point network. Network nodes in a transport network utilize a chained data structure to validate and store data and employ a distributed node consensus algorithm to generate and update data.

The two biggest challenges in the current enterprise-level blockchain platform technology are privacy and performance, which are often difficult to solve simultaneously. Most solutions trade privacy for loss of performance or do not consider privacy much to pursue performance. Common encryption technologies for solving privacy problems, such as Homomorphic encryption (Homomorphic encryption) and Zero-knowledge proof (Zero-knowledge proof), have high complexity and poor universality, and may cause serious performance loss.

Trusted Execution Environment (TEE) is another way to address privacy concerns. The TEE can play a role of a black box in hardware, a code and data operating system layer executed in the TEE cannot be peeped, and the TEE can be operated only through an interface defined in advance in the code. In the aspect of efficiency, due to the black box property of the TEE, plaintext data is operated in the TEE instead of complex cryptography operation in homomorphic encryption, and the efficiency of the calculation process is not lost, so that the safety and privacy of a block chain can be improved to a great extent on the premise of small performance loss by combining with the TEE. The industry is concerned with TEE solutions, and almost all mainstream chip and Software consortiums have their own TEE solutions, including Software-oriented TPM (Trusted Platform Module) and hardware-oriented Intel SGX (Software Guard Extensions), ARM Trustzone (Trusted zone), and AMD PSP (Platform Security Processor).

Disclosure of Invention

In view of the above, one or more embodiments of the present specification provide a method and node for storing receipts that conditionally combines code annotation with a type dimension.

To achieve the above object, one or more embodiments of the present disclosure provide the following technical solutions:

according to a first aspect of one or more embodiments of the present specification, there is provided a method for conditional storing of receipts combining code annotation with a type dimension, comprising:

a first block chain node receives encrypted transactions corresponding to intelligent contracts, wherein codes of the intelligent contracts comprise fields marked by exposed identifiers;

decrypting the transaction in a trusted execution environment by a first blockchain node to obtain the smart contract, the smart contract comprising a special event function;

executing the intelligent contract in the trusted execution environment by a first blockchain node to obtain receipt data, wherein the receipt data comprises a log corresponding to the special event function;

determining a corresponding exposed field by the first block chain node according to the transaction type of the transaction;

and storing the receipt data by a first block chain link point, so that at least one part of receipt content in a log corresponding to the special event function is stored in a plain text form, and the rest of the receipt content is stored in a cipher text form, wherein the at least one part of receipt content comprises an exposure field which is marked by the exposure identifier and meets a preset condition.

According to a second aspect of one or more embodiments of the present specification, there is provided a receipt storage node that conditionally combines code annotation with a type dimension, comprising:

a receiving unit that receives encrypted transactions corresponding to a smart contract, the smart contract having a code including a field designated by an exposed identifier;

a decryption unit to decrypt the transaction in a trusted execution environment to obtain the smart contract, the smart contract comprising a special event function;

an execution unit that executes the smart contract in the trusted execution environment, resulting in receipt data that includes a log corresponding to the special event function;

the determining unit is used for determining a corresponding exposed field according to the transaction type of the transaction;

and the storage unit is used for storing the receipt data, so that at least one part of receipt content in the log corresponding to the special event function is stored in a plaintext form, and the rest of the receipt content in the log is stored in a ciphertext form, wherein the at least one part of receipt content comprises an exposure field which is marked by the exposure identifier and meets a preset condition.

According to a third aspect of one or more embodiments of the present specification, there is provided an electronic apparatus including:

a processor;

a memory for storing processor-executable instructions;

wherein the processor implements the method of the first aspect by executing the executable instructions.

According to a fourth aspect of one or more embodiments of the present description, a computer-readable storage medium is presented, having stored thereon computer instructions which, when executed by a processor, implement the steps of the method according to the first aspect.

Drawings

FIG. 1 is a schematic diagram of creating an intelligent contract, provided by an exemplary embodiment.

FIG. 2 is a schematic diagram of a calling smart contract provided by an exemplary embodiment.

FIG. 3 is a flowchart of a method for conditional receipt storage incorporating code labeling and type dimensions, provided by an exemplary embodiment.

Fig. 4 is a schematic diagram of implementing privacy protection at block link points according to an exemplary embodiment.

Fig. 5 is a schematic diagram of the functional logic for implementing a blockchain network via system contracts and chain code in accordance with an exemplary embodiment.

FIG. 6 is a block diagram of a receipt storage node that combines code labeling with a type dimension that is conditional, as provided by an exemplary embodiment.

Detailed Description

Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, like numbers in different drawings represent the same or similar elements unless otherwise indicated. The implementations described in the following exemplary embodiments do not represent all implementations consistent with one or more embodiments of the present specification. Rather, they are merely examples of apparatus and methods consistent with certain aspects of one or more embodiments of the specification, as detailed in the claims which follow.

It should be noted that: in other embodiments, the steps of the corresponding methods are not necessarily performed in the order shown and described herein. In some other embodiments, the method may include more or fewer steps than those described herein. Moreover, a single step described in this specification may be broken down into multiple steps for description in other embodiments; multiple steps described in this specification may be combined into a single step in other embodiments.

Blockchains are generally divided into three types: public chain (Public Blockchain), Private chain (Private Blockchain) and alliance chain (Consortium Blockchain). In addition, there are various types of combinations, such as private chain + federation chain, federation chain + public chain, and other different combinations. The most decentralized of these is the public chain. The public chain is represented by bitcoin and ether house, and the participators joining the public chain can read the data record on the chain, participate in transaction, compete for accounting right of new blocks, and the like. Furthermore, each participant (i.e., node) is free to join and leave the network and perform related operations. Private chains are the opposite, with the network's write rights controlled by an organization or organization and the data read rights specified by the organization. Briefly, a private chain can be a weakly centralized system with strictly limited and few participating nodes. This type of blockchain is more suitable for use within a particular establishment. A federation chain is a block chain between a public chain and a private chain, and "partial decentralization" can be achieved. Each node in a federation chain typically has a physical organization or organization corresponding to it; participants jointly maintain blockchain operation by authorizing to join the network and forming a benefit-related alliance.

Whether public, private, or alliance, may provide the functionality of an intelligent contract. An intelligent contract on a blockchain is a contract that can be executed on a blockchain system triggered by a transaction. An intelligent contract may be defined in the form of code.

Taking the ethernet as an example, the support user creates and invokes some complex logic in the ethernet network, which is the biggest challenge of ethernet to distinguish from bitcoin blockchain technology. The core of the ethernet plant as a programmable blockchain is the ethernet plant virtual machine (EVM), each ethernet plant node can run the EVM. The EVM is a well-behaved virtual machine, which means that a variety of complex logic can be implemented through it. The user issuing and invoking smart contracts in the etherhouse is running on the EVM. In fact, what the virtual machine directly runs is virtual machine code (virtual machine bytecode, hereinafter referred to as "bytecode"). The intelligent contracts deployed on the blockchain may be in the form of bytecodes.

For example, as shown in fig. 1, after Bob sends a transaction containing information to create an intelligent contract to the ethernet network, the EVM of node 1 may execute the transaction and generate a corresponding contract instance. The "0 x6f8ae93 …" in fig. 1 represents the address of the contract, the data field of the transaction holds the byte code, and the to field of the transaction is empty. After agreement is reached between the nodes through the consensus mechanism, this contract is successfully created and can be invoked in subsequent procedures. After the contract is created, a contract account corresponding to the intelligent contract appears on the blockchain and has a specific address, and the contract code is stored in the contract account. The behavior of the intelligent contract is controlled by the contract code. In other words, an intelligent contract causes a virtual account to be generated on a blockchain that contains a contract code and an account store (Storage).

As shown in fig. 2, still taking an ethernet house as an example, after Bob sends a transaction for invoking an intelligent contract to the ethernet house network, the EVM of a certain node may execute the transaction and generate a corresponding contract instance. The from field of the transaction in fig. 2 is the address of the account of the transaction initiator (i.e., Bob), the "0 x6f8ae93 …" in the to field represents the address of the smart contract called, and the value field is the value of tai-currency in the etherhouse, and the data field of the transaction holds the method and parameters for calling the smart contract. The intelligent contract is independently executed at each node in the blockchain network in a specified mode, and all execution records and data are stored on the blockchain, so that after the transaction is completed, transaction certificates which cannot be tampered and cannot be lost are stored on the blockchain.

After executing Bob-initiated transaction, a node in the blockchain network generates corresponding receipt (receipt) data for recording receipt information related to the transaction. Taking the ether house as an example, the receipt data obtained by the node executing the transaction may include the following:

a Result field indicating the execution Result of the transaction;

a Gas used field representing a Gas value consumed by the transaction;

a Logs field for representing a Log generated by the transaction, wherein the Log may further comprise a From field for representing an account address of an initiator of the call, a To field for representing an account address of an object (such as a smart contract) To be called, a Topic field for representing a subject of the Log, a Log data field for representing Log data, and the like;

an Output field, representing the Output of the transaction.

Generally, receipt data generated after a transaction is executed is stored in a clear text form, so that anyone can see the contents of the receipt fields contained in the receipt data, and the setting and the capability of privacy protection are not provided. In some combined blockchain and TEE solutions, the entire content of the receipt data is stored on the blockchain as data requiring privacy protection in order to achieve privacy protection. The block chain is a data set organized by specific logics stored in a database of nodes. The database, as described later, may be a storage medium, such as a persistent storage medium, in physical carrier. In fact, only part of the receipt data may be sensitive, while other content is not sensitive, only privacy protection is required for the sensitive content, other content can be disclosed, and even in some cases, retrieval of part of the content may be required to drive implementation of relevant operations, and then implementing privacy protection for the part of the content will affect implementation of the retrieval operations.

The following describes the implementation of an embodiment of a conditional receipt storing method combining code labeling and type dimension according to the present application with reference to fig. 3:

in step 302, a first block chain node receives an encrypted transaction corresponding to a smart contract having a code including a field designated by an exposed identifier.

The exposure identifier is a global identifier defined in a programming language of the intelligent contract and is applicable to all intelligent contracts written by the programming language. Thus, by defining the exposed identifier in the programming language such that the exposed identifier is used in the code of any intelligent contract, storage control of receipt data may be achieved. For example, when a user writes the code of the intelligent contract, one or more fields can be marked by adding an exposed identifier in the code to indicate that the user wants the receipt content corresponding to the field in the receipt data to be stored in plain text, and the receipt content corresponding to the field which is not marked with the exposed identifier is not allowed to be stored in plain text and must be stored in cipher text, so that the corresponding privacy protection is realized.

In other words, for the fields marked by the exposed identifiers, the corresponding receipt content is allowed to be stored in clear text from the dimension of the programming language; however, the present specification may further consider the transaction type, the event function included in the smart contract, and the satisfaction of the receipt content to the preset condition, and implement a comprehensive consideration from the dimensions of the programming language, the transaction type, the event function, and the preset condition to determine whether to store the receipt content corresponding to the field indicated by the exposed identifier in a plaintext form. Information related to the transaction type, the event function, and the preset condition will be described below, and will not be described in detail herein.

As described above, in a transaction for creating a smart contract, the data field may hold the byte code of the smart contract. A bytecode consists of a series of bytes, each of which can identify an operation. Based on the multiple considerations of development efficiency, readability and the like, a developer can select a high-level language to write intelligent contract codes instead of directly writing byte codes. The code of the intelligent contract written by the high-level language is compiled by a compiler to generate byte codes, and the byte codes can be deployed on the block chain. The high-level languages supported by Etherns are many, such as Solidity, Serpent, LLL, etc.

Taking the Solidity language as an example, the contract written by the method is similar to a Class (Class) in an object-oriented programming language, and various members including state variables, functions, function modifiers, events and the like can be declared in one contract. The following code example 1 is a simple intelligent contract written in the Solidity language:

in the code of the intelligent contract written based on the solid language, one or more fields can be marked by exposing identifiers, so that the receipt content corresponding to the part of the fields in the receipt data is allowed to be stored in a plaintext form (the plaintext storage needs to be determined whether to actually adopt the plaintext storage by further combining the dimensions of the transaction type, the event function and the preset condition), and the rest of the receipt content should be stored in a ciphertext form. Similarly, in the code of smart contracts written based on Serpent, LLL language, etc., one or more fields may also be designated by an exposed identifier to enable clear text storage of the relevant receipt content.

The exposed identifier may be a receipt field dedicated to marking the permission for plaintext storage, for example, a keyword play may be used to characterize the exposed identifier. Then, for receipt content that is desired to be stored in clear text, a plain may be added before (or otherwise associated with) the corresponding field.

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

in the above code example 2, the exposure identifier plain is added at the top of the code of the smart contract, and only from the dimension of the programming language indicates that: so that after the code of the smart contract is executed, all fields in the generated receipt data are allowed to be stored in clear text, and then retrieval operations can be subsequently performed on the receipt contents in these fields, such as counting the amount of transactions initiated by an account in the case of the From field. By further combining dimensions such as transaction types, event functions, preset conditions and the like, different storage schemes for receipt data may exist, and the From field is still taken as an example: the From fields in the receipt data may not all be stored in a plain text form, taking event currentPrice as an example, when the event currentPrice is a special event function and the From fields meet preset conditions, storing the From fields in the log generated by the event currentPrice in a plain text form, otherwise, storing the From fields in a ciphertext form; see below for details.

In one embodiment, the intelligent contract corresponding to the transaction received by the first blockchain node may be an intelligent contract written in a high-level language or may be an intelligent contract in a byte code form. When the intelligent contract is an intelligent contract written in a high-level language, the first block chain node also compiles the intelligent contract written in the high-level language through a compiler to generate the intelligent contract in a byte code form to be executed in a trusted execution environment. And when the intelligent contract corresponding to the transaction received by the first blockchain node is the intelligent contract in the form of byte codes, the intelligent contract in the form of byte codes can be obtained by compiling the intelligent contract written in the high-level language by the client through the compiler, and the intelligent contract written in the high-level language is obtained by writing on the client by the user.

For the intelligent contract corresponding to the transaction received by the first blockchain node, the intelligent contract generated on the first blockchain node by the user can be generated. When a user adopts a high-level language to compile the intelligent contract, the first block chain node compiles the intelligent contract compiled by the high-level language into an intelligent contract in a byte code form through a compiler; alternatively, the user may write the intelligent contract directly on the first blockchain node in bytecode.

For the intelligent contract corresponding to the transaction received by the first blockchain node, the intelligent contract generated on the client side for the user can be obtained. For example, after the user generates the transaction at the client through the corresponding account, the transaction is submitted to the first blockchain node through the client. Taking fig. 4 as an example, the first tile nexus includes a transaction/query interface that can interface with the client so that the client can submit the transaction to the first tile nexus. For example, as described above, a user may write an intelligent contract in a high-level language on a client, and then the client compiles the intelligent contract in the high-level language through a compiler to obtain a corresponding intelligent contract in a bytecode form. Of course, the client may directly send the intelligent contract written in the high-level language to the first block chain node, so that the first block chain node is compiled into the intelligent contract in the form of byte codes by the compiler.

For the intelligent contract corresponding to the transaction received by the first blockchain node, the intelligent contract may be an intelligent contract in the transaction sent by the client through the second blockchain node, and the intelligent contract is usually in a byte code form; of course, the intelligent contract may also be an intelligent contract written in a high-level language, and the first block link point may be compiled into an intelligent contract in a byte code form by a compiler.

In one embodiment, when an exposed identifier is included in the code of a smart contract, a high-level language written smart contract may have the same exposed identifier as a bytecode-style smart contract. And those skilled in the art will understand that: the bytecode can adopt an exposed identifier different from the high-level language, for example, the code of the intelligent contract written in the high-level language includes a first identifier, and the code of the intelligent contract in the form of the bytecode includes a second identifier, so that there is a correspondence between the first identifier and the second identifier, and it is ensured that the function of the exposed identifier is not affected after the bytecode is compiled from the high-level language.

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

In one embodiment, a smart contract may contain one or more events, each event for implementing predefined associated processing logic. After each event included in the intelligent contract is called and executed, a corresponding Logs field is generated, for example, when the intelligent contract includes event 1 and event 2, event 1 may generate a corresponding Logs field, and event 2 may generate a corresponding Logs field, so that the receipt data corresponding to the intelligent contract includes 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 general event functions, wherein: the log generated by the common event function is stored in a ciphertext mode so as to realize privacy protection; the log generated by the special event function allows at least a part of log fields to be stored in a clear text form (specifically, dimensions of a programming language, a transaction type and preset conditions are required to be combined to determine whether the log fields are stored in the clear text form) on the premise of meeting the requirement of privacy protection, so that retrieval can be implemented according to the contents of the part of log fields to drive implementation of related operations.

In one embodiment, event functions belonging to "special event functions" may be recorded in a chain code or system contract of a block chain network, for example, may be recorded in a special event function list; accordingly, by comparing the event function included in the intelligent contract with the above-mentioned special event function list, it can be determined whether the event function included in the intelligent contract is the above-mentioned special event function.

In one embodiment, the special event function can be any function customized in the intelligent contract, and the event function can be marked as the special event function by adding a type identifier for the event function in the intelligent contract. Taking the Solidity language as an example, the code example 1 includes the following code examples of the event function:

event currentPrice(int price)；

in the code example described above, the intelligent contract defines the event: event currentPrice. However, the event does not contain any type identifier, and thus the corresponding event function belongs to a general event function. After the event function in the code example 1 is adjusted, the following code examples of the event function can be obtained:

event currentPrice expose(int price)；

in the modified code example above, the smart contract defines the event: event currentPrice. The event currentPrice can be tagged as the special event function described above by adding a type identifier "expose" to the event currentPrice.

Many high-level languages supported by etherhouses, such as Solidity, Serpent, LLL, etc., may contain the type identifier described above. The intelligent contract written in the high-level language can be compiled into a corresponding byte code through a compiler, and the first block link point finally executes the intelligent contract in the form of the byte code in the EVM virtual machine. Then, the type identifiers may be the same in the intelligent contract codes in the high-level language and the bytecode, or the intelligent contract codes in the high-level language may be the first type identifiers and the intelligent contract codes in the bytecode may be the second type identifiers, and the first type identifiers and the second type identifiers may correspond to each other.

In an embodiment, by encrypting the transaction content, the encrypted transaction can be in a privacy protection state, and the transaction content is prevented from being exposed. For example, the transaction content may include information such as an account address of the transaction initiator and an account address of the transaction target, and the encryption process may ensure that none of the transaction content can be directly read.

In an embodiment, the transaction may be encrypted by a symmetric encryption algorithm or may be encrypted by an asymmetric encryption algorithm. The encryption algorithm used for symmetric encryption is, for example, DES algorithm, 3DES algorithm, TDEA algorithm, Blowfish algorithm, RC5 algorithm, IDEA algorithm, etc. Examples of asymmetric encryption algorithms are RSA, Elgamal, knapsack Algorithm, Rabin, D-H, ECC (elliptic curve encryption Algorithm), etc.

In one embodiment, the transaction may be encrypted by combining a symmetric encryption algorithm with an asymmetric encryption algorithm. Taking the example that the client submits the transaction to the first blockchain node, the client may encrypt the transaction content using a symmetric encryption algorithm, that is, encrypt the transaction content using a key of the symmetric encryption algorithm, and encrypt the key used in the symmetric encryption algorithm using an asymmetric encryption algorithm, for example, encrypt the key used in the symmetric encryption algorithm using a public key of the asymmetric encryption algorithm. Therefore, after the first block chain node receives the encrypted transaction, the first block chain node can firstly decrypt by using the private key of the asymmetric encryption algorithm to obtain the key of the symmetric encryption algorithm, and then decrypt by using the key of the symmetric encryption algorithm to obtain the transaction content.

When the transaction is used to invoke a smart contract, it may be an invocation of multiple nested structures. For example, a transaction directly calls intelligent contract 1, while the code of intelligent contract 1 calls intelligent contract 2, and the code in intelligent contract 2 points to the contract address of intelligent contract 3, so that the transaction actually indirectly calls the code of intelligent contract 3, while intelligent contract 3 includes some event function. Thus, it is equivalent to the event function included in the intelligent contract 1. The specific implementation process is similar to the above process, and is not described herein again.

Step 306A, the first blockchain node executes the smart contract in the trusted execution environment, resulting in receipt data, which includes a log corresponding to the special event function.

As described above, when executing the code of the intelligent contract, the first blockchain node generates a corresponding Logs field for each event function included in the code, that is, generates a log corresponding to each event function. By determining the special event function, the log corresponding to the special event function can be further determined, so that at least a part of log fields corresponding to the special event function are stored in a plaintext form.

In one embodiment, for example, in an ethernet, after receiving a transaction for invoking an intelligent contract sent by a client, the first block node may check whether the transaction is valid, whether the format is correct, whether the signature of the transaction is valid, and the like.

Typically, the nodes in the Etherhouse are also accounting contested nodes, and thus the first blockchain node can perform the transaction locally as accounting contested node. If one of the nodes competing for accounting rights wins the current round of accounting rights, the node becomes the accounting node. If the first block link point wins the accounting right in the current round, the first block link point becomes an accounting node; of course, if the first block link point does not win in the process of competing for accounting rights in the current round, it is not an accounting node, and other nodes may become accounting nodes.

An intelligent contract is similar to a class in object-oriented programming, with the result of execution generating a contract instance corresponding to the intelligent contract, similar to generating an object corresponding to a class. Executing code in the transaction to create the intelligent contract creates a contract account and deploys the contract in the account space. In the etherhouse, the address of the intelligent contract account is generated by an encryption algorithm by taking the address of the sender (e.g., "0 xf5e …" in fig. 1-2) and a transaction random number (nonce) as input, such as the contract address "0 x6f8ae93 …" in fig. 1-2, i.e., by the address of the sender "0 xf5e …" and the nonce in the transaction.

In general, in a blockchain network supporting intelligent contracts using consensus algorithms such as Proof of Work (POW) and Proof of equity (POS), Proof of commission (DPOS), nodes competing for accounting rights may execute a transaction including creation of an intelligent contract after receiving the transaction. One of the nodes competing for the accounting right wins the accounting right in the current round of the accounting right competition, and becomes the accounting node. The accounting node may 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 block chain network supporting an intelligent contract by using a Practical Byzantine Fault Tolerance (PBFT) mechanism and the like, nodes with the accounting right are already agreed before accounting in the current round. Therefore, after the first block link node receives the transaction, if the first block link node is not the accounting node of the current round, the transaction can be sent to the accounting node. For the accounting node of the current round (which may be the first blockchain node), the transaction may be performed during or before the process of packaging the transaction and generating the new tile, or during or before the process of packaging the transaction with other transactions and generating the new tile. After the accounting node packages the transaction (or packages other transactions together) and generates a new block, the generated new block or a block header is sent to other nodes for consensus.

As described above, in the blockchain network supporting the intelligent contract using the POW mechanism or the blockchain network supporting the intelligent contract using the POS, DPOS, or PBFT mechanisms, the accounting node in the current round may package the transaction and generate a new block, and send the block header after the generated new block to other nodes for consensus. If the other nodes verify that no problem exists after receiving the block, the new block can be added to the tail of the original block chain, so that the accounting process is completed, and consensus is achieved; and if the transaction is used for calling the intelligent contract, the calling and executing of the intelligent contract are finished. Other nodes may also perform transactions in the block while verifying the new block or block header sent by the accounting node.

The execution process may be generally performed by a virtual machine. Taking the ethernet house as an example, the support user creates and/or invokes some complex logic in the ethernet house network, which is the biggest challenge of the ethernet house to distinguish from the bitcoin blockchain technology. The core of an etherhouse as a programmable block chain is an Etherhouse Virtual Machine (EVM), and each etherhouse node can run the EVM. The EVM is a well-behaved virtual machine, which means that a variety of complex logic can be implemented through it. The user issuing and invoking smart contracts in the etherhouse is running on the EVM.

In this embodiment, the first block link point may execute the decrypted code of the smart contract in a Trusted Execution Environment (TEE). For example, as shown in fig. 4, the first block node may be divided into a regular execution environment (left side in the figure) and a TEE, a transaction submitted by a client (as described above, the transaction may have other sources; the transaction submitted by the client is taken as an example for explanation here) first enters a "transaction/query interface" in the regular execution environment to be identified, a transaction without a privacy processing requirement may be left in the regular execution environment to be processed (whether the privacy processing requirement exists may be identified here according to a user type of a transaction initiator, a transaction type, an identifier included in the transaction, and the like), and a transaction with the privacy processing requirement may be transferred to the TEE to be processed. The TEE is isolated from the regular execution environment. The transaction is in an encrypted state before entering the TEE, and is decrypted into plaintext transaction content in a trusted execution environment, so that the plaintext transaction content can be efficiently processed in the TEE on the premise of ensuring data security, and plaintext receipt data is generated in the TEE.

The TEE is a trusted execution environment that is based on a secure extension of the CPU hardware and is completely isolated from the outside. TEE was originally proposed by Global Platform to address the secure isolation of resources on mobile devices, providing a trusted and secure execution environment for applications parallel to the operating system. The Trust Zone technology of ARM realizes the real commercial TEE technology at the earliest. Along with the rapid development of the internet, the security requirement is higher and higher, and more requirements are provided for the TEE by mobile equipment, cloud equipment and a data center. The concept of TEE has also been developed and expanded at a high rate. The concept now referred to as TEE has been a more generalized TEE than the concept originally proposed. For example, server chip manufacturers Intel, AMD, etc. have introduced hardware-assisted TEE in turn and enriched the concept and characteristics of TEE, which have gained wide acceptance in the industry. The mention of TEE now is more generally directed to such hardware assisted TEE techniques. Unlike the mobile terminal, the cloud access requires remote access, and the end user is not visible to the hardware platform, so the first step of using the TEE is to confirm the authenticity and credibility of the TEE. Therefore, the current TEE technology introduces a remote attestation mechanism which is endorsed by a hardware manufacturer (mainly a CPU manufacturer) and ensures that a user can verify the TEE state through a digital signature technology. Meanwhile, the security requirement which cannot be met by only safe resource isolation is also met, and further data privacy protection is also provided. Commercial TEE including Intel SGX, AMD SEV also provide memory encryption techniques, limiting trusted hardware within the CPU, with the data of the bus and memory being ciphertext to prevent snooping by malicious users. For example, TEE technology such as intel's software protection extensions (SGX) isolates code execution, remote attestation, secure configuration, secure storage of data, and trusted paths for executing code. Applications running in the TEE are secured and are almost impossible to access by third parties.

Taking the Intel SGX technology as an example, SGX provides an enclosure (also called enclave), that is, an encrypted trusted execution area in memory, and a CPU protects data from being stolen. Taking the example that the first block link point adopts a CPU supporting SGX, a part of an area EPC (enclosure Page Cache, Enclave Page Cache, or Enclave Page Cache) may be allocated in the memory by using a newly added processor instruction, and data therein is encrypted by an Encryption engine mee (memory Encryption engine) in the CPU. The encrypted content in the EPC is decrypted into plaintext only after entering the CPU. Therefore, in the SGX, a user may not trust an operating System, a VMM (Virtual Machine Monitor), or even a BIOS (Basic Input Output System), and only need to trust the CPU to ensure that private data is not leaked. In practical application, the private data can be encrypted and then transmitted to the enclosure in a ciphertext form, and the corresponding secret key is transmitted to the enclosure through remote certification. Then, the operation is performed by using the data under the encryption protection of the CPU, and the result is returned in a ciphertext form. In this mode, not only can the powerful calculation be utilized, but also data leakage is not worried about.

As described above, by executing the decrypted transaction content in the TEE, the execution process may be assured of being completed within the trusted environment to ensure that private information is not revealed. When the transaction with the privacy processing requirement is used for creating the intelligent contract, the transaction comprises the code of the intelligent contract, and the first block link point can decrypt the transaction in the TEE to obtain the code of the intelligent contract contained in the transaction and further execute the code in the TEE. When the transaction requiring privacy processing is used for invoking the intelligent contract, the first block link point may execute the code in the TEE (if the invoked intelligent contract handles the encryption state, the intelligent contract needs to be decrypted in the TEE to obtain the corresponding code). Specifically, the first block link point may allocate a part of the area EPC in the memory by using a processor instruction newly added in the CPU, and encrypt the plaintext code by using an encryption engine MEE in the CPU and store the plaintext code in the EPC. The encrypted content in the EPC enters the CPU and is decrypted into plaintext. And in the CPU, the operation is carried out on the code of the plaintext, and the execution process is completed. For example, in SGX technology, the EVM may be loaded into the enclosure by executing the plaintext code of the smart contract. In the remote certification process, the key management server can calculate a hash value of the local EVM code, compare the hash value with the hash value of the EVM code loaded in the first block chain link point, and correctly use a comparison result as a necessary condition for passing the remote certification, thereby completing measurement of the code loaded on the SGX enclosure of the first block chain node. Measured, the correct EVM can execute the code of the intelligent contract described above in the SGX.

In step 304B, the first block link point determines a corresponding exposed field according to the transaction type of the transaction.

In one embodiment, a transaction may include a Type field (e.g., a Type field) whose value is used to indicate the corresponding transaction Type. Therefore, by reading the value of the type field included in the transaction, the transaction type, such as a deposit evidence type, an asset transfer (e.g., transfer) type, a contract creation type, a contract invocation type, etc., may be determined, which is not limited in this specification.

In one embodiment, there may be corresponding exposed fields for different types of transactions, respectively. The exposed fields are one or more fields specified in the receipt data, and on the premise that the receipt data needs ciphertext storage to protect privacy, the exposed fields which are indicated by the exposed identifiers in the logs corresponding to the special event functions and meet the preset conditions can be selectively stored in a plaintext form in combination with the fields indicated by the exposed identifiers, the matching conditions between the logs corresponding to the special event functions and the exposed fields, and the satisfaction conditions of the receipt content to the preset conditions, instead of storing all the fields indicated by the exposed identifiers or all the exposed fields in a plaintext form, so that the following operations such as retrieval and the like can be performed on the receipt content stored in the plaintext form while the privacy protection requirements are met.

In one embodiment, a mapping relationship between each transaction type and the exposed field may be predefined and recorded in the blockchain, so that the predefined mapping relationship may be obtained by the first blockchain node, and the exposed field in the receipt data may be further determined according to the transaction type and the mapping relationship of the transaction. For example, the exposed field corresponding To the evidence type may include all fields except the From field, the exposed field corresponding To the asset transfer type may include the To field, and the exposed fields corresponding To the contract creation type and the contract invocation type may include all fields except the From field, which is not described in detail herein for other transaction types.

The mapping relationship may be recorded in a system contract. The mapping relationship may also be recorded in a chain code of the blockchain network. The mapping relationship is recorded in the system contract, so that subsequent updating and upgrading aiming at the mapping relationship are facilitated, the mapping relationship recorded in the chain code is relatively difficult to realize updating and upgrading, and the subsequent description aiming at the difference between the mapping relationship and the chain code is omitted for the moment.

And 308, storing the receipt data by the first block chain link point, so that at least one part of receipt content in the log corresponding to the special event function is stored in a plaintext form, and the rest of the receipt content in the log is stored in a ciphertext form, wherein the at least one part of receipt content comprises an exposure field which is marked by the exposure identifier and meets a preset condition.

In the code of the smart contract, the exposure identifier may identify one or more fields that present corresponding receipt content in the receipt data. Different types of transactions often have different privacy protection requirements that may allow the corresponding exposed fields to be stored in clear text. When the special event function is executed, the receipt data includes a log corresponding to the special event function, and the log is actually part of the receipt content in the receipt data. Meanwhile, the transaction initiator can select a preset condition which is expected to be adopted according to actual requirements, and at least part of receipt content meeting the preset condition possibly exists in the receipt data. Therefore, the cross content of the four receipt contents can be screened out by comprehensively considering the exposure identifier, the transaction type, the special event function and the preset condition, the plaintext storage is implemented for the cross content, and the rest contents of the receipt data are stored by adopting the ciphertext.

The content of the preset condition may include at least one of: the corresponding receipt content comprises preset content, the value of the corresponding receipt content belongs to a preset numerical value interval and the like.

The preset contents may include: the specified one or more keywords, such as the keyword, may include a predefined state variable, a predefined event function, information indicating a transaction execution result, and the like, so that when the receipt content contains the information of the state variable, the event function, the transaction execution result, or the like as the keyword, it may be determined that the receipt content satisfies the preset condition.

The preset contents may include: a preset value. For example, the preset value may be a numerical value, and the numerical value may be compared with the value of the state variable, so as to determine whether the value of the state variable is expected; for another example, the preset value may be a character string composed of numeric values, letters, special symbols, and the like, and the character string may be compared with an account address of the transaction initiator, an account address of the transaction target, a log topic, and the like to identify a specific transaction initiator, a specific transaction target, or a specific log topic, and the like. By taking the preset content as a character string as an example, assuming that the character string is a certain account address, under the condition that a user as a transaction initiator belongs To a preset user type and the To field belongs To an exposed field, when the user initiates a transaction aiming at the account address and the To field is marked by an exposed identifier, the To field in the log is stored in a plaintext form, and other From fields and the like are stored in a ciphertext form, so that privacy disclosure is avoided.

The preset value interval can indicate the privacy protection requirement condition of the relevant receipt field, for example, in a transfer scene, the preset value interval can be a value interval with a smaller value and a lower privacy protection requirement, so that even if the relevant receipt field is disclosed, serious user privacy disclosure can not be caused, but the relevant operation such as a DAPP client side can be automatically triggered, and certain balance is achieved between privacy protection and convenience.

In one embodiment, the preset condition may include a general condition corresponding to all receipt fields in the receipt data, that is, when the receipt content corresponding to the field marked by the exposure identifier is in any receipt field in the receipt data, the general condition is used for comparing with the preset condition. For example, when the preset condition is "including a preset keyword", the receipt content corresponding to the field marked by the exposure identifier may be compared with the keyword included in the preset condition to determine the receipt content including the keyword as the receipt content satisfying the preset condition; when the receipt content corresponding to the field marked by the exposure identifier belongs to a certain receipt field, the receipt field may further contain other receipt content, and the receipt content is stored in a ciphertext form.

In an embodiment, the preset condition may include a dedicated condition corresponding to each receipt field in the receipt data, that is, there is a corresponding preset condition in each receipt field in the receipt data, and it is required to determine the corresponding preset condition and perform the comparison according to the receipt field in which the receipt content corresponding to the field marked by the exposure identifier is located. 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 may be "whether the preset condition includes the preset content", the preset content may be a preset account address indicating a transaction initiated by the account address, the preset condition corresponding to the Topic field may be "whether the preset condition belongs to a preset value interval", and the Topic field may record a value of a state variable referenced by a related event, for example, a state variable representing "transfer amount" may be included in a transfer scenario, indicating that the transfer amount is in the preset value interval; then: when the receipt content corresponding to the object marked by the exposure identifier is in the From field and the Topic field at the same time, the receipt content in the From field is suitable for being compared with a preset condition of 'whether the receipt content contains the preset content', and the receipt content in the Topic field is suitable for being compared with a preset condition of 'whether the receipt content belongs to a preset value interval'.

Since the exposed identifier is a global identifier defined in the programming language of the intelligent contract, it is difficult to modify the field marked by the exposed identifier whenever the exposed identifier is written in the intelligent contract. The preset condition is not necessarily realized in the intelligent contract where the exposed identifier is located based on the programming language, so that the limitation of the exposed identifier can be broken off by calling the intelligent contract by different users or adjusting the adopted preset condition, and the receipt content needing plaintext or ciphertext storage can be adjusted. For example:

in an embodiment, the preset condition may be located in the transaction (not in the code of the intelligent contract included in the transaction, and may be set when the transaction is created), so that even if different transactions invoke the same intelligent contract, the adopted preset condition may have a difference to meet the demand difference faced by different transactions; of course, the same preset conditions may be used for different transactions. The difference in the preset conditions may be represented as: the content of the preset condition, the receipt field to which the preset condition applies, and the difference of at least one dimension in the processing logic for judging whether the receipt content satisfies the preset condition.

In one embodiment, the preset condition may be located in the smart contract invoked for the transaction, so that the transaction may determine whether to use the preset condition by selecting the invoked smart contract; alternatively, the preset condition may be located in another intelligent contract B invoked by the intelligent contract a invoked for trading, so that the used preset condition may be changed by configuring the intelligent contract invoked by the intelligent contract a, for example, by switching the intelligent contract B to the intelligent contract C (the preset condition defined in the intelligent contract B is changed to the preset condition defined in the intelligent contract C). The intelligent contract can be created by the transaction initiator or any other user in advance; of course, if there is a corresponding invoking condition for the smart contract, it is necessary to enable the transaction to invoke the smart contract when the invoking condition is satisfied, for example, the invoking condition may include: the transaction initiator belongs to a preset white list, the transaction initiator does not belong to a preset black list or other conditions.

In one embodiment, the preset condition may be located in the system contract or the chain code, so that the preset condition is a global condition applicable to all transactions in the block chain, and is different from the preset condition included in the above-mentioned transaction or smart contract, so that even if the smart contract called by the transaction or transaction does not include the preset condition, it may be determined whether the receipt content corresponding to the field indicated by the exposed identifier is stored in a clear text form based on the preset condition defined in the system contract or the chain code.

It should be noted that: the preset conditions contained in the trading or intelligent contracts do not contradict the preset conditions contained in the chain codes or the system contracts: the two can respectively contain preset conditions with different dimensions, for example, receipt fields suitable for the preset conditions are different; alternatively, when there is a conflict between the preset conditions included in the two, it may be defaulted to preferentially adopt the preset conditions included in the transaction or the smart contract, or to preferentially adopt the preset conditions included in the chain code or the system contract, depending on the predefined selection logic.

Except the preset conditions, the transaction type is irrelevant to the programming language and can be selected by a user according to actual requirements; meanwhile, the definition of the special event function is not necessarily implemented based on a programming language, for example, when recording the special event function based on a special event function list or the like, even if a certain event function included in the intelligent contract originally belongs to the special event function, the original special event function can be updated to the ordinary event function by changing the special event function list, so that the log generated by the event function is prevented from being stored in a plaintext form, or the original ordinary event function is updated to the special event function, so that at least a part of the content in the log generated by the event function is stored in a plaintext form.

Taking the code example 2 as an example: assuming that the event currentPrice is not originally recorded in the special event function list, that is, the event currentPrice corresponds to the ordinary event function, even if the exposure identifier place is added to the code of the smart contract and the From field belongs to the exposure field, each field (including the exposure field) in the log generated by the event currentPrice is stored in a ciphertext form. However, if the event currentPrice is added to the special event function list, the code example 2 can store the exposed field in the log corresponding to the event currentPrice in a plaintext form without adjustment; for example, when the From field and the To field are exposed fields, the From field and the To field in the log generated by the event currentPrice are stored in a plain text form, and the rest fields are stored in a cipher text form.

It should be noted that: in the code example 2 described above, by declaring "plain" at the very front of the code, the fields designated by the exposed identifier "plain" are all fields in the receipt data, and these fields are both contract-level fields, so that when the first blockchain node stores the receipt data, all the receipt contents in the receipt data corresponding to the contract-level fields are allowed to be stored in clear text. Of course, if the code example 2 is labeled with, for example, a From field through an exposure identifier, the From field is the contract level field mentioned above, and when the From field further belongs to the exposure field corresponding to the transaction type, the first blockchain node can be enabled to store all the receipt contents, which correspond to the From field and satisfy the preset condition, in the receipt data in a clear text form when storing the receipt data.

When a plurality of event functions are included in the code of the intelligent contract, exposed fields belonging to contract-level fields may exist in Logs fields respectively corresponding to the event functions; further, all exposed fields belonging to the contract-level field in the log generated by the special event function can be stored in a clear text form by identifying the type of each event function as a general event function or a special event function. For example, a smart contract may include code example 3 as follows:

plain Contract Example{

int price；

int price1；

event currentPrice1(int price)；

event currentPrice2(int price1)；

…

in code example 3 above, similar to code example 2, the exposed identifier "plain" is at the very front of the code for the smart contract, such that all fields in the receipt data are labeled as contract-level fields; meanwhile, the intelligent contract comprises an event currentPrice1 and an event currentPrice 2: assuming that the From field is an exposed field corresponding to the transaction type, the event currentPrice1 corresponds to a special event function defined in the special event function list, and the event currentPrice2 corresponds to a normal event function, in logs 1 and 2 respectively generated by the event currentPrice1 and the event currentPrice2, the From field contained in the Log1 is stored in a plain text form and the From field contained in the Log2 is stored in a cipher text form when a preset condition is met; similarly, other fields in Log1 that belong to exposed fields are also stored in plaintext form, non-exposed fields are stored in ciphertext form, and all fields of Log2 are stored in ciphertext form. And, if the event currentPrice2 is updated to correspond to the special event function after the special event function list is updated, all the fields contained in the Log2, which belong to the exposed fields and satisfy the preset condition, will be stored in the clear without any change to the code of the smart contract.

For the contract level field described above, whether the event function included in the intelligent contract is a special event function can be indicated by the type identifier described above. For example, the above code example 3 may be adjusted to the following code example 4:

plain Contract Example{

int price；

int price1；

event currentPrice1expose(int price)；

event currentPrice2(int price1)；

…

in code example 4 described above, similar to code example 2, the contract-level fields include all fields in the receipt data; meanwhile, the intelligent contract comprises an event currentPrice1 and an event currentPrice 2: since the event currentPrice1 contains the type identifier expose as described above, so that the event currentPrice1 is labeled as corresponding to a special event function, and the event currentPrice2 does not contain the type identifier expose, so that the event currentPrice2 is labeled as corresponding to a normal event function, in the logs 1 and 2 respectively generated by the event currentPrice1 and the event currentPrice2, all exposed fields in the Log1 corresponding to the transaction type are stored in a plain text form, and all fields contained in the Log2 are necessarily stored in a cipher text form if preset conditions are met.

Although the type identifier and the exposed identifier are similar and are all global identifiers defined in a programming language of the intelligent contract, the exposed identifier acts on the contract level field, and the type identifier acts on the event function, so that by using the exposed identifier and the type identifier together, the contract level field can be set and formed only by adding the exposed identifier once, and further the event function which wants to store the contract level field in the clear text can be flexibly marked.

In addition to contract level fields, the fields designated by the exposure identifier may include: and the event-level field corresponds to at least one event defined in the intelligent contract, so that when the first blockchain node stores the receipt data, the first blockchain node can determine a log generated by a special event function corresponding to the at least one event, and store an exposed field which belongs to the event-level field and meets a preset condition in the determined log in a plaintext form. In particular, when a plurality of events are included in the smart contract, the event level field may be set for at least a part of the events, so that the exposed fields that belong to the event level field and satisfy the preset condition in the log corresponding to the part of the events are stored in a plaintext form, and the other fields in the log corresponding to the part of the events and the receipt contents corresponding to the other events are stored in a ciphertext form. Taking the From field as an example, the above code example 4 can be adjusted to the following code example 5:

Contract Example{

int price；

int price1；

event currentPrice1(“from”,int price)；

event currentPrice2(int price1)；

…

in the above-described code example 5, the event currentPrice1 contains the content "From" corresponding to the From field indicating that the From field in the log generated by the event currentPrice1 needs to be stored in plaintext although the exposure identifier "plain" is not added, and thus the content "From" belongs to both the exposure identifier described above and the From field that needs to be stored in plaintext. And, since the content "From" is located 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, in the log Logs correspondingly generated by the event currentPrice1, the From field will be stored in a plaintext form if a preset condition is satisfied, stored in a ciphertext form if the preset condition is not satisfied, and other fields are necessarily stored in a ciphertext form. However, for another event currentPrice2 included in code example 5, since an exposure identifier is not added for this event currentPrice2, the generated log Logs are stored in a ciphertext form regardless of whether this event currentPrice2 corresponds to a special event function or a general event function.

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

Contract Example{

int price；

int price1；

plain event currentPrice1(int price)；

event currentPrice2(int price1)；

…

in the above-described code example 6, by adding the exposure identifier "plain" before the event currentPrice1, all fields in the Log generated by the event currentPrice1 can be regarded as the above-described event-level fields, such as the above-described From field, To field, Topic field, Log Data field, and the like. Then, when the event currentPrice1 corresponds to a special event function, a log field belonging to both the event level field and the exposure field corresponding to the transaction type may be determined from the log generated by the event currentPrice1, and stored in a plaintext form when the determined log field satisfies a preset condition; if the From field, To field, Topic field, Log Data field, etc. are all exposed fields and satisfy the preset condition, it is equivalent To store all the receipt contents (such as the generated Log) corresponding To the event currentPrice1 in a clear text form.

In the embodiments corresponding to the code examples 5 to 6, that is, for the event level field, whether the event function included in the intelligent contract is a special event function may be identified by using a special event function list or a type identifier, which is not described herein again.

The present specification serves to implement a driver or other functional extension to the DAPP client by exposing the receipt content to some extent. In addition, the field for plaintext storage can be accurately selected by comprehensively considering the conditions of meeting the preset conditions of the field marked by the exposure identifier, the exposure field corresponding to the transaction type, the log generated by the special event function and the receipt content, namely, the fields matched with the field marked by the exposure identifier, the transaction type, the log generated by the special event function and the receipt content meeting the preset conditions are met, so that most of the user privacy can be protected while the function expansion requirements are met. In particular, when the first blockchain node identifies the special event function according to information (such as a special event function list) recorded on the blockchain network, the storage manner of the receipt data can be adjusted by updating the "special event function" after the intelligent contract has been created, for example, the receipt content stored in the original plain text is changed to the ciphertext storage, or the receipt content stored in the original ciphertext is changed to the plain text storage.

By running program code (hereinafter simply referred to as chain code) of a blockchain on a computing device (physical or virtual machine), the computing device can be configured as a blockchain link point in a blockchain network, such as the first blockchain node described above, or the like. In other words, the first block link point implements the corresponding functional logic by running the above-mentioned chain code. Thus, the receipt data storage logic described above in relation to the exposure identifier, transaction type, event function and preset conditions may be written into the chain code when creating the blockchain network, such that each blockchain link point may implement the receipt data storage logic; taking the first blockchain node as an example, the receipt data storage logic associated with the exposure identifier, the transaction type, the event function and the preset condition may include: identification logic for transaction type, identification logic for event function, determination logic for preset conditions, and logic for storing receipt content based on the exposure identifier.

The identification logic for the transaction type is to instruct the first blockchain node to: a type of transaction initiated by a transaction initiator is identified. Such as: and determining the transaction type corresponding to the transaction according to the value of the type field contained in the transaction. Reference may be made to the above description for identifying the transaction type, which is not repeated herein.

The identification logic to the event function is to instruct the first blockchain node to: the type of event function included in the smart contract corresponding to the transaction is identified. Such as: the identification is carried out according to a type identifier contained in the event function or according to a special event function list recorded in the block chain network. Specifically, reference may be made to the above description for identifying the special event function, which is not described herein again.

The determination logic for the preset condition is to instruct the first blockchain node to: and acquiring preset conditions applicable to the receipt content corresponding to the object marked by the exposure identifier. Such as: the method comprises the steps of acquiring a general condition applicable to all receipt fields, or acquiring a special condition applicable to a field where receipt content corresponding to an object marked by an exposed identifier is located, and the like. Specifically, reference may be made to the above description related to the preset condition, which is not described herein again.

Logic to store receipt content based on the exposure identifier is to instruct the first blockchain node to: the corresponding receipt content is stored in what manner for the fields marked by the exposure identifier, the fields not marked by the exposure identifier, and the like. Such as: for the identified special event function, the exposed field which is marked by the exposed identifier and meets the preset condition in the log generated by the special event function is stored in a plaintext form, the rest part of the log is stored in a ciphertext form, and other receipt contents in the receipt data are stored in the ciphertext form.

However, upgrading and updating of the chain code are relatively difficult, so that the chain code is adopted to realize storage of the receipt data, and the problems of low flexibility and insufficient expandability exist. In order to implement the functional extension of the chain code, as shown in fig. 5, the chain code may be combined with a system contract: the chain code is used for realizing basic functions of the block chain network, and the function extension in the running process can be realized in a system contract mode. Similar to the above-mentioned smart contract, the system contract includes code in the form of byte code, for example, and the first block link node may be functionally complementary to the chain code by running the code of the system contract (for example, reading the code in the system contract according to the uniquely corresponding address "0 x53a98 …"). Accordingly, the first block link point may read code of a system contract, the code of the system contract defining receipt data storage logic associated with the exposure identifier, the transaction type, the event function, and the preset condition; then, the first block link point may execute code of a system contract to store at least a portion of receipt content in a log corresponding to the special event function in plaintext form and the remainder of the receipt data in ciphertext form based on receipt data storage logic associated with the exposure identifier, the transaction type, the event function, and the preset condition, the at least a portion of receipt content including an exposure field designated by the exposure identifier and satisfying the preset condition.

Unlike the above-described intelligent contracts issued by users to blockchains, 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 a founder block of the blockchain network; and an administrator (i.e., the above-mentioned administrative user) in the blockchain network may have an update authority for the system contract, so as to perform an update for a preset system contract such as the above-mentioned system contract, the system contract read by the above-mentioned first blockchain node may further include a corresponding updated system contract. Certainly, the updated system contract can be obtained by the administrator by performing one-time update on the preset system contract; or, the updated system contract may be obtained by performing multiple iterative updates on the preset system contract by the administrator, for example, the preset system contract is updated to obtain the system contract 1, the system contract 1 is updated to obtain the system contract 2, and the system contract 2 is updated to obtain the system contract 3, where the system contract 1, the system contract 2, and the system contract 3 may all be regarded as the updated system contract, but the first block link point generally is subject to the latest version of the system contract, for example, the first block link node is subject to the code in the system contract 3, but not the code in the system contract 1 or the system contract 2.

In addition to the preset system contracts contained in the foundational blocks, the administrator may also publish system contracts within subsequent blocks and make updates to the published system contracts. In summary, a certain degree of restriction should be imposed on the issuance and updating of system contracts by means such as rights management to ensure that the functional logic of the blockchain network is functioning properly and to avoid unnecessary loss to any user.

The first block link point encrypts at least a portion of the receipt content with a key. The encryption can adopt symmetric encryption or asymmetric encryption. If the first blockchain node encrypts the receipt content in a symmetric encryption manner, i.e., using the symmetric key of the symmetric encryption algorithm, the client (or other object holding the key) can decrypt the encrypted receipt content using the symmetric key of the symmetric encryption algorithm.

When the first blockchain node encrypts the receipt content with the symmetric key of the symmetric encryption algorithm, the symmetric key may be provided to the first blockchain node in advance by the client. Then, only the client (which should actually be the user corresponding to the logged-in account on the client) and the first block link point grasp the symmetric key, so that only the client can decrypt the corresponding encrypted receipt content, and an unrelated user or even a lawbreaker is prevented from decrypting the encrypted receipt content.

For example, when the client initiates a transaction to the first block link node, the client may encrypt the transaction content with an initial key of a symmetric encryption algorithm to obtain the transaction; accordingly, the first tile chain node may be used to directly or indirectly encrypt the receipt content by obtaining the initial key. For example, the initial key may be pre-negotiated 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 to the first block chain node by the client, the client can encrypt the initial key by the public key of the asymmetric encryption algorithm and then send the encrypted initial key to the first block chain node, and the first block chain node decrypts the encrypted initial key by the private key of the asymmetric encryption algorithm to obtain the initial key, that is, the digital envelope encryption described above, which is not described herein again.

The first tile link point may encrypt the receipt content using the initial key described above. The initial keys used for different transactions may be the same, so that all transactions submitted by the same user are encrypted using the initial keys, or the initial keys used for different transactions may be different, for example, the client may randomly generate an initial key for each transaction, so as to improve security.

The first tile chain node may generate a derivative key based on the initial key and the impact factor, and encrypt the receipt content with the derivative key. Compared with the method that the initial key is directly adopted for encryption, the derived key can increase the randomness, so that the difficulty of being broken is improved, and the safety protection of data is optimized. The impact factor may be related to the transaction; for example, the impact factor may include designated bits of the transaction hash value, such as the first chunk nexus may concatenate the initial key with the first 16 bits (or the first 32 bits, the last 16 bits, the last 32 bits, or other bits) of the transaction hash value and hash the concatenated string to generate the derivative key.

The first block link point can also adopt an asymmetric encryption mode, namely, the receipt content is encrypted by using a public key of an asymmetric encryption algorithm, and accordingly, the client can decrypt the encrypted receipt content by using a private key of the asymmetric encryption algorithm. The key of the asymmetric encryption algorithm may be, for example, a pair of a public key and a private key generated by the client, and the public key is sent to the first blockchain node in advance, so that the first blockchain node may encrypt the receipt content with the public key.

The first block link point implements a function by running code for implementing the function. Thus, for functions that need to be implemented in the TEE, the relevant code needs to be executed as well. For code executed in the TEE, relevant specifications and requirements of the TEE need to be met; accordingly, for codes used for realizing a certain function in the related art, code writing needs to be performed again in combination with the specification and requirements of the TEE, so that not only is a relatively large development amount, but also a bug (bug) is easily generated in the rewriting process, and reliability and stability of function realization are affected.

Thus, a first block link point may store receipt data generated in the TEE (including receipt content in plain text requiring plain text storage, and receipt content in cipher text requiring cipher text storage) to an external storage space outside the TEE by executing a store function code outside the TEE, so that the storage function code can be the code used for realizing the storage function in the related art, does not need to be re-written with the specification and requirement of the TEE, the receipt data can be safely and reliably stored, the development amount of related codes can be reduced on the basis of not influencing the safety and reliability, furthermore, the TCB (Trusted Computing Base) can be reduced by reducing the related codes of the TEE, so that the additional security risk caused by the combination of the TEE technology and the block chain technology is in a controllable range.

In one embodiment, the first block chain node may execute a write cache function code within the TEE to store the receipt data described above in a write cache within the TEE, such as may correspond to a "cache" as shown in fig. 2. Further, the first block chain node outputs the data in the write cache from the trusted execution environment to be stored in the external storage space. The writing cache function code can be stored in the TEE in a plaintext form, and the cache function code in the plaintext form can be directly executed in the TEE; alternatively, the write cache function code may be stored outside the TEE in a ciphertext form, such as in the external storage space (for example, "pack + store" shown in fig. 2, where "pack" indicates that the first blockchain node packs the transaction into blocks outside the trusted execution environment), and the write cache function code in the ciphertext form may be read into the TEE, decrypted in the TEE into a plaintext code, and executed.

Write caching refers to a "buffering" mechanism provided to avoid causing a "shock" to an external storage space when data is written to the external storage space. For example, the above write cache may be implemented by using a buffer; of course, the write cache may also be implemented by using a cache, which is not limited in this specification. In fact, because the TEE is an isolated security environment and the external storage space is located outside the TEE, the external storage space can be written into the data in the cache in batches by adopting a cache writing mechanism, so that the interaction times between the TEE and the external storage space are reduced, and the data storage efficiency is improved. Meanwhile, the TEE may need to call generated data in the process of continuously executing each transaction, and if the data needing to be called is just located in the write cache, the data can be directly read from the write cache, so that on one hand, interaction with an external storage space can be reduced, on the other hand, a decryption process of the data read from the external storage space is omitted, and therefore the data processing efficiency in the TEE is improved.

Of course, the write cache may also be established outside the TEE, for example, the first tile chain node may execute the write cache function code outside the TEE, so as to store the receipt data in the write cache outside the TEE, and further store the data in the write cache to the external storage space.

An embodiment of a conditional receipt store node that combines code labeling and type dimensions of the present specification is described below in conjunction with FIG. 6, including:

a receiving unit 61 that receives encrypted transactions corresponding to smart contracts, the smart contracts having a code including a field designated by an exposed identifier;

a decryption unit 62 that decrypts the transaction in a trusted execution environment to obtain the smart contract, the smart contract containing a special event function;

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

a determining unit 64 for determining the corresponding exposed field according to the transaction type of the transaction;

and the storage unit 65 is used for storing the receipt data, so that at least one part of receipt content in the log corresponding to the special event function is stored in a plaintext form, and the rest of the receipt content in the log is stored in a ciphertext form, wherein the at least one part of receipt content comprises an exposure field which is marked by the exposure identifier and meets a preset condition.

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

intelligent contracts written in a high-level language; or the like, or, alternatively,

an intelligent contract in bytecode.

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

and the compiling unit 66 is used for compiling the intelligent contract written in the high-level language through a compiler to generate the intelligent contract in a byte code form so as to execute in the trusted execution environment.

Optionally, when the intelligent contract corresponding to the transaction received by the first blockchain node is an intelligent contract in a byte code form, the intelligent contract in the byte code form is compiled by the client through a compiler on an intelligent contract written in a high-level language, and the intelligent contract written in the high-level language is compiled by the user on the client.

Optionally, the intelligent contract written in the high-level language has the same or corresponding exposed identifier as the intelligent contract in bytecode.

the intelligent contract generated by the user on the first block chain node; or the like, or, alternatively,

intelligent contracts generated by users on clients; or the like, or, alternatively,

and the client sends the intelligent contract in the transaction through the second blockchain node.

Optionally, the fields marked by the exposure identifier include: a contract level field; the storage unit 65 is specifically configured to:

when the receipt data is stored, all exposed fields which belong to the contract level fields and meet the preset conditions in the logs generated by the special event functions are stored in a plaintext form.

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

and when the receipt data is stored, determining a log generated by a special event function corresponding to the at least one event, and storing an exposed field which belongs to the event-level field and meets a preset condition in the determined log in a plaintext form.

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

Optionally, the transaction type of the transaction includes: a deposit evidence type, an asset transfer type, a contract creation type, and a contract invocation type.

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

Optionally, the event function in the intelligent contract includes a type identifier, and the type identifier is used for marking the event function as a special event function.

Optionally, when the event function included in the intelligent contract is located in a special function list recorded on the blockchain, the event function included in the intelligent contract is determined as a special event function.

Optionally, the preset condition includes at least one of: the corresponding receipt content comprises preset content, and the value of the corresponding receipt content belongs to a preset numerical value interval.

Alternatively to this, the first and second parts may,

the preset conditions comprise general conditions corresponding to all receipt fields in the receipt data; or the like, or, alternatively,

the preset conditions comprise special conditions corresponding to each receipt field in the receipt data.

Alternatively to this, the first and second parts may,

the preset condition is located in the transaction; or the like, or, alternatively,

the preset condition is positioned in the intelligent contract corresponding to the transaction or another intelligent contract called by the intelligent contract corresponding to the transaction; or the like, or, alternatively,

the preset condition is located in a system contract or a chain code.

Optionally, the storage unit 65 is specifically configured to:

reading code of a system contract, the code of the system contract defining receipt data storage logic associated with the exposure identifier, the transaction type, the special event function, and the preset condition;

code for executing the system contract to store at least a portion of receipt content in the log corresponding to the special event function in plaintext form and the remainder of the receipt data in ciphertext form, the at least a portion of receipt content including an exposed field designated by the exposed identifier and satisfying a predetermined condition.

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

Optionally, the storage unit 65 is specifically configured to:

executing storage function code outside the trusted execution environment to store the receipt data to an external storage space outside the trusted execution environment.

Optionally, the key for encrypting the receipt data by the first block link point 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 comprises the initial key and a derivative key generated by the 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:

and decrypting by using a private key of the asymmetric encryption algorithm to obtain the initial key, and decrypting the transaction by using 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 a key management server.

Optionally, the impact factor is associated with the transaction.

Optionally, the influence factor includes: a specified bit of the hash value for the transaction.

In the 90 s of the 20 th century, improvements in a technology could clearly distinguish between improvements in hardware (e.g., improvements in circuit structures such as diodes, transistors, switches, etc.) and improvements in software (improvements in process flow). However, as technology advances, many of today's process flow improvements have been seen as direct improvements in hardware circuit architecture. Designers almost always obtain the corresponding hardware circuit structure by programming an improved method flow into the hardware circuit. Thus, it cannot be said that an improvement in the process flow cannot be realized by hardware physical modules. For example, a Programmable Logic Device (PLD), such as a Field Programmable Gate Array (FPGA), is an integrated circuit whose Logic functions are determined by programming the Device by a user. A digital system is "integrated" on a PLD by the designer's own programming without requiring the chip manufacturer to design and fabricate application-specific integrated circuit chips. Furthermore, nowadays, instead of manually making an Integrated Circuit chip, such Programming is often implemented by "logic compiler" software, which is similar to a software compiler used in program development and writing, but the original code before compiling is also written by a specific Programming Language, which is called Hardware Description Language (HDL), and HDL is not only one but many, such as abel (advanced Boolean Expression Language), ahdl (alternate Hardware Description Language), traffic, pl (core universal Programming Language), HDCal (jhdware Description Language), lang, Lola, HDL, laspam, hardward Description Language (vhr Description Language), vhal (Hardware Description Language), and vhigh-Language, which are currently used in most common. It will also be apparent to those skilled in the art that hardware circuitry that implements the logical method flows can be readily obtained by merely slightly programming the method flows into an integrated circuit using the hardware description languages described above.

The controller may be implemented in any suitable manner, for example, the controller may take the form of, for example, a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro) processor, logic gates, switches, an Application Specific Integrated Circuit (ASIC), a programmable logic controller, and an embedded microcontroller, examples of which include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicone Labs C8051F320, the memory controller may also be implemented as part of the control logic for the memory. Those skilled in the art will also appreciate that, in addition to implementing the controller as pure computer readable program code, the same functionality can be implemented by logically programming method steps such that the controller is in the form of logic gates, switches, application specific integrated circuits, programmable logic controllers, embedded microcontrollers and the like. Such a controller may thus be considered a hardware component, and the means included therein for performing the various functions may also be considered as a structure within the hardware component. Or even means for performing the functions may be regarded as being both a software module for performing the method and a structure within a hardware component.

The systems, devices, modules or units illustrated in the above embodiments may be implemented by a computer chip or an entity, or by a product with certain functions. One typical implementation device is a computer. In particular, the computer may be, for example, a personal computer, a laptop computer, a cellular telephone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.

For convenience of description, the above devices are described as being divided into various units by function, and are described separately. Of course, the functions of the various elements may be implemented in the same one or more software and/or hardware implementations of the present description.

As will be appreciated by one skilled in the art, embodiments of the present invention may be provided as a method, system, or computer program product. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present invention may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.

The present invention is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

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

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

These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks. In a typical configuration, a computer includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.

The memory may include forms of volatile memory in a computer readable medium, Random Access Memory (RAM) and/or non-volatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of a computer-readable medium.

Computer-readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), Read Only Memory (ROM), Electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), Digital Versatile Discs (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 medium that can be used to store information that can be accessed by a computing device. As defined herein, a computer readable medium does not include a transitory computer readable medium such as a modulated data signal and a carrier wave.

It should also be noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element.

The foregoing description has been directed to specific embodiments of this disclosure. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims may be performed in a different order than in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing may also be possible or may be advantageous.

The terminology used in the description of the one or more embodiments is for the purpose of describing the particular embodiments only and is not intended to be limiting of the description of the one or more embodiments. As used in one or more embodiments of the present specification and the appended claims, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should also be understood that the term "and/or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items.

It should be understood that although the terms first, second, third, etc. may be used in one or more embodiments of the present description to describe various information, such information should not be limited to these terms. These terms are only used to distinguish one type of information from another. For example, first information may also be referred to as second information, and similarly, second information may also be referred to as first information, without departing from the scope of one or more embodiments herein. The word "if" as used herein may be interpreted as "at … …" or "when … …" or "in response to a determination", depending on the context.

The above description is only for the purpose of illustrating the preferred embodiments of the one or more embodiments of the present disclosure, and is not intended to limit the scope of the one or more embodiments of the present disclosure, and any modifications, equivalent substitutions, improvements, etc. made within the spirit and principle of the one or more embodiments of the present disclosure should be included in the scope of the one or more embodiments of the present disclosure.

Claims

1. A conditional receipt store method that combines code labeling with a type dimension, comprising:

the first block chain node determines a corresponding exposed field according to the transaction type of the transaction and a mapping relation between a predefined transaction type and the exposed field;

2. The method of claim 1, the first blockchain node receiving a smart contract corresponding to the transaction, comprising:

an intelligent contract in bytecode.

3. The method of claim 2, when the intelligent contract corresponding to the transaction received by the first blockchain node is an intelligent contract written in a high-level language, the method further comprising:

the first block chain link point compiles the intelligent contract written in the high-level language through a compiler to generate the intelligent contract in a byte code form to be executed in the trusted execution environment.

4. The method of claim 2, wherein when the intelligent contract corresponding to the transaction received by the first blockchain node is a byte-code intelligent contract, the byte-code intelligent contract is compiled by the client through a compiler on a high-level language intelligent contract, and the high-level language intelligent contract is compiled by the user on the client.

5. The method of claim 2, the high-level language written smart contract having the same or corresponding exposed identifier as the bytecode-style smart contract.

6. The method of claim 1, the first blockchain node receiving a smart contract corresponding to the transaction, comprising:

7. The method of claim 1, wherein exposing the identifier-designated field comprises: a contract level field; a first block link point storing the receipt data, comprising:

and when the receipt data is stored, the first blockchain node stores exposed fields which belong to the contract level fields and meet preset conditions in the logs generated by all special event functions in a plaintext form.

8. The method of claim 1, wherein exposing the identifier-designated field comprises: an event-level field corresponding to at least one event defined in the smart contract; a first block link point storing the receipt data, comprising:

when the first block chain node stores the receipt data, determining a log generated by a special event function corresponding to the at least one event, and storing an exposed field which belongs to the event-level field and meets a preset condition in the determined log in a plaintext form.

9. The method of claim 1, the transaction comprising a type field, a value of the type field indicating a corresponding transaction type.

10. The method of claim 1, the transaction type of the transaction comprising: a deposit evidence type, an asset transfer type, a contract creation type, and a contract invocation type.

11. The method of claim 1, wherein a mapping relationship between predefined transaction types and exposed fields is stored in a blockchain, and the mapping relationship is used for determining the exposed fields corresponding to the transaction types of the transactions.

12. The method of claim 1, wherein an event function in the intelligent contract comprises a type identifier that is used to mark the event function as a special event function.

13. The method according to claim 1, wherein the event function contained in the intelligent contract is determined as a special event function when the event function contained in the intelligent contract is located in a special function list recorded on a blockchain.

14. The method of claim 1, the preset condition comprising at least one of: the corresponding receipt content comprises preset content, and the value of the corresponding receipt content belongs to a preset numerical value interval.

15. The method of claim 1, wherein the first and second light sources are selected from the group consisting of,

16. The method of claim 1, wherein the first and second light sources are selected from the group consisting of,

the preset condition is located in a system contract or a chain code.

17. The method of claim 1, a first block link point storing the receipt data, comprising:

code for reading a system contract at a first block link point, the code for the system contract defining receipt data storage logic associated with an exposure identifier, a transaction type, a special event function, and a preset condition;

the first block chain node executes the code of the system contract to store at least a part of receipt content in a plain text form and the rest of the receipt data in a cipher text form in the log corresponding to the special event function, wherein the at least a part of receipt content comprises an exposure field which is marked by the exposure identifier and meets a preset condition.

18. The method of claim 17, the system contract comprising: the preset system contract recorded in the creation block or the updated system contract corresponding to the preset system contract.

19. The method of claim 1, a first block link point storing the receipt data, comprising:

the first blockchain node executes storage function code outside the trusted execution environment to store the receipt data to an external storage space outside the trusted execution environment.

20. The method of claim 1, the key for the first block chain node to encrypt the receipt data comprising: a key of a symmetric encryption algorithm or a key of an asymmetric encryption algorithm.

21. The method of claim 20, the key of the symmetric encryption algorithm comprising a client-provided initial key that initiates the transaction; or, the key of the symmetric encryption algorithm comprises the initial key and a derivative key generated by the influence factor.

22. The method of claim 21, the transaction is encrypted by the initial key, and the initial key is encrypted by a public key of an asymmetric encryption algorithm; the first blockchain node decrypts the transaction in the trusted execution environment, including:

and the first blockchain node decrypts by using a private key of the asymmetric encryption algorithm to obtain the initial key, and decrypts the transaction by using the initial key to obtain the transaction content of the transaction.

23. The method of claim 21, the initial key is generated by a client; or, the initial key is sent to the client by a key management server.

24. The method of claim 21, the impact factor being related to the transaction.

25. The method of claim 24, the impact factor comprising: a specified bit of the hash value for the transaction.

26. A conditional receipt storage node that combines code labeling with a type dimension, comprising:

the determining unit is used for determining the corresponding exposed field according to the transaction type of the transaction and the mapping relation between the predefined transaction type and the exposed field;

27. An electronic device, comprising:

a processor;

a memory for storing processor-executable instructions;

wherein the processor implements the method of any one of claims 1-25 by executing the executable instructions.

28. A computer readable storage medium having stored thereon computer instructions which, when executed by a processor, carry out the steps of the method according to any one of claims 1 to 25.