WO2020233421A1 - 基于代码标注的对象级收据存储方法和节点 - Google Patents

基于代码标注的对象级收据存储方法和节点 Download PDF

Info

Publication number
WO2020233421A1
WO2020233421A1 PCT/CN2020/089381 CN2020089381W WO2020233421A1 WO 2020233421 A1 WO2020233421 A1 WO 2020233421A1 CN 2020089381 W CN2020089381 W CN 2020089381W WO 2020233421 A1 WO2020233421 A1 WO 2020233421A1
Authority
WO
WIPO (PCT)
Prior art keywords
event
receipt
smart contract
transaction
field
Prior art date
Application number
PCT/CN2020/089381
Other languages
English (en)
French (fr)
Inventor
刘琦
闫莺
魏长征
Original Assignee
创新先进技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from CN201910419924.8A external-priority patent/CN110247895B/zh
Priority claimed from CN201910420666.5A external-priority patent/CN110263091B/zh
Priority claimed from CN201910419913.XA external-priority patent/CN110245503B/zh
Priority claimed from CN201910420663.1A external-priority patent/CN110245946B/zh
Priority claimed from CN201910419928.6A external-priority patent/CN110245945B/zh
Priority claimed from CN201910419897.4A external-priority patent/CN110278193B/zh
Priority claimed from CN201910420679.2A external-priority patent/CN110266644B/zh
Priority claimed from CN201910419907.4A external-priority patent/CN110263088B/zh
Priority claimed from CN201910420668.4A external-priority patent/CN110264198B/zh
Priority claimed from CN201910419887.0A external-priority patent/CN110264195B/zh
Priority claimed from CN201910419755.8A external-priority patent/CN110263543B/zh
Priority claimed from CN201910419900.2A external-priority patent/CN110245490B/zh
Priority claimed from CN201910419893.6A external-priority patent/CN110264196B/zh
Priority claimed from CN201910419898.9A external-priority patent/CN110263087B/zh
Priority claimed from CN201910419908.9A external-priority patent/CN110223172B/zh
Application filed by 创新先进技术有限公司 filed Critical 创新先进技术有限公司
Publication of WO2020233421A1 publication Critical patent/WO2020233421A1/zh

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof

Definitions

  • One or more embodiments of this specification relate to the field of blockchain technology, and in particular to an object-level receipt storage method and node based on code annotation.
  • Blockchain technology is built on a transmission network (such as a peer-to-peer network).
  • the network nodes in the transmission network use chained data structures to verify and store data, and use distributed node consensus algorithms to generate and update data.
  • TEE Trusted Execution Environment
  • TEE can play the role of a black box in the hardware. Neither the code executed in the TEE nor the data operating system layer can be peeped. Only the pre-defined interface in the code can operate on it.
  • plaintext data is calculated in TEE instead of complex cryptographic operations in homomorphic encryption. There is no loss of efficiency in the calculation process. Therefore, the combination with TEE can achieve less performance loss. Under the premise, the security and privacy of the blockchain are greatly improved. At present, the industry is very concerned about TEE solutions.
  • TEE solutions including TPM (Trusted Platform Module) for software and Intel SGX (Software Guard Extensions) for hardware. , Software Protection Extension), ARM Trustzone (trust zone) and AMD PSP (Platform Security Processor, platform security processor).
  • one or more embodiments of this specification provide an object-level receipt storage method and node based on code annotation.
  • an object-level receipt storage method based on code annotation including:
  • the first blockchain node receives an encrypted transaction corresponding to a smart contract, and the code of the smart contract includes an object marked by an exposed identifier;
  • the first blockchain node decrypts the transaction in the trusted execution environment to obtain the code of the smart contract
  • the first blockchain node executes the code of the smart contract in the trusted execution environment to obtain receipt data
  • the first blockchain node stores the receipt data so that at least part of the receipt content corresponding to the object indicated by the exposure identifier is stored in plain text, and the rest of the receipt content is stored in cipher text.
  • an object-level receipt storage node based on code annotation including:
  • the receiving unit receives an encrypted transaction corresponding to a smart contract, and the code of the smart contract includes an object marked by an exposed identifier;
  • the execution unit executes the code of the smart contract in the trusted execution environment to obtain receipt data
  • the storage unit stores the receipt data so that at least part of the receipt content corresponding to the object indicated by the exposure identifier is stored in plain text, and the rest of the receipt content is stored in cipher text.
  • an electronic device including:
  • a memory for storing processor executable instructions
  • the processor implements the method according to the first aspect by running the executable instruction.
  • a computer-readable storage medium is provided, and computer instructions are stored thereon, which, when executed by a processor, implement the steps of the method described in the first aspect.
  • Fig. 1 is a schematic diagram of creating a smart contract according to an exemplary embodiment.
  • Fig. 2 is a schematic diagram of invoking a smart contract provided by an exemplary embodiment.
  • Fig. 3 is a flowchart of an object-level receipt storage method based on code labeling provided by an exemplary embodiment.
  • Fig. 4 is a schematic diagram of implementing privacy protection on blockchain nodes according to an exemplary embodiment.
  • Fig. 5 is a block diagram of an object-level receipt storage node based on code annotation provided by an exemplary embodiment.
  • the steps of the corresponding method may not be executed in the order shown and described in this specification.
  • the method includes more or fewer steps than described in this specification.
  • a single step described in this specification may be decomposed into multiple steps for description in other embodiments; and multiple steps described in this specification may also be combined into a single step in other embodiments. description.
  • Blockchain is generally divided into three types: Public Blockchain, Private Blockchain and Consortium Blockchain.
  • the most decentralized one is the public chain.
  • the public chain is represented by Bitcoin and Ethereum. Participants who join the public chain can read the data records on the chain, participate in transactions, and compete for the accounting rights of new blocks. Moreover, each participant (ie, node) can freely join and exit the network, and perform related operations.
  • the private chain is the opposite.
  • the write permission of the network is controlled by an organization or institution, and the data read permission is regulated by the organization.
  • the private chain can be a weakly centralized system with strict restrictions and few participating nodes. This type of blockchain is more suitable for internal use by specific institutions.
  • the alliance chain is a block chain between the public chain and the private chain, which can achieve "partial decentralization".
  • Each node in the alliance chain usually has a corresponding entity or organization; participants are authorized to join the network and form a stakeholder alliance to jointly maintain the operation of the blockchain.
  • a smart contract on the blockchain is a contract that can be triggered and executed by a transaction on the blockchain system.
  • Smart contracts can be defined in the form of codes.
  • EVM Ethereum Virtual Machine
  • bytecode virtual machine code
  • the EVM of node 1 can execute the transaction and generate a corresponding contract instance.
  • "0x6f8ae93" in the figure 1 represents the address of this contract, the data field of the transaction can be stored in bytecode, and the to field of the transaction is empty.
  • the contract is successfully created and can be called in the subsequent process.
  • a contract account corresponding to the smart contract appears on the blockchain and has a specific address, and the contract code will be stored in the contract account.
  • the behavior of the smart contract is controlled by the contract code.
  • smart contracts enable virtual accounts containing contract codes and account storage (Storage) to be generated on the blockchain.
  • the EVM of a certain node can execute the transaction and generate a corresponding contract instance.
  • the from field of the transaction in Figure 2 is the address of the account of the transaction initiator (ie Bob), the "0x6f8ae93" in the to field represents the address of the called smart contract, and the value field in Ethereum is the value of Ether ,
  • the method and parameters of calling the smart contract are stored in the data field of the transaction. Smart contracts are executed independently on each node in the blockchain network in a prescribed manner. All execution records and data are stored on the blockchain, so when the transaction is completed, the blockchain will be stored on the blockchain that cannot be tampered with. Lost transaction certificate.
  • the receipt data obtained by a node executing a transaction can include the following:
  • the Result field indicates the execution result of the transaction
  • the Gas used field indicates the gas value consumed by the transaction
  • the Logs field indicates the log generated by the transaction.
  • the log can further include the From field, To field, Topic field, and Log data field, among which the From field indicates the account address of the initiator of the call, and the To field indicates the called object (such as a smart contract)
  • the account address and Topic field indicate the subject of the log, and the Log data field indicates the log data;
  • the Output field indicates the output of the transaction.
  • the receipt data generated after the transaction is executed is stored in plain text, and anyone can see the contents of the above-mentioned receipt fields contained in the receipt data, without privacy protection settings and capabilities.
  • the block chain is a data set stored in a database of a node and organized by a specific logic.
  • the database as described later, may be a storage medium, such as a persistent storage medium, on a physical carrier.
  • only part of the content of the receipt data may be sensitive, while other content is not sensitive. Only sensitive content needs to be protected for privacy, other content can be disclosed, and in some cases it may even be necessary to retrieve some content to drive Implementation of related operations, the implementation of privacy protection for this part of the content will affect the implementation of retrieval operations.
  • an exposure identifier to the code of the smart contract
  • objects with clear text storage requirements can be marked, so that all receipts corresponding to the object marked by the exposure identifier are stored in clear text.
  • the remaining receipt content corresponding to other objects that are not marked by the exposed identifier is stored in ciphertext; or, by filtering the receipt content corresponding to the object marked by the exposed identifier, the first blockchain node can only filter the selected
  • the content of the receipt is stored in plain text, and the content of the receipt that has not been screened out and the remaining receipt content corresponding to other objects not marked by the exposed identifier are stored in cipher text.
  • the first blockchain node can determine the user type to which the transaction initiator belongs, so that when the transaction initiator belongs to the preset user type, the above-mentioned scheme of mixed storage of plaintext and ciphertext for the receipt data is adopted, otherwise All receipt data are stored in cipher text.
  • this specification can be based on the above technical solution, so that at least part of the receipt content corresponding to the object marked by the exposure identifier is stored in plain text, and the rest of the receipt content generated by the smart contract is stored in cipher text.
  • the first blockchain node receives an encrypted transaction corresponding to a smart contract, and the code of the smart contract includes an object marked by an exposed identifier.
  • the user when the user writes the code of the smart contract, he can add an exposure identifier to the code to mark one or more objects, so that the receipt content corresponding to this part of the object in the receipt data can be stored in plain text, then The contents of the receipts corresponding to the remaining objects without an exposed identifier need to be stored in cipher text to achieve corresponding privacy protection.
  • all the contents of receipts corresponding to the above-mentioned objects in the receipt data are stored in plain text, and the contents of receipts corresponding to the remaining objects without an exposure identifier need to be stored in cipher text.
  • the receipt data can be stored only according to the exposed identifier, so that after the first blockchain node determines the objects indicated by the exposed identifier, all the contents of the receipt corresponding to these objects in the receipt data are always stored in plain text , The content of the receipt corresponding to the remaining objects with no exposed identifiers is stored in ciphertext; or, the first blockchain node can combine the user type of the transaction initiator of the above transaction, and the transaction initiator belongs to the preset In the case of the user type, the contents of all receipts corresponding to these objects in the receipt data are stored in plain text, and the contents of the receipts corresponding to the remaining objects with no exposed identifiers are stored in cipher text, otherwise (that is, the transaction initiator does not belong to The above-mentione
  • the first blockchain node can determine the receipt content corresponding to these objects in the receipt data, and the first blockchain node can further filter the receipt content, so as to filter out only
  • the contents of receipts are stored in plain text, while the contents of receipts that have not been screened out and the contents of receipts corresponding to objects without an exposed identifier are stored in cipher text.
  • the screening condition may include at least one of the following: the at least part of the receipt content corresponds to the exposed field indicated by the exposure identifier, and the exposed field matches the transaction type of the transaction; the at least part of the receipt content Generated by the special event function contained in the smart contract; the information contained in the at least part of the receipt content satisfies preset conditions, etc. This specification does not limit this.
  • the data field can store the bytecode of the smart contract.
  • the bytecode consists of a series of bytes, and each byte can identify an operation. Based on many considerations such as development efficiency and readability, developers can choose a high-level language to write smart contract code instead of directly writing bytecode.
  • the code of a smart contract written in a high-level language is compiled by a compiler to generate bytecode, and then the bytecode can be deployed on the blockchain.
  • Solidity language As an example, the contract written in it is very similar to the class in the object-oriented programming language. A variety of members can be declared in a contract, including state variables, functions, function modifiers, and events. The following is a simple smart contract code example 1 written in Solidity language:
  • one or more objects can be marked by exposing identifiers, so that the receipt content corresponding to this part of the object in the receipt data can be stored in plain text, while the rest of the receipt content is encrypted Document storage.
  • one or more objects can also be marked by exposing identifiers to realize the plaintext storage of the relevant receipt content.
  • the exposure identifier may be a receipt field dedicated to indicating that plain text storage is required.
  • the keyword plain may be used to characterize the exposure identifier. Then, for the receipt content that you want to store in plain text, you can add plain before the corresponding object (or, you can also associate with the corresponding object in other ways).
  • the object marked by the exposure identifier can include receipt fields, such as the Result field, Gas used field, Logs field, Output field, etc., as described above, or the From field, To field, Topic field, and Log data field further contained in the Logs field Wait.
  • receipt fields such as the Result field, Gas used field, Logs field, Output field, etc., as described above, or the From field, To field, Topic field, and Log data field further contained in the Logs field Wait.
  • the code sample 1 above can be adjusted to the following code sample 2:
  • the fields that need to be stored in plaintext can also be specified.
  • the From field is annotated by exposing the identifier
  • the content of the receipt corresponding to the From field in the generated receipt data is stored in plain text, and then the following can be targeted at the From field
  • the content of the receipt can be retrieved, for example, the transaction volume initiated by a certain account can be counted.
  • the objects (all fields or From fields) marked by the exposed identifier "plain" are contract-level objects, so that the first blockchain node is storing
  • all receipt contents corresponding to the contract-level object in the receipt data are stored in plain text.
  • the contract-level object can be applied to all events in the smart contract. Take the From field as an example: when multiple events generate their own corresponding Logs field, each The From field contained in the Logs field will be stored in plain text, without the need to add an exposure identifier for each event.
  • the exposed identifier can also be used to identify other objects.
  • the object indicated by the exposure identifier may include a state variable, and the state variable may also be a contract-level object. Taking the state variable "price" as an example, the above code example 1 can be adjusted to the following code example 3:
  • each Logs field (such as the Topic field in the Logs field) will store the receipt content related to the state variable "price” in clear text, and the Output field will also be stored in clear text with the state variable "price” "Related receipt content, there is no need to add an exposure identifier for the state variable "price” in each event.
  • a smart contract can include the following code example 4:
  • the objects indicated by the exposure identifier may include: event-level objects corresponding to at least one event defined in the smart contract, so that when the first blockchain node stores the receipt data, it determines the corresponding The content of the receipt for the at least one event, and the determined part of the receipt content corresponding to the event-level object is stored in plain text.
  • the above event-level objects can be set for at least some of the events, so that the content of the receipt corresponding to this part of the event is stored in plain text, and the content of the receipt corresponding to the remaining events is stored in cipher text .
  • Event-level objects can also include state variables. Taking the state variable "price" as an example, the above code example 1 can be adjusted to the following code example 6:
  • the event-level object may include fields, which is similar to the above-mentioned From field. However, since no specific fields are specified, all fields in the log generated by the event currentPrice can be regarded as the above event-level objects, such as the aforementioned From field, To field, Topic field, Log Data field, etc. All the contents of the receipt corresponding to the event currentPrice are stored in plain text.
  • event-level objects can include state variables.
  • the above code example 6 defines the state variable "price”
  • the event currentPrice refers to the state variable "price”, which corresponds to adding the exposure identifier "plain” before the event function "event currentPrice(int price)”
  • the state variable "price” can be used as the above-mentioned event-level object, so that all the contents of receipts related to the state variable "price” generated by the event are stored in plain text.
  • the state variable "price” belongs to the event-level object in Code Example 6, when the code of the smart contract also contains another event event1 that references the state variable "price”, if no level of exposure is added to the event event1 Identifier, even if the event event1 references the state variable "price", the content of the receipt generated by the event event1 will still be stored in cipher text, not in plain text.
  • the above event-level object may include all the state variables referenced.
  • the above code sample 4 can be adjusted to the following code sample 7:
  • the keyword “plain” is added before the event function "event currentPrice(int price, int price1)" corresponding to the event currentPrice, so that all the contents of the receipt corresponding to the event are stored in plain text.
  • event currentPrice(int price, int price1) corresponding to the event currentPrice
  • all the receipts related to the state variables "price” and "price1” generated by the event The content is stored in plain text.
  • the contents of the receipts generated are stored in cipher text.
  • the event-level object When the event-level object includes state variables, it can also specifically indicate one or more state variables referenced by the event. Taking the state variable "price" as an example, the above code example 1 can be adjusted to the following code example 8:
  • the event function "event currentPrice(int price)" corresponding to the event currentPrice refers to the state variable "price", and by adding the exposure identifier plain before the type int of the state variable "price", so that
  • the state variable "price” is configured as an event-level object, which is only applicable to the event currentPrice and not applicable to other events included in the smart contract, that is: only the receipt related to the state variable "price” generated by the event currentPrice
  • the content is stored in plain text. Unless an exposed identifier is added to the state variable "price” in other events, the content of the receipt generated in other events is still stored in cipher text even if the state variable "price” is applied.
  • the event currentPrice references the state variables "price” and “price1" at the same time
  • the state variable "price” can be configured by adding the exposure identifier plain before the type int of the state variable "price” It is an event-level object, and the state variable "price1" without the exposed identifier plain is not an event-level object, so that the content of the receipt related to the state variable "price” generated by the event is stored in plain text, and the state variable "price1" "The relevant receipt content is still stored in ciphertext.
  • the smart contract corresponding to the transaction received by the first blockchain node may be a smart contract written in a high-level language, or may be a smart contract in the form of bytecode.
  • the first blockchain node when the smart contract is a smart contract written in a high-level language, the first blockchain node also compiles the smart contract written in the high-level language through a compiler to generate a smart contract in the form of bytecode to be used in a trusted execution environment In execution.
  • the smart contract in bytecode form can be obtained by compiling the smart contract written in high-level language by the client through the compiler , And the smart contract written in this high-level language is written by the user on the client.
  • the smart contract corresponding to the transaction received by the first blockchain node may be a smart contract generated by the user on the first blockchain node.
  • the first blockchain node also uses a compiler to compile the smart contract written in the high-level language into a smart contract in the form of bytecode; or, the user may also be in the first area Smart contracts in bytecode form are directly written on the blockchain nodes.
  • the smart contract corresponding to the transaction received by the first blockchain node may be a smart contract generated by the user on the client.
  • the client submits the transaction to the first blockchain node.
  • the first blockchain node includes a transaction/query interface, which can be connected with the client, so that the client can submit the above-mentioned transaction to the first blockchain node.
  • the user can use a high-level language to write a smart contract on the client, and then the client uses a compiler to compile the smart contract in the high-level language to obtain the corresponding smart contract in bytecode form.
  • the client can directly send a smart contract written in a high-level language to the first blockchain node, so that the first blockchain node is compiled into a bytecode smart contract by a compiler.
  • the smart contract corresponding to the transaction received by the first blockchain node can be the smart contract in the transaction sent by the client through the second blockchain node.
  • the smart contract is usually in the form of bytecode; of course, the smart contract It can also be a smart contract written in a high-level language, and the first blockchain node can be compiled into a bytecode smart contract by a compiler.
  • the smart contract written in a high-level language and the smart contract in the form of bytecode may have the same exposure identifier.
  • the bytecode can use an exposed identifier different from a high-level language.
  • the code of a smart contract written in a high-level language contains the first identifier and the code of the smart contract in the form of bytecode. If the second identifier is included, there is a corresponding relationship between the first identifier and the second identifier to ensure that after being compiled into bytecode by a high-level language, the function of exposing the identifier will not be affected.
  • Step 304 The first blockchain node decrypts the transaction in the trusted execution environment to obtain the code of the smart contract.
  • the foregoing transaction may be encrypted by a symmetric encryption algorithm, or may be encrypted by an asymmetric algorithm.
  • the encryption algorithm used by symmetric encryption such as DES algorithm, 3DES algorithm, TDEA algorithm, Blowfish algorithm, RC5 algorithm, IDEA algorithm, etc.
  • Asymmetric encryption algorithms such as RSA, Elgamal, knapsack algorithm, Rabin, D-H, ECC (elliptic curve encryption algorithm), etc.
  • the foregoing transaction may be encrypted by a combination of a symmetric encryption algorithm and an asymmetric encryption algorithm.
  • the client can use a symmetric encryption algorithm to encrypt the transaction content, that is, use the symmetric encryption algorithm key to encrypt the transaction content, and use an asymmetric encryption algorithm to encrypt the symmetric encryption algorithm
  • the key used for example, the key used in the public key encryption symmetric encryption algorithm using an asymmetric encryption algorithm.
  • the first blockchain node after the first blockchain node receives the encrypted transaction, it can first decrypt it with the private key of the asymmetric encryption algorithm to obtain the key of the symmetric encryption algorithm, and then decrypt it with the key of the symmetric encryption algorithm to obtain the transaction content.
  • the transaction content can include the code of the smart contract that needs to be created; when the transaction is used to call a smart contract, the transaction content can include the account address of the smart contract being called, and the required input Methods and parameters, etc.
  • a transaction When a transaction is used to call a smart contract, it can be a call of multiple nested structures. For example, the transaction directly calls smart contract 1, and the code of smart contract 1 calls smart contract 2, and the code in smart contract 2 points to the contract address of smart contract 3, so that the transaction actually calls the code of smart contract 3 indirectly , And the code in smart contract 3 can include objects marked by exposed identifiers. In this way, it is equivalent to that the smart contract 1 contains the object identified by the exposed identifier.
  • the specific implementation process is similar to the above process, and will not be repeated here.
  • Step 306 The first blockchain node executes the code of the smart contract in the trusted execution environment to obtain receipt data.
  • the transaction received by the first blockchain node may be, for example, a transaction for creating and/or invoking a smart contract.
  • a transaction for creating and/or invoking a smart contract For example, in Ethereum, after the first blockchain node receives the transaction to create and/or call the smart contract from the client, it can check whether the transaction is valid, the format is correct, and the signature of the transaction is legal.
  • the nodes in Ethereum are generally nodes that compete for the right to bookkeeping. Therefore, the first blockchain node as the node that competes for the right to bookkeeping can execute the transaction locally. If one of the nodes competing for the accounting right wins in the current round of the accounting right, it becomes the accounting node. If the first blockchain node wins this round of competition for accounting rights, it becomes the accounting node; of course, if the first blockchain node does not win in this round of competition for accounting rights, it is not Accounting nodes, and other nodes may become accounting nodes.
  • a smart contract is similar to a class in object-oriented programming.
  • the result of execution generates a contract instance corresponding to the smart contract, similar to the object corresponding to the generated class.
  • the process of executing the code used to create a smart contract in a transaction will create a contract account and deploy the contract in the account space.
  • the address of the smart contract account is generated from the sender's address ("0xf5e -- in Figure 1-2) and the transaction nonce (nonce) as input, and is generated by an encryption algorithm, such as in Figure 1-2
  • the contract address "0x6f8ae93" is generated from the sender's address "0xf5e" and the nonce in the transaction through an encryption algorithm.
  • consensus algorithms such as Proof of Work (POW), Proof of Stake (POS), and Delegated Proof of Stake (DPOS) are adopted in blockchain networks that support smart contracts. All nodes competing for the right to account can execute the transaction after receiving the transaction including the creation of a smart contract. One of the nodes competing for the right to bookkeeping may win this round and become the bookkeeping node.
  • the accounting node can package the transaction containing the smart contract with other transactions and generate a new block, and send the generated new block to other nodes for consensus.
  • the nodes with the right to book accounts have been agreed before this round of bookkeeping. Therefore, after the first blockchain node receives the above transaction, if it is not the accounting node of this round, it can send the transaction to the accounting node.
  • accounting nodes which can be the first blockchain node
  • the accounting node packages the transaction (or other transactions together) and generates a new block
  • the generated new block or block header is sent to other nodes for consensus.
  • the accounting nodes in this round can package and package the transaction. Generate a new block, and send the header of the generated new block to other nodes for consensus. If other nodes receive the block and verify that there is no problem, they can append the new block to the end of the original block chain to complete the accounting process and reach a consensus; if the transaction is used to create a smart contract, then The deployment of the smart contract on the blockchain network is completed. If the transaction is used to call the smart contract, the call and execution of the smart contract are completed. In the process of verifying the new block or block header sent by the accounting node, other nodes may also execute the transaction in the block.
  • the execution process can generally be executed by a virtual machine. Taking Ethereum as an example, it supports users to create and/or call some complex logic in the Ethereum network. This is the biggest challenge that distinguishes Ethereum from Bitcoin blockchain technology.
  • the core of Ethereum as a programmable blockchain is the Ethereum Virtual Machine (EVM), and every Ethereum node can run EVM.
  • EVM is a Turing complete virtual machine, which means that various complex logic can be implemented through it. Users publish and call smart contracts in Ethereum run on the EVM.
  • the first blockchain node can execute the decrypted smart contract code in a Trusted Execution Environment (TEE).
  • TEE Trusted Execution Environment
  • the first blockchain node can be divided into a regular execution environment (on the left in the figure) and TEE, and transactions submitted by the client (as described above, transactions can have other sources; here, the client submits Take the transaction as an example to illustrate)
  • First enter the "transaction/query interface" in the regular execution environment for identification.
  • Transactions that do not require privacy processing can be left in the regular execution environment for processing (here can be based on the user type of the transaction initiator , Transaction type, identifier contained in the exchange, etc.
  • TEE is isolated from the conventional execution environment.
  • the transaction is encrypted before entering the TEE, and it is decrypted into the transaction content in the clear in the trusted execution environment, so that the transaction content in the clear text can be efficiently processed in the TEE and in the TEE under the premise of ensuring data security.
  • the receipt data in plaintext is generated in.
  • TEE is a secure extension based on CPU hardware and a trusted execution environment completely isolated from the outside.
  • TEE was first proposed by Global Platform to solve the security isolation of resources on mobile devices, and parallel to the operating system to provide a trusted and secure execution environment for applications.
  • ARM's Trust Zone technology is the first to realize the real commercial TEE technology.
  • security requirements are getting higher and higher.
  • Not only mobile devices, cloud devices, and data centers have put forward more needs for TEE.
  • the concept of TEE has also been rapidly developed and expanded. Compared with the originally proposed concept, TEE is a broader TEE. For example, server chip manufacturers Intel, AMD, etc. have successively introduced hardware-assisted TEE and enriched the concept and characteristics of TEE, which has been widely recognized in the industry.
  • Intel Software Protection Extensions (SGX) and other TEE technologies isolate code execution, remote attestation, secure configuration, secure storage of data, and trusted paths for code execution.
  • the applications running in the TEE are protected by security and are almost impossible to be accessed by third parties.
  • SGX provides an enclave (also called an enclave), which is an encrypted trusted execution area in the memory, and the CPU protects data from being stolen.
  • enclave also called an enclave
  • the CPU protects data from being stolen.
  • a part of the area EPC Enclave Page Cache, enclave page cache or enclave page cache
  • the encryption engine MEE Memory Encryption Engine
  • SGX users can distrust the operating system, VMM (Virtual Machine Monitor), and even BIOS (Basic Input Output System). They only need to trust the CPU to ensure that private data will not leakage.
  • the private data can be encrypted and transmitted to the circle in cipher text, and the corresponding secret key can also be transmitted to the circle through remote certification. Then, the data is used for calculation under the encryption protection of the CPU, and the result will be returned in ciphertext. In this mode, you can use powerful computing power without worrying about data leakage.
  • the transaction contains the code of the smart contract
  • the first blockchain node can decrypt the transaction in the TEE to obtain the code of the smart contract contained therein, and then Execute this code in TEE.
  • the first blockchain node can execute the code in the TEE (if the called smart contract handles the encryption state, the smart contract needs to be executed in the TEE first. Decrypt to get the corresponding code).
  • the first blockchain node may use the newly added processor instructions in the CPU to allocate a part of the area EPC in the memory, and encrypt the above-mentioned plaintext code and store it in the EPC through the encryption engine MEE in the CPU.
  • the encrypted content in EPC is decrypted into plain text after entering the CPU.
  • the CPU perform operations on the plaintext code to complete the execution process.
  • the plaintext code for executing smart contracts can load the EVM into the enclosure.
  • the key management server can calculate the hash value of the local EVM code and compare it with the hash value of the EVM code loaded in the first blockchain node. The correct comparison result is a necessary condition for passing remote certification. , So as to complete the measurement of the code loaded in the SGX circle of the first blockchain node. After measurement, the correct EVM can execute the above smart contract code in SGX.
  • Step 308 The first blockchain node stores the receipt data, so that the content of the receipt corresponding to the object indicated by the exposure identifier is stored in plain text, and the remaining content of the receipt is stored in cipher text.
  • the first blockchain node stores the content of the receipt corresponding to the object indicated by the exposure identifier in plain text, and stores the rest of the receipt content in cipher text, which can flexibly store the receipt data in plain text or cipher text.
  • Document storage enables the receipt content stored in ciphertext form to meet the user's privacy requirements, while the receipt content stored in plaintext form can meet the user's retrieval requirements.
  • the log in the receipt data (such as the entire Logs field; or at least one of the From field, To field, Topic field, and Log data field) is stored in plain text, it can support subsequent retrieval of the log content, thereby For example, it implements event-driven based on log content, such as driving DAPP (Decentralized Application, distributed application) clients to perform related processing operations.
  • DAPP Decentralized Application, distributed application
  • the first blockchain node uses the key to encrypt the content of the receipt corresponding to the object not marked by the exposure identifier.
  • the encryption may be symmetric encryption or asymmetric encryption. If the first blockchain node uses symmetric encryption, that is, the symmetric key of the symmetric encryption algorithm is used to encrypt the content of the receipt, the client (or other object holding the key) can use the symmetric key pair of the symmetric encryption algorithm The encrypted receipt content is decrypted.
  • the symmetric key may be provided to the first blockchain node in advance by the client. Then, since only the client (actually the user corresponding to the logged-in account on the client) and the first blockchain node have the symmetric key, only the client can decrypt the corresponding encrypted receipt content, avoiding Irrelevant users and even criminals decrypt the encrypted receipt content.
  • the client when the client initiates a transaction to the first blockchain node, the client can use the initial key of the symmetric encryption algorithm to encrypt the transaction content to obtain the transaction; accordingly, the first blockchain node can obtain
  • the initial key is used to directly or indirectly encrypt the content of the receipt.
  • the initial key can be negotiated in advance by the client and the first blockchain node, or sent by the key management server to the client and the first blockchain node, or sent by the client to the first blockchain node.
  • the client can encrypt the initial key with the public key of the asymmetric encryption algorithm, and then send the encrypted initial key to the first block
  • the chain node, and the first blockchain node decrypts the encrypted initial key through the private key of the asymmetric encryption algorithm to obtain the initial key, which is the digital envelope encryption described above, which will not be repeated here.
  • the first blockchain node can use the aforementioned initial key to encrypt the content of the receipt. Different transactions can use the same initial key, so that all transactions submitted by the same user are encrypted with this initial key, or different transactions can use different initial keys. For example, the client can randomly generate an initial key for each transaction. Key to improve security.
  • the first blockchain node can generate a derived key according to the initial key and the impact factor, and encrypt the content of the receipt through the derived key.
  • the derived key can increase the degree of randomness, thereby increasing the difficulty of being compromised and helping to optimize the security protection of data.
  • the impact factor can be related to the transaction; for example, the impact factor can include the specified bits of the transaction hash value.
  • the first blockchain node can associate the initial key with the first 16 bits (or the first 32 bits and the last 16 bits) of the transaction hash value. Bits, last 32 bits, or other bits) are spliced, and the spliced string is hashed to generate a derived key.
  • the first blockchain node can also use an asymmetric encryption method, that is, use the public key of the asymmetric encryption algorithm to encrypt the content of the receipt, and accordingly, the client can use the private key of the asymmetric encryption algorithm to decrypt the encrypted The contents of the receipt.
  • the key of an asymmetric encryption algorithm for example, can be that the client generates a pair of public and private keys, and sends the public key to the first blockchain node in advance, so that the first blockchain node can use the receipt content Public key encryption.
  • the first blockchain node realizes the function by running the code used to realize the function. Therefore, for the functions that need to be implemented in the TEE, the relevant code also needs to be executed. For the code executed in the TEE, it needs to comply with the relevant specifications and requirements of the TEE; accordingly, for the code used to implement a certain function in the related technology, the code needs to be rewritten in combination with the specifications and requirements of the TEE. Large amount of development, and easy to produce loopholes (bugs) in the process of rewriting, affecting the reliability and stability of function implementation.
  • the first blockchain node can execute the storage function code outside the TEE to store the receipt data generated in the TEE (including the receipt content in plain text that needs to be stored in plain text, and the receipt content in cipher text that needs to be stored in cipher text.
  • TEE Is stored in an external storage space outside the TEE, so that the storage function code can be the code used to implement the storage function in the related technology, and does not need to be rewritten in conjunction with the specifications and requirements of the TEE to achieve safe and reliable receipt data
  • the storage of TEE can not only reduce the amount of related code development without affecting security and reliability, but also reduce TCB (Trusted Computing Base) by reducing the related code of TEE, making TEE technology and regional In the process of combining block chain technology, the additional security risks caused are in a controllable range.
  • TCB Trusted Computing Base
  • the first blockchain node may execute the write cache function code in the TEE to store the above-mentioned receipt data in the write cache in the TEE.
  • the write cache may correspond to the one shown in FIG. 2 "Cache".
  • the first blockchain node outputs the data in the write cache from the trusted execution environment to be stored in the external storage space.
  • the write cache function code can be stored in the TEE in plain text, and the cache function code in the plain text can be directly executed in the TEE; or, the write cache function code can be stored outside the TEE in cipher text, such as the above External storage space (such as the "package + storage” shown in Figure 2, where "package” means that the first blockchain node packages the transaction into blocks outside of the trusted execution environment), the ciphertext form
  • the write cache function code is read into the TEE, decrypted into the plaintext code in the TEE, and the plaintext code is executed.
  • Write cache refers to a "buffer" mechanism provided to avoid “impact” to the external storage space when data is written to the external storage space.
  • the above-mentioned write cache can be implemented by using buffer; of course, the write cache can also be implemented by using cache, which is not limited in this specification.
  • the write cache mechanism can be used to write the data in the cache to the external storage space in batches, thereby reducing the gap between the TEE and the external storage space. The number of interactions increases the efficiency of data storage.
  • TEE may need to retrieve the generated data.
  • the data to be called happens to be in the write cache, the data can be read directly from the write cache.
  • the interaction between the external storage space eliminates the decryption process of the data read from the external storage space, thereby improving the data processing efficiency in the TEE.
  • the write cache can also be established outside the TEE.
  • the first blockchain node can execute the write cache function code outside the TEE, so as to store the above receipt data in the write cache outside the TEE, and further write The data in the cache is stored in an external storage space.
  • this specification can further identify the user type of the transaction initiator, so as to determine the storage method of the receipt data according to the exposed identifier and the user type of the transaction initiator at the same time. Therefore, the above step 308 can be improved as follows: the first blockchain node stores the receipt data, and when the transaction initiator belongs to the preset user type, the content of the receipt corresponding to the object indicated by the exposure identifier is stored in plain text , The rest of the receipt content is stored in cipher text.
  • the exposed identifier in addition to the exposed identifier, it is also necessary to identify the user type to which the transaction initiator belongs, so that only when the transaction initiator belongs to the preset user type, the content of the receipt corresponding to the object marked by the exposed identifier is stored in plain text , The rest of the receipt content (that is, the receipt content corresponding to the object that is not marked with the exposed identifier) is stored in cipher text, otherwise (that is, when the transaction initiator does not belong to the preset user type) all receipt content is in cipher text storage.
  • the first blockchain node can determine the strength of the transaction initiator’s privacy protection needs by identifying the user type to which the transaction initiator belongs: when it belongs to the preset user type, it can be determined that the transaction initiator’s privacy protection needs are relatively weak , Can accept the exposure of receipt data to a certain extent to achieve corresponding function expansion; when it does not belong to the preset user type, it can be determined that the transaction initiator has relatively strong privacy protection requirements and cannot accept the exposure of receipt data. Therefore, based on the identification of the user type to which the transaction initiator belongs, the storage method for the receipt data can meet the actual needs of the transaction initiator, and it can take into account privacy protection and function expansion. For example, ordinary users have relatively lower requirements for privacy protection and higher requirements for function expansion based on receipt data.
  • the foregoing code example can be improved based on the user type to which the transaction initiator belongs.
  • code example 2 by adding the exposed identifier plain at the front of the smart contract code, after the smart contract code is executed, if the transaction initiator belongs to the preset user type, all fields in the generated receipt data All are stored in plain text.
  • the fields that need to be stored in plaintext can also be specified. For example, when the From field is marked by the exposed identifier, after the code of the smart contract is executed, if the transaction initiator belongs to the preset user type, the content of the receipt corresponding to the From field in the generated receipt data is in plain text.
  • the objects (all fields or From fields) marked by the exposed identifier "plain" are contract-level objects, so that the first blockchain node is storing
  • the contract-level object can be applied to all events in the smart contract.
  • From field Take the From field as an example: when the transaction initiator belongs to the preset user type, for multiple events The corresponding Logs fields are generated separately, and the From field contained in each Logs field will be stored in plain text, without the need to add an exposure identifier for each event.
  • the exposed identifier can also be used to identify other objects.
  • the object indicated by the exposure identifier may include a state variable, and the state variable may also be a contract-level object. Take the state variable "price" as an example.
  • the exposed identifier "plain” is added before the type int of the state variable "price” (or, the exposed identifier plain can be placed after the type int) , So that when the transaction initiator belongs to the preset user type, in each field (usually including Topic field, Output field, etc.) of the receipt data generated after the code of the smart contract is executed, the content of the receipt related to the state variable "price” They are all stored in plain text, so subsequent retrieval operations can be performed on the content of the receipt related to the state variable "price". Since the state variable "price” belongs to the contract-level object in code example 3, when the code of the smart contract contains multiple events, the contract-level object can be applied to all events in the smart contract.
  • each Logs field (such as the Topic field in the Logs field) will store the receipt content related to the state variable "price” in clear text, and the Output field will also be stored in clear text with the state variable "price” "Related receipt content, there is no need to add an exposure identifier for the state variable "price” in each event.
  • the above-mentioned contract-level object may include some or all of the state variables.
  • the code example 4 above multiple state variables such as “price” and “price1" are defined in the code of the smart contract, and the user can only add the exposed identifier plain for the state variable "price” to make the state variable "Price” becomes a contract-level object, while the state variable "price1" is not marked by an exposed identifier.
  • the objects indicated by the exposure identifier may include: event-level objects corresponding to at least one event defined in the smart contract, so that when the first blockchain node stores receipt data, if the transaction initiator belongs to the pre- Assuming the user type, the receipt content corresponding to the at least one event in the receipt data can be stored in plain text.
  • the above event-level objects can be set for at least some of the events, so that the content of the receipt corresponding to this part of the event is stored in plain text, and the content of the receipt corresponding to the remaining events is stored in cipher text . Take the From field as an example.
  • the character "from” corresponding to the From field is added to the event function "event currentPrice(int price)" corresponding to the event currentPrice, and the character “from” is exposed
  • the identifier is different from the aforementioned plain, but the character from is modified by quotation marks.
  • the quotation marks in code example 5 are equivalent to the aforementioned exposed identifier, and the From field is configured as an event-level object, so that when the transaction initiator belongs to the expected When the user type is set, in the Logs field corresponding to the event, the From field will be stored in plain text.
  • Event-level objects can also include state variables. Taking the state variable “price” as an example, in the above code example 6, the keyword “plain” is added before the event function "event currentPrice(int price)" corresponding to the event currentPrice, which is different from the one added in code example 5. "From”, so that the event-level object is not specified as the From field, then: in one case, the event-level object can include fields, which is similar to the From field described above.
  • event-level objects can include state variables.
  • the above code example 6 defines the state variable "price", and the event currentPrice refers to the state variable "price”, which corresponds to adding the exposure identifier "plain” before the event function "event currentPrice(int price)",
  • the state variable "price” can be used as the above-mentioned event-level object, so that when the transaction initiator belongs to the preset user type, all receipts related to the state variable "price” generated by the event are stored in plain text.
  • the state variable "price” belongs to the event-level object in Code Example 6, when the code of the smart contract also contains another event event1 that references the state variable "price”, if no level of exposure is added to the event event1 Identifier, even if the event event1 references the state variable "price", the content of the receipt generated by the event event1 will still be stored in cipher text, not in plain text.
  • the above event-level object may include all the state variables referenced.
  • the event function "event currentPrice(int price, int price1)" corresponding to the event currentPrice refers to the state variables "price” and "price1”
  • the exposing identifier plain is added before the event . So that the referenced state variables "price” and "price1” will be affected, so when the transaction initiator belongs to the preset user type, all the receipts related to the state variables "price” and "price1” generated by the event All are stored in plain text. However, for other events where the exposed identifier plain is not added, the contents of the receipts generated are stored in cipher text.
  • the event-level object When the event-level object includes state variables, it can also specifically indicate one or more state variables referenced by the event. Take the state variable "price” as an example.
  • the event function "event currentPrice(int price)" corresponding to the event currentPrice refers to the state variable "price", and the type of the state variable "price” Add the exposing identifier plain before int, so that the state variable "price” is configured as an event-level object, and the event-level object is only applicable to the event currentPrice, not applicable to other events included in the smart contract, that is: when the transaction is initiated
  • the party belongs to the preset user type
  • only the receipt content related to the state variable "price” generated by the event currentPrice is stored in plain text, unless an exposure identifier is added to the state variable "price” in other events, otherwise Even if the state variable "price” is applied to the event, the generated receipt content is still stored in cipher text.
  • the event currentPrice references the state variables "price” and “price1” at the same time, and the Add the exposing identifier plain before the type int of the variable "price", you can configure the state variable "price” as an event-level object, while the state variable "price1" without the exposing identifier plain is not an event-level object, making it satisfy
  • the transaction initiator belongs to the preset user type, the receipt content related to the state variable "price” generated by the event is stored in plain text, and the receipt content related to the state variable "price1" is still stored in cipher text.
  • the user may have a corresponding external account on the blockchain, and initiate a transaction or perform other operations based on the external account. Then, the user type to which the transaction initiator belongs, that is, the user type to which the external account belongs. Therefore, the first blockchain node can determine the external account corresponding to the transaction initiator, and query the user type corresponding to the external account recorded on the blockchain as the user type to which the transaction initiator belongs.
  • the external account may include a user type field (such as a UserType field) recorded on the blockchain, and the value of the user type field corresponds to the user type.
  • a user type field such as a UserType field
  • the first blockchain node can determine the corresponding user type based on the value by reading the user type field of the external account mentioned above.
  • the user type when creating the above-mentioned external account, can be configured to be associated with the external account, so that the association relationship between the user type and the external account is recorded in the blockchain, such as through the user type and The account address of the external account is used to establish the above-mentioned association relationship, so that the data structure of the external account does not need to be changed, that is, the external account does not need to include the above-mentioned user type field. Therefore, the first blockchain node can determine the above-mentioned preset user type corresponding to the external account by reading the association relationship recorded on the blockchain and based on the external account corresponding to the transaction initiator.
  • the user type of the external account can be modified under certain conditions.
  • the management user may have a modification right item, so that the first blockchain node can change the user type corresponding to the above-mentioned external account according to the change request initiated by the management user.
  • the management user can correspond to the external account preset in the genesis block with management authority, so that the management user can make type changes to other ordinary users, advanced users, etc., such as changing ordinary users to advanced users, and changing advanced users For ordinary users, etc.
  • this specification can further identify the transaction type of the transaction, so as to determine the storage method of the receipt data according to the exposure identifier and the exposure field corresponding to the transaction type at the same time. Therefore, the above step 308 can be improved as: the first blockchain node stores the receipt data, so that the receipt content exposed field corresponding to the object marked by the exposure identifier in the receipt data is stored in plain text, and the remaining receipts The content field is stored in cipher text.
  • a user when a user writes the code of a smart contract, he can add an exposed identifier to the code to indicate one or more fields, thereby expressing the following meaning in the code dimension of the smart contract: For the fields indicated by the exposed identifier, hope The corresponding receipt content in the receipt data is stored in plain text, and the receipt content corresponding to the remaining fields is stored in cipher text. Of course, whether the field marked by the exposed identifier is finally stored in plain text, and it needs to be combined with the transaction type, so that when the field marked by the exposed identifier is also an exposed field corresponding to the transaction type, the content of the receipt corresponding to the field can be stored in plain text , Otherwise it is still stored in ciphertext form.
  • the foregoing code example can be improved based on the user type to which the transaction initiator belongs.
  • the above code example 2 by adding the exposing identifier plain to the front of the smart contract code, after the smart contract code is executed, for the exposed fields corresponding to the transaction type of the smart contract to which the transaction belongs, the generated receipt data The contents of the receipt corresponding to the above exposed fields are all stored in plain text.
  • the fields that need to be stored in plaintext can also be specified.
  • only the From field can be judged: if the From field is the exposed field corresponding to the transaction type of the transaction to which the smart contract belongs, then after the code of the smart contract is executed, it will be generated
  • the receipt content corresponding to the From field in the receipt data is stored in plain text, and subsequent retrieval operations can be performed on the receipt content in the From field, such as counting the transaction volume initiated by an account, etc.; and before the From field All other fields are stored in cipher text.
  • the fields (all fields or From fields) marked by the exposed identifier "plain" are contract-level fields, so that the first blockchain node is storing
  • the contract-level field is an exposed field
  • the first blockchain node will store all receipt contents corresponding to the contract-level field in the receipt data in plain text.
  • the contract-level field can be applied to all events in the smart contract.
  • From field Take the From field as an example: when the From field is a contract-level field and the exposed field corresponding to the transaction type , For multiple events to generate their corresponding Logs fields, the From field contained in each Logs field will be stored in plain text, without the need to add an exposure identifier for each event.
  • the fields indicated by the exposure identifier may include: event-level fields corresponding to at least one event defined in the smart contract, so that when the first blockchain node stores the receipt data, if the event-level field belongs to the transaction
  • the exposed field corresponding to the type can determine the receipt content corresponding to the at least one event in the receipt data, and store the determined portion of the receipt content corresponding to the event-level field in plain text.
  • the above event-level fields can be set for at least some of the events, so that the part of the receipt content corresponding to these events that corresponds to the event-level field is stored in plain text, and this part The remaining part of the receipt content corresponding to the event and the receipt content corresponding to the remaining events are stored in cipher text.
  • From field Take the From field as an example.
  • the character from corresponding to the From field is added to the event function "event currentPrice(int price)" corresponding to the event currentPrice, and the exposed identifier used by the character from is different
  • the character from is modified by quotation marks.
  • the quotation marks in code example 5 are equivalent to the aforementioned exposure identifier, and the From field is configured as an event-level field, so that when the From field belongs to the exposure corresponding to the transaction type Field, in the Logs field corresponding to the event, the From field will be stored in plain text.
  • the code of the smart contract also contains another event, then the above character from will not affect the other event, and the receipt content corresponding to the other event will be stored in ciphertext unless there is a "From" added for this other event.
  • the exposure identifier "plain” is added before the event function "event currentPrice(int price)" corresponding to the event currentPrice, which is different from the "from” added in code example 5, so that If the event-level field is not specified as the From field, all fields in the log generated by the event currentPrice can be used as the above-mentioned event-level fields, such as the aforementioned From field, To field, Topic field, Log Data field, etc., which are equivalent to All the contents of the receipt corresponding to the event currentPrice are stored in plain text.
  • the transaction may include a transaction type field (such as a TransType field), and the value of the transaction type field is used to indicate the corresponding transaction type. Therefore, by reading the value of the transaction type field in the exchange, the transaction type can be determined, such as the type of deposit certificate, the type of asset transfer (such as transfer), the type of contract creation, and the type of contract invocation. This manual does not limit this . Different types of transactions can have corresponding exposed fields.
  • the exposed field is one or more fields specified in the receipt data.
  • the matching situation between the fields indicated by the aforementioned exposure identifier and the exposed fields can be combined to selectively
  • the content of the receipt corresponding to the exposed field marked by the exposed identifier is stored in plain text, instead of storing all the fields marked by the exposed identifier in plain text, it can meet the privacy protection requirements, so that it can be subsequently addressed.
  • the contents of the receipt stored in plaintext are searched and other operations.
  • the mapping relationship between each transaction type and the exposed field may be predefined, and the mapping relationship may be recorded in the blockchain, so that the first blockchain node can obtain the predefined mapping relationship, And further determine the exposed fields in the receipt data according to the transaction type of the above-mentioned transaction and the mapping relationship.
  • the exposed field corresponding to the attestation type may include all fields except the above-mentioned From field
  • the exposed field corresponding to the asset transfer type may include the above-mentioned To field
  • the exposed field corresponding to the contract creation type and contract invocation type may include the above-mentioned From field. All the fields except for the other transaction types will not be repeated here.
  • the above-mentioned mapping relationship can be specifically recorded in the system contract.
  • the mapping relationship can also be recorded in the chain code of the blockchain network.
  • By recording the mapping relationship in the system contract it is convenient to update and upgrade the mapping relationship later, while the mapping relationship recorded in the chain code is relatively difficult to update and upgrade. The differences between the two will be described later, and I will not temporarily Repeat.
  • this specification can further identify the event function contained in the smart contract, so as to determine the storage method of the receipt data according to the exposed identifier and the special event function contained in the smart contract at the same time. Therefore, the above step 308 can be improved as: the first blockchain node stores the receipt data, so that at least part of the receipt content in the log corresponding to the special event function is stored in plain text, and the rest of the receipt data It is stored in a ciphertext form, and the content of the at least a part of the receipt matches the object indicated by the exposure identifier.
  • the exposed identifier can indicate one or more objects, and these objects have corresponding receipt content in the receipt data.
  • the receipt data contains a log corresponding to the special event function, which is actually part of the receipt content in the receipt data.
  • the cross content of the above two parts of the receipt content can be filtered out, and the cross content can be stored in plain text, and the rest of the receipt data is stored in cipher text.
  • the smart contract may include one or more events, and each event is used to implement predefined related processing logic. After each event contained in the smart contract is called and executed, the corresponding Logs field will be generated. For example, when the smart contract contains event 1 and event 2, event 1 can generate the corresponding Logs field, and event 2 can generate the corresponding Logs field. , So that the receipt data corresponding to the smart contract contains multiple Logs fields at the same time.
  • the events contained in smart contracts can be divided into special event functions and ordinary event functions.
  • the logs generated by the ordinary event functions are stored in cipher text to achieve privacy protection; the logs generated by the special event functions are allowed to satisfy privacy Under the premise of protection requirements, at least part of the log content is stored in plaintext, so that the content of this part of the log content can be retrieved to drive the implementation of related operations.
  • the event function belonging to the "special event function" can be recorded in the chain code of the blockchain network or the system contract, for example, it can be recorded in the special event function list; accordingly, by combining the event function contained in the smart contract with the above special By comparing the event function list, you can determine whether the event function included in the smart contract is the above-mentioned special event function.
  • the special event function can be any function defined in the smart contract, and by adding a type identifier for the event function in the smart contract, the event function can be marked as a special event function.
  • the code example of the event function in the above code example 1 is as follows:
  • the smart contract defines an event: the event currentPrice.
  • the event does not contain any type identifier, so the corresponding event function is a normal event function.
  • the code example of the event function can be obtained as follows:
  • the smart contract defines an event: event currentPrice.
  • event currentPrice By adding the type identifier "expose" to the event currentPrice, the event currentPrice can be marked as the above-mentioned special event function.
  • a smart contract written in a high-level language can be compiled into a corresponding bytecode through a compiler, and the first blockchain node will finally execute the smart contract in the form of bytecode in the EVM virtual machine.
  • the above-mentioned type identifier can be the same in high-level language and bytecode smart contract code, or the first type identifier in high-level language smart contract code, and the second type in bytecode smart contract code Type identifier, the first type identifier and the second type identifier can correspond to each other.
  • the exposed identifier can indicate one or more objects, and these objects have corresponding receipt content in the receipt data.
  • the receipt data contains a log corresponding to the special event function, which is actually part of the receipt content in the receipt data.
  • the cross content of the above two parts of the receipt content can be filtered out, and the cross content can be stored in plain text, and the rest of the receipt data is stored in cipher text.
  • the definition of special event functions is not necessarily based on programming languages. For example, when recording special event functions based on a list of special event functions, even if an event function included in the smart contract originally belongs to a special event function, it can be To change the event function list, update the original special event function to a normal event function, so as to avoid storing the log generated by the event function in plain text, or update the original normal event function to a special event function to make the At least part of the content in the log generated by the event function is stored in plain text.
  • the state variable "price" marked by the exposure identifier "plain” is also a contract-level object, so that when the first blockchain node stores the receipt data, all of the receipt data corresponds to The content of the receipt of the contract-level object "price" is allowed to be stored in clear text.
  • a smart contract can include the following code example 10:
  • the exposed identifier "plain" is located at the forefront of the code of the smart contract, so that all fields in the receipt data are marked as contract-level objects; at the same time, in the smart contract Contains the event currentPrice1 and event currentPrice2: assuming that the event currentPrice1 corresponds to the special event function defined in the special event function list, and the event currentPrice2 corresponds to the ordinary event function, then in the logs Log1 and Log2 generated by the event currentPrice1 and event currentPrice2, log Log1 All fields included are stored in plain text, and all fields included in log Log2 are stored in cipher text.
  • the From field is the contract-level object mentioned above, so that when the event currentPrice1 is a special event function and the event currentPrice2 is a normal event function, the From field in the log Log1 is Stored in plain text, the rest of the fields are stored in cipher text, and all fields contained in log Log2 are stored in cipher text; and, when the event currentPrice2 is updated as a special event function, then the From field in log Log2 is stored in plain text, and the rest The fields are stored in cipher text.
  • the aforementioned type identifier can be used to indicate whether the event function contained in the smart contract is a special event function.
  • the above code sample 10 can be adjusted to the following code sample 11:
  • the contract-level object includes all the fields in the receipt data; at the same time, the smart contract contains the event currentPrice1 and the event currentPrice2: because the event currentPrice1 contains the aforementioned
  • the type identifier expose causes the event currentPrice1 to be marked as corresponding to the special event function, while the event currentPrice2 does not contain the type identifier expose, so that the event currentPrice2 is marked as corresponding to the normal event function, then the event currentPrice1 and event currentPrice2 are generated respectively In the logs Log1 and Log2, all fields contained in log Log1 are stored in plain text, and all fields contained in log Log2 are stored in cipher text.
  • the type identifier and the exposed identifier are similar, they are both global identifiers defined in the programming language of the smart contract, but the exposed identifier acts on contract-level objects and the type identifier acts on the event function.
  • the number of event functions included in the event function is large, and the number of objects (such as fields or state variables) involved in the event function is large, there is no need to implement setting operations for each object involved in each event function, which can simplify the code logic , Prevent mislabeling or missing labels.
  • the contract-level object in the above embodiment includes fields, such as the From field. Contract-level objects can also include state variables; for example, the above code example 10 can be adjusted to the following code example 12:
  • the event currentPrice1 and event currentPrice2 refer to the state variable price
  • the event currentPrice3 refers to the state variable price1; since the type of the state variable price is added before the type int, the state variable can be the state variable.
  • Price is the contract-level object mentioned above.
  • the event function that references the contract-level object in the log generated by the special event function, the content of the receipt corresponding to the contract-level object is stored in plain text, while the ordinary event function even refers to the contract-level object. The logs are still stored in cipher text.
  • the event currentPrice1 corresponds to the special event function, because the event currentPrice1 references the state variable price as a contract-level object, in the log Logs generated by the event currentPrice1,
  • the contents of receipts related to the state variable price are stored in plain text
  • the event currentPrice2 corresponds to a normal event function, although the event currentPrice2 references the state variable price as a contract-level object, in the log Logs generated by the event currentPrice2
  • the contents of receipts related to the state variable price are stored in ciphertext
  • the event currentPrice3 corresponds to a special event function, since the event currentPrice3 does not reference the state variable price as a contract-level object, the log Logs generated by the event currentPrice3 are all in Stored in ciphertext form.
  • the type of the event function can be marked by the type identifier.
  • the above code sample 12 can be adjusted to the following code sample 13:
  • the state variable price can be marked as a contract-level object by exposing the identifier, while the state variable price1 is not a contract-level object; the events currentPrice1 and currentPrice3 marked by the type identifier expose correspond to special event functions. , And the event currentPrice2 corresponds to the normal event function. Therefore, in the log Logs generated by the event currentPrice1, the receipt content related to the state variable price is stored in plain text; in the log Logs generated by the event currentPrice2, the receipt content related to the state variable price is all stored in cipher text Stored; all logs generated by the event currentPrice3 are stored in cipher text.
  • the objects indicated by the exposed identifiers may include: event-level objects corresponding to at least one event defined in the smart contract, so that the first blockchain node generates the special event function when storing the receipt data
  • the part of the receipt content corresponding to the event-level object is stored in plain text.
  • the above event-level object can be set for at least some of the events, so that the part of the receipt content generated by these events that corresponds to the event-level object is stored in plain text, and this The contents of other receipts generated by some events and all the contents of receipts generated by other events are stored in ciphertext.
  • the event currentPrice1 does not add the exposed identifier "plain", it contains the content "from".
  • the content "from” corresponds to the From field and is used to indicate the From field in the log generated by the event currentPrice1 It needs to be stored in plain text, so the content "from” not only belongs to the above exposed identifier, but also indicates the From field that needs to be stored in plain text.
  • the From field is an event-level object, so that when the event currentPrice1 corresponds to a special event function, in the log Logs generated corresponding to the event currentPrice1, the From field will be in plain text. Storage, other fields are stored in cipher text.
  • From field is set as an event-level object; for the case where the event-level object is a field type, the specific field may not be specified.
  • code sample 11 can be adjusted to the following code sample 15:
  • Event-level objects can also include state variables. From the perspective of the state variable, the code example 15 above can be interpreted as: the event currentPrice1 refers to the state variables price and price1, and the event currentPrice2 refers to the state variable price1; because the exposure identifier "plain" is added before the event currentPrice1, you can The state variables price and price1 referenced by the event currentPrice1 are used as the above event-level objects, so that when the event currentPrice1 corresponds to a special event function, in the log Logs generated by the event currentPrice1, the receipts related to the state variables price and price1 The content is stored in plain text.
  • the event-level object when the event-level object includes state variables, it can also specifically indicate one or more state variables referenced by the event.
  • the above code sample 11 can be adjusted to the following code sample 16:
  • the event function corresponding to the event currentPrice1 contains the exposed identifier plain added before the type int of the state variable price, so that the state variable price is configured as an event-level object, and the event-level object is only Applies to the event currentPrice1. Since the exposure identifier plain is located in the event function corresponding to the event currentPrice1, and the event function corresponding to the event currentPrice2 refers to the state variable price but does not label the exposure identifier plain, the event function corresponding to the event currentPrice2 has nothing to do with event-level objects.
  • the event currentPrice1 and the event currentPrice2 correspond to special event functions, only in the log generated by the event currentPrice1, the content of the receipt corresponding to the state variable price as the event-level object is stored in plain text, while the logs generated by the event currentPrice2 are all Stored in cipher text.
  • the event currentPrice1 references the state variable price1, because the state variable price1 is not marked by the exposed identifier, the state variable price1 does not belong to the event-level object, even if the event currentPrice1 corresponds to a special event function, In the log generated by the event currentPrice1, the content of the receipt corresponding to the state variable price1 is still stored in ciphertext.
  • this specification can further identify the receipt content that meets the preset conditions in the receipt data, so as to determine the storage of the receipt data according to the exposure identifier and the receipt content meeting the preset conditions at the same time the way. Therefore, the above step 308 can be improved to: the first blockchain node stores the receipt data, so that the part of the receipt content corresponding to the object marked by the exposure identifier that meets the preset conditions is stored in plain text. The remaining receipt content of the receipt data is stored in cipher text.
  • the exposed identifier can indicate one or more objects, and these objects have corresponding receipt content in the receipt data.
  • the difference in privacy protection can be reflected in the storage process according to the satisfaction of the preset conditions by the content of the receipt Requirements and processing: Store the receipt content that meets the preset conditions in plain text, while other receipt content must be stored in cipher text.
  • the foregoing code example can be improved based on the satisfaction of the content of the receipt to the preset conditions.
  • code example 2 by adding the exposed identifier plain to the front of the smart contract code, after the smart contract code is executed, all fields in the generated receipt data that meet the preset conditions are stored in plain text.
  • the fields that need to be stored in plaintext can also be specified.
  • the From field is marked by the exposed identifier
  • the code of the smart contract is executed, if the receipt content corresponding to the From field in the generated receipt data meets the preset conditions, the receipt content corresponding to the From field is in plain text
  • the form is stored, and subsequent retrieval operations can be performed on the receipt content in the From field, for example, the transaction volume initiated by a certain account can be counted.
  • the objects (all fields or From fields) marked by the exposed identifier "plain" are contract-level objects, so that the first blockchain node is storing
  • all the receipt contents corresponding to the "From field” of the contract-level object in the receipt data are allowed to be stored in plain text (provided that the relevant receipt contents meet the preset conditions).
  • the contract-level object can be applied to all events in the smart contract. Take the From field as an example: For the log Logs generated by any event, if the log Logs contains If the From field satisfies the preset conditions, the From field will be stored in plain text without adding an exposure identifier for each event.
  • the exposed identifier can also be used to identify other objects.
  • the object indicated by the exposure identifier may include a state variable, and the state variable may also be a contract-level object.
  • the state variable Take the state variable "price” as an example.
  • the exposed identifier "plain” is added before the type int of the state variable "price” (or, the exposed identifier plain can be placed after the type int) , You can mark the state variable price as a contract-level object.
  • the various fields of the receipt data generated after the code of the smart contract is executed (usually including Topic field, Output field, etc.)
  • the state variable "price" belongs to the contract-level object in code example 3
  • the contract-level object can be applied to all events in the smart contract.
  • each log Logs may generate the receipt content related to the state variable "price" (depending on whether the state variable price is applied to the related event), which can be connected with
  • the preset conditions are compared and judged to determine whether the price value in each log Logs is stored in plain text, without adding an exposure identifier to the state variable "price" in each event; similarly, the Output field will also contain The content of the receipt related to the state variable "price".
  • the same or different preset conditions can be used to determine whether to store in plaintext form, which depends on the configuration rules for "preset conditions", see Related description below.
  • the above-mentioned contract-level object may include some or all of the state variables.
  • the code example 4 above multiple state variables such as “price” and “price1” are defined in the code of the smart contract, and the user can only add the exposure identifier plain for the state variable "price”, so that the state variable "Price” becomes a contract-level object, while the state variable "price1" is not marked by an exposed identifier.
  • the objects indicated by the exposure identifier may include: event-level objects corresponding to at least one event defined in the smart contract, so that when the first blockchain node stores the receipt data, if the receipt data corresponds to The receipt content of the at least one event meets the preset condition, and the corresponding receipt content is stored in plain text.
  • event-level objects can be set for at least some of the events, so that the receipt content corresponding to these events is stored in plaintext when the preset conditions are met, and the receipts corresponding to the remaining events The content is stored in cipher text. Take the From field as an example.
  • the character from corresponding to the From field is added to the event function "event currentPrice(int price)" corresponding to the event currentPrice, and the exposed identifier used by the character from is different
  • the character from is modified by quotation marks.
  • the quotation marks in code example 5 are equivalent to the aforementioned exposed identifier, so that the From field is marked as an event-level object, so the event corresponds to the generated Logs field If the From field meets the preset conditions, the From field is stored in plain text.
  • the event-level object by adding the keyword "plain” before the event function "event currentPrice(int price)" corresponding to the event currentPrice, the event-level object includes all the fields in the log Logs corresponding to the event currentPrice, such as The aforementioned From field, To field, Topic field, Log Data field, etc., can be compared with preset conditions, respectively, so that the fields that meet the preset conditions are stored in plain text.
  • Event-level objects can also include state variables. From the perspective of state variables, the above code example 6 can be interpreted as: the event currentPrice refers to the state variable "price".
  • the state variable referenced by the event currentPrice can be price is the event-level object mentioned above, and the receipt content related to the state variable price in the log Logs generated by the event currentPrice is determined, and the part of the determined receipt content that meets the preset conditions is stored in plaintext, and does not meet the preset conditions.
  • the part of the condition is stored in cipher text.
  • the state variable "price” belongs to the event-level object in Code Example 6, when the code of the smart contract also contains another event event1 that references the state variable "price”, if no level of exposure is added to the event event1 Identifier, even if the event event1 references the state variable "price", the content of the receipt generated by the event event1 will still be stored in cipher text, not in plain text.
  • the above event-level object may include all the state variables referenced.
  • the event function "event currentPrice(int price, int price1)" corresponding to the event currentPrice refers to the state variables "price” and "price1”
  • the exposing identifier plain is added before the event . So that the referenced state variables “price” and “price1” will be affected. All receipts related to the state variables "price” and "price1" generated by the event will be stored in clear text if they meet the preset conditions , Those that do not meet the conditions are stored in cipher text. However, for other events where the exposed identifier plain is not added, the contents of the receipts generated are stored in cipher text.
  • the event-level object When the event-level object includes state variables, it can also specifically indicate one or more state variables referenced by the event. Take the state variable "price” as an example.
  • the event function "event currentPrice(int price)" corresponding to the event currentPrice refers to the state variable "price", and the type of the state variable "price” Add the exposed identifier plain before int, so that the state variable "price” is configured as an event-level object, and the event-level object is only applicable to the event currentPrice, not applicable to other events included in the smart contract, that is: only the event currentPrice is generated
  • the content of the receipt related to the state variable "price” can be stored in plain text when preset conditions are met, and other content in the receipt data is stored in cipher text.
  • the event function "event currentPrice(int price,int price1)" corresponding to the event currentPrice is also referenced
  • the state variable "price1" is not an event-level object, so that the receipt content related to the state variable "price” generated by the event currentPrice is stored in clear text when the preset conditions are met, and the receipt related to the state variable "price1" The content must be stored in ciphertext.
  • the content of the preset condition may include at least one of the following: the content of the corresponding receipt includes the preset content, the value of the content of the corresponding receipt belongs to the preset numerical interval, and so on.
  • the preset content may include: one or more specified keywords.
  • the keywords may include predefined state variables, predefined event functions, information indicating the results of transaction execution, etc., so that when the receipt content contains keywords as keywords When information such as state variables, event functions, or transaction execution results, it can be determined that the content of the receipt meets the preset conditions.
  • the preset content may include: preset values.
  • the preset value can be a numeric value, which can be compared with the value of a state variable, etc., to determine whether the value of the state variable meets expectations; for another example, the preset value can be composed of numeric values, letters, special symbols, etc.
  • a character string which can be compared with the account address of the transaction initiator, the account address of the transaction target, the log subject, etc. to identify a specific transaction initiator, a specific transaction target, or a specific log subject, etc. Taking the preset content as a string as an example, assuming that the string is a certain account address, the user can use plain text for the To field in the log when a transaction is initiated against the account address and the To field is marked by an exposed identifier.
  • the preset value range can indicate the privacy protection requirements of the relevant receipt fields.
  • the preset value range can be a value range with a smaller value and a lower privacy protection requirement, so that even if the relevant receipt field is disclosed, it will not cause Serious user privacy leakage, but it can be used to automatically trigger related operations such as DAPP client, so as to achieve a certain balance between privacy protection and convenience.
  • the preset conditions may include general conditions corresponding to all receipt fields in the receipt data, that is, when the content of the receipt corresponding to the object indicated by the exposure identifier is in any receipt field in the receipt data, it is used to The preset conditions are compared. For example, when the preset condition is "Contains preset keywords", the content of the receipt corresponding to the object indicated by the exposure identifier can be compared with the keywords contained in the preset condition to determine the keywords that contain the keyword.
  • the content of the receipt is regarded as the content of the receipt meeting the above-mentioned preset conditions; among them, when the content of the receipt corresponding to the object indicated by the exposure identifier is in a certain receipt field, the receipt field may also contain other receipt content, and the content of these receipts is secret Document format for storage.
  • the preset condition may include a dedicated condition corresponding to each receipt field in the receipt data, that is, each receipt field in the receipt data has a corresponding preset condition, which needs to be based on the object indicated by the exposure identifier.
  • the preset conditions corresponding to different receipt fields are independent of each other, but may be the same or different.
  • the preset condition corresponding to the From field may be "whether the preset content is included", and the preset content may be a preset account address, indicating a transaction initiated by the account address, and the preset condition corresponding to the Topic field may be "Whether it belongs to the preset value range", and the value of the state variable referenced by the related event can be recorded in the Topic field.
  • the state variable representing "transfer amount” can be included, indicating that the transfer amount is within the preset value range ; Then: when the content of the receipt corresponding to the object indicated by the exposure identifier is in both the From field and the Topic field, the content of the receipt in the From field is suitable for comparison with the preset condition "Does it contain preset content" and is in the Topic field The content of the receipt in is suitable for comparison with the preset condition "whether it belongs to the preset value interval".
  • the preset condition is not necessarily implemented based on the programming language in the smart contract where the exposed identifier is located.
  • the preset condition can be located in the transaction (not in the code of the smart contract included in the exchange.
  • the preset conditions are set when creating a transaction), so that even when the same smart contract is invoked for different transactions, the preset conditions used can be different to meet the needs of different exchanges; of course, Different transactions can also use the same preset conditions.
  • the difference in the preset conditions may be expressed as: differences in at least one dimension in the content of the preset conditions, the receipt fields to which the preset conditions apply, and the processing logic for determining whether the content of the receipt meets the preset conditions.
  • the preset condition may be located in the smart contract called by the transaction, so that the transaction can determine whether to use the preset condition by selecting the called smart contract; or the preset condition may be located in the smart contract A called by the transaction
  • the smart contract called by smart contract A can be configured by replacing smart contract B with smart contract C to replace the preset conditions used (defined by smart contract B
  • the preset conditions are replaced with the preset conditions defined in smart contract C).
  • the smart contract can be pre-created by the transaction initiator or any other user; of course, if the smart contract has a corresponding calling condition, then the above-mentioned transaction can call the smart contract only when the calling condition is met.
  • the calling condition may include :
  • the transaction initiator belongs to the preset whitelist, the transaction initiator does not belong to the preset blacklist or other conditions.
  • the preset condition may be located in the system contract or chain code, so that the preset condition is a global condition applicable to all transactions on the blockchain, and is different from the foregoing transaction or the preset contained in the smart contract.
  • Set conditions so that even if the transaction or the smart contract invoked by the transaction does not contain preset conditions, it can be determined based on the preset conditions defined in the system contract or chain code whether the content of the receipt corresponding to the object indicated by the exposure identifier is Stored in clear text. It should be pointed out that there is no contradiction between the preset conditions contained in the transaction or smart contract and the preset conditions contained in the chain code or system contract: the two can contain preset conditions of different dimensions, such as preset conditions. The applicable receipt fields are different; or, when there is a conflict between the preset conditions contained in the two, the preset conditions contained in the transaction or smart contract may be used by default, or the preset conditions contained in the chain code or system contract may be preferred. Set conditions, which depend on the predefined selection logic.
  • this specification can further take into account the identification of the user type of the transaction initiator and the transaction type of the transaction, thereby simultaneously according to the exposure identifier, the user type of the transaction initiator and the exposure corresponding to the transaction type.
  • Field which determines how to store receipt data. Therefore, the above step 308 can be improved to: the first blockchain node stores the receipt data, and when the transaction initiator belongs to the preset user type, the exposed field in the receipt data marked by the exposure identifier is changed to Stored in plain text, and the rest of the receipt fields are stored in cipher text.
  • the exposed identifier is a global identifier defined in the programming language of the smart contract, it is difficult to modify the fields marked by the exposed identifier as long as the exposed identifier is written in the smart contract. Therefore, by combining the consideration of user type and transaction type, it is possible to more accurately select the fields stored in plain text based on the user type of the transaction initiator and the exposed fields corresponding to the transaction type, rather than just based on the exposed identifier. Determine, so that when different users call the same smart contract or call the same smart contract through different types of transactions, the fields stored in the plaintext are matched to the user type and transaction type, so that the storage method of the receipt data can meet the actual needs in different situations , Can take into account privacy protection and function expansion.
  • the foregoing code example can be improved based on the user type to which the transaction initiator belongs and the exposed fields corresponding to the transaction type.
  • code example 2 by adding the exposed identifier "plain" to the front of the smart contract code, all fields in the receipt data are allowed to be stored in plain text.
  • the transaction initiator belongs to the preset user type
  • the exposed fields corresponding to the transaction type of the transaction to which the smart contract belongs after the code of the smart contract is executed, the corresponding receipt content in the generated receipt data will be stored in plain text, and subsequent retrieval operations can be performed on the receipt content ;
  • the From field belongs to the above-mentioned exposed field
  • the From field can be used to count the transaction volume initiated by a certain account after being stored in plain text.
  • the above-mentioned exposure identifier plain corresponds to all the fields in the receipt data; in other embodiments, the fields that need to be stored in plain text can also be specified. For example, when annotating the From field with an exposed identifier, only the From field needs to be judged: when the From field is the above-mentioned exposed field, when the transaction initiator belongs to the preset user type, for the smart contract
  • the receipt data generated after the code is executed can store the contents of the receipt corresponding to the From field in plain text, and the contents of other receipts are stored in cipher text.
  • the fields (all fields or From fields) marked by the exposed identifier "plain" are contract-level fields, so that the first blockchain node is storing
  • the first blockchain node When receiving the receipt data, if the transaction initiator belongs to the preset user type and the From field is an exposed field, the first blockchain node will store all the receipt contents corresponding to the contract-level field in the receipt data in plain text.
  • the contract-level field can be applied to all events in the smart contract.
  • From field Take the From field as an example: when the transaction initiator belongs to the preset user type and the From field is the transaction type
  • the corresponding Logs fields are generated separately, and the From field contained in each Logs field will be stored in plain text, without the need to add an exposure identifier for each event.
  • the fields indicated by the exposure identifier may include: event-level fields corresponding to at least one event defined in the smart contract, so that when the first blockchain node stores the receipt data, if the transaction initiator belongs to the pre- Assuming that the user type and the event-level field belong to the exposed field corresponding to the transaction type, the receipt content corresponding to the at least one event in the receipt data can be determined, and the part of the determined receipt content corresponding to the above-mentioned event-level field can be in plaintext form storage.
  • the above event-level fields can be set for at least some of the events, so that the part of the receipt content corresponding to these events that corresponds to the event-level field is stored in plain text, and this part The remaining part of the receipt content corresponding to the event and the receipt content corresponding to the remaining events are stored in cipher text.
  • From field Take the From field as an example.
  • the character from corresponding to the From field is added to the event function "event currentPrice(int price)" corresponding to the event currentPrice, and the exposed identifier used by the character from is different
  • the character from is modified by quotation marks.
  • the quotation marks in code example 5 are equivalent to the aforementioned exposed identifier, so that the From field is marked as an event-level field. Therefore, when the transaction initiator belongs to the default user When the type and the From field belongs to the exposed field corresponding to the transaction type, the From field will be stored in plain text in the Logs field corresponding to the event. In addition to the aforementioned event currentPrice, if the code of the smart contract also contains another event, the aforementioned event-level field will not affect the other event, and the content of the receipt corresponding to the other event will be stored in ciphertext.
  • the event-level fields include all the fields in the log Logs corresponding to the event currentPrice For example, the aforementioned From field, To field, Topic field, Log Data field, etc., when the transaction initiator belongs to the preset user type, the exposed fields in these fields can be determined according to the transaction type, and the determined exposed fields are Stored in clear text.
  • this specification can further take into account the identification of the user type of the transaction initiator and the event function contained in the smart contract, so as to simultaneously identify the user type of the transaction initiator and the event function contained in the smart contract.
  • the special event function determines the storage method of the receipt data. Therefore, the above step 308 can be improved as: the first blockchain node stores the receipt data so that when the transaction initiator belongs to the preset user type, at least part of the receipt content in the log corresponding to the special event function The remaining content of the receipt data is stored in a plaintext form, and the remaining content of the receipt data is stored in a ciphertext form, and the at least a part of the receipt content matches the object indicated by the exposure identifier.
  • the aforementioned code example can be improved based on the user type of the transaction initiator and the special event function contained in the smart contract.
  • the smart contract code by adding the exposed identifier plain to the front of the smart contract code, after the smart contract code is executed, all fields in the generated receipt data are allowed to be stored in plain text.
  • the transaction initiator belongs to the preset user type, for the log generated by the special event function in the receipt data, all the contents of the receipt corresponding to the log are allowed to be stored in plain text.
  • the fields that need to be stored in plaintext can also be specified.
  • the code of the smart contract can be executed.
  • the log generated by the special event function in the receipt data allows the From field to correspond
  • the content of the receipt is stored in plain text, then the subsequent retrieval operation can be performed on the content of the receipt in the From field, for example, the transaction volume initiated by a certain account can be counted.
  • the exposed identifier can also be used to identify other objects.
  • the object identified by the exposure identifier may include state variables. Take the state variable "price" as an example.
  • the exposed identifier "plain” is added before the type int of the state variable "price” (or, the exposed identifier plain can be placed after the type int) .
  • the receipt content related to the state variable "price” is allowed to be stored in clear text ( The premise is that the transaction initiator belongs to the preset user type), then the subsequent retrieval operation can be performed on the receipt content related to the state variable "price".
  • the exposed identifier is a global identifier defined in the programming language of the smart contract, it is difficult to modify the object marked by the exposed identifier as long as the exposed identifier is written in the smart contract.
  • the user type depends on the transaction initiator and has nothing to do with the programming language, so that even when different transaction initiators call the same smart contract, the storage method (ciphertext or plaintext) of the receipt data may be different.
  • the definition of special event functions is not necessarily based on programming languages.
  • the state variable "price" marked by the exposure identifier "plain” is also a contract-level object, so that when the first blockchain node stores the receipt data, all of the receipt data corresponds to The content of the receipt of the contract-level object "price" is allowed to be stored in clear text.
  • a smart contract can include the following code example 17:
  • the exposed identifier "plain" is located at the forefront of the smart contract code, so that all fields in the receipt data are marked as contract-level objects; at the same time, in the smart contract Contains the event currentPrice1 and event currentPrice2: assuming that the event currentPrice1 corresponds to the special event function defined in the special event function list, and the event currentPrice2 corresponds to the normal event function, then in the case that the transaction initiator belongs to the preset user type, in the event currentPrice1 and In the logs Log1 and Log2 generated by the event currentPrice2, all the fields contained in the log Log1 are stored in plain text, and all the fields contained in the log Log2 are stored in cipher text.
  • the event currentPrice1 is made as a special event function
  • event currentPrice2 When it is a normal event function, the From field in log Log1 is stored in plain text, the rest of the fields are stored in cipher text, and all the fields contained in log Log2 are stored in cipher text; and, when the event currentPrice2 is updated as a special event function, Then the From field in the log Log2 is stored in plain text, and the remaining fields are stored in cipher text.
  • the aforementioned type identifier can be used to indicate whether the event function contained in the smart contract is a special event function.
  • the above code sample 17 can be adjusted to the following code sample 18:
  • the contract-level object includes all the fields in the receipt data; at the same time, the smart contract contains the event currentPrice1 and the event currentPrice2: because the event currentPrice1 contains the aforementioned The type identifier expose, so that the event currentPrice1 is marked as corresponding to the special event function, and the event currentPrice2 does not contain the type identifier expose, so that the event currentPrice2 is marked as corresponding to the normal event function, then the transaction initiator belongs to the default user In the case of type, in the logs Log1 and Log2 generated by the event currentPrice1 and the event currentPrice2 respectively, all the fields contained in the log Log1 are stored in plain text, and all the fields contained in the log Log2 are stored in cipher text.
  • the type identifier and the exposed identifier are similar, they are both global identifiers defined in the programming language of the smart contract, but the exposed identifier acts on contract-level objects and the type identifier acts on the event function.
  • the number of event functions included in the event function is large, and the number of objects (such as fields or state variables) involved in the event function is large, there is no need to implement setting operations for each object involved in each event function, which can simplify the code logic , Prevent mislabeling or missing labels.
  • the contract-level object in the above embodiment includes fields, such as the From field. Contract-level objects can also include state variables; for example, the above code example 17 can be adjusted to the following code example 19:
  • the event currentPrice1 and event currentPrice2 refer to the state variable price
  • the event currentPrice3 refers to the state variable price1
  • the state variable can be used Price is the contract-level object mentioned above.
  • the transaction initiator belongs to the preset user type
  • the event function that references the contract-level object in the log generated by the special event function, the content of the receipt corresponding to the contract-level object is stored in plain text, and Even if the ordinary event function refers to the contract-level object, the generated log is still stored in ciphertext.
  • the event currentPrice1 corresponds to the special event function, because the event currentPrice1 refers to the state variable as a contract-level object price, so in the log Logs generated by the event currentPrice1, the receipt content related to the state variable price is stored in plain text;
  • the event currentPrice2 corresponds to a normal event function, although the event currentPrice2 refers to the state variable as a contract-level object price, but in the log Logs generated by the event currentPrice2, the receipt content related to the state variable price is stored in ciphertext; although the event currentPrice3 corresponds to a special event function, because the event currentPrice3 does not reference the contract-level object The state variable price, therefore the log Logs generated by the event currentPrice3 are stored in cipher text.
  • the type of the event function can be marked by the type identifier.
  • the above code sample 19 can be adjusted to the following code sample 20:
  • the state variable price can be marked as a contract-level object by exposing the identifier, while the state variable price1 is not a contract-level object; the events currentPrice1 and currentPrice3 marked by the type identifier expose correspond to special event functions , And the event currentPrice2 corresponds to the normal event function. Therefore, in the case that the transaction initiator belongs to the preset user type, in the log Logs generated by the event currentPrice1, the receipt content related to the state variable price is stored in plain text; in the log Logs generated by the event currentPrice2, The contents of receipts related to the state variable price are all stored in ciphertext; the log Logs generated by the event currentPrice3 are all stored in ciphertext.
  • the objects indicated by the exposure identifier may include: event-level objects corresponding to at least one event defined in the smart contract, so that when the transaction initiator belongs to the preset user type, the first blockchain The node stores the part of the receipt content generated by the special event function that corresponds to the event-level object in plain text.
  • the above event-level objects can be set for at least some of the events, so that the content of the receipt corresponding to this part of the event is stored in plain text, and the content of the receipt corresponding to the remaining events is stored in cipher text .
  • the above code example 18 can be adjusted to the following code example 21:
  • the event currentPrice1 does not add the exposed identifier "plain", it contains the content "from".
  • the content "from” corresponds to the From field and is used to indicate the From field in the log generated by the event currentPrice1 It needs to be stored in plain text, so the content "from” not only belongs to the above exposed identifier, but also indicates the From field that needs to be stored in plain text.
  • the From field is an event-level object, so that when the transaction initiator belongs to the preset user type, when the event currentPrice1 corresponds to a special event function, the event currentPrice1 corresponds to In the generated log Logs, the From field will be stored in plain text, and other fields will be stored in cipher text.
  • the other event currentPrice2 contained in code example 21 since no exposure identifier is added for the event currentPrice2, regardless of whether the event currentPrice2 corresponds to a special event function or a normal event function, the generated log Logs are in the form of ciphertext storage.
  • From field indicates that the From field is set as an event-level object; for the case where the event-level object is a field type, the specific field may not be specified.
  • the above code example 18 can be adjusted to the following code example 22:
  • Event-level objects can also include state variables. From the perspective of the state variable, the above code example 22 can be interpreted as: the event currentPrice1 refers to the state variables price and price1, and the event currentPrice2 refers to the state variable price1; because by adding the exposure identifier "plain" before the event currentPrice1, you can The state variables price and price1 referenced by the event currentPrice1 are used as the above event-level objects, so that when the transaction initiator belongs to the preset user type, when the event currentPrice1 corresponds to a special event function, the event currentPrice1 is generated In Logs, the receipt content related to the state variables price and price1 are stored in plain text.
  • the event-level object when the event-level object includes state variables, it can also specifically indicate one or more state variables referenced by the event.
  • the above code sample 18 can be adjusted to the following code sample 23:
  • the event function corresponding to the event currentPrice1 includes the exposed identifier plain added before the type int of the state variable price, so that the state variable price is configured as an event-level object. Since the exposure identifier plain is located in the event function corresponding to the event currentPrice1, and the event function corresponding to the event currentPrice2 refers to the state variable price but does not label the exposure identifier plain, the event function corresponding to the event currentPrice2 has nothing to do with event-level objects.
  • the transaction initiator belongs to the preset user type, even if both the event currentPrice1 and the event currentPrice2 correspond to special event functions, only the log generated by the event currentPrice1 will be the receipt corresponding to the state variable price of the event-level object
  • the content is stored in plain text, and the logs generated by the event currentPrice2 are stored in cipher text.
  • the event currentPrice1 references the state variable price1
  • the state variable price1 since the state variable price1 is not marked by the exposed identifier, the state variable price1 does not belong to the event level Object, even if the event currentPrice1 corresponds to a special event function, in the log generated by the event currentPrice1, the content of the receipt corresponding to the state variable price1 is still stored in cipher text.
  • this specification can further take into account the identification of the user type of the transaction initiator and the receipt content in the receipt data that meets the preset conditions, thereby simultaneously according to the exposed identifier, the user type of the transaction initiator and the receipt The content meets the preset conditions and determines the storage method of the receipt data. Therefore, the above step 308 can be improved as: the first blockchain node stores the receipt data so that when the transaction initiator belongs to the preset user type, the content of the receipt corresponding to the object indicated by the exposure identifier satisfies The part of the preset conditions is stored in plain text, and the remaining receipt content of the receipt data is stored in cipher text.
  • the exposed identifier is a global identifier defined in the programming language of the smart contract, as long as the exposed identifier is written in the smart contract, it is difficult to modify the object marked by the exposed identifier.
  • the user type depends on the transaction initiator and has nothing to do with the programming language, so that even when different transaction initiators call the same smart contract, the storage method (ciphertext or plaintext) of the receipt data may be different.
  • the preset conditions are not necessarily implemented based on the programming language in the smart contract where the identifier is exposed. Therefore, by calling the smart contract by different users or adjusting the preset conditions used, it is possible to escape the exposure of the identifier. Limit and adjust the content of receipts that need to be stored in plain text or cipher text.
  • the foregoing code example can be improved based on the satisfaction of the preset conditions by the user type of the transaction initiator and the content of the receipt.
  • the code example 2 above by adding the exposed identifier plain to the front of the code of the smart contract, after the code of the smart contract is executed, the receipt data can be generated when the transaction initiator belongs to the preset user type. All fields that meet the preset conditions are stored in plain text.
  • the fields that need to be stored in plaintext can also be specified.
  • the From field is marked by the exposed identifier, it can be made that if the transaction initiator belongs to the preset user type, if the receipt content corresponding to the From field in the generated receipt data meets the preset conditions, the From field corresponds to The receipt content of is stored in plain text, and subsequent retrieval operations can be performed on the receipt content in the From field, for example, the transaction volume initiated by a certain account can be counted.
  • the objects (all fields or From fields) marked by the exposed identifier "plain" are contract-level objects, so that the first blockchain node is storing
  • all receipt contents corresponding to the "From field” of the contract-level object in the receipt data are allowed to be stored in plain text (provided that the transaction initiator belongs to the preset user type and the relevant receipt contents meet the preset conditions).
  • the contract-level object can be applied to all events in the smart contract.
  • From field Take the From field as an example: when the transaction initiator belongs to the preset user type, for any For the log Logs generated by an event, if the From field contained in the log Logs meets the preset condition, the From field will be stored in plain text without adding an exposure identifier for each event.
  • the exposed identifier can also be used to identify other objects.
  • the object indicated by the exposure identifier may include a state variable, and the state variable may also be a contract-level object.
  • the state variable Take the state variable "price” as an example.
  • the exposed identifier "plain” is added before the type int of the state variable "price” (or, the exposed identifier plain can be placed after the type int) , You can mark the state variable price as a contract-level object.
  • the various fields of the receipt data generated after the code of the smart contract is executed (usually including Topic field, Output field, etc.)
  • the state variable price usually the value of the state variable price is recorded
  • the contract-level object can be applied to all events in the smart contract.
  • each log Logs may generate the receipt content related to the state variable "price" (depending on whether the state variable price is applied to the related event), which can be connected with
  • the preset conditions are compared and judged to determine whether the price value in each log Logs is stored in plain text, without adding an exposure identifier to the state variable "price" in each event; similarly, the Output field will also contain The content of the receipt related to the state variable "price".
  • the same or different preset conditions can be used to determine whether to store in plaintext form, which depends on the configuration rules for the “preset conditions”.
  • the above-mentioned contract-level object may include some or all of the state variables.
  • the code example 4 above multiple state variables such as “price” and “price1" are defined in the code of the smart contract, and the user can only add the exposed identifier plain for the state variable "price” to make the state variable "Price” becomes a contract-level object, while the state variable "price1" is not marked by an exposed identifier.
  • the objects indicated by the exposed identifiers may include: event-level objects corresponding to at least one event defined in the smart contract, so that when the transaction initiator belongs to the preset user type, if the receipt data corresponds to If the receipt content of the at least one event meets the preset condition, the corresponding receipt content is stored in plain text.
  • event-level objects can be set for at least some of the events, so that when the transaction initiator belongs to the preset user type, the content of the receipt corresponding to this part of the event is satisfied
  • preset conditions are stored in plain text
  • the contents of receipts corresponding to other events are stored in cipher text. Take the From field as an example.
  • the character from corresponding to the From field is added to the event function "event currentPrice(int price)" corresponding to the event currentPrice, and the exposed identifier used by the character from is different
  • the character from is modified by quotation marks.
  • the quotation marks in code example 5 are equivalent to the aforementioned exposed identifier, so that the From field is marked as an event-level object, and therefore belongs to the default user at the transaction initiator In the case of type, if the From field of the log generated corresponding to the event meets the preset condition, the From field is stored in plain text.
  • the above event-level object will not affect the other event, and the receipt content corresponding to the other event will be stored in ciphertext unless it exists
  • the "from” added for the other event and the From field in the Logs generated by the other event meets the preset condition.
  • the event-level object includes all the fields in the log Logs corresponding to the event currentPrice.
  • the aforementioned From field, To field, Topic field, Log Data field, etc. can be compared with preset conditions respectively, so that when the transaction initiator belongs to the preset user type, the fields that meet the preset conditions are written in plain text Form storage.
  • Event-level objects can also include state variables. From the perspective of state variables, the above code example 6 can be interpreted as: the event currentPrice refers to the state variable "price". By adding the exposure identifier "plain" before the event currentPrice, the state variable referenced by the event currentPrice can be price is used as the above event-level object, and the receipt content related to the state variable price in the log Logs generated by the event currentPrice is determined, so that when the transaction initiator belongs to the preset user type, the determined receipt content is satisfied
  • the preset conditions are stored in plain text, and when the preset conditions are not met, they are stored in cipher text.
  • the state variable "price” belongs to the event-level object in Code Example 6, when the code of the smart contract also contains another event event1 that references the state variable "price”, if no level of exposure is added to the event event1 Identifier, even if the event event1 references the state variable "price", the content of the receipt generated by the event event1 will still be stored in cipher text, not in plain text.
  • the above event-level object may include all the state variables referenced.
  • the event function "event currentPrice(int price, int price1)" corresponding to the event currentPrice refers to the state variables "price” and "price1”
  • the exposing identifier plain is added before the event , So that the referenced state variables "price” and "price1” will be affected.
  • the transaction initiator belongs to the preset user type In this case, those that meet the preset conditions are stored in plain text, and those that do not meet the conditions are stored in cipher text. However, for other events where the exposed identifier plain is not added, the contents of the receipts generated are stored in cipher text.
  • the event-level object When the event-level object includes state variables, it can also specifically indicate one or more state variables referenced by the event. Take the state variable "price” as an example.
  • the event function "event currentPrice(int price)" corresponding to the event currentPrice refers to the state variable "price", and the type of the state variable "price” Add the exposure identifier plain before int, so that the state variable "price” is configured as an event-level object, and the event-level object is only applicable to the event currentPrice, not applicable to other events included in the smart contract, that is: on the transaction initiator
  • only the receipt content related to the state variable "price” generated by the event currentPrice can be stored in plain text when the preset conditions are met, and other content in the receipt data is in cipher text. storage.
  • the state variable "price” can be configured as an event-level object without adding the exposed identifier plain
  • the state variable "price1" is not an event-level object, so that when the transaction initiator belongs to the preset user type, the content of the receipt related to the state variable "price” generated by the event currentPrice will be in plain text when the preset conditions are met
  • the receipt content related to the state variable "price1" must be stored in ciphertext.
  • this specification can further take into account the transaction type of the transaction and the event function contained in the smart contract, so as to simultaneously identify the transaction type and the exposed field corresponding to the transaction type and the event function contained in the smart contract.
  • the special event function determines the storage method of the receipt data. Therefore, the above step 308 can be improved as: the first blockchain node stores the receipt data, so that at least part of the receipt content in the log corresponding to the special event function is stored in plain text, and the rest of the receipt data It is stored in a ciphertext form, and the at least a part of the receipt content includes an exposed field indicated by the exposure identifier.
  • the exposed identifier plain is added to the front of the code of the smart contract. From the perspective of the programming language, the exposed identifier plain indicates: the receipt data generated after the code of the smart contract is executed All fields in are allowed to be stored in plain text, so subsequent retrieval operations can be performed on the receipt content in these fields. For example, the From field can be used to count the transaction volume initiated by an account.
  • the exposed identifier is a global identifier defined in the programming language of the smart contract, it is difficult to modify the fields marked by the exposed identifier as long as the exposed identifier is written in the smart contract.
  • the transaction type has nothing to do with the programming language and can be selected by the user according to the actual needs.
  • the definition of the special event function is not necessarily based on the programming language. For example, when recording the special event function based on the special event function list, even in the smart contract A certain event function included is originally a special event function.
  • a smart contract can include the following code example 24:
  • the exposed identifier "plain" is located at the forefront of the smart contract code, so that all fields in the receipt data are marked as contract-level fields; at the same time, in the smart contract Contains events currentPrice1 and event currentPrice2: Assuming that the From field is the exposed field corresponding to the transaction type, and the event currentPrice1 corresponds to the special event function defined in the special event function list, and the event currentPrice2 corresponds to the normal event function, then in the event currentPrice1 and event currentPrice2 In the generated logs Log1 and Log2, the From field contained in log Log1 is stored in plain text, and the From field contained in log Log2 is stored in cipher text; similarly, other fields in log Log1 that are exposed fields are also stored in plain text.
  • Non-exposed fields are stored in cipher text, and all fields of log Log2 are stored in cipher text. Moreover, if the event currentPrice2 is updated to correspond to the special event function by updating the list of special event functions, all the fields that belong to the exposed fields contained in the log Log2 will be stored in plain text, without the need to do anything to the smart contract code change.
  • the aforementioned type identifier can be used to indicate whether the event function included in the smart contract is a special event function.
  • the above code example 24 can be adjusted to the following code example 25:
  • the contract-level fields include all the fields in the receipt data; at the same time, the smart contract contains the event currentPrice1 and the event currentPrice2: because the event currentPrice1 contains the above-mentioned
  • the type identifier expose causes the event currentPrice1 to be marked as corresponding to the special event function, while the event currentPrice2 does not contain the type identifier expose, so that the event currentPrice2 is marked as corresponding to the normal event function, then the event currentPrice1 and event currentPrice2 are generated respectively In the logs Log1 and Log2, all the exposed fields corresponding to the transaction type in the log Log1 are stored in plain text, and all the fields contained in the log Log2 are stored in cipher text.
  • the type identifier and the exposed identifier are similar, they are both global identifiers defined in the programming language of the smart contract, but the exposed identifier acts on the contract-level fields and the type identifier acts on the event function, so that by In conjunction with the type identifier, you only need to add a single exposure identifier to set the contract-level fields mentioned above, and then you can flexibly mark the event functions that you want to store the contract-level fields in plaintext, especially when smart contracts When there are a large number of event functions included in the event function and the number of fields involved in the event function is large, you only need to add a "plain" similar to the above. There is no need to implement settings for each event function separately, which can simplify the code logic , Prevent mislabeling or missing labels.
  • the fields marked by the exposure identifier may include: event-level fields corresponding to at least one event defined in the smart contract, so that the first blockchain node can determine the at least one event when storing the receipt data.
  • a log generated by a special event function corresponding to an event, and the determined exposed fields belonging to the event-level field in the log are stored in plain text.
  • the above event-level fields can be set for at least some of the events, so that the exposed fields belonging to the event-level fields in the logs corresponding to these events are stored in plain text, and this part of the events Other fields in the corresponding log and the contents of receipts corresponding to other events are stored in cipher text.
  • the above code example 25 can be adjusted to the following code example 26:
  • the event currentPrice1 does not add the exposed identifier "plain", it contains the content "from".
  • the content "from” corresponds to the From field and is used to indicate the From field in the log generated by the event currentPrice1 It needs to be stored in plain text, so the content "from” not only belongs to the above exposed identifier, but also indicates the From field that needs to be stored in plain text.
  • the From field is an event-level field, so that when the From field is an exposed field corresponding to the transaction type and the event currentPrice1 corresponds to a special event function, the log generated in the event currentPrice1 corresponds to In Logs, the From field will be stored in plain text, and other fields will be stored in cipher text.
  • the other event currentPrice2 contained in code example 26 since no exposure identifier is added for the event currentPrice2, regardless of whether the event currentPrice2 corresponds to a special event function or a normal event function, the generated log Logs are in the form of ciphertext storage.
  • From indicates that the From field is set as an event-level field; however, in other embodiments, the specific field may not be specified.
  • code example 25 can be adjusted to the following code example 27:
  • all the fields in the log generated by the event currentPrice1 can be used as the aforementioned event-level fields, such as the aforementioned From and To fields. , Topic field, Log Data field, etc.
  • the event currentPrice1 corresponds to a special event function
  • the log field that belongs to both the above event-level field and the exposed field corresponding to the transaction type can be determined from the log generated by the event currentPrice1, and stored in plain text; If the above-mentioned From field, To field, Topic field, Log Data field, etc. are all exposed fields, it is equivalent to storing all receipt content (such as the generated log) corresponding to the event currentPrice1 in plain text.
  • this specification can further recognize the transaction type of the transaction and the receipt content that meets the preset conditions in the receipt data, thereby simultaneously according to the exposed identifier, the exposed field corresponding to the transaction type and the receipt The content meets the preset conditions and determines the storage method of the receipt data. Therefore, the above step 308 can be improved to: the first blockchain node stores the receipt data, so that the exposed fields in the receipt data that are marked by the exposure identifier and meet the preset conditions are stored in plain text, and the remaining receipts The fields are stored in cipher text.
  • the foregoing code examples can be improved based on the transaction type and the content of the receipt satisfying the preset conditions.
  • the above code example 2 by adding the exposing identifier plain to the front of the smart contract code, after the smart contract code is executed, for the exposed fields corresponding to the transaction type of the smart contract to which the transaction belongs, the generated receipt data
  • the contents of the receipt corresponding to the above exposed fields and meeting the preset conditions are all stored in plain text.
  • the fields that need to be stored in plaintext can also be specified.
  • the From field when annotating the From field with an exposed identifier, only the From field can be judged: if the From field is the exposed field corresponding to the transaction type of the transaction to which the smart contract belongs, then after the code of the smart contract is executed, it will be generated
  • the content of the receipt corresponding to the From field that meets the preset conditions in the receipt data is stored in plain text, and subsequent retrieval operations can be performed on the content of the receipt in the From field stored in plain text, for example, the transaction volume initiated by a certain account can be counted And so on; except for the other fields before the From field, they are all stored in cipher text.
  • the fields (all fields or From fields) marked by the exposed identifier "plain" are contract-level fields, so that the first blockchain node is storing
  • the contract-level field is an exposed field
  • the first blockchain node will store all the receipt contents in the receipt data that correspond to the contract-level field and meet the preset conditions in plain text.
  • the contract-level field can be applied to all events in the smart contract.
  • From field Take the From field as an example: when the From field is a contract-level field and the exposed field corresponding to the transaction type For multiple events to generate their corresponding Logs fields, the From field contained in each Logs field can be compared with preset conditions, so that the From field that meets the preset conditions is stored in plain text without Add an exposure identifier for each event.
  • the fields indicated by the exposure identifier may include: event-level fields corresponding to at least one event defined in the smart contract, so that when the first blockchain node stores the receipt data, if the event-level field belongs to the transaction
  • the exposed field corresponding to the type can determine the receipt content corresponding to the at least one event in the receipt data, and store the determined part of the receipt content corresponding to the event-level field and meeting preset conditions in plain text.
  • the above event-level fields can be set for at least some of the events, so that the part of the receipt content corresponding to these events that corresponds to the event-level field and meets the preset conditions is in plain text Store, and the remaining part of the receipt content corresponding to this part of the event and the receipt content corresponding to the remaining events are stored in cipher text.
  • From field Take the From field as an example.
  • the character from corresponding to the From field is added to the event function "event currentPrice(int price)" corresponding to the event currentPrice, and the exposed identifier used by the character from is different
  • the character from is modified by quotation marks.
  • the quotation marks in code example 5 are equivalent to the aforementioned exposure identifier, and the From field is configured as an event-level field, so that when the From field belongs to the exposure corresponding to the transaction type In the Logs field corresponding to the event, the From field can be stored in plain text when the preset conditions are met, otherwise the From field will still be stored in cipher text.
  • the code of the smart contract also contains another event, then the above “from” will not affect the other event, and the receipt content corresponding to the other event will be stored in ciphertext unless it exists "From" added for this other event.
  • this specification can further recognize the event function contained in the smart contract and the receipt content in the receipt data that meets the preset conditions, thereby simultaneously revealing the identifier and the special event contained in the smart contract.
  • the function and receipt content meets the preset conditions and determines the storage method of the receipt data. Therefore, the above step 308 can be improved as: the first blockchain node stores the receipt data, so that at least part of the receipt content in the log corresponding to the special event function is stored in plain text, and the rest of the receipt data Stored in a ciphertext form, the at least a part of the receipt content matches the object indicated by the exposure identifier and meets a preset condition.
  • the foregoing code example can be improved based on the event function contained in the smart contract and the content of the receipt to meet the preset conditions.
  • code example 2 by adding the exposed identifier plain to the front of the smart contract code, after the smart contract code is executed, all fields in the generated receipt data are allowed to be stored in plain text.
  • the fields that need to be stored in plaintext can also be specified.
  • the code of the smart contract can be executed, and the receipt content corresponding to the From field in the generated receipt data can be stored in plain text (it is necessary to further combine the event function and preset The dimensions of the conditions are used to determine whether plaintext storage is actually used), then subsequent retrieval operations can be performed on the receipt content in the From field, for example, the transaction volume initiated by a certain account can be counted.
  • the exposed identifier can also be used to identify other objects.
  • the object identified by the exposure identifier may include state variables. Take the state variable "price" as an example.
  • the exposed identifier "plain” is added before the type int of the state variable "price” (or, the exposed identifier plain can be placed after the type int)
  • the receipt content related to the state variable "price” is allowed to be stored in plain text (requires further combination
  • the dimensions of the event function and the preset conditions are used to determine whether to actually use plaintext storage), then subsequent retrieval operations can be implemented for the content of the receipt related to the state variable "price".
  • special event functions are not necessarily based on programming languages. For example, when special event functions are recorded based on a list of special event functions, even if an event function included in the smart contract originally belongs to For special event functions, you can also update the original special event functions to ordinary event functions by changing the list of special event functions, so as to prevent the log generated by the event function from being stored in plain text, or to store the original ordinary events The function is updated to a special event function, so that at least part of the content in the log generated by the event function is stored in plain text.
  • the state variable "price" marked by the exposure identifier "plain” is also a contract-level object, so that when the first blockchain node stores the receipt data, all of the receipt data corresponds to The content of receipts for the contract-level object "price" and meeting preset conditions are allowed to be stored in plain text.
  • a smart contract can include the following code example28:
  • the exposed identifier "plain" is located at the forefront of the code of the smart contract, so that all fields in the receipt data are marked as contract-level objects; at the same time, in the smart contract Contains the event currentPrice1 and event currentPrice2: assuming that the event currentPrice1 corresponds to the special event function defined in the special event function list, and the event currentPrice2 corresponds to the ordinary event function, then in the logs Log1 and Log2 generated by the event currentPrice1 and event currentPrice2, log Log1 All fields that meet the preset conditions in the log are stored in plain text, and regardless of whether the fields in the log Log2 meet the preset conditions, the fields contained in the log Log2 are stored in cipher text.
  • the event currentPrice2 is updated to correspond to the special event function after the special event function list is updated, all fields in the log Log2 that meet the preset conditions are stored in plain text, without the need to do anything to the smart contract code change.
  • the From field is marked by the exposed identifier in Code Example 28, so that when the event currentPrice1 is a special event function and the event currentPrice2 is a normal event function, the From field in the log Log1 is When the preset conditions are met, it is stored in plain text, and when the preset conditions are not met, it is stored in cipher text.
  • log Log1 The remaining fields in log Log1 must be stored in cipher text, while all fields contained in log Log2 are stored in cipher text. ; And, when the event currentPrice2 is updated as a special event function, then the From field in the log Log2 is stored in plain text when the preset conditions are met, otherwise it is stored in cipher text, and the rest of the fields in log Log2 are stored in cipher text .
  • the aforementioned type identifier can be used to indicate whether the event function contained in the smart contract is a special event function.
  • the above code example 28 can be adjusted to the following code example 29:
  • the contract-level object includes all the fields in the receipt data; at the same time, the smart contract includes the event currentPrice1 and the event currentPrice2: because the event currentPrice1 contains the above-mentioned
  • the type identifier expose causes the event currentPrice1 to be marked as corresponding to the special event function, while the event currentPrice2 does not contain the type identifier expose, so that the event currentPrice2 is marked as corresponding to the normal event function, then the event currentPrice1 and event currentPrice2 are generated respectively In logs Log1 and Log2, all fields in log Log1 that meet the preset conditions are stored in plain text, regardless of whether the fields in log Log2 meet the preset conditions, all fields in log Log2 are stored in cipher text.
  • the type identifier and the exposed identifier are similar, they are both global identifiers defined in the programming language of the smart contract, but the exposed identifier acts on contract-level objects and the type identifier acts on the event function.
  • the number of event functions included in the event function is large, and the number of objects (such as fields or state variables) involved in the event function is large, there is no need to implement setting operations for each object involved in each event function, which can simplify the code logic , Prevent mislabeling or missing labels.
  • the contract-level object in the above embodiment includes fields, such as the From field. Contract-level objects can also include state variables; for example, the above code example 28 can be adjusted to the following code example 30:
  • the event currentPrice1 and event currentPrice2 refer to the state variable price
  • the event currentPrice3 refers to the state variable price1
  • the state variable can be the state variable Price is the contract-level object mentioned above.
  • the event function that refers to the contract-level object in the log generated by the special event function, the content of the receipt corresponding to the contract-level object is stored in plaintext when the preset conditions are met, while the ordinary event function is even referenced With this contract-level object, the generated log is still stored in ciphertext.
  • the event currentPrice1 corresponds to the special event function, because the event currentPrice1 references the state variable price as a contract-level object, in the log Logs generated by the event currentPrice1,
  • the receipt content related to the state variable price is stored in clear text when the preset conditions are met;
  • the event currentPrice2 corresponds to a normal event function, although the event currentPrice2 refers to the state variable price as a contract-level object, it is in the event In the log Logs generated by currentPrice2, the receipt content related to the state variable price is stored in ciphertext regardless of whether it meets the preset conditions; although the event currentPrice3 corresponds to a special event function, because the event currentPrice3 is not referenced as a contract-level object
  • the state variable price so the log Logs generated by the event currentPrice3 are stored in ciphertext regardless of whether they meet the preset conditions.
  • the type of the event function can be marked by the type identifier.
  • the above code example 30 can be adjusted to the following code example 31:
  • the state variable price can be marked as a contract-level object by exposing the identifier, while the state variable price1 is not a contract-level object; the events currentPrice1 and currentPrice3 marked by the type identifier expose correspond to special event functions. , And the event currentPrice2 corresponds to the normal event function.
  • the receipt content related to the state variable price is stored in plaintext when the preset conditions are met; in the log Logs generated by the event currentPrice2, the content related to the state variable price The contents of the receipt are stored in ciphertext regardless of whether they meet the preset conditions; the log Logs generated by the event currentPrice3 are stored in ciphertext regardless of whether they meet the preset conditions.
  • the objects indicated by the exposed identifiers may include: event-level objects corresponding to at least one event defined in the smart contract, so that the first blockchain node generates the special event function when storing the receipt data
  • the part of the receipt content corresponding to the event-level object is stored in plain text.
  • the above event-level object can be set for at least some of the events, so that the part of the receipt content generated by this part of the event that corresponds to the event-level object meets the preset conditions
  • the following is stored in plain text, and the contents of other receipts generated by this part of the event and all receipts generated by other events are stored in cipher text.
  • the above code example 29 can be adjusted to the following code example 32:
  • the event currentPrice1 does not add the exposed identifier "plain", it contains the content "from".
  • the content "from” corresponds to the From field and is used to indicate the From field in the log generated by the event currentPrice1 It needs to be stored in plain text, so the content "from” not only belongs to the above exposed identifier, but also indicates the From field that needs to be stored in plain text.
  • the From field is an event-level object, so that when the event currentPrice1 corresponds to a special event function, in the log Logs generated corresponding to the event currentPrice1, the From field satisfies the preset conditions In the case of storing in plaintext, other fields are stored in ciphertext.
  • the other event currentPrice2 contained in code example 32 since no exposure identifier is added for the event currentPrice2, regardless of whether the event currentPrice2 corresponds to a special event function or a normal event function, the generated log Logs are in the form of ciphertext storage.
  • From field indicates that the From field is set as an event-level object; for the case where the event-level object is a field type, the specific field may not be specified.
  • the above code example 29 can be adjusted to the following code example 33:
  • Event-level objects can also include state variables. From the perspective of the state variable, the code example 33 above can be interpreted as: the event currentPrice1 refers to the state variables price and price1, and the event currentPrice2 refers to the state variable price1; because by adding the exposure identifier "plain" before the event currentPrice1, you can The state variables price and price1 referenced by the event currentPrice1 are used as the above event-level objects, so that when the event currentPrice1 corresponds to a special event function, in the log Logs generated by the event currentPrice1, the receipts related to the state variables price and price1 The content is stored in plaintext when the preset conditions are met.
  • the event-level object When the event-level object includes state variables, it can also specifically indicate one or more state variables referenced by the event.
  • the above code example 29 can be adjusted to the following code example 34:
  • the event function corresponding to the event currentPrice1 contains the exposed identifier plain added before the type int of the state variable price, so that the state variable price is configured as an event-level object, and the event-level object is only Applies to the event currentPrice1. Since the exposure identifier plain is located in the event function corresponding to the event currentPrice1, and the event function corresponding to the event currentPrice2 refers to the state variable price but does not label the exposure identifier plain, the event function corresponding to the event currentPrice2 has nothing to do with event-level objects.
  • the event currentPrice1 and the event currentPrice2 correspond to special event functions, only in the log generated by the event currentPrice1, the content of the receipt corresponding to the state variable price as the event-level object will be stored in clear text when the preset conditions are met. , And the logs generated by the event currentPrice2 are stored in ciphertext.
  • the event currentPrice1 references the state variable price1, because the state variable price1 is not marked by the exposed identifier, the state variable price1 does not belong to the event-level object, even if the event currentPrice1 corresponds to a special event function, In the log generated by the event currentPrice1, the content of the receipt corresponding to the state variable price1 is still stored in ciphertext.
  • this specification can further consider the user type of the transaction initiator, the transaction type of the transaction, and the event function contained in the smart contract, so as to be based on the exposed identifier and the user type of the transaction initiator.
  • the exposed field corresponding to the transaction type and the special event function contained in the smart contract determine the storage method of the receipt data.
  • the above step 308 can be improved as: the first blockchain node stores the receipt data so that when the transaction initiator belongs to the preset user type, at least part of the receipt content in the log corresponding to the special event function It is stored in plain text, and the rest of the receipt data is stored in cipher text, and the at least a part of the receipt content matches the exposed field indicated by the exposure identifier.
  • the foregoing code examples can be improved based on the user type of the transaction initiator, the exposed fields corresponding to the transaction type, and the special event functions contained in the smart contract.
  • the exposed identifier plain is added to the front of the smart contract code, so that after the smart contract code is executed, when the transaction initiator belongs to the preset user type, the receipt data is subject to special events
  • the log generated by the function allows the content of the receipt corresponding to the exposed field corresponding to the transaction type of the smart contract to be stored in plain text. For example, when the From field in the log is an exposed field and the To field is not an exposed field, you can change The From field of all logs in the receipt data is stored in plain text, and the To field is stored in cipher text. Then, subsequent retrieval operations can be performed on the receipt content in the From field, for example, the transaction volume initiated by a certain account can be counted.
  • the exposed identifier is a global identifier defined in the programming language of the smart contract, it is difficult to modify the fields marked by the exposed identifier as long as the exposed identifier is written in the smart contract.
  • the user type depends on the transaction initiator and has nothing to do with the programming language, so that even when different transaction initiators call the same smart contract, the storage method (ciphertext or plaintext) of the receipt data may be different.
  • the transaction type can also be selected by the transaction initiator according to demand to indicate the actual needs of the transaction initiator.
  • the definition of special event functions is not necessarily based on programming languages.
  • the From field When the From field is further an exposed field corresponding to the transaction type, it can be preset at the transaction initiator In the case of the user type, when the first blockchain node stores the receipt data, all the receipt contents corresponding to the From field in the receipt data are allowed to be stored in plain text.
  • a smart contract can include the following code example 35:
  • the exposed identifier "plain" is located at the forefront of the smart contract code, so that all fields in the receipt data are marked as contract-level fields; at the same time, in the smart contract Contains the event currentPrice1 and the event currentPrice2: assuming that the event currentPrice1 corresponds to the special event function defined in the special event function list, and the event currentPrice2 corresponds to the normal event function, then the transaction initiator belongs to the preset user type and the From field is an exposed field.
  • the From field contained in the log Log1 is stored in plain text
  • the From field contained in the log Log2 is stored in cipher text; similarly, the log Log1 belongs to the exposed field.
  • Other fields are also stored in plain text, non-exposed fields are stored in cipher text, and all fields of log Log2 are stored in cipher text.
  • the event currentPrice2 is updated to correspond to the special event function by updating the list of special event functions, all the fields that belong to the exposed fields contained in the log Log2 will be stored in plain text, without the need to do anything to the smart contract code change.
  • the aforementioned type identifier can be used to indicate whether the event function included in the smart contract is a special event function.
  • the above code example 35 can be adjusted to the following code example 36:
  • the contract-level fields include all the fields in the receipt data; at the same time, the smart contract contains the event currentPrice1 and the event currentPrice2: because the event currentPrice1 contains the above-mentioned
  • the type identifier expose, so that the event currentPrice1 is marked as corresponding to the special event function, and the event currentPrice2 does not contain the type identifier expose, so that the event currentPrice2 is marked as corresponding to the normal event function, then the transaction initiator belongs to the default user
  • all the exposed fields corresponding to the transaction type in the log Log1 are stored in plain text, and all the fields contained in the log Log2 are stored in cipher text.
  • the fields indicated by the exposure identifier may include: event-level fields corresponding to at least one event defined in the smart contract, so that the transaction initiator belongs to the preset user type and the event-level field belongs to the exposed field
  • the first blockchain node stores the part of the receipt content generated by the special event function that corresponds to the event-level field in plain text.
  • the above event-level fields can be set for at least some of the events, so that the contents of the receipts corresponding to the above-mentioned event-level fields in the logs generated by these events are stored in plain text, and this The content of the remaining receipts in the log generated by some events and the content of the receipts corresponding to the remaining events are stored in ciphertext.
  • the above code example 36 can be adjusted to the following code example 37:
  • the event currentPrice1 does not add the exposed identifier "plain", it contains the content "from".
  • the content "from” corresponds to the From field and is used to indicate the From field in the log generated by the event currentPrice1 It needs to be stored in plain text, so the content "from” not only belongs to the above exposed identifier, but also indicates the From field that needs to be stored in plain text.
  • the From field is an event-level field, so that when the transaction initiator belongs to the preset user type and the From field is an exposed field, when the event currentPrice1 corresponds to a special event function
  • the From field will be stored in plain text, and other fields will be stored in cipher text.
  • the other event currentPrice2 contained in code example 37 since no exposure identifier is added for the event currentPrice2, regardless of whether the event currentPrice2 corresponds to a special event function or a normal event function, the generated log Logs are in ciphertext form storage. In the embodiment corresponding to this code example 37, that is, for event-level fields, it is possible to identify whether the event functions contained in the smart contract are special event functions by means of a special event function list or type identifier. Repeat.
  • this specification can further take into account the user type identifying the transaction initiator, the transaction type of the transaction, and the receipt content that meets the preset conditions in the receipt data, thereby simultaneously according to the exposed identifier, the transaction initiator
  • the user type, the exposure field corresponding to the transaction type, and the satisfaction of the receipt content to the preset conditions determine the storage method of the receipt data. Therefore, the above step 308 can be improved to: the first blockchain node stores the receipt data, and when the transaction initiator belongs to the preset user type, the receipt data is marked by the exposure identifier and meets the preset requirements.
  • the exposed fields of the conditions are stored in plain text, and the remaining receipt fields are stored in cipher text.
  • the foregoing code examples can be improved based on the user type of the transaction initiator, the exposure fields corresponding to the transaction type, and the content of the receipt to meet the preset conditions.
  • the above code example 2 by adding the exposed identifier plain to the front of the smart contract code, after the smart contract code is executed, when the transaction initiator belongs to the preset user type, the transaction to which the smart contract belongs.
  • the exposed fields corresponding to the transaction types of the generated receipt data corresponding to the above exposed fields and meeting the preset conditions are stored in plain text.
  • the fields that need to be stored in plaintext can also be specified.
  • the fields (all fields or From fields) marked by the exposed identifier "plain" are contract-level fields, so that the first blockchain node is storing
  • the first blockchain node will use all the receipt contents in the receipt data that correspond to the contract-level field and meet the preset conditions with Stored in clear text.
  • the contract-level field can be applied to all events in the smart contract.
  • From field Take the From field as an example: when the transaction initiator belongs to the preset user type, the From field is at the contract level When the fields and the exposed fields corresponding to the transaction type are generated, the Logs fields corresponding to multiple events are generated separately, and the From field contained in each Logs field will be stored in plain text, without the need to add exposure identifiers for each event. symbol.
  • the fields indicated by the exposure identifier may include: event-level fields corresponding to at least one event defined in the smart contract, so that when the first blockchain node stores the receipt data, if the transaction initiator belongs to the pre- Assuming that the user type and the event-level field belong to the exposed field corresponding to the transaction type, the log corresponding to the at least one event in the receipt data can be determined, and the content of the receipt corresponding to the event-level field in the determined log and the preset conditions The comparison is performed so that the content of the receipt meeting the preset condition is stored in plain text.
  • the above event-level fields can be set for at least some of the events, so that the part of the receipt content corresponding to these events that corresponds to the event-level field and meets the preset conditions is in plain text Store, and the remaining part of the receipt content corresponding to this part of the event and the receipt content corresponding to the remaining events are stored in cipher text.
  • From field Take the From field as an example.
  • the character from corresponding to the From field is added to the event function "event currentPrice(int price)" corresponding to the event currentPrice, and the exposed identifier used by the character from is different
  • the character from is modified by quotation marks.
  • the quotation marks in code example 5 are equivalent to the aforementioned exposure identifier.
  • the From field is configured as an event-level field, so that the From field is marked as an event-level field. Therefore, when the transaction initiator belongs to the preset user type and the From field belongs to the exposed field corresponding to the transaction type, in the Logs field corresponding to the event, the From field will be stored in plain text when the preset conditions are met.
  • the code of the smart contract also contains another event, the aforementioned "from" will not affect the other event, and the content of the receipt corresponding to the other event will be stored in ciphertext.
  • the event-level fields include all the fields in the log Logs corresponding to the event currentPrice.
  • the aforementioned From field, To field, Topic field, Log Data field, etc. when the transaction initiator belongs to the preset user type, the exposed fields in these fields can be determined according to the transaction type, and the determined exposed fields are compared with the preset user types. Set conditions for comparison, so that the exposed fields that meet the preset conditions are stored in plain text. Therefore, if the aforementioned From field, To field, Topic field, Log Data field, etc. all meet the preset conditions, it is equivalent to storing all the contents of the receipt generated by the event currentPrice in plain text.
  • this specification can further take into account the transaction type of the identification transaction, the event function contained in the smart contract, and the receipt content in the receipt data that meet the preset conditions, so as to correspond to the exposed identifier at the same time.
  • the exposure field of the transaction type, the special event function contained in the smart contract, and the satisfaction of the content of the receipt to the preset conditions determine the storage method of the receipt data.
  • the above step 308 can be improved as: the first blockchain node stores the receipt data, so that at least part of the receipt content in the log corresponding to the special event function is stored in plain text, and the rest of the receipt data It is stored in a ciphertext form, and the at least a part of the receipt content includes exposed fields that are marked by the exposure identifier and meet a preset condition.
  • the exposure identifier can indicate one or more fields, and these fields have corresponding receipt content in the receipt data. Different types of transactions often have different privacy protection requirements, and the corresponding exposed fields can be allowed to be stored in plain text.
  • the receipt data contains a log corresponding to the special event function, which is actually part of the receipt content in the receipt data.
  • the transaction initiator can select the preset condition that it wants to adopt according to actual needs, and there may be at least a part of the receipt content that meets the preset condition in the receipt data. Therefore, through comprehensive consideration of exposure identifiers, transaction types, special event functions, and preset conditions in this manual, the cross content of the above four parts of receipt content can be screened out, and the cross content can be stored in plain text. The rest of the receipt data Both are stored in cipher text.
  • the transaction type has nothing to do with the programming language and can be selected by the user according to actual needs.
  • the definition of special event functions may not necessarily be implemented based on the programming language, such as recording special events based on the special event function list.
  • the event function even if an event function included in the smart contract originally belongs to a special event function, you can also update the original special event function to a normal event function by changing the list of special event functions to avoid the event
  • the log generated by the function is stored in plain text, or the original ordinary event function is updated to a special event function, so that at least part of the content in the log generated by the event function is stored in plain text.
  • the exposed fields in the log corresponding to the event currentPrice can be stored in plain text without the need to adjust the code example 2; for example, when the From field and the To field To expose fields, the From field and To field in the log generated by the event currentPrice will be stored in plain text, while the remaining fields will be stored in cipher text.
  • the fields marked by the exposed identifier "plain” are all fields in the receipt data, and these fields are contract-level fields . So that when the first blockchain node stores the receipt data, all the receipt contents corresponding to the contract-level field in the receipt data are allowed to be stored in plain text.
  • the From field is marked with the exposed identifier in Code Example 2, then the From field is the contract-level field mentioned above.
  • the From field is further an exposed field corresponding to the transaction type, the first blockchain node can be used When storing receipt data, all the receipt contents corresponding to the From field and meeting preset conditions in the receipt data are allowed to be stored in plain text.
  • a smart contract can include the following code example 38:
  • the exposed identifier "plain" is located at the forefront of the smart contract code, so that all fields in the receipt data are marked as contract-level fields; at the same time, in the smart contract Contains events currentPrice1 and event currentPrice2: Assuming that the From field is the exposed field corresponding to the transaction type, and the event currentPrice1 corresponds to the special event function defined in the special event function list, and the event currentPrice2 corresponds to the normal event function, then in the event currentPrice1 and event currentPrice2 In the generated logs Log1 and Log2, the From field contained in log Log1 is stored in plain text when the preset conditions are met, and the From field contained in log Log2 is stored in cipher text; similarly, other fields in log Log1 that are exposed fields It is also stored in plain text, non-exposed fields are stored in cipher text, and all fields of the log Log2 are stored in cipher text.
  • the aforementioned type identifier can be used to indicate whether the event function included in the smart contract is a special event function.
  • the above code sample 38 can be adjusted to the following code sample 39:
  • the contract-level fields include all the fields in the receipt data; at the same time, the smart contract contains the event currentPrice1 and the event currentPrice2: because the event currentPrice1 contains the above-mentioned
  • the type identifier expose causes the event currentPrice1 to be marked as corresponding to the special event function, while the event currentPrice2 does not contain the type identifier expose, so that the event currentPrice2 is marked as corresponding to the normal event function, then the event currentPrice1 and event currentPrice2 are generated respectively In the logs Log1 and Log2, all the exposed fields in the log Log1 corresponding to the transaction type are stored in plain text when the preset conditions are met, and all the fields contained in the log Log2 must be stored in cipher text.
  • the type identifier and the exposed identifier are similar, they are both global identifiers defined in the programming language of the smart contract, but the exposed identifier acts on the contract-level fields and the type identifier acts on the event function, so that by In conjunction with the type identifier, you only need to add a single exposure identifier to set the contract-level fields mentioned above, and then you can flexibly mark the event functions that you want to store the contract-level fields in plaintext, especially when smart contracts When there are a large number of event functions included in the event function and the number of fields involved in the event function is large, you only need to add a "plain" similar to the above. There is no need to implement settings for each event function separately, which can simplify the code logic , Prevent mislabeling or missing labels.
  • the fields marked by the exposure identifier may include: event-level fields corresponding to at least one event defined in the smart contract, so that the first blockchain node can determine the at least one event when storing the receipt data.
  • a log generated by a special event function corresponding to an event, and the determined exposed fields belonging to event-level fields and meeting preset conditions in the determined log are stored in plain text.
  • the above event-level fields can be set for at least some of the events, so that the exposed fields that belong to the event-level fields and meet the preset conditions in the logs corresponding to this part of the events are stored in plain text , And other fields in the log corresponding to this part of the event, and the content of the receipt corresponding to the remaining events are stored in cipher text.
  • the above code example 39 can be adjusted to the following code example 40:
  • the event currentPrice1 does not add the exposed identifier "plain", it contains the content "from".
  • the content "from” corresponds to the From field and is used to indicate the From field in the log generated by the event currentPrice1 It needs to be stored in plain text, so the content "from” not only belongs to the above exposed identifier, but also indicates the From field that needs to be stored in plain text.
  • the From field is an event-level field, so that when the From field is an exposed field corresponding to the transaction type and the event currentPrice1 corresponds to a special event function, the log generated in the event currentPrice1 corresponds to In Logs, the From field will be stored in plain text when the preset conditions are met, and in cipher text when the preset conditions are not met, and other fields must be stored in cipher text.
  • the other event currentPrice2 contained in code example 40 since no exposure identifier is added for the event currentPrice2, regardless of whether the event currentPrice2 corresponds to a special event function or a normal event function, the generated log Logs are in the form of ciphertext storage.
  • From indicates that the From field is set as an event-level field; however, in other embodiments, the specific field may not be specified.
  • code example 39 can be adjusted to the following code example 41:
  • this specification can further take into account the user type identifying the transaction initiator, the event function contained in the smart contract, and the receipt content in the receipt data that meets the preset conditions, so as to simultaneously expose the identifier, The user type of the transaction initiator, the special event function contained in the smart contract, and the satisfaction of the content of the receipt to the preset conditions determine the storage method of the receipt data.
  • the above step 308 can be improved as: the first blockchain node stores the receipt data so that when the transaction initiator belongs to the preset user type, at least part of the receipt content in the log corresponding to the special event function It is stored in plain text, and the remaining content of the receipt data is stored in cipher text, and the at least part of the receipt content matches the field indicated by the exposure identifier and meets a preset condition.
  • this specification can further take into account the user type identifying the transaction initiator, the transaction type of the transaction, the event function contained in the smart contract, and the receipt content that meets the preset conditions in the receipt data, thereby simultaneously According to the exposure identifier, the user type of the transaction initiator, the exposure field corresponding to the transaction type, the special event function contained in the smart contract, and the satisfaction of the preset conditions by the receipt content, the storage method of the receipt data is determined.
  • the above step 308 can be improved as: the first blockchain node stores the receipt data so that when the transaction initiator belongs to the preset user type, at least part of the receipt content in the log corresponding to the special event function Stored in plain text, and the remaining content of the receipt data is stored in cipher text, and the at least part of the receipt content matches the exposure field indicated by the exposure identifier and meets a preset condition.
  • the first blockchain node when it recognizes the special event function based on the information recorded on the blockchain network (such as the list of special event functions), it can perform the "special event function" after the smart contract has been created.
  • Update to adjust the storage method of receipt data such as changing the original receipt content stored in plain text to cipher text storage, or changing the original receipt content stored in cipher text to plain text storage.
  • the aforementioned code examples can be improved based on the user type of the transaction initiator, the exposed fields corresponding to the transaction type, the special event functions contained in the smart contract, and the content of the receipt to achieve improvement.
  • the exposed identifier plain is added to the front of the smart contract code, so that after the smart contract code is executed, when the transaction initiator belongs to the preset user type, the receipt data is subject to special events
  • the log generated by the function allows the exposed field corresponding to the transaction type of the smart contract to be stored and the content of the receipt meeting preset conditions is stored in clear text, for example, when the From field in the log is an exposed field, and the To field is not an exposed field
  • the From field of all logs in the receipt data can be stored in plain text when the preset conditions are met, and the To field can be stored in cipher text.
  • subsequent retrieval operations can be performed on the receipt content in the From field, such as statistics The volume of transactions initiated by an account, etc.
  • the exposed identifier is a global identifier defined in the programming language of the smart contract, it is difficult to modify the fields marked by the exposed identifier as long as the exposed identifier is written in the smart contract.
  • the user type depends on the transaction initiator and has nothing to do with the programming language, so that even when different transaction initiators call the same smart contract, the storage method (ciphertext or plaintext) of the receipt data may be different.
  • the transaction type can also be selected by the transaction initiator according to demand to indicate the actual needs of the transaction initiator.
  • the preset conditions can be selected by the transaction initiator according to actual needs, regardless of the programming language. At the same time, the definition of special event functions is not necessarily based on programming languages.
  • the From field When the From field is further an exposed field corresponding to the transaction type, it can be preset at the transaction initiator In the case of the user type, when the first blockchain node stores receipt data, all receipt content in the receipt data that corresponds to the From field and meets the preset conditions is allowed to be stored in plain text.
  • a smart contract may include the following code example 42:
  • the exposed identifier "plain" is located at the forefront of the smart contract code, so that all fields in the receipt data are marked as contract-level fields; at the same time, in the smart contract Contains the event currentPrice1 and the event currentPrice2: assuming that the event currentPrice1 corresponds to the special event function defined in the special event function list, and the event currentPrice2 corresponds to the normal event function, then the transaction initiator belongs to the preset user type and the From field is an exposed field.
  • the From field contained in the log Log1 is stored in plaintext when the preset conditions are met, and stored in ciphertext when the preset conditions are not met.
  • the From field contained in log Log2 must be stored in cipher text; similarly, other fields in log Log1 that are exposed fields are also stored in plain text when the preset conditions are met, and non-exposed fields are stored in cipher text. All fields of Log2 are stored in cipher text.
  • the event currentPrice2 is updated to correspond to the special event function after updating the list of special event functions, all the fields belonging to the exposed fields contained in the log Log2 can be stored in plain text under the condition that the preset conditions are met. If the preset conditions are not met, it will be stored in cipher text without any changes to the smart contract code.
  • the aforementioned type identifier can be used to indicate whether the event function included in the smart contract is a special event function.
  • the above code example 42 can be adjusted to the following code example 43:
  • the contract-level fields include all the fields in the receipt data; at the same time, the smart contract contains the event currentPrice1 and the event currentPrice2: because the event currentPrice1 contains the aforementioned The type identifier expose, so that the event currentPrice1 is marked as corresponding to the special event function, and the event currentPrice2 does not contain the type identifier expose, so that the event currentPrice2 is marked as corresponding to the normal event function, then the transaction initiator belongs to the default user
  • all the exposed fields in the log Log1 corresponding to the transaction type are stored in plaintext when the preset conditions are met, and the preset conditions are not met. In the case of, it is stored in cipher text, and all fields contained in the log Log2 must be stored in cipher text.
  • the fields indicated by the exposure identifier may include: event-level fields corresponding to at least one event defined in the smart contract, so that the transaction initiator belongs to the preset user type and the event-level field belongs to the exposed field
  • the first blockchain node stores the part of the receipt content generated by the special event function that corresponds to the event-level field and meets the preset condition in plain text.
  • the above event-level fields can be set for at least some of the events, so that the contents of the receipts that correspond to the above-mentioned event-level fields and meet the preset conditions in the logs generated by this part of the events are in plain text
  • the content of the remaining receipts in the log generated by this part of the event and the content of the receipt corresponding to the remaining events are stored in the form of ciphertext.
  • the event currentPrice1 does not add the exposed identifier "plain", it contains the content "from".
  • the content "from” corresponds to the From field and is used to indicate the From field in the log generated by the event currentPrice1 It needs to be stored in plain text, so the content "from” not only belongs to the above exposed identifier, but also indicates the From field that needs to be stored in plain text.
  • the From field is an event-level field, so that when the transaction initiator belongs to the preset user type and the From field is an exposed field, when the event currentPrice1 corresponds to a special event function In the log Logs corresponding to the event currentPrice1, the From field is stored in plain text when the preset conditions are met, and stored in cipher text when the preset conditions are not met, and other fields must be stored in cipher text Form storage.
  • the generated log Logs are in the form of ciphertext storage.
  • the embodiment corresponding to this code example 44 that is, for event-level fields, it is possible to identify whether the event functions contained in the smart contract are special event functions by means of a special event function list or type identifier. Repeat.
  • the computing device By running the program code of the blockchain (hereinafter referred to as the chain code) on the computing device (physical machine or virtual machine), the computing device can be configured as a blockchain node in the blockchain network, such as the first Blockchain nodes, etc.
  • the first blockchain node runs the above chain code to realize the corresponding functional logic. Therefore, when the blockchain network is created, the receipt data storage logic related to the exposed identifier can be written into the chain code, so that each blockchain node can implement the receipt data storage logic.
  • the receipt data storage logic related to the exposure identifier may include: logic for storing the content of the receipt based on the exposure identifier.
  • the logic of storing the content of the receipt based on the exposed identifier is used to instruct the first blockchain node: for the objects marked by the exposed identifier and the unmarked objects, how to store the corresponding receipt content respectively.
  • the corresponding receipt content is stored in plain text, while for objects not marked by the exposed identifier, the corresponding receipt content is stored in cipher text.
  • this specification can further consider at least one of the following factors: the user type of the transaction initiator, the transaction type of the transaction, and the receipt data meeting preset conditions The content of the receipt and the event function contained in the smart contract.
  • One or more of the above factors can be combined with the exposed identifier to obtain the corresponding receipt data storage logic.
  • the receipt data storage logic When the receipt data storage logic is related to the user type of the transaction initiator, the receipt data storage logic includes: identification logic for the user type.
  • the user type identification logic is used to instruct the first blockchain node to identify the user type of the transaction initiator.
  • the system contract can record the association relationship between the predefined external account and the user type, or the system contract can record the correspondence between the value of the user type field and the user type. For details, please refer to the relevant description of identifying user types above, which will not be repeated here.
  • the receipt data storage logic When the receipt data storage logic is related to the transaction type of the transaction, the receipt data storage logic includes: an identification logic for the transaction type.
  • the identification logic of the transaction type is used to instruct the first blockchain node: to identify the type of transaction initiated by the transaction initiator. For example, according to the value of the transaction type field contained in the exchange, the transaction type corresponding to the transaction is determined. For details, please refer to the relevant description of identifying transaction types above, which will not be repeated here.
  • the receipt data storage logic When the receipt data storage logic is related to the receipt content that meets the preset condition in the receipt data, the receipt data storage logic includes: recognition logic of the event function.
  • the identification logic of the event function is used to instruct the first blockchain node to identify the type of event function contained in the smart contract corresponding to the transaction. For example: according to the type identifier contained in the event function, or according to the list of special event functions recorded in the blockchain network. For details, please refer to the relevant description of identifying special event functions above, which will not be repeated here.
  • the receipt data storage logic When the receipt data storage logic is related to the event function contained in the smart contract, the receipt data storage logic includes: determining logic for preset conditions.
  • the determination logic of the preset condition is used to instruct the first blockchain node to obtain the preset condition applicable to the content of the receipt corresponding to the object indicated by the exposure identifier. For example, obtain general conditions applicable to all receipt fields, or obtain special conditions applicable to the field of the receipt content corresponding to the object indicated by the exposure identifier. For details, please refer to the relevant description of the preset conditions above, which will not be repeated here.
  • the chain code can be combined with the system contract: the chain code is used to realize the basic functions of the blockchain network, and the function extension during operation can be achieved through the system Realized by way of contract.
  • the system contract includes code in the form of bytecode, for example, the first blockchain node can run the system contract code (for example, according to the unique corresponding address "0x53a98" to read the system The code in the contract) to realize the functional supplement of the chain code.
  • the first blockchain node can read the code of the system contract, and the above-mentioned receipt data storage logic related to the exposed identifier is defined in the code of the system contract; then, the first blockchain node can execute the system contract
  • the code based on the above-mentioned receipt data storage logic related to the exposure identifier, stores at least a part of the receipt content in the receipt data corresponding to the object marked by the exposure identifier in plain text, and the rest of the receipt data in cipher text.
  • the system contract read by the first blockchain node may include a preset system contract configured in the genesis block of the blockchain network; and, the administrator in the blockchain network (ie, the above-mentioned management user) may have The update authority of the system contract, so as to update the preset system contract such as the above, the system contract read by the first blockchain node may also include the corresponding updated system contract.
  • the updated system contract can be obtained by the administrator after one update of the preset system contract; or, the updated system contract can be obtained by the administrator after multiple iterations of the preset system contract, such as the preset system contract Update the system contract 1, update the system contract 1 to obtain the system contract 2, update the system contract 2 to obtain the system contract 3.
  • the system contract 1, the system contract 2, and the system contract 3 can all be regarded as the updated system contract, but the first Blockchain nodes usually follow the latest version of the system contract. For example, the first blockchain node will follow the code in system contract 3 instead of the code in system contract 1 or system contract 2.
  • the administrator can also publish system contracts in subsequent blocks and update the published system contracts.
  • system contracts in subsequent blocks and update the published system contracts.
  • a certain degree of restrictions should be imposed on the issuance and update of system contracts through methods such as authority management to ensure that the functional logic of the blockchain network can operate normally and avoid unnecessary losses to any users.
  • the receiving unit 51 receives an encrypted transaction corresponding to a smart contract, the code of the smart contract includes an object marked by an exposed identifier;
  • the decryption unit 52 decrypts the transaction in a trusted execution environment to obtain the code of the smart contract
  • the execution unit 53 executes the code of the smart contract in the trusted execution environment to obtain receipt data
  • the storage unit 54 stores the receipt data so that at least part of the receipt content corresponding to the object indicated by the exposure identifier is stored in plain text, and the rest of the receipt content is stored in cipher text.
  • the smart contract corresponding to the transaction received by the first blockchain node includes:
  • the device when the smart contract corresponding to the transaction received by the first blockchain node is a smart contract written in a high-level language, the device further includes:
  • the compiling unit 55 compiles the smart contract written in the high-level language through a compiler, and generates the smart contract in the form of bytecode for execution in the trusted execution environment.
  • the smart contract in the form of bytecode is a smart contract written in a high-level language by the client through a compiler It is obtained by compiling, and the smart contract written in the high-level language is written by the user on the client.
  • the smart contract written in the high-level language and the smart contract in bytecode form have the same or corresponding exposure identifier.
  • the smart contract corresponding to the transaction received by the first blockchain node includes:
  • the smart contract generated by the user on the first blockchain node or,
  • the smart contract generated by the user on the client or,
  • the objects indicated by the exposure identifier include: receipt fields and/or state variables.
  • the objects indicated by the exposure identifier include: contract-level objects applicable to all events defined in the smart contract; the storage unit 54 is specifically configured to:
  • At least a part of the receipt content corresponding to the contract-level object in the receipt data is stored in plain text.
  • the objects indicated by the exposure identifier include: event-level objects corresponding to at least one event defined in the smart contract; the storage unit 54 is specifically configured to:
  • the receipt content corresponding to the at least one event in the receipt data is determined, and at least a part of the determined receipt content corresponding to the event-level object is stored in plaintext.
  • the storage unit 54 is specifically configured to:
  • the receipt data is stored so that the transaction initiator belongs to the preset user type
  • at least part of the receipt content corresponding to the object indicated by the exposure identifier is stored in plain text
  • the rest of the receipt content is stored in cipher text.
  • the storage unit 54 determines the user type to which the transaction initiator belongs in the following manner:
  • the external account includes a user type field recorded on the blockchain, and the value of the user type field corresponds to the user type.
  • the user type is configured to be associated with the external account, so that the association relationship between the user type and the external account is recorded in the blockchain.
  • Optional also includes:
  • the changing unit 56 changes the user type corresponding to the external account according to the change request initiated by the management user.
  • the at least part of the receipt content stored in plaintext includes at least one of the following:
  • the at least a part of the receipt content corresponds to the exposed field indicated by the exposure identifier, and the exposed field matches the transaction type of the transaction;
  • the at least part of the receipt content is generated by a special event function included in the smart contract
  • the information contained in the at least part of the receipt content meets a preset condition.
  • the transaction includes a transaction type field, and the value of the transaction type field is used to indicate the corresponding transaction type.
  • a predefined mapping relationship between the transaction type and the exposed field is stored in the blockchain, and the mapping relationship is used to determine the exposed field corresponding to the transaction type of the transaction.
  • the transaction type of the transaction includes: deposit certificate type, asset transfer type, contract creation type, contract call type.
  • the event function in the smart contract includes a type identifier, and the type identifier is used to mark the event function as a special event function.
  • the event function included in the smart contract is in the special function list recorded on the blockchain, the event function included in the smart contract is determined to be a special event function.
  • the preset condition includes at least one of the following: the corresponding receipt content includes the preset content, and the value of the corresponding receipt content belongs to the preset numerical interval.
  • the preset conditions include general conditions corresponding to all receipt fields in the receipt data; or,
  • the preset condition includes a dedicated condition corresponding to each receipt field in the receipt data.
  • the preset condition is in the transaction; or,
  • the preset condition is located in the smart contract corresponding to the transaction, or in another smart contract called by the smart contract corresponding to the transaction; or,
  • the preset conditions are located in the system contract or chain code.
  • the storage unit 54 is specifically configured to:
  • the code of the system contract is executed so that at least part of the receipt content corresponding to the object indicated by the exposure identifier is stored in plain text, and the rest of the receipt content is stored in cipher text.
  • the system contract includes: a preset system contract recorded in the genesis block, or an updated system contract corresponding to the preset system contract.
  • the storage unit 54 is specifically configured to:
  • the storage function code is executed outside the trusted execution environment to store the receipt data in an external storage space outside the trusted execution environment.
  • the transaction is used to create and/or call the smart contract.
  • the key used by the first blockchain node to encrypt the receipt field includes: a key of a symmetric encryption algorithm or a key of an asymmetric encryption algorithm.
  • the key of the symmetric encryption algorithm includes an initial key provided by the client; or, the key of the symmetric encryption algorithm includes a derived key generated by the initial key and an influence factor.
  • 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 52 is specifically configured to:
  • the first blockchain node decrypts the private key of the asymmetric encryption algorithm to obtain the initial key, and uses the initial key to decrypt the transaction to obtain the code of the smart contract.
  • the initial key is generated by the client; or, the initial key is sent to the client by the key management server.
  • the impact factor is related to the transaction.
  • the impact factor includes: a designated bit of the hash value of the transaction.
  • a programmable logic device Programmable Logic Device, PLD
  • FPGA Field Programmable Gate Array
  • HDL Hardware Description Language
  • ABEL Advanced Boolean Expression Language
  • AHDL Altera Hardware Description Language
  • HDCal JHDL
  • Lava Lava
  • Lola MyHDL
  • PALASM RHDL
  • Verilog Verilog
  • the controller can be implemented in any suitable manner.
  • the controller can take the form of, for example, a microprocessor or a processor and a computer-readable medium storing computer-readable program codes (such as software or firmware) executable by the (micro)processor. , Logic gates, switches, application specific integrated circuits (ASICs), programmable logic controllers and embedded microcontrollers.
  • controllers include but are not limited to the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20 and Silicon Labs C8051F320, the memory controller can also be implemented as a part of the memory control logic.
  • controller in addition to implementing the controller in a purely computer-readable program code manner, it is entirely possible to program the method steps to make the controller use logic gates, switches, application specific integrated circuits, programmable logic controllers and embedded The same function can be realized in the form of a microcontroller, etc. Therefore, such a controller can be regarded as a hardware component, and the devices included in it for implementing various functions can also be regarded as a structure within the hardware component. Or even, the device for realizing various functions can be regarded as both a software module for realizing the method and a structure within a hardware component.
  • a typical implementation device is a computer.
  • the computer may be, for example, a personal computer, a laptop computer, a cell phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or Any combination of these devices.
  • the embodiments of the present invention may be provided as methods, systems, or computer program products. Therefore, the present invention may adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Moreover, the present invention may adopt the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program codes.
  • a computer-usable storage media including but not limited to disk storage, CD-ROM, optical storage, etc.
  • program modules include routines, programs, objects, components, data structures, etc. that perform specific tasks or implement specific abstract data types.
  • This specification can also be practiced in distributed computing environments, in which tasks are performed by remote processing devices connected through a communication network.
  • program modules can be located in local and remote computer storage media including storage devices.
  • These computer program instructions can also be stored in a computer-readable memory that can guide a computer or other programmable data processing equipment to work in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture including the instruction device.
  • the device implements the functions specified in one process or multiple processes in the flowchart and/or one block or multiple blocks in the block diagram.
  • These computer program instructions can also be loaded on a computer or other programmable data processing equipment, so that a series of operation steps are executed on the computer or other programmable equipment to produce computer-implemented processing, so as to execute on the computer or other programmable equipment.
  • the instructions provide steps for implementing functions specified in a flow or multiple flows in the flowchart and/or a block or multiple blocks in the block diagram.
  • the computer includes one or more processors (CPU), input/output interfaces, network interfaces, and memory.
  • the memory may include non-permanent memory in computer readable media, random access memory (RAM) and/or non-volatile memory, such as read-only memory (ROM) or flash memory (flash RAM). Memory is an example of computer readable media.
  • RAM random access memory
  • ROM read-only memory
  • flash RAM flash memory
  • Computer-readable media include permanent and non-permanent, removable and non-removable media, and information storage can be realized by any method or technology.
  • the information can be computer-readable instructions, data structures, program modules, or other data.
  • Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, CD-ROM, digital versatile disc (DVD) or other optical storage, Magnetic cassettes, magnetic disk storage, quantum memory, graphene-based storage media or other magnetic storage devices or any other non-transmission media can be used to store information that can be accessed by computing devices. According to the definition in this article, computer-readable media does not include transitory media, such as modulated data signals and carrier waves.
  • first, second, third, etc. may be used in one or more embodiments of this specification to describe various information, the information should not be limited to these terms. These terms are only used to distinguish the same type of information from each other.
  • first information may also be referred to as second information, and similarly, the second information may also be referred to as first information.
  • word “if” as used herein can be interpreted as "when” or “when” or "in response to determination”.

Abstract

本说明书一个或多个实施例提供一种基于代码标注的对象级收据存储方法和节点，该方法可以包括：第一区块链节点接收经过加密的对应于智能合约的交易，所述智能合约的代码中包括通过暴露标识符标明的对象；第一区块链节点在可信执行环境中解密所述交易，以获得所述智能合约的代码；第一区块链节点在所述可信执行环境中执行所述智能合约的代码，得到收据数据；第一区块链节点存储所述收据数据，使所述暴露标识符标明的对象对应的至少一部分收据内容以明文形式存储、其余收据内容以密文形式存储。

Description

基于代码标注的对象级收据存储方法和节点 技术领域
本说明书一个或多个实施例涉及区块链技术领域，尤其涉及一种基于代码标注的对象级收据存储方法和节点。
背景技术
区块链技术构建在传输网络(例如点对点网络)之上。传输网络中的网络节点利用链式数据结构来验证与存储数据，并采用分布式节点共识算法来生成和更新数据。
目前企业级的区块链平台技术上最大的两个挑战就是隐私和性能，往往这两个挑战很难同时解决。大多解决方案都是通过损失性能换取隐私，或者不大考虑隐私去追求性能。常见的解决隐私问题的加密技术，如同态加密(Homomorphic encryption)和零知识证明(Zero-knowledge proof)等复杂度高，通用性差，而且还可能带来严重的性能损失。
可信执行环境(Trusted Execution Environment,TEE)是另一种解决隐私问题的方式。TEE可以起到硬件中的黑箱作用，在TEE中执行的代码和数据操作系统层都无法偷窥，只有代码中预先定义的接口才能对其进行操作。在效率方面，由于TEE的黑箱性质，在TEE中进行运算的是明文数据，而不是同态加密中的复杂密码学运算，计算过程效率没有损失，因此与TEE相结合可以在性能损失较小的前提下很大程度上提升区块链的安全性和隐私性。目前工业界十分关注TEE的方案，几乎所有主流的芯片和软件联盟都有自己的TEE解决方案，包括软件方面的TPM(Trusted Platform Module，可信赖平台模块)以及硬件方面的Intel SGX(Software Guard Extensions,软件保护扩展)、ARM Trustzone(信任区)和AMD PSP(Platform Security Processor，平台安全处理器)。
发明内容
有鉴于此，本说明书一个或多个实施例提供一种基于代码标注的对象级收据存储方法和节点。
为实现上述目的，本说明书一个或多个实施例提供技术方案如下：
根据本说明书一个或多个实施例的第一方面，提出了一种基于代码标注的对象级收据存储方法，包括：
第一区块链节点接收经过加密的对应于智能合约的交易，所述智能合约的代码中包括通过暴露标识符标明的对象；
第一区块链节点在可信执行环境中解密所述交易，以获得所述智能合约的代码；
第一区块链节点在所述可信执行环境中执行所述智能合约的代码，得到收据数据；
第一区块链节点存储所述收据数据，使所述暴露标识符标明的对象对应的至少一部分收据内容以明文形式存储、其余收据内容以密文形式存储。
根据本说明书一个或多个实施例的第二方面，提出了一种基于代码标注的对象级收据存储节点，包括：
接收单元，接收经过加密的对应于智能合约的交易，所述智能合约的代码中包括通过暴露标识符标明的对象；
解密单元，在可信执行环境中解密所述交易，以获得所述智能合约的代码；
执行单元，在所述可信执行环境中执行所述智能合约的代码，得到收据数据；
存储单元，存储所述收据数据，使所述暴露标识符标明的对象对应的至少一部分收据内容以明文形式存储、其余收据内容以密文形式存储。
根据本说明书一个或多个实施例的第三方面，提出了一种电子设备，包括：
处理器；
用于存储处理器可执行指令的存储器；
其中，所述处理器通过运行所述可执行指令以实现如第一方面所述的方法。
根据本说明书一个或多个实施例的第四方面，提出了一种计算机可读存储介质，其上存储有计算机指令，该指令被处理器执行时实现如第一方面所述方法的步骤。
附图说明
图1是一示例性实施例提供的一种创建智能合约的示意图。
图2是一示例性实施例提供的一种调用智能合约的示意图。
图3是一示例性实施例提供的一种基于代码标注的对象级收据存储方法的流程图。
图4是一示例性实施例提供的一种在区块链节点上实现隐私保护的示意图。
图5是一示例性实施例提供的一种基于代码标注的对象级收据存储节点的框图。
具体实施方式
这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本说明书一个或多个实施例相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本说明书一个或多个实施例的一些方面相一致的装置和方法的例子。
需要说明的是：在其他实施例中并不一定按照本说明书示出和描述的顺序来执行相应方法的步骤。在一些其他实施例中，其方法所包括的步骤可以比本说明书所描述的更多或更少。此外，本说明书中所描述的单个步骤，在其他实施例中可能被分解为多个步骤进行描述；而本说明书中所描述的多个步骤，在其他实施例中也可能被合并为单个步骤进行描述。
区块链一般被划分为三种类型：公有链(Public Blockchain)，私有链(Private Blockchain)和联盟链(Consortium Blockchain)。此外，还有多种类型的结合，比如私有链+联盟链、联盟链+公有链等不同组合形式。其中去中心化程度最高的是公有链。公有链以比特币、以太坊为代表，加入公有链的参与者可以读取链上的数据记录、参与交易以及竞争新区块的记账权等。而且，各参与者(即节点)可自由加入以及退出网络，并进行相关操作。私有链则相反，该网络的写入权限由某个组织或者机构控制，数据读取权限受组织规定。简单来说，私有链可以为一个弱中心化系统，参与节点具有严格限制且少。这种类型的区块链更适合于特定机构内部使用。联盟链则是介于公有链以及私有链之间的区块链，可实现“部分去中心化”。联盟链中各个节点通常有与之相对应的实体机构或者组织；参与者通过授权加入网络并组成利益相关联盟，共同维护区块链运行。
不论是公有链、私有链还是联盟链，都可能提供智能合约的功能。区块链上的智能 合约是在区块链系统上可以被交易触发执行的合约。智能合约可以通过代码的形式定义。
以以太坊为例，支持用户在以太坊网络中创建并调用一些复杂的逻辑，这是以太坊区别于比特币区块链技术的最大挑战。以太坊作为一个可编程区块链的核心是以太坊虚拟机(EVM)，每个以太坊节点都可以运行EVM。EVM是一个图灵完备的虚拟机，这意味着可以通过它实现各种复杂的逻辑。用户在以太坊中发布和调用智能合约就是在EVM上运行的。实际上，虚拟机直接运行的是虚拟机代码(虚拟机字节码，下简称“字节码”)。部署在区块链上的智能合约可以是字节码的形式。
例如图1所示，Bob将一个包含创建智能合约信息的交易发送到以太坊网络后，节点1的EVM可以执行这个交易并生成对应的合约实例。图中1中的“0x6f8ae93…”代表了这个合约的地址，交易的data字段保存的可以是字节码，交易的to字段为空。节点间通过共识机制达成一致后，这个合约成功创建，并且可以在后续过程中被调用。合约创建后，区块链上出现一个与该智能合约对应的合约账户，并拥有一个特定的地址，合约代码将保存在该合约账户中。智能合约的行为由合约代码控制。换句话说，智能合约使得区块链上产生包含合约代码和账户存储(Storage)的虚拟账户。
如图2所示，仍以以太坊为例，Bob将一个用于调用智能合约的交易发送到以太坊网络后，某一节点的EVM可以执行这个交易并生成对应的合约实例。图中2中交易的from字段是交易发起方(即Bob)的账户的地址，to字段中的“0x6f8ae93…”代表了被调用的智能合约的地址，value字段在以太坊中是以太币的值，交易的data字段保存的调用智能合约的方法和参数。智能合约以规定的方式在区块链网络中每个节点独立的执行，所有执行记录和数据都保存在区块链上，所以当交易完成后，区块链上就保存了无法篡改、不会丢失的交易凭证。
区块链网络中的节点在执行Bob发起的交易后，会生成相应的收据(receipt)数据，以用于记录该交易相关的收据信息。以以太坊为例，节点执行交易所得的收据数据可以包括如下内容：
Result字段，表示交易的执行结果；
Gas used字段，表示交易消耗的gas值；
Logs字段，表示交易产生的日志，日志可以进一步包括From字段、To字段、Topic字段和Log data字段等，其中From字段表示调用的发起方的账户地址、To字段表示被 调用对象(如智能合约)的账户地址、Topic字段表示日志的主题、Log data字段表示日志数据；
Output字段，表示交易的输出。
一般的，交易执行后生成的收据数据以明文形式进行存储，任何人都可以看到收据数据所含的上述各个收据字段的内容，无隐私保护的设置和能力。而在一些区块链与TEE相结合的解决方案中，为了实现隐私保护，收据数据的全部内容均被当作需要隐私保护的数据存储在区块链上。所述区块链，是存储在节点的数据库中特定逻辑组织而成的数据集合。所述数据库，如后所述，其物理载体可以存储介质，例如持久性存储介质。实际上，收据数据中可能只有部分内容是敏感的，而其它内容并不敏感，只需要针对敏感的内容进行隐私保护、其他内容可以公开，甚至在一些情况下可能需要对部分内容实施检索以驱动相关操作的实施，那么针对这部分内容实施隐私保护将影响检索操作的实施。
在本说明书的技术方案中，通过在智能合约的代码中添加暴露标识符，可以对存在明文存储需求的对象进行标注，从而将暴露标识符标明的对象对应的所有收据内容以明文形式存储、而未由暴露标识符进行标注的其他对象对应的其余收据内容以密文形式存储；或者，通过对暴露标识符标明的对象对应的收据内容进行筛选，第一区块链节点可以仅对筛选出的收据内容以明文形式存储，而未筛选出的收据内容和未由暴露标识符进行标注的其他对象对应的其余收据内容均以密文形式存储。进一步的，第一区块链节点可以确定交易发起方所属的用户类型，从而在交易发起方属于预设用户类型的情况下，采用上述的针对收据数据进行明文与密文混合存储的方案，否则对所有收据数据均采用密文形式存储。总之，本说明书能够基于上述技术方案，使得暴露标识符标明的对象对应的至少一部分收据内容以明文形式存储，而智能合约所产生的其余收据内容以密文形式存储。
以下结合图3所示说明本申请一基于代码标注的对象级收据存储方法的实施例，该实施例仅考量暴露标识符；该实施例的实现过程包括以下步骤：
步骤302，第一区块链节点接收经过加密的对应于智能合约的交易，所述智能合约的代码中包括通过暴露标识符标明的对象。
在一实施例中，用户在编写智能合约的代码时，可以通过在代码中添加暴露标识符来标明一个或多个对象，使得收据数据中对应于这部分对象的收据内容能够采用明文存 储，那么剩余未标注暴露标识符的对象所对应的收据内容需要采用密文存储，以实现相应的隐私保护。
在一实施例中，收据数据中对应于上述对象的所有收据内容均采用明文存储，而剩余未标注暴露标识符的对象所对应的收据内容需要采用密文存储。其中，可以仅根据暴露标识符对收据数据进行存储，使得第一区块链节点确定出暴露标识符所表明的对象后，总是将收据数据中对应于这些对象的所有收据内容均采用明文存储、将剩余未标注暴露标识符的对象所对应的收据内容采用密文存储；或者，第一区块链节点可以结合上述交易的交易发起方所属的用户类型，并在该交易发起方属于预设用户类型的情况下，将收据数据中对应于这些对象的所有收据内容均采用明文存储、将剩余未标注暴露标识符的对象所对应的收据内容采用密文存储，否则(即交易发起方不属于上述的预设用户类型)对所有收据数据均采用密文存储。
第一区块链节点根据暴露标识符所表明的对象，可以确定出收据数据中对应于这些对象的收据内容，并且第一区块链节点可以对这些收据内容做进一步筛选，从而仅针对筛选出的收据内容采用明文存储，而未被筛选出的收据内容和未标注暴露标识符的对象所对应的收据内容均采用密文存储。进一步的，此处同样可以结合上述的交易发起方所属的用户类型，从而仅在交易发起方属于预设用户类型的情况下，针对筛选出的收据内容采用明文存储，而未被筛选出的收据内容和未标注暴露标识符的对象所对应的收据内容均采用密文存储，否则对所有收据数据均采用密文存储。其中，筛选条件可以包括下述至少之一：所述至少一部分收据内容对应于所述暴露标识符标明的暴露字段，所述暴露字段与所述交易的交易类型相匹配；所述至少一部分收据内容由所述智能合约所含的特殊事件函数所产生；所述至少一部分收据内容所含的信息满足预设条件等，本说明书并不对此进行限制。
如上文所述，在用于创建智能合约的交易中，data字段保存的可以是该智能合约的字节码。字节码由一连串的字节组成，每一字节可以标识一个操作。基于开发效率、可读性等多方面考虑，开发者可以不直接书写字节码，而是选择一门高级语言编写智能合约代码。高级语言编写的智能合约的代码，经过编译器编译而生成字节码，进而该字节码可以部署到区块链上。以太坊支持的高级语言很多，如Solidity、Serpent、LLL语言等。
以Solidity语言为例，用其编写的合约与面向对象编程语言中的类(Class)很相似，在一个合约中可以声明多种成员，包括状态变量、函数、函数修改器、事件等。如下是 以Solidity语言编写的一个简单的智能合约的代码示例1：
Figure PCTCN2020089381-appb-000001
在基于Solidity语言编写的智能合约的代码中，可以通过暴露标识符来标明一个或多个对象，使得收据数据中对应于这部分对象的收据内容能够以明文形式存储，而其余的收据内容以密文形式存储。类似地，在基于Serpent、LLL语言等编写的智能合约的代码中，同样可以通过暴露标识符来标明一个或多个对象，以实现相关收据内容的明文存储。
暴露标识符可以为专用于表明需要明文存储的收据字段，例如可以采用关键字plain来表征该暴露标识符。那么，对于希望以明文形式存储的收据内容，可以在相应的对象之前添加plain(或者，也可以采用其他方式与相应的对象进行关联)。
暴露标识符标明的对象可以包括收据字段，比如上文所述的Result字段、Gas used字段、Logs字段、Output字段等，或者Logs字段中进一步包含的From字段、To字段、Topic字段、Log data字段等。例如，可以将上述的代码示例1调整为下述的代码示例2：
Figure PCTCN2020089381-appb-000002
在上述的代码示例2中，通过在智能合约的代码最前方添加暴露标识符plain，使得智能合约的代码被执行后，产生的收据数据中的所有字段均以明文形式进行存储。
当然，在其他实施例中，也可以具体指明需要明文存储的字段。比如，通过暴露标识符对From字段进行标注时，可使得智能合约的代码被执行后，产生的收据数据中的From字段对应的收据内容以明文形式进行存储，那么后续可以针对该From字段中的收据内容实施检索操作，比如可以统计某一账户所发起的交易量等。
需要指出的是：在上述的代码示例2及其相关实施例中，由暴露标识符“plain”所标明的对象(所有字段或From字段)为合约级对象，使得第一区块链节点在存储收据数据时，将收据数据中对应于该合约级对象的所有收据内容以明文形式存储。尤其是，当智能合约的代码中包含多个事件时，合约级对象可以适用于智能合约中的所有事件，那么以From字段为例：当多个事件分别产生各自对应的Logs字段时，每一Logs字段所含的From字段均会采用明文形式进行存储，而无需针对每一事件分别添加暴露标识符。
除了收据字段之外，暴露标识符还可以用于标明其他对象。例如，暴露标识符标明的对象可以包括状态变量，且该状态变量同样可以为合约级对象。以状态变量“price”为例，可以将上述的代码示例1调整为下述的代码示例3：
Figure PCTCN2020089381-appb-000003
在上述的代码示例3中，通过在状态变量“price”的类型int之前添加暴露标识符“plain”(或者，可以将暴露标识符plain置于类型int之后)，使得智能合约的代码被执行后，在产生的收据数据的各个字段(通常包括Topic字段、Output字段等)中，与状态变量“price”相关的收据内容均以明文形式进行存储，那么后续可以针对与状态变量“price”相关的收据内容实施检索操作。由于状态变量“price”在代码示例3中属于 合约级对象，使得当智能合约的代码中包含多个事件时，合约级对象可以适用于智能合约中的所有事件，那么当多个事件分别产生各自对应的Logs字段时，每一Logs字段(如Logs字段中的Topic字段)均会采用明文形式存储与状态变量“price”相关的收据内容，Output字段等也会采用明文形式存储与状态变量“price”相关的收据内容，无需在每一事件中分别针对状态变量“price”添加暴露标识符。
当智能合约的代码中定义了多个状态变量时，上述的合约级对象可以包括其中的部分或全部状态变量。例如，智能合约可以包括下述的代码示例4：
Figure PCTCN2020089381-appb-000004
在上述的代码示例4中，智能合约的代码中定义了“price”、“price1”等多个状态变量，而用户可以仅针对状态变量“price”添加暴露标识符plain，使得该状态变量“price”成为合约级对象，而状态变量“price1”则并未由暴露标识符进行标注。
除了合约级对象之外，暴露标识符标明的对象可以包括：对应于智能合约中定义的至少一个事件的事件级对象，使得第一区块链节点在存储收据数据时，确定出收据数据中对应于该至少一个事件的收据内容，并将确定出的收据内容中对应于事件级对象的部分以明文形式存储。尤其是，当智能合约中包含多个事件时，可以针对至少一部分事件设定上述的事件级对象，使得这部分事件对应的收据内容以明文形式存储、其余事件对应的收据内容以密文形式存储。以From字段为例，可以将上述的代码示例1调整为下述的代码示例5：
Figure PCTCN2020089381-appb-000005
Figure PCTCN2020089381-appb-000006
在上述的代码示例5中，通过在事件currentPrice对应的事件函数“event currentPrice(int price)”中添加From字段对应的字符from，并且该字符from所采用的暴露标识符区别于前述的plain，而是通过引号对该字符from进行修饰，则代码示例5中的引号相当于前述的暴露标识符，将From字段配置为事件级对象，使得在该事件对应产生的Logs字段中，From字段将以明文形式进行存储。除了上述事件currentPrice之外，如果智能合约的代码还包含另一事件，那么上述的字符from不会影响该另一事件、该另一事件对应的收据内容将以密文形式进行存储，除非存在针对该另一事件而添加的“from”。
事件级对象还可以包括状态变量。以状态变量“price”为例，可以将上述的代码示例1调整为下述的代码示例6：
Figure PCTCN2020089381-appb-000007
在上述的代码示例6中，通过在事件currentPrice对应的事件函数“event currentPrice(int price)”之前添加暴露标识符“plain”，而区别于代码示例5中添加的“from”，使得此处并未指明事件级对象为From字段，那么：
一种情况下，事件级对象可以包括字段，这与上述的From字段相类似。但是，由于未指明具体的字段，可以将事件currentPrice所产生的日志中的所有字段均作为上 述的事件级对象，譬如前述的From字段、To字段、Topic字段、Log Data字段等，相当于将该事件currentPrice对应的所有收据内容均以明文形式存储。
另一种情况下，事件级对象可以包括状态变量。例如，上述的代码示例6中定义了状态变量“price”，并且事件currentPrice引用了该状态变量“price”，对应于在事件函数“event currentPrice(int price)”之前添加暴露标识符“plain”，可以将状态变量“price”作为上述的事件级对象，使得该事件产生的所有与状态变量“price”相关的收据内容均以明文形式进行存储。由于状态变量“price”在代码示例6中属于事件级对象，使得当智能合约的代码中还包含另一引用状态变量“price”的事件event1时，如果并未针对该事件event1添加任何级别的暴露标识符，那么即便该事件event1引用了状态变量“price”，该事件event1所产生的收据内容仍将以密文形式进行存储，而并非以明文形式存储。
当同一事件中引用了多个状态变量时，上述的事件级对象可以包括被引用的全部状态变量。例如，可以将上述的代码示例4调整为下述的代码示例7：
Figure PCTCN2020089381-appb-000008
在上述的代码示例7中，事件currentPrice对应的事件函数“event currentPrice(int price,int price1)”之前添加关键字“plain”，使得该事件对应的所有收据内容均以明文形式存储。譬如，该事件引用了状态变量“price”和“price1”，使得状态变量“price”和“price1”均会受到影响，那么该事件产生的所有与状态变量“price”和“price1”相关的收据内容均以明文形式进行存储。但是，对于其他并未添加暴露标识符plain的事件，产生的收据内容均以密文形式进行存储。
当事件级对象包括状态变量时，还可以具体指示为事件所引用的一个或多个状 态变量。以状态变量“price”为例，可以将上述的代码示例1调整为下述的代码示例8：
Figure PCTCN2020089381-appb-000009
在上述的代码示例8中，事件currentPrice对应的事件函数“event currentPrice(int price)”引用了状态变量“price”，而通过在该状态变量“price”的类型int之前添加暴露标识符plain，使得该状态变量“price”被配置为事件级对象，该事件级对象仅适用于该事件currentPrice、不适用于智能合约包含的其他事件，即：只有事件currentPrice产生的与状态变量“price”相关的收据内容以明文形式进行存储，除非其他事件中也针对状态变量“price”添加了暴露标识符，否则其他事件即便应用了该状态变量“price”，产生的收据内容仍以密文形式进行存储。
由于代码示例8中的事件currentPrice仅应用了状态变量“price”，使其实际效果与上述的代码示例6中针对该事件添加暴露标识符、将该事件引用的状态变量“price”配置为事件级对象相似。而当事件同时应用多个状态变量时，可以更加清晰地体现出两者的不同，比如可以将上述的代码示例4调整为下述的代码示例9：
Figure PCTCN2020089381-appb-000010
Figure PCTCN2020089381-appb-000011
在上述的代码示例9中，事件currentPrice同时引用了状态变量“price”和“price1”，而通过在状态变量“price”的类型int之前添加暴露标识符plain，可以将该状态变量“price”配置为事件级对象，而未添加暴露标识符plain的状态变量“price1”则并非事件级对象，使得该事件产生的与状态变量“price”相关的收据内容以明文形式进行存储、与状态变量“price1”相关的收据内容仍以密文形式进行存储。
在一实施例中，第一区块链节点接收的交易对应的智能合约，可以是通过高级语言编写的智能合约，或者可以是字节码形式的智能合约。其中，当智能合约为高级语言编写的智能合约时，第一区块链节点还通过编译器对该高级语言编写的智能合约进行编译，生成字节码形式的智能合约，以在可信执行环境中执行。而当第一区块链节点接收的交易对应的智能合约为字节码形式的智能合约时，该字节码形式的智能合约可由客户端通过编译器对高级语言编写的智能合约进行编译而得到，而该高级语言编写的智能合约由用户在客户端上编写得到。
对于第一区块链节点接收的交易对应的智能合约，可以为用户在第一区块链节点上生成的智能合约。当用户采用高级语言编写得到上述的智能合约时，第一区块链节点还通过编译器将该高级语言编写的智能合约编译为字节码形式的智能合约；或者，用户也可能在第一区块链节点上直接编写得到字节码形式的智能合约。
对于第一区块链节点接收的交易对应的智能合约，可以为用户在客户端上生成的智能合约。例如，用户通过对应的账户在客户端生成该交易后，通过该客户端将交易提交至第一区块链节点。以图4为例，第一区块链节点中包含交易/查询接口，该接口可与客户端对接，使得客户端可以向第一区块链节点提交上述交易。比如上文所述，用户可以采用高级语言在客户端上编写智能合约，然后由客户端通过编译器对该高级语言的智能合约进行编译，得到相应的字节码形式的智能合约。当然，客户端可以直接将高级语言编写的智能合约发送至第一区块链节点，使得第一区块链节点通过编译器编译为字节码形式的智能合约。
对于第一区块链节点接收的交易对应的智能合约，可以为客户端通过第二区块链节点发来的交易中的智能合约，该智能合约通常为字节码形式；当然，该智能合约也可以为高级语言编写的智能合约，则第一区块链节点可以通过编译器编译为字节码形式的智能合约。
在一实施例中，当智能合约的代码中包括暴露标识符时，高级语言编写的智能 合约与字节码形式的智能合约可以具有相同的暴露标识符。而本领域技术人员应当理解的是：字节码可以采用不同于高级语言的暴露标识符，比如高级语言编写的智能合约的代码中包含第一标识符、字节码形式的智能合约的代码中包含第二标识符，则第一标识符与第二标识符之间存在对应关系，确保由高级语言编译为字节码后，不会影响暴露标识符的功能。
步骤304，第一区块链节点在可信执行环境中解密所述交易，以获得所述智能合约的代码。
在一实施例中，上述交易可以通过对称加密算法的方式进行加密，也可以采用非对称算法的方式进行加密。对称加密采用的加密算法，例如是DES算法，3DES算法，TDEA算法，Blowfish算法，RC5算法，IDEA算法等。非对称加密算法，例如是RSA、Elgamal、背包算法、Rabin、D-H、ECC(椭圆曲线加密算法)等。
在一实施例中，上述交易可以通过对称加密算法结合非对称加密算法的方式进行加密。以客户端将上述交易提交至第一区块链节点为例，客户端可以采用对称加密算法加密交易内容，即采用对称加密算法的密钥加密交易内容，并用非对称加密算法加密对称加密算法中采用的密钥，譬如采用非对称加密算法的公钥加密对称加密算法中采用的密钥。这样，第一区块链节点接收到加密的交易后，可以先采用非对称加密算法的私钥进行解密，得到对称加密算法的密钥，进而用对称加密算法的密钥解密得到交易内容。例如，当交易用于创建智能合约时，交易内容可以包括所需创建的智能合约的代码；当交易用于调用智能合约时，交易内容可以包括被调用的智能合约的账户地址、需要传入的方法和参数等。
当交易用于调用智能合约时，可以是多重嵌套结构的调用。例如，交易直接调用智能合约1，而该智能合约1的代码调用了智能合约2，且智能合约2中的代码指向了智能合约3的合约地址，使得交易实际上间接调用了智能合约3的代码，而智能合约3中的代码可以包括通过暴露标识符标明的对象。这样，相当于智能合约1中包含了通过暴露标识符标明的对象。具体实现过程与上述过程类似，在此不再赘述。
步骤306，第一区块链节点在所述可信执行环境中执行所述智能合约的代码，得到收据数据。
如前所述，第一区块链节点接收的交易，例如可以是创建和/或调用智能合约的交易。比如在以太坊中，第一区块链节点接收到客户端发来的创建和/或调用智能合约的 交易后，可以检查交易是否有效、格式是否正确，验证交易的签名是否合法等。
一般来说，以太坊中的节点一般也是争夺记账权的节点，因此，第一区块链节点作为争夺记账权的节点可以在本地执行所述交易。如果争夺记账权的节点中的一个在本轮争夺记账权的过程中胜出，则成为记账节点。第一区块链节点如果在本轮争夺记账权的过程中胜出，就成为记账节点；当然，如果第一区块链节点如果在本轮争夺记账权的过程中没有胜出，则不是记账节点，而其它节点可能成为记账节点。
智能合约类似于面向对象编程中的类，执行的结果生成对应该智能合约的合约实例，类似于生成类对应的对象。执行交易中用于创建智能合约的代码的过程，会创建合约账户，并在账户空间中部署合约。以太坊中，智能合约账户的地址是由发送者的地址(如图1-2中的“0xf5e…”)和交易随机数(nonce)作为输入，通过加密算法生成的，比如图1-2中的合约地址“0x6f8ae93…”即由发送者的地址“0xf5e…”和交易中的nonce经加密算法生成。
一般的，采用工作量证明(Proof of Work,POW)以及股权证明(Proof of Stake，POS)、委任权益证明(Delegated Proof of Stake，DPOS)等共识算法的支持智能合约的区块链网络中，争夺记账权的节点都可以在接收到包含创建智能合约的交易后执行所述交易。争夺记账权的节点中可能其中一个在本轮争夺记账权的过程中胜出，成为记账节点。记账节点可以将该包含智能合约的交易与其它交易一起打包并生成新的区块，并将生成的新的区块发送至其它节点进行共识。
对于采用实用拜占庭容错(Practical Byzantine Fault Tolerance，PBFT)等机制的支持智能合约的区块链网络中，具有记账权的节点在本轮记账前已经商定好。因此，第一区块链节点接收到上述交易后，如果自身不是本轮的记账节点，则可以将该交易发送至记账节点。对于本轮的记账节点(可以是第一区块链节点)，在将该交易打包并生成新区块的过程中或者之前，或在将该交易与其它交易一起打包并生成新区块的过程中或者之前，可以执行该交易。所述记账节点将该交易打包(或还包括其它交易一起打包)并生成新的区块后，将生成的新的区块或者区块头发送至其它节点进行共识。
如上所述，采用POW机制的支持智能合约的区块链网络中，或者采用POS、DPOS、PBFT机制的支持智能合约的区块链网络中，本轮的记账节点都可以将该交易打包并生成新的区块，并将生成的新的区块后区块头发送至其它节点进行共识。如果其它节点接收到所述区块后经验证没有问题，可以将该新的区块追加到原有的区块链末尾，从而完成记账过程，达成共识；若交易用于创建智能合约，则完成了智能合约在区块链 网络上的部署，若交易用于调用智能合约，则完成了智能合约的调用和执行。其它节点验证记账节点发来的新的区块或区块头的过程中，也可以执行所述区块中的交易。
所述执行过程，一般可以通过虚拟机执行。以以太坊为例，支持用户在以太坊网络中创建和/或调用一些复杂的逻辑，这是以太坊区别于比特币区块链技术的最大挑战。以太坊作为一个可编程区块链的核心是以太坊虚拟机(EVM，Ethereum Virtual Machine)，每个以太坊节点都可以运行EVM。EVM是一个图灵完备的虚拟机，这意味着可以通过它实现各种复杂的逻辑。用户在以太坊中发布和调用智能合约就是在EVM上运行的。
本实施例中，第一区块链节点可以在可信执行环境(Trusted Execution Environment，TEE)中执行解密的智能合约的代码。例如图4所示，第一区块链节点可以划分为常规执行环境(图中位于左侧)和TEE，客户端提交的交易(如上文所述，交易可以存在其他来源；此处以客户端提交的交易为例进行说明)首先进入常规执行环境中的“交易/查询接口”进行识别，不存在隐私处理需求的交易可以被留在常规执行环境中进行处理(这里可以根据交易发起方的用户类型、交易类型、交易所含的标识符等识别是否存在隐私处理需求)，而将存在隐私处理需求的交易传递至TEE中进行处理。TEE与常规执行环境相互隔离。交易在进入TEE之前处于加密状态，在可信执行环境内则被解密为明文的交易内容，从而在确保数据安全的前提下，使得该明文的交易内容能够在TEE中实现高效处理，并在TEE中生成明文的收据数据。
TEE是基于CPU硬件的安全扩展，且与外部完全隔离的可信执行环境。TEE最早是由Global Platform提出的概念，用于解决移动设备上资源的安全隔离，平行于操作系统为应用程序提供可信安全的执行环境。ARM的Trust Zone技术最早实现了真正商用的TEE技术。伴随着互联网的高速发展，安全的需求越来越高，不仅限于移动设备，云端设备，数据中心都对TEE提出了更多的需求。TEE的概念也得到了高速的发展和扩充。现在所说的TEE相比与最初提出的概念已经是更加广义的TEE。例如，服务器芯片厂商Intel，AMD等都先后推出了硬件辅助的TEE并丰富了TEE的概念和特性，在工业界得到了广泛的认可。现在提起的TEE通常更多指这类硬件辅助的TEE技术。不同于移动端，云端访问需要远程访问，终端用户对硬件平台不可见，因此使用TEE的第一步就是要确认TEE的真实可信。因此现在的TEE技术都引入了远程证明机制，由硬件厂商(主要是CPU厂商)背书并通过数字签名技术确保用户对TEE状态可验证。同时仅仅是安全的资源隔离也无法满足的安全需求，进一步的数据隐私保护也被提 出。包括Intel SGX，AMD SEV在内的商用TEE也都提供了内存加密技术，将可信硬件限定在CPU内部，总线和内存的数据均是密文防止恶意用户进行窥探。例如，英特尔的软件保护扩展(SGX)等TEE技术隔离了代码执行、远程证明、安全配置、数据的安全存储以及用于执行代码的可信路径。在TEE中运行的应用程序受到安全保护，几乎不可能被第三方访问。
以Intel SGX技术为例，SGX提供了围圈(enclave，也称为飞地)，即内存中一个加密的可信执行区域，由CPU保护数据不被窃取。以第一区块链节点采用支持SGX的CPU为例，利用新增的处理器指令，在内存中可以分配一部分区域EPC(Enclave Page Cache，围圈页面缓存或飞地页面缓存)，通过CPU内的加密引擎MEE(Memory Encryption Engine)对其中的数据进行加密。EPC中加密的内容只有进入CPU后才会被解密成明文。因此，在SGX中，用户可以不信任操作系统、VMM(Virtual Machine Monitor，虚拟机监控器)、甚至BIOS(Basic Input Output System，基本输入输出系统)，只需要信任CPU便能确保隐私数据不会泄漏。实际应用中，可以将隐私数据加密后以密文形式传递至围圈中，并通过远程证明将对应的秘钥也传入围圈。然后，在CPU的加密保护下利用数据进行运算，结果会以密文形式返回。这种模式下，既可以利用强大的计算力，又不用担心数据泄漏。
当上述存在隐私处理需求的交易用于创建智能合约时，该交易中包含智能合约的代码，第一区块链节点可以在TEE中对该交易进行解密得到其所含智能合约的代码，并进而在TEE中执行该代码。当上述存在隐私处理需求的交易用于调用智能合约时，第一区块链节点可以在TEE中执行该代码(若被调用的智能合约处理加密状态，则需要先在TEE中对该智能合约进行解密，以得到相应的代码)。具体的，第一区块链节点可以利用CPU中新增的处理器指令，在内存中分配一部分区域EPC，通过CPU内的加密引擎MEE对上述的明文代码进行加密存入所述EPC中。EPC中加密的内容进入CPU后被解密成明文。在CPU中，对明文的代码进行运算，完成执行过程。例如，在SGX技术中，执行智能合约的明文代码，可以将EVM加载进围圈中。在远程证明过程中，密钥管理服务器可以计算本地EVM代码的hash值，并与第一区块链节点中加载的EVM代码的hash值比对，比对结果正确作为通过远程证明的一个必要条件，从而完成对第一区块链节点SGX围圈加载的代码的度量。经过度量，正确的EVM可以在SGX中执行上述智能合约的代码。
步骤308，第一区块链节点存储所述收据数据，使所述暴露标识符标明的对象对 应的收据内容以明文形式存储、其余收据内容以密文形式存储。
在一实施例中，第一区块链节点将暴露标识符标明的对象对应的收据内容以明文形式存储，并将其余收据内容以密文形式存储，可以灵活地针对收据数据进行明文存储或密文存储，使得采用密文形式存储的收据内容能够满足用户的隐私需求，而采用明文形式存储的收据内容能够满足用户的检索需求。例如，当收据数据中的日志(如整个Logs字段；或者，From字段、To字段、Topic字段、Log data字段中的至少一个)采用明文形式存储时，能够支持后续对该日志内容的检索，从而实现譬如基于日志内容的事件驱动，比如驱动DAPP(Decentralized Application，分布式应用)客户端执行相关处理操作等。
第一区块链节点通过密钥对未通过暴露标识符标明的对象对应的收据内容进行加密。所述加密，可以采用对称加密，也可以采用非对称加密。如果第一区块链节点用对称加密方式，即用对称加密算法的对称密钥对收据内容加密，则客户端(或其他持有密钥的对象)可以用该对称加密算法的对称密钥对加密后的收据内容进行解密。
第一区块链节点用对称加密算法的对称密钥对收据内容进行加密时，该对称密钥可由客户端预先提供至第一区块链节点。那么，由于只有客户端(实际应当为客户端上的已登录账户对应的用户)和第一区块链节点掌握该对称密钥，使得仅该客户端能够解密相应的加密后的收据内容，避免无关用户甚至不法分子对加密后的收据内容进行解密。
例如，客户端在向第一区块链节点发起交易时，客户端可以用对称加密算法的初始密钥对交易内容进行加密，以得到该交易；相应地，第一区块链节点可以通过获得该初始密钥，以用于直接或间接对收据内容进行加密。譬如，该初始密钥可以由客户端与第一区块链节点预先协商得到，或者由密钥管理服务器发送至客户端和第一区块链节点，或者由客户端发送至第一区块链节点。当初始密钥由客户端发送至第一区块链节点时，客户端可以通过非对称加密算法的公钥对该初始密钥进行加密后，将加密后的初始密钥发送至第一区块链节点，而第一区块链节点通过非对称加密算法的私钥对该加密后的初始密钥进行解密，得到初始密钥，即上文所述的数字信封加密，此处不再赘述。
第一区块链节点可以采用上述的初始密钥对收据内容进行加密。不同交易采用的初始密钥可以相同，使得同一用户所提交的所有交易均采用该初始密钥进行加密，或者不同交易采用的初始密钥可以不同，比如客户端可以针对每一交易随机生成一初始密钥，以提升安全性。
第一区块链节点可以根据初始密钥与影响因子生成衍生密钥，并通过该衍生密钥对收据内容进行加密。相比于直接采用初始密钥进行加密，衍生密钥可以增加随机度，从而提升被攻破的难度，有助于优化数据的安全保护。影响因子可以与交易相关；例如，影响因子可以包括交易哈希值的指定位，比如第一区块链节点可以将初始密钥与交易哈希值的前16位(或前32位、后16位、后32位，或者其他位)进行拼接，并对拼接后的字符串进行哈希运算，从而生成衍生密钥。
第一区块链节点还可以采用非对称加密方式，即用非对称加密算法的公钥对收据内容加密，则相应地，客户端可以用所述非对称加密算法的私钥解密上述加密后的收据内容。非对称加密算法的密钥，例如可以是由客户端生成一对公钥和私钥，并将公钥预先发送至第一区块链节点，从而第一区块链节点可以将收据内容用该公钥加密。
第一区块链节点通过运行用于实现某一功能的代码，以实现该功能。因此，对于需要在TEE中实现的功能，同样需要执行相关代码。而对于在TEE中执行的代码，需要符合TEE的相关规范和要求；相应地，对于相关技术中用于实现某一功能的代码，需要结合TEE的规范和要求重新进行代码编写，不仅存在相对更大的开发量，而且容易在重新编写过程中产生漏洞(bug)，影响功能实现的可靠性和稳定性。
因此，第一区块链节点可以通过在TEE之外执行存储功能代码，将TEE中生成的收据数据(包括需要明文存储的明文形式的收据内容，以及需要密文存储的密文形式的收据内容)存储至TEE之外的外部存储空间，使得该存储功能代码可以为相关技术中用于实现存储功能的代码、不需要结合TEE的规范和要求重新进行代码编写，即可针对收据数据实现安全可靠的存储，不仅可以在不影响安全、可靠程度的基础上，减少相关代码的开发量，而且可以通过减少TEE的相关代码而降低TCB(Trusted Computing Base，可信计算基)，使得TEE技术与区块链技术进行结合的过程中，额外造成的安全风险处于可控范围。
在一实施例中，第一区块链节点可以在TEE内执行写缓存功能代码，以将上述的收据数据存入TEE内的写缓存中，比如该写缓存可以对应于如图2所示的“缓存”。进一步的，第一区块链节点将写缓存中的数据从可信执行环境输出，以存储至外部存储空间。其中，写缓存功能代码可以以明文形式存储于TEE中，可以直接在TEE中执行该明文形式的缓存功能代码；或，写缓存功能代码可以以密文形式存储于TEE之外，比如存储于上述的外部存储空间(比如图2所示的“打包+存储”，其中“打包”表示第一区块链节点在可信执行环境之外对交易进行打包成块)，可以将该密文形式的写缓 存功能代码读入TEE、在TEE中进行解密为明文代码，并执行该明文代码。
写缓存是指在将数据写入外部存储空间时，为了避免造成对外部存储空间的“冲击”而提供的“缓冲”机制。例如，可以采用buffer实现上述的写缓存；当然，写缓存也可以采用cache来实现，本说明书并不对此进行限制。实际上，由于TEE为隔离的安全环境，而外部存储空间位于TEE之外，使得通过采用写缓存机制，可以对缓存内的数据进行批量写入外部存储空间，从而减少TEE与外部存储空间之间的交互次数，提升数据存储效率。同时，TEE在不断执行各条交易的过程中，可能需要调取已生成的数据，如果需调用的数据恰好位于写缓存中，可以直接从写缓存中读取该数据，这样一方面可以减少与外部存储空间之间的交互，另一方面免去了对从外部存储空间所读取数据的解密过程，从而提升在TEE中的数据处理效率。
当然，也可以将写缓存建立于TEE之外，比如第一区块链节点可以在TEE之外执行写缓存功能代码，从而将上述的收据数据存入TEE外的写缓存中，并进一步将写缓存中的数据存储至外部存储空间。
在图3所示实施例的基础上，本说明书可以进一步识别交易发起方的用户类型，从而同时根据暴露标识符和交易发起方的用户类型，确定对收据数据的存储方式。因此，上述的步骤308可以改进为：第一区块链节点存储所述收据数据，当交易发起方属于预设用户类型时，使所述暴露标识符标明的对象对应的收据内容以明文形式存储、其余收据内容以密文形式存储。换言之，除了暴露标识符之外，还需要识别交易发起方所属的用户类型，从而在交易发起方属于预设用户类型的情况下，才对暴露标识符标明的对象对应的收据内容以明文形式存储、其余收据内容(即未采用暴露标识符标明的对象所对应的收据内容)以密文形式存储，否则(即交易发起方不属于预设用户类型的情况下)所有收据内容均采用密文形式存储。
第一区块链节点通过识别交易发起方所属的用户类型，可以确定交易发起方的隐私保护需求的强烈程度：当属于预设用户类型时，可以确定该交易发起方的隐私保护需求相对较弱，能够接受收据数据在一定程度上的暴露，以实现相应的功能扩展；当不属于预设用户类型时，可以确定该交易发起方的隐私保护需求相对较强，无法接受对收据数据的暴露。因而，基于对交易发起方所属的用户类型的识别，可使针对收据数据的存储方式满足交易发起方的实际需求，能够兼顾隐私保护和功能扩展。例如，普通用户的隐私保护的需求相对更低、对基于收据数据的功能扩展需求相对更高，那么对于普通用户发起的交易所产生的收据数据，可以将相对更多的收据内容采用明文形式存储，以 便针对明文存储的收据内容实施功能扩展。再例如，高级用户的隐私保护的需求相对更高、对基于收据数据的功能扩展需求相对更低，那么对于高级用户发起的交易所产生的收据数据，可以将相对更少的收据内容采用明文形式存储、相对更多的收据内容采用密文形式存储，以便在支持部分功能扩展的同时，确保密文形式的收据内容得以安全保存。又例如，管理用户的隐私保护需求极高，那么对于管理用户发起的交易所产生的收据数据，可以将所有收据内容均采用密文形式存储。
前述的代码示例可以基于交易发起方所属的用户类型实现改进。在上述的代码示例2中，通过在智能合约的代码最前方添加暴露标识符plain，使得智能合约的代码被执行后，如果交易发起方属于预设用户类型，那么产生的收据数据中的所有字段均以明文形式进行存储。当然，在其他实施例中，也可以具体指明需要明文存储的字段。比如，通过暴露标识符对From字段进行标注时，可使得智能合约的代码被执行后，如果交易发起方属于预设用户类型，那么产生的收据数据中的From字段对应的收据内容以明文形式进行存储，而后续可以针对该From字段中的收据内容实施检索操作，比如可以统计某一账户所发起的交易量等。需要指出的是：在上述的代码示例2及其相关实施例中，由暴露标识符“plain”所标明的对象(所有字段或From字段)为合约级对象，使得第一区块链节点在存储收据数据时，将收据数据中对应于该合约级对象的所有收据内容以明文形式存储(前提为交易发起方属于预设用户类型)。尤其是，当智能合约的代码中包含多个事件时，合约级对象可以适用于智能合约中的所有事件，那么以From字段为例：当交易发起方属于预设用户类型时，对于多个事件分别的产生各自对应的Logs字段，每一Logs字段所含的From字段均会采用明文形式进行存储，而无需针对每一事件分别添加暴露标识符。
除了收据字段之外，暴露标识符还可以用于标明其他对象。例如，暴露标识符标明的对象可以包括状态变量，且该状态变量同样可以为合约级对象。以状态变量“price”为例，在上述的代码示例3中，通过在状态变量“price”的类型int之前添加暴露标识符“plain”(或者，可以将暴露标识符plain置于类型int之后)，使得当交易发起方属于预设用户类型时，在智能合约的代码被执行后产生的收据数据的各个字段(通常包括Topic字段、Output字段等)中，与状态变量“price”相关的收据内容均以明文形式进行存储，那么后续可以针对与状态变量“price”相关的收据内容实施检索操作。由于状态变量“price”在代码示例3中属于合约级对象，使得当智能合约的代码中包含多个事件时，合约级对象可以适用于智能合约中的所有事件，那么当多个事件分别产生各自对应的Logs字段时，每一Logs字段(如Logs字段中的Topic字段)均会采 用明文形式存储与状态变量“price”相关的收据内容，Output字段等也会采用明文形式存储与状态变量“price”相关的收据内容，无需在每一事件中分别针对状态变量“price”添加暴露标识符。
当智能合约的代码中定义了多个状态变量时，上述的合约级对象可以包括其中的部分或全部状态变量。例如，在上述的代码示例4中，智能合约的代码中定义了“price”、“price1”等多个状态变量，而用户可以仅针对状态变量“price”添加暴露标识符plain，使得该状态变量“price”成为合约级对象，而状态变量“price1”则并未由暴露标识符进行标注。
除了合约级对象之外，暴露标识符标明的对象可以包括：对应于智能合约中定义的至少一个事件的事件级对象，使得第一区块链节点在存储收据数据时，如果交易发起方属于预设用户类型，就可以将收据数据中对应于该至少一个事件的收据内容以明文形式存储。尤其是，当智能合约中包含多个事件时，可以针对至少一部分事件设定上述的事件级对象，使得这部分事件对应的收据内容以明文形式存储、其余事件对应的收据内容以密文形式存储。以From字段为例，在上述的代码示例5中，通过在事件currentPrice对应的事件函数“event currentPrice(int price)”中添加From字段对应的字符“from”，并且在该字符from所采用的暴露标识符区别于前述的plain，而是通过引号对该字符from进行修饰，则代码示例5中的引号相当于前述的暴露标识符，将From字段配置为事件级对象，使得当交易发起方属于预设用户类型时，在该事件对应产生的Logs字段中，From字段将以明文形式进行存储。除了上述事件currentPrice之外，如果智能合约的代码还包含另一事件，那么上述的字符from不会影响该另一事件、该另一事件对应的收据内容将以密文形式进行存储，除非存在针对该另一事件而添加的“from”。
事件级对象还可以包括状态变量。以状态变量“price”为例，在上述的代码示例6中，通过在事件currentPrice对应的事件函数“event currentPrice(int price)”之前添加关键字“plain”，而区别于代码示例5中添加的“from”，使得此处并未指明事件级对象为From字段，那么：一种情况下，事件级对象可以包括字段，这与上述的From字段相类似。但是，由于未指明具体的字段，可以将事件currentPrice所产生的日志中的所有字段均作为上述的事件级对象，譬如前述的From字段、To字段、Topic字段、Log Data字段等，使得在交易发起方属于预设用户类型时，将该事件currentPrice对应的所有收据内容均以明文形式存储。另一种情况下，事件级对象可以包括状态变量。例如，上述的代码示例6中定义了状态变量“price”，并且事件currentPrice引用了该状 态变量“price”，对应于在事件函数“event currentPrice(int price)”之前添加暴露标识符“plain”，可以将状态变量“price”作为上述的事件级对象，使得在交易发起方属于预设用户类型时，该事件产生的所有与状态变量“price”相关的收据内容均以明文形式进行存储。由于状态变量“price”在代码示例6中属于事件级对象，使得当智能合约的代码中还包含另一引用状态变量“price”的事件event1时，如果并未针对该事件event1添加任何级别的暴露标识符，那么即便该事件event1引用了状态变量“price”，该事件event1所产生的收据内容仍将以密文形式进行存储，而并非以明文形式存储。
当同一事件中引用了多个状态变量时，上述的事件级对象可以包括被引用的全部状态变量。例如，在上述的代码示例7中，事件currentPrice对应的事件函数“event currentPrice(int price,int price1)”引用了状态变量“price”和“price1”，而通过在该事件之前添加暴露标识符plain，使得被引用的状态变量“price”和“price1”均会受到影响，那么当交易发起方属于预设用户类型时，该事件产生的所有与状态变量“price”和“price1”相关的收据内容均以明文形式进行存储。但是，对于其他并未添加暴露标识符plain的事件，产生的收据内容均以密文形式进行存储。
当事件级对象包括状态变量时，还可以具体指示为事件所引用的一个或多个状态变量。以状态变量“price”为例，在上述的代码示例8中，事件currentPrice对应的事件函数“event currentPrice(int price)”引用了状态变量“price”，而通过在该状态变量“price”的类型int之前添加暴露标识符plain，使得该状态变量“price”被配置为事件级对象，并且该事件级对象仅适用于该事件currentPrice、不适用于智能合约包含的其他事件，即：在满足交易发起方属于预设用户类型的前提下，只有事件currentPrice产生的与状态变量“price”相关的收据内容以明文形式进行存储，除非其他事件中也针对状态变量“price”添加了暴露标识符，否则其他事件即便应用了该状态变量“price”，产生的收据内容仍以密文形式进行存储。
由于代码示例8中的事件currentPrice仅应用了状态变量“price”，使其实际效果与上述的代码示例6中针对该事件添加暴露标识符、将该事件引用的状态变量“price”配置为事件级对象相似。而当事件同时应用多个状态变量时，可以更加清晰地体现出两者的不同，例如在上述的代码示例9中，事件currentPrice同时引用了状态变量“price”和“price1”，而通过在状态变量“price”的类型int之前添加暴露标识符plain，可以将该状态变量“price”配置为事件级对象，而未添加暴露标识符plain的状态变量“price1”则并非事件级对象，使得在满足交易发起方属于预设用户类型的前提下，该事件产生的 与状态变量“price”相关的收据内容以明文形式进行存储、与状态变量“price1”相关的收据内容仍以密文形式进行存储。
在一实施例中，用户可以在区块链上存在对应的外部账户，并基于该外部账户发起交易或实施其他操作。那么，交易发起方所属的用户类型，即该外部账户所属的用户类型。因此，第一区块链节点可以确定所述交易发起方对应的外部账户，并通过查询区块链上记录的所述外部账户对应的用户类型，以作为所述交易发起方所属的用户类型。
在一实施例中，外部账户可以包括记录于区块链上的用户类型字段(如UserType字段)，该用户类型字段的取值对应于用户类型。比如，当用户类型字段的取值为00时，用户类型为普通用户，当用户类型字段的取值为01时，用户类型为高级用户，当用户类型字段的取值为11时，用户类型为管理用户等。因此，第一区块链节点可以通过读取上述的外部账户的用户类型字段，即可基于取值确定相应的用户类型。
在一实施例中，在创建上述的外部账户时，用户类型可以被配置为关联至该外部账户，使用户类型与外部账户之间的关联关系被记录于区块链中，比如通过用户类型与外部账户的账户地址来建立上述的关联关系，使得外部账户的数据结构并不需要改变，即外部账户无需包含上述的用户类型字段。因此，第一区块链节点可以通过读取区块链上记录的关联关系，并基于交易发起方对应的外部账户，确定该外部账户对应的上述预设用户类型。
在一实施例中，可以在一定条件下对外部账户的用户类型进行修改。例如，管理用户可以具备修改权项，使得第一区块链节点可以根据管理用户发起的更改请求，更改上述外部账户对应的用户类型。管理用户可以对应于创世块中预置的、具有管理权限的外部账户，使得管理用户可以对其他的普通用户、高级用户等进行类型更改，比如将普通用户更改为高级用户、将高级用户更改为普通用户等。
在图3所示实施例的基础上，本说明书可以进一步识别交易的交易类型，从而同时根据暴露标识符和对应于该交易类型的暴露字段，确定对收据数据的存储方式。因此，上述的步骤308可以改进为：第一区块链节点存储所述收据数据，使所述收据数据中由所述暴露标识符标明的对象对应的收据内容暴露字段以明文形式存储、其余收据内容字段以密文形式存储。换言之，用户在编写智能合约的代码时，可以在代码中添加暴露标识符来标明一个或多个字段，从而在该智能合约的代码维度上表达下述含义：对于暴露标识符标明的字段，希望将收据数据中相应的收据内容采用明文形式存储，而剩余 字段所对应的收据内容则采用密文形式存储。当然，最终是否将暴露标识符标明的字段采用明文形式存储，还需要结合交易类型，使得暴露标识符标明的字段同时属于交易类型对应的暴露字段时，该字段对应的收据内容能够以明文形式存储，否则仍然采用密文形式存储。
前述的代码示例可以基于交易发起方所属的用户类型实现改进。在上述的代码示例2中，通过在智能合约的代码最前方添加暴露标识符plain，使得智能合约的代码被执行后，对于该智能合约所属交易的交易类型对应的暴露字段，产生的收据数据中对应于上述暴露字段的收据内容均以明文形式进行存储。
当然，在其他实施例中，也可以具体指明需要明文存储的字段。比如，通过暴露标识符对From字段进行标注时，可以仅对该From字段进行判断：如果From字段为该智能合约所属交易的交易类型对应的暴露字段，那么在智能合约的代码被执行后，产生的收据数据中的From字段对应的收据内容以明文形式进行存储，而后续可以针对上述From字段中的收据内容实施检索操作，比如可以统计某一账户所发起的交易量等；而除了From字段之前的其他字段，则均以密文形式存储。
需要指出的是：在上述的代码示例2及其相关实施例中，由暴露标识符“plain”所标明的字段(所有字段或From字段)为合约级字段，使得第一区块链节点在存储收据数据时，如果该合约级字段为暴露字段，那么第一区块链节点会将收据数据中对应于该合约级字段的所有收据内容以明文形式存储。尤其是，当智能合约的代码中包含多个事件时，合约级字段可以适用于智能合约中的所有事件，那么以From字段为例：当From字段为合约级字段以及交易类型对应的暴露字段时，对于多个事件分别的产生各自对应的Logs字段，每一Logs字段所含的From字段均会采用明文形式进行存储，而无需针对每一事件分别添加暴露标识符。
除了合约级字段之外，暴露标识符标明的字段可以包括：对应于智能合约中定义的至少一个事件的事件级字段，使得第一区块链节点在存储收据数据时，如果事件级字段属于交易类型对应的暴露字段，可以确定出收据数据中对应于该至少一个事件的收据内容，并将确定出的收据内容中对应于上述事件级字段的部分以明文形式存储。尤其是，当智能合约中包含多个事件时，可以针对至少一部分事件设定上述的事件级字段，使得这部分事件对应的收据内容中对应于事件级字段的部分以明文形式存储，而这部分事件对应的收据内容中的剩余部分、其余事件对应的收据内容等均以密文形式存储。以From字段为例，在上述的代码示例5中，通过在事件currentPrice对应的事件函数“event  currentPrice(int price)”中添加From字段对应的字符from，并且该字符from所采用的暴露标识符区别于前述的plain，而是通过引号对该字符from进行修饰，则代码示例5中的引号相当于前述的暴露标识符，将From字段配置为事件级字段，使得当From字段属于交易类型对应的暴露字段时，在该事件对应产生的Logs字段中，From字段将以明文形式进行存储。除了上述事件currentPrice之外，如果智能合约的代码还包含另一事件，那么上述的字符from不会影响该另一事件、该另一事件对应的收据内容将以密文形式进行存储，除非存在针对该另一事件而添加的“from”。而在上述的代码示例6中，通过在事件currentPrice对应的事件函数“event currentPrice(int price)”之前添加暴露标识符“plain”，而区别于代码示例5中添加的“from”，使得此处并未指明事件级字段为From字段，那么可以将事件currentPrice所产生的日志中的所有字段均作为上述的事件级字段，譬如前述的From字段、To字段、Topic字段、Log Data字段等，相当于将该事件currentPrice对应的所有收据内容均以明文形式存储。
在一实施例中，交易可以包括交易类型字段(如TransType字段)，该交易类型字段的取值用于标明相应的交易类型。因此，通过读取交易所含交易类型字段的取值，可以确定出交易类型，比如存证类型、资产转移(如转账)类型、合约创建类型、合约调用类型等，本说明书并不对此进行限制。不同类型的交易可以分别存在对应的暴露字段。暴露字段为收据数据中指定的一个或多个字段，在收据数据需要密文存储以保护隐私的前提下，可以结合前述的暴露标识符标明的字段与暴露字段之间的匹配情况，选择性地将被暴露标识符标明的暴露字段对应的收据内容以明文形式进行存储，而并非将所有被暴露标识符标明的字段均以明文形式进行存储，可以在满足隐私保护需求的同时，以便后续针对该明文形式存储的收据内容实施检索等操作。
在一实施例中，可以预先定义每一交易类型与暴露字段之间的映射关系，并将该映射关系记录于区块链中，使得第一区块链节点可以获取该预定义的映射关系，并进一步根据上述交易的交易类型和该映射关系，确定收据数据中的暴露字段。例如，存证类型对应的暴露字段可以包括上述From字段之外的所有字段，资产转移类型对应的暴露字段可以包括上述的To字段，合约创建类型和合约调用类型对应的暴露字段可以包括上述From字段之外的所有字段，而对于其他交易类型的情况，此处不再一一赘述。其中，上述的映射关系具体可以记录于系统合约中。还可以将该映射关系记录于区块链网络的链代码中。通过将映射关系记录于系统合约中，便于后续针对该映射关系进行更新升级，而记录于链代码中的映射关系则相对不易实现更新升级，后续将针对两者的差异进行描述，此处暂不赘述。
在图3所示实施例的基础上，本说明书可以进一步识别智能合约所含的事件函数，从而同时根据暴露标识符和智能合约所含的特殊事件函数，确定对收据数据的存储方式。因此，上述的步骤308可以改进为：第一区块链节点存储所述收据数据，使对应于所述特殊事件函数的日志中的至少一部分收据内容以明文形式存储、所述收据数据的其余内容以密文形式存储，所述至少一部分收据内容匹配于所述暴露标识符标明的对象。换言之，在智能合约的代码中，暴露标识符可以标明一个或多个对象，这些对象在收据数据中存在对应的收据内容。而特殊事件函数被执行后，收据数据中包含对应于特殊事件函数的日志，该日志实际为收据数据中的部分收据内容。而本说明书中通过对暴露标识符和特殊事件函数进行综合考量，可以筛选出上述两部分收据内容的交叉内容，并针对该交叉内容实施明文存储，收据数据的其余内容均采用密文存储。
在一实施例中，智能合约可以包含一个或多个事件，每一事件用于实现预定义的相关处理逻辑。智能合约所含的每一事件被调用执行后，均会生成对应的Logs字段，比如当智能合约包含事件1和事件2时，事件1可以生成对应的Logs字段、事件2可以生成对应的Logs字段，使得该智能合约对应的收据数据同时包含多个Logs字段。智能合约所含的事件可以分为特殊事件函数和普通事件函数，其中：普通事件函数所产生的日志采用密文形式进行存储，以实现隐私保护；特殊事件函数所产生的日志则允许在满足隐私保护需求的前提下，将至少一部分日志内容以明文形式进行存储，从而可以针对该部分日志内容的内容实施检索，以驱动相关操作的实施。可以在区块链网络的链代码或系统合约中记录属于“特殊事件函数”的事件函数，譬如可以记录在特殊事件函数列表中；相应地，通过将智能合约中包含的事件函数与上述的特殊事件函数列表进行对比，可以确定智能合约包含的事件函数是否为上述的特殊事件函数。
在一实施例中，特殊事件函数可以为智能合约中自定义的任意函数，并通过在智能合约中添加针对事件函数的类型标识符，可以将该事件函数标记为特殊事件函数。以Solidity语言为例，上述代码示例1中包含事件函数的代码示例如下：
event currentPrice(int price)；
在上述代码示例中，智能合约定义了事件：事件currentPrice。但是，该事件未包含任何类型标识符，因而相应的事件函数属于普通事件函数。而对代码示例1中的事件函数进行调整后，可以得到事件函数的代码示例如下：
event currentPrice expose(int price)；
在上述修改后的代码示例中，智能合约定义了事件：事件currentPrice。通过在 事件currentPrice中添加类型标识符“expose”，可以将该事件currentPrice标记为上述的特殊事件函数。以太坊支持的高级语言很多，如Solidity、Serpent、LLL语言等，均可以包含上述的类型标识符。通过编译器可以将高级语言编写的智能合约编译为相应的字节码，第一区块链节点最终在EVM虚拟机中执行字节码形式的智能合约。那么，上述的类型标识符在高级语言和字节码形式的智能合约代码中可以相同，或者高级语言的智能合约代码中为第一类型标识符、字节码形式的智能合约代码中为第二类型标识符，第一类型标识符与第二类型标识符之间可以相互对应。
在智能合约的代码中，暴露标识符可以标明一个或多个对象，这些对象在收据数据中存在对应的收据内容。而特殊事件函数被执行后，收据数据中包含对应于特殊事件函数的日志，该日志实际为收据数据中的部分收据内容。而本说明书中通过对暴露标识符和特殊事件函数进行综合考量，可以筛选出上述两部分收据内容的交叉内容，并针对该交叉内容实施明文存储，收据数据的其余内容均采用密文存储。
由于暴露标识符为智能合约的编程语言中所定义的全局性标识，因而只要在智能合约中写入暴露标识符后，就难以修改该暴露标识符所标明的对象。而特殊事件函数的定义并不一定基于编程语言实现，比如在基于特殊事件函数列表等方式记录特殊事件函数时，即便智能合约中包含的某一事件函数原本属于特殊事件函数，也可以通过对特殊事件函数列表进行更改的方式，将原有的特殊事件函数更新为普通事件函数，从而避免该事件函数产生的日志以明文形式存储，或者将原有的普通事件函数更新为特殊事件函数，使得该事件函数产生的日志中的至少一部分内容以明文形式存储。
以上述的代码示例2为例：假定事件currentPrice原本并未记录于特殊事件函数列表中，即事件currentPrice对应于普通事件函数，那么即便在智能合约的代码中添加了暴露标识符plain，事件currentPrice产生的日志中的各个字段仍以密文形式存储。但是，如果将事件currentPrice添加至特殊事件函数列表中，那么代码示例2不需要调整的情况下，即可使得事件currentPrice对应的日志中的各个字段以明文形式存储。
以上述的代码示例3为例：假定事件currentPrice原本并未记录于特殊事件函数列表中，即事件currentPrice对应于普通事件函数，那么即便在智能合约的代码中添加了暴露标识符plain，在事件currentPrice产生的日志中，状态变量price的取值仍以密文形式存储。但是，如果将事件currentPrice添加至特殊事件函数列表中，那么代码示例3不需要调整的情况下，即可使得事件currentPrice对应的日志中，状态变量price的取值以明文形式存储。
需要指出的是：在上述的代码示例2中，通过在代码最前方声明“plain”，该暴露标识符“plain”所标明的对象为收据数据中的所有字段，且这些字段均为合约级对象，使得第一区块链节点在存储收据数据时，收据数据中所有对应于该合约级对象的收据内容，均被允许以明文形式存储。当然，如果代码示例2中通过暴露标识符标注了From字段，那么该From字段为上述的合约级对象，使得第一区块链节点在存储收据数据时，收据数据中所有对应于该From字段的收据内容，均被允许以明文形式存储。类似地，在上述的代码示例3中，暴露标识符“plain”所标明的状态变量“price”同样为合约级对象，使得第一区块链节点在存储收据数据时，收据数据中所有对应于该合约级对象“price”的收据内容，均被允许以明文形式存储。
尤其是，当智能合约的代码中包含多个事件函数时，在多个事件函数分别产生的各自对应的Logs字段中，均可能存在合约级对象所对应的收据内容；进一步地，可以通过识别各个事件函数的类型为普通事件函数或特殊事件函数，从而将所有特殊事件函数所产生的日志中对应于合约级对象的收据内容以明文形式存储。例如，智能合约可以包括下述的代码示例10：
plain Contract Example{
int price；
int price1；
event currentPrice1(int price)；
event currentPrice2(int price1)；
…
在上述的代码示例10中，与代码示例2相类似地，暴露标识符“plain”位于智能合约的代码最前方，使得收据数据中的所有字段均被标注为合约级对象；同时，智能合约中包含了事件currentPrice1和事件currentPrice2：假定事件currentPrice1对应于特殊事件函数列表中定义的特殊事件函数、事件currentPrice2对应于普通事件函数，那么在事件currentPrice1和事件currentPrice2分别产生的日志Log1、Log2中，日志Log1包含的所有字段均以明文形式存储、日志Log2包含的所有字段均以密文形式存储。并且，如果通过对特殊事件函数列表进行更新后，将事件currentPrice2更新为对应于特殊事件函数，那么日志Log2包含的所有字段将均以明文形式存储，而无需对智能合约的代码做任何变动。当然，如果代码示例10中通过暴露标识符标注了From字段，那么该From字段为上述的合约级对象，使得事件currentPrice1为特殊事件函数、事件currentPrice2 为普通事件函数时，日志Log1中的From字段以明文形式存储、其余字段以密文形式存储，而日志Log2包含的所有字段均以密文形式存储；以及，当事件currentPrice2更新为特殊事件函数，那么日志Log2中的From字段以明文形式存储、其余字段以密文形式存储。
对于上述的合约级对象而言，可以通过前述的类型标识符来标明智能合约所含的事件函数是否为特殊事件函数。例如，可以将上述的代码示例10调整为下述的代码示例11：
plain Contract Example{
int price；
int price1；
event currentPrice1 expose(int price)；
event currentPrice2(int price1)；
…
在上述的代码示例11中，与代码示例2相类似地，合约级对象包括收据数据中的所有字段；同时，智能合约中包含了事件currentPrice1和事件currentPrice2：由于事件currentPrice1在包含如前所述的类型标识符expose，使得该事件currentPrice1被标注为对应于特殊事件函数，而事件currentPrice2并未包含类型标识符expose，使得事件currentPrice2被标注为对应于普通事件函数，那么在事件currentPrice1和事件currentPrice2分别产生的日志Log1、Log2中，日志Log1包含的所有字段以明文形式存储、日志Log2包含的所有字段以密文形式存储。
虽然类型标识符与暴露标识符相类似的，都是智能合约的编程语言中所定义的全局性标识，但是暴露标识符作用于合约级对象、类型标识符作用于事件函数，使得通过将暴露标识符与类型标识符配合使用，仅需单次添加暴露标识符即可设定形成上述的合约级对象，并且进而可以灵活地标注希望对合约级对象进行明文存储的事件函数，尤其是当智能合约中包含的事件函数的数量较多、事件函数中涉及的对象(如字段或状态变量)的数量较多时，无需针对每一事件函数所涉及的每一对象分别实施设定操作，可以简化代码逻辑、防止错标或漏标。
上述实施例中的合约级对象包括字段，比如From字段等。合约级对象还可以包括状态变量；例如，可以将上述的代码示例10调整为下述的代码示例12：
Contract Example{
plain int price；
int price1；
event currentPrice1(int price)；
event currentPrice2(int price)；
event currentPrice3(int price1)；
…
在上述的代码示例12中，事件currentPrice1和事件currentPrice2引用了状态变量price、事件currentPrice3引用了状态变量price1；由于在状态变量price的类型int之前添加了暴露标识符“plain”，可以将该状态变量price作为上述的合约级对象。相应的，对于引用该合约级对象的事件函数，在特殊事件函数所产生的日志中，该合约级对象对应的收据内容以明文形式存储，而普通事件函数即便引用了该合约级对象，所产生的日志仍以密文形式存储。例如，结合区块链网络中记录的特殊事件函数列表：当事件currentPrice1对应于特殊事件函数时，由于事件currentPrice1引用了作为合约级对象的状态变量price，因而在该事件currentPrice1产生的日志Logs中，与状态变量price相关的收据内容均以明文形式进行存储；当事件currentPrice2对应于普通事件函数时，虽然事件currentPrice2引用了作为合约级对象的状态变量price，但在该事件currentPrice2产生的日志Logs中，与状态变量price相关的收据内容均以密文形式进行存储；虽然事件currentPrice3对应于特殊事件函数，但是由于事件currentPrice3并未引用作为合约级对象的状态变量price，因而事件currentPrice3产生的日志Logs均以密文形式进行存储。
与前述实施例相类似的，对于状态变量类型的合约级对象，可以通过类型标识符来标注事件函数的类型。例如，可以将上述的代码示例12调整为下述的代码示例13：
Contract Example{
plain int price；
int price1；
event currentPrice1 expose(int price)；
event currentPrice2(int price)；
event currentPrice3 expose(int price1)；
…
在上述的代码实例13中，通过暴露标识符可以将状态变量price标注为合约级对象，而状态变量price1并非合约级对象；通过类型标识符expose标明的事件currentPrice1、事件currentPrice3均对应于特殊事件函数，而事件currentPrice2对应于普通事件函数。因此，在该事件currentPrice1产生的日志Logs中，与状态变量price相关的收据内容均以明文形式进行存储；在该事件currentPrice2产生的日志Logs中，与状态变量price相关的收据内容均以密文形式进行存储；事件currentPrice3产生的日志Logs均以密文形式进行存储。
除了合约级对象之外，暴露标识符标明的对象可以包括：对应于智能合约中定义的至少一个事件的事件级对象，使得第一区块链节点在存储收据数据时，将特殊事件函数产生的收据内容中对应于该事件级对象的部分以明文形式存储。尤其是，当智能合约中包含多个事件时，可以针对至少一部分事件设定上述的事件级对象，使得这部分事件产生的收据内容中对应于该事件级对象的部分以明文形式存储，而这部分事件产生的其他收据内容和其余事件产生的所有收据内容均以密文形式存储。以From字段为例，可以将上述的代码示例11调整为下述的代码示例14：
Contract Example{
int price；
int price1；
event currentPrice1(“from”,int price)；
event currentPrice2(int price1)；
…
在上述的代码示例14中，事件currentPrice1虽然未添加暴露标识符“plain”，但是包含了内容“from”，该内容“from”对应于From字段，用于表明事件currentPrice1所产生日志中的From字段需要以明文形式存储，因而该内容“from”既属于上述的暴露标识符，又标明了需要明文存储的From字段。并且，由于内容“from”位于事件currentPrice1中，因而From字段为事件级对象，使得当该事件currentPrice1对应于特殊事件函数时，在该事件currentPrice1对应产生的日志Logs中，From字段将以明文形式进行存储、其他字段以密文形式存储。而对于代码示例14所含的另一事件currentPrice2，由于并未针对该事件currentPrice2添加暴露标识符，因而不论该事件currentPrice2对应于特殊事件函数或普通事件函数，所产生的日志Logs均以密文形式存储。
上述的关键词“from”指明了将From字段设定为事件级对象；对于事件级对象为字段类型的情况，也可以并不指明具体的字段。例如，可以将上述的代码示例11调整为下述的代码示例15：
Contract Example{
int price；
int price1；
plain event currentPrice1(int price,int price1)；
event currentPrice2(int price1)；
…
在上述的代码示例15中，通过在事件currentPrice1之前添加暴露标识符“plain”，可以将该事件currentPrice1所产生的日志中的所有字段均作为上述的事件级对象，譬如前述的From字段、To字段、Topic字段、Log Data字段等。那么，当该事件currentPrice1对应于特殊事件函数时，相当于将该事件currentPrice1对应的所有收据内容(比如产生的日志)均以明文形式存储。
事件级对象还可以包括状态变量。从状态变量的维度而言，上述的代码示例15可以解释为：事件currentPrice1引用了状态变量price和price1、事件currentPrice2引用了状态变量price1；由于通过在事件currentPrice1之前添加暴露标识符“plain”，可以将该事件currentPrice1所引用的状态变量price和price1作为上述的事件级对象，使得当该事件currentPrice1对应于特殊事件函数时，在该事件currentPrice1产生的日志Logs中，与状态变量price和price1相关的收据内容均以明文形式进行存储。而对于代码示例15所含的另一事件currentPrice2，由于并未针对该事件currentPrice2添加暴露标识符，因而不论该事件currentPrice2对应于特殊事件函数或普通事件函数，在该事件currentPrice2所产生的日志Logs中，与状态变量price1相关的收据内容均以密文形式存储。
当事件级对象包括状态变量时，还可以具体指示为事件所引用的一个或多个状态变量。例如，可以将上述的代码示例11调整为下述的代码示例16：
Contract Example{
int price；
int price1
event currentPrice1(plain int price，int price1)；
event currentPrice2(int price)；
…
在上述的代码示例16中，在事件currentPrice1对应的事件函数中，包含添加在状态变量price的类型int之前的暴露标识符plain，使得该状态变量price被配置为事件级对象，该事件级对象仅适用于该事件currentPrice1。由于暴露标识符plain位于事件currentPrice1对应的事件函数中，而事件currentPrice2对应的事件函数虽然引用了状态变量price但是并未标注暴露标识符plain，因而事件currentPrice2对应的事件函数与事件级对象无关。因此，即便事件currentPrice1和事件currentPrice2均对应于特殊事件函数，也只有在事件currentPrice1产生的日志中，将作为事件级对象的状态变量price对应的收据内容以明文形式存储，而事件currentPrice2产生的日志均以密文形式存储。类似地，虽然事件currentPrice1引用了状态变量price1，但是由于该状态变量price1并未被暴露标识符进行标注，因而该状态变量price1并不属于事件级对象，即便事件currentPrice1对应于特殊事件函数，但在事件currentPrice1产生的日志中，该状态变量price1对应的收据内容仍以密文形式存储。
在图3所示实施例的基础上，本说明书可以进一步识别收据数据中满足预设条件的收据内容，从而同时根据暴露标识符和收据内容对预设条件的满足情况，确定对收据数据的存储方式。因此，上述的步骤308可以改进为：第一区块链节点存储所述收据数据，使对应于所述暴露标识符标明的对象的收据内容中满足预设条件的部分以明文形式存储、所述收据数据的其余收据内容以密文形式存储。在智能合约的代码中，暴露标识符可以标明一个或多个对象，这些对象在收据数据中存在对应的收据内容。在保护用户隐私的前提下，通过将暴露标识符标明的对象对应的收据内容与预设条件作比较，可以根据收据内容对预设条件的满足情况，在存储过程中体现出对隐私保护的差异化需求和处理：将满足预设条件的收据内容以明文形式存储，而其他收据内容则必然以密文形式存储。
前述的代码示例可以基于收据内容对预设条件的满足情况实现改进。在上述的代码示例2中，通过在智能合约的代码最前方添加暴露标识符plain，使得智能合约的代码被执行后，产生的收据数据中满足预设条件的所有字段均以明文形式进行存储。
当然，在其他实施例中，也可以具体指明需要明文存储的字段。比如，通过暴露标识符对From字段进行标注时，可使得智能合约的代码被执行后，如果产生的收据 数据中的From字段对应的收据内容满足预设条件，该From字段对应的收据内容以明文形式进行存储，而后续可以针对该From字段中的收据内容实施检索操作，比如可以统计某一账户所发起的交易量等。
需要指出的是：在上述的代码示例2及其相关实施例中，由暴露标识符“plain”所标明的对象(所有字段或From字段)为合约级对象，使得第一区块链节点在存储收据数据时，收据数据中所有对应于该合约级对象“From字段”的收据内容，均被允许以明文形式存储(前提为相关收据内容满足预设条件)。尤其是，当智能合约的代码中包含多个事件时，合约级对象可以适用于智能合约中的所有事件，那么以From字段为例：对于任一事件产生的日志Logs，如果该日志Logs所含的From字段满足预设条件，那么该From字段将以明文形式存储，而无需针对每一事件分别添加暴露标识符。
除了收据字段之外，暴露标识符还可以用于标明其他对象。例如，暴露标识符标明的对象可以包括状态变量，且该状态变量同样可以为合约级对象。以状态变量“price”为例，在上述的代码示例3中，通过在状态变量“price”的类型int之前添加暴露标识符“plain”(或者，可以将暴露标识符plain置于类型int之后)，可以将该状态变量price标记为合约级对象。相应的，在智能合约的代码被执行后产生的收据数据的各个字段(通常包括Topic字段、Output字段等)中，如果存在对应于状态变量price的收据内容(通常记载了状态变量price的取值)，可以判断相关收据内容对预设条件的满足情况，并将满足预设条件的收据内容以明文形式进行存储。由于状态变量“price”在代码示例3中属于合约级对象，使得当智能合约的代码中包含多个事件时，合约级对象可以适用于智能合约中的所有事件，那么当多个事件分别产生各自对应的日志Logs时，每一日志Logs(如日志Logs中的Topic字段等)都可能产生与状态变量“price”相关的收据内容(取决于相关事件是否应用了该状态变量price)，可以分别与预设条件进行比较判断，以确定各个日志Logs中的price取值是否以明文形式存储，而无需在每一事件中分别针对状态变量“price”添加暴露标识符；类似地，Output字段也会包含与状态变量“price”相关的收据内容。对于不同收据字段所包含的与状态变量price相关的收据内容，可以采用相同或不同的预设条件进行判断以确定是否采用明文形式存储，这取决于对“预设条件”的配置规则，可参见下文的相关描述。
当智能合约的代码中定义了多个状态变量时，上述的合约级对象可以包括其中的部分或全部状态变量。例如，在上述的代码示例4中，智能合约的代码中定义了“price”、“price1”等多个状态变量，而用户可以仅针对状态变量“price”添加暴露标识符plain， 使得该状态变量“price”成为合约级对象，而状态变量“price1”则并未由暴露标识符进行标注。
除了合约级对象之外，暴露标识符标明的对象可以包括：对应于智能合约中定义的至少一个事件的事件级对象，使得第一区块链节点在存储收据数据时，如果收据数据中对应于该至少一个事件的收据内容满足预设条件，则相应的收据内容以明文形式存储。尤其是，当智能合约中包含多个事件时，可以针对至少一部分事件设定上述的事件级对象，使得这部分事件对应的收据内容在满足预设条件时以明文形式存储、其余事件对应的收据内容以密文形式存储。以From字段为例，在上述的代码示例5中，通过在事件currentPrice对应的事件函数“event currentPrice(int price)”中添加From字段对应的字符from，并且该字符from所采用的暴露标识符区别于前述的plain，而是通过引号对该字符from进行修饰，则代码示例5中的引号相当于前述的暴露标识符，使得From字段被标记为事件级对象，因而在该事件对应产生的Logs字段中，如果From字段满足预设条件，则将From字段以明文形式进行存储。除了上述事件currentPrice之外，如果智能合约的代码还包含另一事件，那么上述的事件级对象不会影响该另一事件、该另一事件对应的收据内容将以密文形式进行存储，除非存在针对该另一事件而添加的“from”且该另一事件产生的Logs中的From字段满足预设条件。
在上述的代码示例6中，通过在事件currentPrice对应的事件函数“event currentPrice(int price)”之前添加关键字“plain”，使得事件级对象包括该事件currentPrice对应的日志Logs中的所有字段，譬如前述的From字段、To字段、Topic字段、Log Data字段等，可以将这些字段分别与预设条件进行比较，从而将满足预设条件的字段以明文形式存储。事件级对象还可以包括状态变量。从状态变量的维度而言，上述的代码示例6可以解释为：事件currentPrice引用了状态变量“price”，通过在事件currentPrice之前添加暴露标识符“plain”，可以将该事件currentPrice所引用的状态变量price作为上述的事件级对象，并确定出该事件currentPrice产生的日志Logs中与状态变量price相关的收据内容，且将确定出的收据内容中满足预设条件的部分以明文形式存储、不满足预设条件的部分以密文形式存储。由于状态变量“price”在代码示例6中属于事件级对象，使得当智能合约的代码中还包含另一引用状态变量“price”的事件event1时，如果并未针对该事件event1添加任何级别的暴露标识符，那么即便该事件event1引用了状态变量“price”，该事件event1所产生的收据内容仍将以密文形式进行存储，而并非以明文形式存储。
当同一事件中引用了多个状态变量时，上述的事件级对象可以包括被引用的全部状态变量。例如，在上述的代码示例7中，事件currentPrice对应的事件函数“event currentPrice(int price,int price1)”引用了状态变量“price”和“price1”，而通过在该事件之前添加暴露标识符plain，使得被引用的状态变量“price”和“price1”均会受到影响，对该事件产生的所有与状态变量“price”和“price1”相关的收据内容，满足预设条件的均以明文形式存储、未满足条件的均以密文形式存储。但是，对于其他并未添加暴露标识符plain的事件，产生的收据内容均以密文形式进行存储。
当事件级对象包括状态变量时，还可以具体指示为事件所引用的一个或多个状态变量。以状态变量“price”为例，在上述的代码示例8中，事件currentPrice对应的事件函数“event currentPrice(int price)”引用了状态变量“price”，而通过在该状态变量“price”的类型int之前添加暴露标识符plain，使得该状态变量“price”被配置为事件级对象，并且该事件级对象仅适用于该事件currentPrice、不适用于智能合约包含的其他事件，即：只有事件currentPrice产生的与状态变量“price”相关的收据内容，能够在满足预设条件的情况下以明文形式进行存储，收据数据中的其他内容均以密文形式进行存储。
由于代码示例8中的事件currentPrice仅引用了状态变量“price”，使其实际效果与上述的代码示例6中针对该事件添加暴露标识符、将该事件引用的状态变量“price”配置为事件级对象相似。而当事件同时应用多个状态变量时，可以更加清晰地体现出两者的不同，在上述的代码示例9中，事件currentPrice对应的事件函数“event currentPrice(int price,int price1)”同时引用了状态变量“price”和“price1”，而通过在状态变量“price”的类型int之前添加暴露标识符plain，可以将该状态变量“price”配置为事件级对象，而未添加暴露标识符plain的状态变量“price1”则并非事件级对象，使得该事件currentPrice产生的与状态变量“price”相关的收据内容在满足预设条件的情况下以明文形式进行存储、与状态变量“price1”相关的收据内容则必然以密文形式进行存储。
预设条件的内容可以包括以下至少之一：相应的收据内容中包含预设内容、相应的收据内容的取值属于预设数值区间等。预设内容可以包括：指定的一个或多个关键词，比如该关键词可以包括预定义的状态变量、预定义的事件函数、表示交易执行结果的信息等，使得当收据内容包含作为关键词的状态变量、事件函数或交易执行结果等信息时，可以判定该收据内容满足预设条件。预设内容可以包括：预设值。比如该预设值 可以为数值，该数值可与状态变量的取值等进行比较，以确定状态变量的取值是否符合预期；再比如该预设值可以为数值、字母、特殊符号等构成的字符串，该字符串可与交易发起方的账户地址、交易目标方的账户地址、日志主题等进行比较，以识别出特定的交易发起方、特定的交易目标方或特定的日志主题等。以预设内容为字符串为例，假定该字符串为某一账户地址，可使用户在针对该账户地址发起交易且To字段被暴露标识符标明时，将该日志中的To字段采用明文形式存储，而其他的From字段等则采用密文形式存储，避免泄露隐私。预设数值区间可以表明相关收据字段的隐私保护需求情况，比如在转账场景中，预设数值区间可以为数值较小、隐私保护需求较低的数值区间，使得即便公开相关收据字段也不会造成严重的用户隐私泄露，但可以用于自动触发如DAPP客户端的相关操作，从而在隐私保护与便捷性之间取得一定平衡。
在一实施例中，预设条件可以包括收据数据中的所有收据字段对应的通用条件，即暴露标识符标明的对象所对应的收据内容处于收据数据中的任意收据字段时，均被用于与该预设条件进行比较。例如，当预设条件为“包含预设关键词”时，可以将暴露标识符标明的对象所对应的收据内容与该预设条件所含的关键词进行比较，以确定出包含该关键词的收据内容，作为满足上述预设条件的收据内容；其中，当暴露标识符标明的对象所对应的收据内容处于某一收据字段时，该收据字段还可能包含其他收据内容，这些收据内容均以密文形式进行存储。
在一实施例中，预设条件可以包括收据数据中的每一收据字段分别对应的专用条件，即收据数据中的各个收据字段分别存在对应的预设条件，需要根据暴露标识符标明的对象所对应的收据内容所处的收据字段，确定相应的预设条件并实施比较。不同收据字段对应的预设条件之间相互独立，但可能相同，也可能不同。例如，From字段对应的预设条件可以为“是否包含预设内容”，且该预设内容可以为预设的账户地址，表明由该账户地址发起的交易，Topic字段对应的预设条件可以为“是否属于预设取值区间”，而Topic字段中可以记录相关事件引用的状态变量的取值，譬如转账场景下可以包括代表“转账金额”的状态变量，表明转账金额处于预设取值区间；那么：当暴露标识符标明的对象所对应的收据内容同时处于From字段和Topic字段时，处于From字段中的收据内容适用于与预设条件“是否包含预设内容”进行比较、处于Topic字段中的收据内容适用于与预设条件“是否属于预设取值区间”进行比较。
由于暴露标识符为智能合约的编程语言中所定义的全局性标识，因而只要在智能合约中写入暴露标识符后，就难以修改该暴露标识符所标明的对象。而预设条件并不 一定在暴露标识符所处的智能合约中基于编程语言实现，例如：在一实施例中，预设条件可以位于交易中(不在交易所含的智能合约的代码中，可以在创建交易时对该预设条件进行设定)，使得不同交易即便在调用同一智能合约的情况下，所采用的预设条件也可以存在差异，以满足不同交易所面临的需求差异；当然，不同交易也可以采用相同的预设条件。预设条件的不同可以表现为：预设条件的内容、预设条件适用的收据字段、对收据内容是否满足预设条件进行判断的处理逻辑中的至少一个维度的差异。在一实施例中，预设条件可以位于交易调用的智能合约中，使得交易可以通过选取所调用的智能合约，以确定是否使用预设条件；或者，预设条件可以位于交易调用的智能合约A所调用的另一智能合约B中，使得通过配置智能合约A所调用的智能合约，比如将智能合约B换为智能合约C，即可更换所使用的预设条件(由智能合约B中定义的预设条件更换为智能合约C中定义的预设条件)。智能合约可由交易发起方自身或其他任意用户预先创建；当然，如果智能合约存在相应的调用条件，那么需要在该调用条件被满足时才能够使得上述交易调用该智能合约，比如该调用条件可以包括：交易发起方属于预设白名单、交易发起方不属于预设黑名单或其他条件。在一实施例中，预设条件可以位于系统合约或链代码中，使得该预设条件为适用于区块链上的所有交易的全局条件，而区别于上述的交易或智能合约所含的预设条件，使得即便交易或交易调用的智能合约并未包含预设条件的情况下，可以基于系统合约或链代码中定义的预设条件，确定暴露标识符标明的对象所对应的收据内容是否以明文形式存储。需要指出的是：交易或智能合约所含的预设条件，与链代码或系统合约所含的预设条件之间并不矛盾：两者可以分别包含不同维度的预设条件，比如预设条件适用的收据字段不同；或者，当两者包含的预设条件之间存在冲突时，可以默认为优先采用交易或智能合约所含的预设条件，或者优先采用链代码或系统合约所含的预设条件，这取决于预定义的选择逻辑。
在图3所示实施例的基础上，本说明书可以进一步兼顾识别交易发起方的用户类型和交易的交易类型，从而同时根据暴露标识符、交易发起方的用户类型和对应于该交易类型的暴露字段，确定对收据数据的存储方式。因此，上述的步骤308可以改进为：第一区块链节点存储所述收据数据，当交易发起方属于预设用户类型时，使所述收据数据中由所述暴露标识符标明的暴露字段以明文形式存储、其余收据字段以密文形式存储。由于暴露标识符为智能合约的编程语言中所定义的全局性标识，因而只要在智能合约中写入暴露标识符后，就难以修改该暴露标识符所标明的字段。因此，通过结合对用户类型和交易类型的考量，可以根据交易发起方所属的用户类型、交易类型对应的暴露字段，更准确地选取采用明文形式进行存储的字段，而并非仅基于暴露标识符进行确定， 从而在不同用户调用同一智能合约或通过不同类型的交易调用同一智能合约时，使得明文存储的字段配合于用户类型和交易类型，可使针对收据数据的存储方式满足不同情形下的实际需求，能够兼顾隐私保护和功能扩展。
前述的代码示例可以基于交易发起方所属的用户类型和对应于该交易类型的暴露字段实现改进。在上述的代码示例2中，通过在智能合约的代码最前方添加暴露标识符“plain”，使得收据数据中的所有字段均允许以明文形式进行存储，因而如果交易发起方属于预设用户类型，那么对于该智能合约所属交易的交易类型对应的暴露字段，在智能合约的代码被执行后，产生的收据数据中对应的收据内容将以明文形式进行存储，而后续可以针对这些收据内容实施检索操作；例如，当From字段属于上述的暴露字段时，该From字段以明文形式存储后，可以用于统计某一账户所发起的交易量等。
上述暴露标识符plain对应于收据数据中的所有字段；而在其他实施例中，也可以具体指明需要明文存储的字段。比如，通过暴露标识符对From字段进行标注时，只需要针对该From字段进行判断：当该From字段为上述的暴露字段时，在交易发起方属于预设用户类型的情况下，对于智能合约的代码被执行后产生的收据数据，可以将From字段对应的收据内容以明文形式存储，而其他收据内容均以密文形式存储。
需要指出的是：在上述的代码示例2及其相关实施例中，由暴露标识符“plain”所标明的字段(所有字段或From字段)为合约级字段，使得第一区块链节点在存储收据数据时，如果交易发起方属于预设用户类型且该From字段为暴露字段，那么第一区块链节点会将收据数据中对应于该合约级字段的所有收据内容以明文形式存储。尤其是，当智能合约的代码中包含多个事件时，合约级字段可以适用于智能合约中的所有事件，那么以From字段为例：当交易发起方属于预设用户类型且From字段为交易类型对应的暴露字段时，对于多个事件分别的产生各自对应的Logs字段，每一Logs字段所含的From字段均会采用明文形式进行存储，而无需针对每一事件分别添加暴露标识符。
除了合约级字段之外，暴露标识符标明的字段可以包括：对应于智能合约中定义的至少一个事件的事件级字段，使得第一区块链节点在存储收据数据时，如果交易发起方属于预设用户类型且事件级字段属于交易类型对应的暴露字段，可以确定出收据数据中对应于该至少一个事件的收据内容，并将确定出的收据内容中对应于上述事件级字段的部分以明文形式存储。尤其是，当智能合约中包含多个事件时，可以针对至少一部分事件设定上述的事件级字段，使得这部分事件对应的收据内容中对应于事件级字段的部分以明文形式存储，而这部分事件对应的收据内容中的剩余部分、其余事件对应的收 据内容等均以密文形式存储。以From字段为例，在上述的代码示例5中，通过在事件currentPrice对应的事件函数“event currentPrice(int price)”中添加From字段对应的字符from，并且该字符from所采用的暴露标识符区别于前述的plain，而是通过引号对该字符from进行修饰，则代码示例5中的引号相当于前述的暴露标识符，使得From字段被标记为事件级字段，因而当交易发起方属于预设用户类型且From字段属于交易类型对应的暴露字段时，在该事件对应产生的Logs字段中，From字段将以明文形式进行存储。除了上述事件currentPrice之外，如果智能合约的代码还包含另一事件，那么上述的事件级字段不会影响该另一事件、该另一事件对应的收据内容将以密文形式进行存储。而在上述的代码示例6中，通过在事件currentPrice对应的事件函数“event currentPrice(int price)”之前添加暴露标识符“plain”，使得事件级字段包括该事件currentPrice对应的日志Logs中的所有字段，譬如前述的From字段、To字段、Topic字段、Log Data字段等，当交易发起方属于预设用户类型时，可以根据交易类型确定出这些字段中的暴露字段，并将确定出的暴露字段以明文形式存储。
在图3所示实施例的基础上，本说明书可以进一步兼顾识别交易发起方的用户类型和智能合约所含的事件函数，从而同时根据暴露标识符、交易发起方的用户类型和智能合约所含的特殊事件函数，确定对收据数据的存储方式。因此，上述的步骤308可以改进为：第一区块链节点存储所述收据数据，以在交易发起方属于预设用户类型时，使对应于所述特殊事件函数的日志中的至少一部分收据内容以明文形式存储、所述收据数据的其余内容以密文形式存储，所述至少一部分收据内容匹配于所述暴露标识符标明的对象。
前述的代码示例可以基于交易发起方的用户类型和智能合约所含的特殊事件函数实现改进。在上述的代码示例2中，通过在智能合约的代码最前方添加暴露标识符plain，使得智能合约的代码被执行后，产生的收据数据中的所有字段均允许以明文形式进行存储。具体的，当交易发起方属于预设用户类型时，对于收据数据中由特殊事件函数产生的日志，允许该日志对应的所有收据内容以明文形式进行存储。
当然，在其他实施例中，也可以具体指明需要明文存储的字段。比如，通过暴露标识符对From字段进行标注时，可使得智能合约的代码被执行后，当交易发起方属于预设用户类型时，对于收据数据中由特殊事件函数产生的日志，允许From字段对应的收据内容以明文形式进行存储，那么后续可以针对该From字段中的收据内容实施检索操作，比如可以统计某一账户所发起的交易量等。
除了收据字段之外，暴露标识符还可以用于标明其他对象。例如，暴露标识符标明的对象可以包括状态变量。以状态变量“price”为例，在上述的代码示例3中，通过在状态变量“price”的类型int之前添加暴露标识符“plain”(或者，可以将暴露标识符plain置于类型int之后)，使得智能合约的代码被执行后，当交易发起方属于预设用户类型时，对于收据数据中由特殊事件函数产生的日志，允许与状态变量“price”相关的收据内容以明文形式进行存储(前提是交易发起方属于预设用户类型)，那么后续可以针对与状态变量“price”相关的收据内容实施检索操作。
由于暴露标识符为智能合约的编程语言中所定义的全局性标识，因而只要在智能合约中写入暴露标识符后，就难以修改该暴露标识符所标明的对象。而用户类型则取决于交易发起方、与编程语言无关，使得不同交易发起方即便调用同一智能合约时，对收据数据的存储方式(密文或明文)也可能存在不同。同时，特殊事件函数的定义并不一定基于编程语言实现，比如在基于特殊事件函数列表等方式记录特殊事件函数时，即便智能合约中包含的某一事件函数原本属于特殊事件函数，也可以通过对特殊事件函数列表进行更改的方式，将原有的特殊事件函数更新为普通事件函数，从而避免该事件函数产生的日志以明文形式存储，或者将原有的普通事件函数更新为特殊事件函数，使得该事件函数产生的日志中的至少一部分内容以明文形式存储。因此，通过由不同用户对智能合约进行调用，或者调整智能合约所含事件函数的类型，可以跳脱暴露标识符的限制，调整需要明文或密文存储的收据内容。
以上述的代码示例2为例：假定事件currentPrice原本并未记录于特殊事件函数列表中，即事件currentPrice对应于普通事件函数，那么即便在智能合约的代码中添加了暴露标识符plain且交易发起方属于预设用户类型，事件currentPrice产生的日志中的各个字段仍以密文形式存储。但是，如果将事件currentPrice添加至特殊事件函数列表中，那么代码示例2不需要调整的情况下，当交易发起方属于预设用户类型时，可使事件currentPrice对应的日志中的各个字段以明文形式存储。
以上述的代码示例3为例：假定事件currentPrice原本并未记录于特殊事件函数列表中，即事件currentPrice对应于普通事件函数，那么即便在智能合约的代码中添加了暴露标识符plain且交易发起方属于预设用户类型，在事件currentPrice产生的日志中，状态变量price的取值仍以密文形式存储。但是，如果将事件currentPrice添加至特殊事件函数列表中，那么代码示例2不需要调整的情况下，当交易发起方属于预设用户类型时，可使事件currentPrice对应的日志中，状态变量price的取值以明文形式存储。
需要指出的是：在上述的代码示例2中，通过在代码最前方声明“plain”，该暴露标识符“plain”所标明的对象为收据数据中的所有字段，且这些字段均为合约级对象，使得第一区块链节点在存储收据数据时，收据数据中所有对应于该合约级对象的收据内容，均被允许以明文形式存储。当然，如果代码示例2中通过暴露标识符标注了From字段，那么该From字段为上述的合约级对象，使得第一区块链节点在存储收据数据时，收据数据中所有对应于该From字段的收据内容，均被允许以明文形式存储。类似地，在上述的代码示例3中，暴露标识符“plain”所标明的状态变量“price”同样为合约级对象，使得第一区块链节点在存储收据数据时，收据数据中所有对应于该合约级对象“price”的收据内容，均被允许以明文形式存储。
尤其是，当智能合约的代码中包含多个事件函数时，在多个事件函数分别产生的各自对应的Logs字段中，均可能存在合约级对象所对应的收据内容；进一步地，可以通过识别交易发起方所属的用户类型以及各个事件函数的类型为普通事件函数或特殊事件函数，从而在交易发起方属于预设用户类型的情况下，将所有特殊事件函数所产生的日志中对应于合约级对象的收据内容以明文形式存储。例如，智能合约可以包括下述的代码示例17：
plain Contract Example{
int price；
int price1；
event currentPrice1(int price)；
event currentPrice2(int price1)；
…
在上述的代码示例17中，与代码示例2相类似地，暴露标识符“plain”位于智能合约的代码最前方，使得收据数据中的所有字段均被标注为合约级对象；同时，智能合约中包含了事件currentPrice1和事件currentPrice2：假定事件currentPrice1对应于特殊事件函数列表中定义的特殊事件函数、事件currentPrice2对应于普通事件函数，那么在交易发起方属于预设用户类型的情况下，在事件currentPrice1和事件currentPrice2分别产生的日志Log1、Log2中，日志Log1包含的所有字段均以明文形式存储、日志Log2包含的所有字段均以密文形式存储。并且，如果通过对特殊事件函数列表进行更新后，将事件currentPrice2更新为对应于特殊事件函数，那么日志Log2包含的所有字段将均以明文形式存储，而无需对智能合约的代码做任何变动。当然，如果代码示例17中通 过暴露标识符标注了From字段，那么该From字段为上述的合约级对象，在交易发起方属于预设用户类型的情况下，使得事件currentPrice1为特殊事件函数、事件currentPrice2为普通事件函数时，日志Log1中的From字段以明文形式存储、其余字段以密文形式存储，而日志Log2包含的所有字段均以密文形式存储；以及，当事件currentPrice2更新为特殊事件函数，那么日志Log2中的From字段以明文形式存储、其余字段以密文形式存储。
对于上述的合约级对象而言，可以通过前述的类型标识符来标明智能合约所含的事件函数是否为特殊事件函数。例如，可以将上述的代码示例17调整为下述的代码示例18：
plain Contract Example{
int price；
int price1；
event currentPrice1 expose(int price)；
event currentPrice2(int price1)；
…
在上述的代码示例18中，与代码示例2相类似地，合约级对象包括收据数据中的所有字段；同时，智能合约中包含了事件currentPrice1和事件currentPrice2：由于事件currentPrice1在包含如前所述的类型标识符expose，使得该事件currentPrice1被标注为对应于特殊事件函数，而事件currentPrice2并未包含类型标识符expose，使得事件currentPrice2被标注为对应于普通事件函数，那么在交易发起方属于预设用户类型的情况下，在事件currentPrice1和事件currentPrice2分别产生的日志Log1、Log2中，日志Log1包含的所有字段以明文形式存储、日志Log2包含的所有字段以密文形式存储。
虽然类型标识符与暴露标识符相类似的，都是智能合约的编程语言中所定义的全局性标识，但是暴露标识符作用于合约级对象、类型标识符作用于事件函数，使得通过将暴露标识符与类型标识符配合使用，仅需单次添加暴露标识符即可设定形成上述的合约级对象，并且进而可以灵活地标注希望对合约级对象进行明文存储的事件函数，尤其是当智能合约中包含的事件函数的数量较多、事件函数中涉及的对象(如字段或状态变量)的数量较多时，无需针对每一事件函数所涉及的每一对象分别实施设定操作，可以简化代码逻辑、防止错标或漏标。
上述实施例中的合约级对象包括字段，比如From字段等。合约级对象还可以包括状态变量；例如，可以将上述的代码示例17调整为下述的代码示例19：
Contract Example{
plain int price；
int price1；
event currentPrice1(int price)；
event currentPrice2(int price)；
event currentPrice3(int price1)；
…
在上述的代码示例19中，事件currentPrice1和事件currentPrice2引用了状态变量price、事件currentPrice3引用了状态变量price1；由于在状态变量price的类型int之前添加了暴露标识符“plain”，可以将该状态变量price作为上述的合约级对象。相应的，在交易发起方属于预设用户类型的情况下，对于引用该合约级对象的事件函数，在特殊事件函数所产生的日志中，该合约级对象对应的收据内容以明文形式存储，而普通事件函数即便引用了该合约级对象，所产生的日志仍以密文形式存储。例如，结合区块链网络中记录的特殊事件函数列表：在交易发起方属于预设用户类型的情况下，当事件currentPrice1对应于特殊事件函数时，由于事件currentPrice1引用了作为合约级对象的状态变量price，因而在该事件currentPrice1产生的日志Logs中，与状态变量price相关的收据内容均以明文形式进行存储；当事件currentPrice2对应于普通事件函数时，虽然事件currentPrice2引用了作为合约级对象的状态变量price，但在该事件currentPrice2产生的日志Logs中，与状态变量price相关的收据内容均以密文形式进行存储；虽然事件currentPrice3对应于特殊事件函数，但是由于事件currentPrice3并未引用作为合约级对象的状态变量price，因而事件currentPrice3产生的日志Logs均以密文形式进行存储。
与前述实施例相类似的，对于状态变量类型的合约级对象，可以通过类型标识符来标注事件函数的类型。例如，可以将上述的代码示例19调整为下述的代码示例20：
Contract Example{
plain int price；
int price1；
event currentPrice1 expose(int price)；
event currentPrice2(int price)；
event currentPrice3 expose(int price1)；
…
在上述的代码实例20中，通过暴露标识符可以将状态变量price标注为合约级对象，而状态变量price1并非合约级对象；通过类型标识符expose标明的事件currentPrice1、事件currentPrice3均对应于特殊事件函数，而事件currentPrice2对应于普通事件函数。因此，在交易发起方属于预设用户类型的情况下，在该事件currentPrice1产生的日志Logs中，与状态变量price相关的收据内容均以明文形式进行存储；在该事件currentPrice2产生的日志Logs中，与状态变量price相关的收据内容均以密文形式进行存储；事件currentPrice3产生的日志Logs均以密文形式进行存储。
除了合约级对象之外，暴露标识符标明的对象可以包括：对应于智能合约中定义的至少一个事件的事件级对象，使得在交易发起方属于预设用户类型的情况下，第一区块链节点将特殊事件函数产生的收据内容中对应于该事件级对象的部分以明文形式存储。尤其是，当智能合约中包含多个事件时，可以针对至少一部分事件设定上述的事件级对象，使得这部分事件对应的收据内容以明文形式存储、其余事件对应的收据内容以密文形式存储。以From字段为例，可以将上述的代码示例18调整为下述的代码示例21：
Contract Example{
int price；
int price1；
event currentPrice1(“from”,int price)；
event currentPrice2(int price1)；
…
在上述的代码示例21中，事件currentPrice1虽然未添加暴露标识符“plain”，但是包含了内容“from”，该内容“from”对应于From字段，用于表明事件currentPrice1所产生日志中的From字段需要以明文形式存储，因而该内容“from”既属于上述的暴露标识符，又标明了需要明文存储的From字段。并且，由于内容“from”位于事件currentPrice1中，因而From字段为事件级对象，使得在交易发起方属于预设用户类型的情况下，当该事件currentPrice1对应于特殊事件函数时，在该事件currentPrice1对应 产生的日志Logs中，From字段将以明文形式进行存储、其他字段以密文形式存储。而对于代码示例21所含的另一事件currentPrice2，由于并未针对该事件currentPrice2添加暴露标识符，因而不论该事件currentPrice2对应于特殊事件函数或普通事件函数，所产生的日志Logs均以密文形式存储。
上述的关键词“from”指明了将From字段设定为事件级对象；对于事件级对象为字段类型的情况，也可以并不指明具体的字段。例如，可以将上述的代码示例18调整为下述的代码示例22：
Contract Example{
int price；
int price1；
plain event currentPrice1(int price,int price1)；
event currentPrice2(int price1)；
…
在上述的代码示例22中，通过在事件currentPrice1之前添加暴露标识符“plain”，可以将该事件currentPrice1所产生的日志中的所有字段均作为上述的事件级对象，譬如前述的From字段、To字段、Topic字段、Log Data字段等。那么，在交易发起方属于预设用户类型的情况下，当该事件currentPrice1对应于特殊事件函数时，相当于将该事件currentPrice1对应的所有收据内容(比如产生的日志)均以明文形式存储。
事件级对象还可以包括状态变量。从状态变量的维度而言，上述的代码示例22可以解释为：事件currentPrice1引用了状态变量price和price1、事件currentPrice2引用了状态变量price1；由于通过在事件currentPrice1之前添加暴露标识符“plain”，可以将该事件currentPrice1所引用的状态变量price和price1作为上述的事件级对象，使得在交易发起方属于预设用户类型的情况下，当该事件currentPrice1对应于特殊事件函数时，在该事件currentPrice1产生的日志Logs中，与状态变量price和price1相关的收据内容均以明文形式进行存储。而对于代码示例22所含的另一事件currentPrice2，由于并未针对该事件currentPrice2添加暴露标识符，因而即便交易发起方属于预设用户类型，不论该事件currentPrice2对应于特殊事件函数或普通事件函数，在该事件currentPrice2所产生的日志Logs中，与状态变量price1相关的收据内容均以密文形式存储。
当事件级对象包括状态变量时，还可以具体指示为事件所引用的一个或多个状 态变量。例如，可以将上述的代码示例18调整为下述的代码示例23：
Contract Example{
int price；
int price1
event currentPrice1(plain int price，int price1)；
event currentPrice2(int price)；
…
在上述的代码示例23中，在事件currentPrice1对应的事件函数中，包含添加在状态变量price的类型int之前的暴露标识符plain，使得该状态变量price被配置为事件级对象。由于暴露标识符plain位于事件currentPrice1对应的事件函数中，而事件currentPrice2对应的事件函数虽然引用了状态变量price但是并未标注暴露标识符plain，因而事件currentPrice2对应的事件函数与事件级对象无关。因此，在交易发起方属于预设用户类型的情况下，即便事件currentPrice1和事件currentPrice2均对应于特殊事件函数，也只有在事件currentPrice1产生的日志中，将作为事件级对象的状态变量price对应的收据内容以明文形式存储，而事件currentPrice2产生的日志均以密文形式存储。类似地，在交易发起方属于预设用户类型的情况下，虽然事件currentPrice1引用了状态变量price1，但是由于该状态变量price1并未被暴露标识符进行标注，因而该状态变量price1并不属于事件级对象，即便事件currentPrice1对应于特殊事件函数，但在事件currentPrice1产生的日志中，该状态变量price1对应的收据内容仍以密文形式存储。
需要指出的是：在上述的代码示例21～23对应的实施例中，即对于事件级对象而言，可以通过特殊事件函数列表或者类型标识符的方式识别智能合约所含的事件函数是否为特殊事件函数，此处不再一一赘述。
在图3所示实施例的基础上，本说明书可以进一步兼顾识别交易发起方的用户类型和收据数据中满足预设条件的收据内容，从而同时根据暴露标识符、交易发起方的用户类型和收据内容对预设条件的满足情况，确定对收据数据的存储方式。因此，上述的步骤308可以改进为：第一区块链节点存储所述收据数据，以在交易发起方属于预设用户类型时，使对应于所述暴露标识符标明的对象的收据内容中满足预设条件的部分以明文形式存储、所述收据数据的其余收据内容以密文形式存储。由于暴露标识符为智能合约的编程语言中所定义的全局性标识，因而只要在智能合约中写入暴露标识符后，就 难以修改该暴露标识符所标明的对象。而用户类型则取决于交易发起方、与编程语言无关，使得不同交易发起方即便调用同一智能合约时，对收据数据的存储方式(密文或明文)也可能存在不同。同时，预设条件并不一定在暴露标识符所处的智能合约中基于编程语言实现，因而通过由不同用户对智能合约进行调用，或者调整所采用的预设条件，可以跳脱暴露标识符的限制，调整需要明文或密文存储的收据内容。
前述的代码示例可以基于交易发起方的用户类型和收据内容对预设条件的满足情况实现改进。在上述的代码示例2中，通过在智能合约的代码最前方添加暴露标识符plain，使得智能合约的代码被执行后，可以在交易发起方属于预设用户类型的情况下，将产生的收据数据中满足预设条件的所有字段均以明文形式进行存储。
当然，在其他实施例中，也可以具体指明需要明文存储的字段。比如，通过暴露标识符对From字段进行标注时，可使得在交易发起方属于预设用户类型的情况下，如果产生的收据数据中的From字段对应的收据内容满足预设条件，该From字段对应的收据内容以明文形式进行存储，而后续可以针对该From字段中的收据内容实施检索操作，比如可以统计某一账户所发起的交易量等。
需要指出的是：在上述的代码示例2及其相关实施例中，由暴露标识符“plain”所标明的对象(所有字段或From字段)为合约级对象，使得第一区块链节点在存储收据数据时，收据数据中所有对应于该合约级对象“From字段”的收据内容，均被允许以明文形式存储(前提为交易发起方属于预设用户类型且相关收据内容满足预设条件)。尤其是，当智能合约的代码中包含多个事件时，合约级对象可以适用于智能合约中的所有事件，那么以From字段为例：在交易发起方属于预设用户类型的情况下，对于任一事件产生的日志Logs，如果该日志Logs所含的From字段满足预设条件，那么该From字段将以明文形式存储，而无需针对每一事件分别添加暴露标识符。
除了收据字段之外，暴露标识符还可以用于标明其他对象。例如，暴露标识符标明的对象可以包括状态变量，且该状态变量同样可以为合约级对象。以状态变量“price”为例，在上述的代码示例3中，通过在状态变量“price”的类型int之前添加暴露标识符“plain”(或者，可以将暴露标识符plain置于类型int之后)，可以将该状态变量price标记为合约级对象。相应的，在智能合约的代码被执行后产生的收据数据的各个字段(通常包括Topic字段、Output字段等)中，如果存在对应于状态变量price的收据内容(通常记载了状态变量price的取值)，可以在交易发起方属于预设用户类型时，将满足预设条件的收据内容以明文形式进行存储。由于状态变量“price”在代码 示例3中属于合约级对象，使得当智能合约的代码中包含多个事件时，合约级对象可以适用于智能合约中的所有事件，那么当多个事件分别产生各自对应的日志Logs时，每一日志Logs(如日志Logs中的Topic字段等)都可能产生与状态变量“price”相关的收据内容(取决于相关事件是否应用了该状态变量price)，可以分别与预设条件进行比较判断，以确定各个日志Logs中的price取值是否以明文形式存储，而无需在每一事件中分别针对状态变量“price”添加暴露标识符；类似地，Output字段也会包含与状态变量“price”相关的收据内容。对于不同收据字段所包含的与状态变量price相关的收据内容，可以采用相同或不同的预设条件进行判断以确定是否采用明文形式存储，这取决于对“预设条件”的配置规则。
当智能合约的代码中定义了多个状态变量时，上述的合约级对象可以包括其中的部分或全部状态变量。例如，在上述的代码示例4中，智能合约的代码中定义了“price”、“price1”等多个状态变量，而用户可以仅针对状态变量“price”添加暴露标识符plain，使得该状态变量“price”成为合约级对象，而状态变量“price1”则并未由暴露标识符进行标注。
除了合约级对象之外，暴露标识符标明的对象可以包括：对应于智能合约中定义的至少一个事件的事件级对象，使得在交易发起方属于预设用户类型的情况下，如果收据数据中对应于该至少一个事件的收据内容满足预设条件，则相应的收据内容以明文形式存储。尤其是，当智能合约中包含多个事件时，可以针对至少一部分事件设定上述的事件级对象，从而在交易发起方属于预设用户类型的情况下，使得这部分事件对应的收据内容在满足预设条件时以明文形式存储、其余事件对应的收据内容以密文形式存储。以From字段为例，在上述的代码示例5中，通过在事件currentPrice对应的事件函数“event currentPrice(int price)”中添加From字段对应的字符from，并且该字符from所采用的暴露标识符区别于前述的plain，而是通过引号对该字符from进行修饰，则代码示例5中的引号相当于前述的暴露标识符，使得From字段被标记为事件级对象，因而在交易发起方属于预设用户类型的情况下，如果该事件对应产生的日志Logs的From字段满足预设条件，则将From字段以明文形式进行存储。除了上述事件currentPrice之外，如果智能合约的代码还包含另一事件，那么上述的事件级对象不会影响该另一事件、该另一事件对应的收据内容将以密文形式进行存储，除非存在针对该另一事件添加的“from”且该另一事件产生的Logs中的From字段满足预设条件。而在上述的代码示例6中，通过在事件currentPrice对应的事件函数“event currentPrice(int price)”之前添加关键字“plain”，使得事件级对象包括该事件currentPrice对应的日志Logs中的所有字 段，譬如前述的From字段、To字段、Topic字段、Log Data字段等，可以将这些字段分别与预设条件进行比较，从而在交易发起方属于预设用户类型时，将满足预设条件的字段以明文形式存储。
事件级对象还可以包括状态变量。从状态变量的维度而言，上述的代码示例6可以解释为：事件currentPrice引用了状态变量“price”，通过在事件currentPrice之前添加暴露标识符“plain”，可以将该事件currentPrice所引用的状态变量price作为上述的事件级对象，并确定出该事件currentPrice产生的日志Logs中与状态变量price相关的收据内容，从而在交易发起方属于预设用户类型的情况下，使得确定出的收据内容在满足预设条件时以明文形式存储、在不满足预设条件时以密文形式存储。由于状态变量“price”在代码示例6中属于事件级对象，使得当智能合约的代码中还包含另一引用状态变量“price”的事件event1时，如果并未针对该事件event1添加任何级别的暴露标识符，那么即便该事件event1引用了状态变量“price”，该事件event1所产生的收据内容仍将以密文形式进行存储，而并非以明文形式存储。
当同一事件中引用了多个状态变量时，上述的事件级对象可以包括被引用的全部状态变量。例如，在上述的代码示例7中，事件currentPrice对应的事件函数“event currentPrice(int price,int price1)”引用了状态变量“price”和“price1”，而通过在该事件之前添加暴露标识符plain，使得被引用的状态变量“price”和“price1”均会受到影响，对于该事件产生的所有与状态变量“price”和“price1”相关的收据内容，在交易发起方属于预设用户类型的情况下，满足预设条件的均以明文形式存储、未满足条件的均以密文形式存储。但是，对于其他并未添加暴露标识符plain的事件，产生的收据内容均以密文形式进行存储。
当事件级对象包括状态变量时，还可以具体指示为事件所引用的一个或多个状态变量。以状态变量“price”为例，在上述的代码示例8中，事件currentPrice对应的事件函数“event currentPrice(int price)”引用了状态变量“price”，而通过在该状态变量“price”的类型int之前添加暴露标识符plain，使得该状态变量“price”被配置为事件级对象，并且该事件级对象仅适用于该事件currentPrice、不适用于智能合约包含的其他事件，即：在交易发起方属于预设用户类型的情况下，只有事件currentPrice产生的与状态变量“price”相关的收据内容，能够在满足预设条件时以明文形式进行存储，收据数据中的其他内容均以密文形式进行存储。
由于代码示例8中的事件currentPrice仅引用了状态变量“price”，使其实际效 果与上述的代码示例6中针对该事件添加暴露标识符、将该事件引用的状态变量“price”配置为事件级对象相似。而当事件同时应用多个状态变量时，可以更加清晰地体现出两者的不同，比如在上述的代码示例9中，事件currentPrice对应的事件函数“event currentPrice(int price,int price1)”同时引用了状态变量“price”和“price1”，而通过在状态变量“price”的类型int之前添加暴露标识符plain，可以将该状态变量“price”配置为事件级对象，而未添加暴露标识符plain的状态变量“price1”则并非事件级对象，使得在交易发起方属于预设用户类型的情况下，该事件currentPrice产生的与状态变量“price”相关的收据内容在满足预设条件时以明文形式进行存储、与状态变量“price1”相关的收据内容则必然以密文形式进行存储。
在图3所示实施例的基础上，本说明书可以进一步兼顾识别交易的交易类型和智能合约所含的事件函数，从而同时根据暴露标识符、对应于该交易类型的暴露字段和智能合约所含的特殊事件函数，确定对收据数据的存储方式。因此，上述的步骤308可以改进为：第一区块链节点存储所述收据数据，使对应于所述特殊事件函数的日志中的至少一部分收据内容以明文形式存储、所述收据数据的其余内容以密文形式存储，所述至少一部分收据内容包括由所述暴露标识符标明的暴露字段。
前述的代码示例可以基于交易的交易类型和智能合约所含的事件函数实现改进。在上述的代码示例2中，在智能合约的代码最前方添加暴露标识符plain，仅从编程语言的维度而言，该暴露标识符plain表明：使得智能合约的代码被执行后，产生的收据数据中的所有字段均允许以明文形式进行存储，那么后续可以针对这些字段中的收据内容实施检索操作，比如对于From字段而言，可以用于统计某一账户所发起的交易量等。
由于暴露标识符为智能合约的编程语言中所定义的全局性标识，因而只要在智能合约中写入暴露标识符后，就难以修改该暴露标识符所标明的字段。而交易类型与编程语言无关，可由用户根据实际需求进行选择；同时，特殊事件函数的定义也不一定基于编程语言实现，比如在基于特殊事件函数列表等方式记录特殊事件函数时，即便智能合约中包含的某一事件函数原本属于特殊事件函数，也可以通过对特殊事件函数列表进行更改的方式，将原有的特殊事件函数更新为普通事件函数，从而避免该事件函数产生的日志以明文形式存储，或者将原有的普通事件函数更新为特殊事件函数，使得该事件函数产生的日志中的至少一部分内容以明文形式存储。
以上述的代码示例2为例：假定事件currentPrice原本并未记录于特殊事件函数 列表中，即事件currentPrice对应于普通事件函数，那么即便在智能合约的代码中添加了暴露标识符plain，事件currentPrice产生的日志中的各个字段(包括暴露字段)仍以密文形式存储。但是，如果将事件currentPrice添加至特殊事件函数列表中，那么代码示例2不需要调整的情况下，即可使得事件currentPrice对应的日志中的暴露字段以明文形式存储；比如，当From字段和To字段为暴露字段时，事件currentPrice所产生日志中的From字段和To字段将以明文形式存储，而其余字段则以密文形式存储。
需要指出的是：在上述的代码示例2中，通过在代码最前方声明“plain”，该暴露标识符“plain”所标明的字段为收据数据中的所有字段，且这些字段均为合约级字段，使得第一区块链节点在存储收据数据时，收据数据中所有对应于该合约级字段的收据内容，均被允许以明文形式存储。当然，如果代码示例2中通过暴露标识符标注了譬如From字段，那么该From字段为上述的合约级字段，当该From字段进一步属于交易类型对应的暴露字段时，可使第一区块链节点在存储收据数据时，收据数据中所有对应于该From字段的收据内容，均被允许以明文形式存储。
当智能合约的代码中包含多个事件函数时，在多个事件函数分别产生的各自对应的Logs字段中，均可能存在属于合约级字段的暴露字段；进一步地，可以通过识别各个事件函数的类型为普通事件函数或特殊事件函数，从而将所有特殊事件函数所产生的日志中属于合约级字段的暴露字段以明文形式存储。例如，智能合约可以包括下述的代码示例24：
plain Contract Example{
int price；
int price1；
event currentPrice1(int price)；
event currentPrice2(int price1)；
…
在上述的代码示例24中，与代码示例2相类似地，暴露标识符“plain”位于智能合约的代码最前方，使得收据数据中的所有字段均被标注为合约级字段；同时，智能合约中包含了事件currentPrice1和事件currentPrice2：假定From字段为交易类型对应的暴露字段，并且事件currentPrice1对应于特殊事件函数列表中定义的特殊事件函数、事件currentPrice2对应于普通事件函数，那么在事件currentPrice1和事件currentPrice2分 别产生的日志Log1、Log2中，日志Log1包含的From字段以明文形式存储、日志Log2包含的From字段以密文形式存储；类似地，日志Log1中属于暴露字段的其他字段也以明文形式存储、非暴露字段以密文形式存储，而日志Log2的所有字段均以密文形式存储。并且，如果通过对特殊事件函数列表进行更新后，将事件currentPrice2更新为对应于特殊事件函数，那么日志Log2包含的属于暴露字段的所有字段将以明文形式存储，而无需对智能合约的代码做任何变动。
对于上述的合约级字段而言，可以通过前述的类型标识符来标明智能合约所含的事件函数是否为特殊事件函数。例如，可以将上述的代码示例24调整为下述的代码示例25：
plain Contract Example{
int price；
int price1；
event currentPrice1 expose(int price)；
event currentPrice2(int price1)；
…
在上述的代码示例25中，与代码示例2相类似地，合约级字段包括收据数据中的所有字段；同时，智能合约中包含了事件currentPrice1和事件currentPrice2：由于事件currentPrice1在包含如前所述的类型标识符expose，使得该事件currentPrice1被标注为对应于特殊事件函数，而事件currentPrice2并未包含类型标识符expose，使得事件currentPrice2被标注为对应于普通事件函数，那么在事件currentPrice1和事件currentPrice2分别产生的日志Log1、Log2中，日志Log1中对应于交易类型的所有暴露字段均以明文形式存储、日志Log2包含的所有字段均以密文形式存储。
虽然类型标识符与暴露标识符相类似的，都是智能合约的编程语言中所定义的全局性标识，但是暴露标识符作用于合约级字段、类型标识符作用于事件函数，使得通过将暴露标识符与类型标识符配合使用，仅需单次添加暴露标识符即可设定形成上述的合约级字段，并且进而可以灵活地标注希望对合约级字段进行明文存储的事件函数，尤其是当智能合约中包含的事件函数的数量较多、事件函数中涉及的字段的数量较多时，仅需添加类似于上述的“plain”即可，无需针对每一事件函数分别实施设定操作，可以简化代码逻辑、防止错标或漏标。
除了合约级字段之外，暴露标识符标明的字段可以包括：对应于智能合约中定义的至少一个事件的事件级字段，使得第一区块链节点在存储收据数据时，可以确定出所述至少一个事件对应的特殊事件函数产生的日志，并将确定出的日志中属于事件级字段的暴露字段以明文形式存储。尤其是，当智能合约中包含多个事件时，可以针对至少一部分事件设定上述的事件级字段，使得这部分事件对应的日志中属于事件级字段的暴露字段以明文形式存储，而这部分事件对应的日志中的其他字段、其余事件对应的收据内容均以密文形式存储。以From字段为例，可以将上述的代码示例25调整为下述的代码示例26：
Contract Example{
int price；
int price1；
event currentPrice1(“from”,int price)；
event currentPrice2(int price1)；
…
在上述的代码示例26中，事件currentPrice1虽然未添加暴露标识符“plain”，但是包含了内容“from”，该内容“from”对应于From字段，用于表明事件currentPrice1所产生日志中的From字段需要以明文形式存储，因而该内容“from”既属于上述的暴露标识符，又标明了需要明文存储的From字段。并且，由于内容“from”位于事件currentPrice1中，因而From字段为事件级字段，使得当From字段为交易类型对应的暴露字段且该事件currentPrice1对应于特殊事件函数时，在该事件currentPrice1对应产生的日志Logs中，From字段将以明文形式进行存储、其他字段以密文形式存储。而对于代码示例26所含的另一事件currentPrice2，由于并未针对该事件currentPrice2添加暴露标识符，因而不论该事件currentPrice2对应于特殊事件函数或普通事件函数，所产生的日志Logs均以密文形式存储。
上述的关键词“from”指明了将From字段设定为事件级字段；而在其他实施例中，也可以并不指明具体的字段。例如，可以将上述的代码示例25调整为下述的代码示例27：
Contract Example{
int price；
int price1；
plain event currentPrice1(int price)；
event currentPrice2(int price1)；
…
在上述的代码示例27中，通过在事件currentPrice1之前添加暴露标识符“plain”，可以将该事件currentPrice1所产生的日志中的所有字段均作为上述的事件级字段，譬如前述的From字段、To字段、Topic字段、Log Data字段等。那么，当该事件currentPrice1对应于特殊事件函数时，可以从该事件currentPrice1所产生日志中的确定出既属于上述的事件级字段又属于交易类型对应的暴露字段的日志字段，以采用明文形式存储；如果上述的From字段、To字段、Topic字段、Log Data字段等均为暴露字段，那么相当于将该事件currentPrice1对应的所有收据内容(比如产生的日志)均以明文形式存储。
在上述的代码示例26-27对应的实施例中，即对于事件级字段而言，可以通过特殊事件函数列表或者类型标识符的方式识别智能合约所含的事件函数是否为特殊事件函数，此处不再一一赘述。
在图3所示实施例的基础上，本说明书可以进一步兼顾识别交易的交易类型和收据数据中满足预设条件的收据内容，从而同时根据暴露标识符、对应于该交易类型的暴露字段和收据内容对预设条件的满足情况，确定对收据数据的存储方式。因此，上述的步骤308可以改进为：第一区块链节点存储所述收据数据，使所述收据数据中由所述暴露标识符标明且满足预设条件的暴露字段以明文形式存储、其余收据字段以密文形式存储。
前述的代码示例可以基于交易的交易类型和收据内容对预设条件的满足情况实现改进。在上述的代码示例2中，通过在智能合约的代码最前方添加暴露标识符plain，使得智能合约的代码被执行后，对于该智能合约所属交易的交易类型对应的暴露字段，产生的收据数据中对应于上述暴露字段且满足预设条件的收据内容均以明文形式进行存储。
当然，在其他实施例中，也可以具体指明需要明文存储的字段。比如，通过暴露标识符对From字段进行标注时，可以仅对该From字段进行判断：如果From字段为该智能合约所属交易的交易类型对应的暴露字段，那么在智能合约的代码被执行后，产生的收据数据中满足预设条件的From字段对应的收据内容以明文形式进行存储，而后 续可以针对上述明文存储的From字段中的收据内容实施检索操作，比如可以统计某一账户所发起的交易量等；而除了From字段之前的其他字段，则均以密文形式存储。
需要指出的是：在上述的代码示例2及其相关实施例中，由暴露标识符“plain”所标明的字段(所有字段或From字段)为合约级字段，使得第一区块链节点在存储收据数据时，如果该合约级字段为暴露字段，那么第一区块链节点会将收据数据中对应于该合约级字段且满足预设条件的所有收据内容以明文形式存储。尤其是，当智能合约的代码中包含多个事件时，合约级字段可以适用于智能合约中的所有事件，那么以From字段为例：当From字段为合约级字段以及交易类型对应的暴露字段时，对于多个事件分别的产生各自对应的Logs字段，每一Logs字段所含的From字段可以分别与预设条件进行比较，从而将满足该预设条件的From字段以明文形式进行存储，而无需针对每一事件分别添加暴露标识符。
除了合约级字段之外，暴露标识符标明的字段可以包括：对应于智能合约中定义的至少一个事件的事件级字段，使得第一区块链节点在存储收据数据时，如果事件级字段属于交易类型对应的暴露字段，可以确定出收据数据中对应于该至少一个事件的收据内容，并将确定出的收据内容中对应于上述事件级字段且满足预设条件的部分以明文形式存储。尤其是，当智能合约中包含多个事件时，可以针对至少一部分事件设定上述的事件级字段，使得这部分事件对应的收据内容中对应于事件级字段且满足预设条件的部分以明文形式存储，而这部分事件对应的收据内容中的剩余部分、其余事件对应的收据内容等均以密文形式存储。以From字段为例，在上述的代码示例5中，通过在事件currentPrice对应的事件函数“event currentPrice(int price)”中添加From字段对应的字符from，并且该字符from所采用的暴露标识符区别于前述的plain，而是通过引号对该字符from进行修饰，则代码示例5中的引号相当于前述的暴露标识符，将From字段配置为事件级字段，使得当From字段属于交易类型对应的暴露字段时，在该事件对应产生的Logs字段中，From字段可以在满足预设条件的情况下以明文形式进行存储，否则From字段仍将以密文形式存储。除了上述事件currentPrice之外，如果智能合约的代码还包含另一事件，那么上述的“from”不会影响该另一事件、该另一事件对应的收据内容将以密文形式进行存储，除非存在针对该另一事件而添加的“from”。而在上述的代码示例6中，通过在事件currentPrice对应的事件函数“event currentPrice(int price)”之前添加暴露标识符“plain”，而区别于代码示例5中添加的“from”，使得此处并未指明事件级字段为From字段，那么可以将事件currentPrice所产生的日志中的所有字段均作为上述的事件级字段，譬如前述的From字段、To字段、Topic字段、Log Data字段 等，这些字段被均用于与预设条件进行比较，使得满足该预设条件的字段以明文形式存储、未满足预设条件的字段以密文形式存储；如果前述的From字段、To字段、Topic字段、Log Data字段等均满足预设条件，那么这些字段均以明文形式存储，相当于将该事件currentPrice对应的所有收据内容均以明文形式存储。
在图3所示实施例的基础上，本说明书可以进一步兼顾识别智能合约所含的事件函数和收据数据中满足预设条件的收据内容，从而同时根据暴露标识符、智能合约所含的特殊事件函数和收据内容对预设条件的满足情况，确定对收据数据的存储方式。因此，上述的步骤308可以改进为：第一区块链节点存储所述收据数据，使对应于所述特殊事件函数的日志中的至少一部分收据内容以明文形式存储、所述收据数据的其余内容以密文形式存储，所述至少一部分收据内容匹配于所述暴露标识符标明的对象且满足预设条件。
前述的代码示例可以基于智能合约所含的事件函数和收据内容对预设条件的满足情况实现改进。在上述的代码示例2中，通过在智能合约的代码最前方添加暴露标识符plain，使得智能合约的代码被执行后，产生的收据数据中的所有字段均允许以明文形式进行存储。
当然，在其他实施例中，也可以具体指明需要明文存储的字段。比如，通过暴露标识符对From字段进行标注时，可使得智能合约的代码被执行后，产生的收据数据中的From字段对应的收据内容允许以明文形式进行存储(需要进一步结合事件函数和预设条件的维度来确定实际是否采用明文存储)，那么后续可以针对该From字段中的收据内容实施检索操作，比如可以统计某一账户所发起的交易量等。
除了收据字段之外，暴露标识符还可以用于标明其他对象。例如，暴露标识符标明的对象可以包括状态变量。以状态变量“price”为例，在上述的代码示例3中，通过在状态变量“price”的类型int之前添加暴露标识符“plain”(或者，可以将暴露标识符plain置于类型int之后)，使得智能合约的代码被执行后，在产生的收据数据的各个字段(通常包括Topic字段、Output字段等)中，与状态变量“price”相关的收据内容允许以明文形式进行存储(需要进一步结合事件函数和预设条件的维度来确定实际是否采用明文存储)，那么后续可以针对与状态变量“price”相关的收据内容实施检索操作。
区别于上述全局性的暴露标识符，特殊事件函数的定义并不一定基于编程语言实现，比如在基于特殊事件函数列表等方式记录特殊事件函数时，即便智能合约中包含 的某一事件函数原本属于特殊事件函数，也可以通过对特殊事件函数列表进行更改的方式，将原有的特殊事件函数更新为普通事件函数，从而避免该事件函数产生的日志以明文形式存储，或者将原有的普通事件函数更新为特殊事件函数，使得该事件函数产生的日志中的至少一部分内容以明文形式存储。
以上述的代码示例2为例：假定事件currentPrice原本并未记录于特殊事件函数列表中，即事件currentPrice对应于普通事件函数，那么即便在智能合约的代码中添加了暴露标识符plain，事件currentPrice产生的日志中的各个字段仍以密文形式存储。但是，如果将事件currentPrice添加至特殊事件函数列表中，那么代码示例2不需要调整的情况下，即可使得事件currentPrice对应的日志中的各个字段以明文形式存储(假定From字段的内容满足预设条件)。
以上述的代码示例3为例：假定事件currentPrice原本并未记录于特殊事件函数列表中，即事件currentPrice对应于普通事件函数，那么即便在智能合约的代码中添加了暴露标识符plain，在事件currentPrice产生的日志中，状态变量price的取值仍以密文形式存储。但是，如果将事件currentPrice添加至特殊事件函数列表中，那么代码示例3不需要调整的情况下，即可使得事件currentPrice对应的日志中，状态变量price的取值以明文形式存储(假定状态变量price的取值满足预设条件)。
需要指出的是：在上述的代码示例2中，通过在代码最前方声明“plain”，该暴露标识符“plain”所标明的对象为收据数据中的所有字段，且这些字段均为合约级对象，使得第一区块链节点在存储收据数据时，收据数据中所有对应于该合约级对象且满足预设条件的收据内容，均被允许以明文形式存储。当然，如果代码示例2中通过暴露标识符标注了From字段，那么该From字段为上述的合约级对象，使得第一区块链节点在存储收据数据时，收据数据中所有对应于该From字段且满足预设条件的收据内容，均被允许以明文形式存储。类似地，在上述的代码示例3中，暴露标识符“plain”所标明的状态变量“price”同样为合约级对象，使得第一区块链节点在存储收据数据时，收据数据中所有对应于该合约级对象“price”且满足预设条件的收据内容，均被允许以明文形式存储。
尤其是，当智能合约的代码中包含多个事件函数时，在多个事件函数分别产生的各自对应的Logs字段中，均可能存在合约级对象所对应的收据内容；进一步地，可以通过识别各个事件函数的类型为普通事件函数或特殊事件函数，从而将所有特殊事件函数所产生的日志中对应于合约级对象且满足预设条件的收据内容以明文形式存储。例 如，智能合约可以包括下述的代码示例28：
plain Contract Example{
int price；
int price1；
event currentPrice1(int price)；
event currentPrice2(int price1)；
…
在上述的代码示例28中，与代码示例2相类似地，暴露标识符“plain”位于智能合约的代码最前方，使得收据数据中的所有字段均被标注为合约级对象；同时，智能合约中包含了事件currentPrice1和事件currentPrice2：假定事件currentPrice1对应于特殊事件函数列表中定义的特殊事件函数、事件currentPrice2对应于普通事件函数，那么在事件currentPrice1和事件currentPrice2分别产生的日志Log1、Log2中，日志Log1中所有满足预设条件的字段均以明文形式存储，而不论日志Log2中的字段是否满足预设条件，日志Log2包含的字段均以密文形式存储。并且，如果通过对特殊事件函数列表进行更新后，将事件currentPrice2更新为对应于特殊事件函数，那么日志Log2中所有满足预设条件的字段均以明文形式存储，而无需对智能合约的代码做任何变动。当然，如果代码示例28中通过暴露标识符标注了From字段，那么该From字段为上述的合约级对象，使得事件currentPrice1为特殊事件函数、事件currentPrice2为普通事件函数时，日志Log1中的From字段在满足预设条件时以明文形式存储、在未满足预设条件时以密文形式存储，而日志Log1中的其余字段必然以密文形式存储，而日志Log2包含的所有字段均以密文形式存储；以及，当事件currentPrice2更新为特殊事件函数，那么日志Log2中的From字段在满足预设条件时以明文形式存储、否则以密文形式存储，且日志Log2中的其余字段均以密文形式存储。
对于上述的合约级对象而言，可以通过前述的类型标识符来标明智能合约所含的事件函数是否为特殊事件函数。例如，可以将上述的代码示例28调整为下述的代码示例29：
plain Contract Example{
int price；
int price1；
event currentPrice1 expose(int price)；
event currentPrice2(int price1)；
…
在上述的代码示例29中，与代码示例2相类似地，合约级对象包括收据数据中的所有字段；同时，智能合约中包含了事件currentPrice1和事件currentPrice2：由于事件currentPrice1在包含如前所述的类型标识符expose，使得该事件currentPrice1被标注为对应于特殊事件函数，而事件currentPrice2并未包含类型标识符expose，使得事件currentPrice2被标注为对应于普通事件函数，那么在事件currentPrice1和事件currentPrice2分别产生的日志Log1、Log2中，日志Log1中满足预设条件的所有字段均以明文形式存储，而不论日志Log2包含的字段是否满足预设条件，日志Log2包含的所有字段均以密文形式存储。
虽然类型标识符与暴露标识符相类似的，都是智能合约的编程语言中所定义的全局性标识，但是暴露标识符作用于合约级对象、类型标识符作用于事件函数，使得通过将暴露标识符与类型标识符配合使用，仅需单次添加暴露标识符即可设定形成上述的合约级对象，并且进而可以灵活地标注希望对合约级对象进行明文存储的事件函数，尤其是当智能合约中包含的事件函数的数量较多、事件函数中涉及的对象(如字段或状态变量)的数量较多时，无需针对每一事件函数所涉及的每一对象分别实施设定操作，可以简化代码逻辑、防止错标或漏标。
上述实施例中的合约级对象包括字段，比如From字段等。合约级对象还可以包括状态变量；例如，可以将上述的代码示例28调整为下述的代码示例30：
Contract Example{
plain int price；
int price1；
event currentPrice1(int price)；
event currentPrice2(int price)；
event currentPrice3(int price1)；
…
在上述的代码示例30中，事件currentPrice1和事件currentPrice2引用了状态变量price、事件currentPrice3引用了状态变量price1；由于在状态变量price的类型int之 前添加了暴露标识符“plain”，可以将该状态变量price作为上述的合约级对象。相应的，对于引用该合约级对象的事件函数，在特殊事件函数所产生的日志中，该合约级对象对应的收据内容在满足预设条件的情况下以明文形式存储，而普通事件函数即便引用了该合约级对象，所产生的日志仍以密文形式存储。例如，结合区块链网络中记录的特殊事件函数列表：当事件currentPrice1对应于特殊事件函数时，由于事件currentPrice1引用了作为合约级对象的状态变量price，因而在该事件currentPrice1产生的日志Logs中，与状态变量price相关的收据内容在满足预设条件的情况下以明文形式进行存储；当事件currentPrice2对应于普通事件函数时，虽然事件currentPrice2引用了作为合约级对象的状态变量price，但在该事件currentPrice2产生的日志Logs中，与状态变量price相关的收据内容不论是否满足预设条件，均以密文形式进行存储；虽然事件currentPrice3对应于特殊事件函数，但是由于事件currentPrice3并未引用作为合约级对象的状态变量price，因而事件currentPrice3产生的日志Logs不论是否满足预设条件，均以密文形式进行存储。
与前述实施例相类似的，对于状态变量类型的合约级对象，可以通过类型标识符来标注事件函数的类型。例如，可以将上述的代码示例30调整为下述的代码示例31：
Contract Example{
plain int price；
int price1；
event currentPrice1 expose(int price)；
event currentPrice2(int price)；
event currentPrice3 expose(int price1)；
…
在上述的代码实例31中，通过暴露标识符可以将状态变量price标注为合约级对象，而状态变量price1并非合约级对象；通过类型标识符expose标明的事件currentPrice1、事件currentPrice3均对应于特殊事件函数，而事件currentPrice2对应于普通事件函数。因此，在该事件currentPrice1产生的日志Logs中，与状态变量price相关的收据内容在满足预设条件的情况下以明文形式进行存储；在该事件currentPrice2产生的日志Logs中，与状态变量price相关的收据内容不论是否满足预设条件，均以密文形式进行存储；事件currentPrice3产生的日志Logs不论是否满足预设条件，均以密文形 式进行存储。
除了合约级对象之外，暴露标识符标明的对象可以包括：对应于智能合约中定义的至少一个事件的事件级对象，使得第一区块链节点在存储收据数据时，将特殊事件函数产生的收据内容中对应于该事件级对象的部分以明文形式存储。尤其是，当智能合约中包含多个事件时，可以针对至少一部分事件设定上述的事件级对象，使得这部分事件产生的收据内容中对应于该事件级对象的部分在满足预设条件的情况下以明文形式存储，而这部分事件产生的其他收据内容和其余事件产生的所有收据内容均以密文形式存储。以From字段为例，可以将上述的代码示例29调整为下述的代码示例32：
Contract Example{
int price；
int price1；
event currentPrice1(“from”,int price)；
event currentPrice2(int price1)；
…
在上述的代码示例32中，事件currentPrice1虽然未添加暴露标识符“plain”，但是包含了内容“from”，该内容“from”对应于From字段，用于表明事件currentPrice1所产生日志中的From字段需要以明文形式存储，因而该内容“from”既属于上述的暴露标识符，又标明了需要明文存储的From字段。并且，由于内容“from”位于事件currentPrice1中，因而From字段为事件级对象，使得当该事件currentPrice1对应于特殊事件函数时，在该事件currentPrice1对应产生的日志Logs中，From字段在满足预设条件的情况下以明文形式进行存储、其他字段以密文形式存储。而对于代码示例32所含的另一事件currentPrice2，由于并未针对该事件currentPrice2添加暴露标识符，因而不论该事件currentPrice2对应于特殊事件函数或普通事件函数，所产生的日志Logs均以密文形式存储。
上述的关键词“from”指明了将From字段设定为事件级对象；对于事件级对象为字段类型的情况，也可以并不指明具体的字段。例如，可以将上述的代码示例29调整为下述的代码示例33：
Contract Example{
int price；
int price1；
plain event currentPrice1(int price,int price1)；
event currentPrice2(int price1)；
…
在上述的代码示例33中，通过在事件currentPrice1之前添加暴露标识符“plain”，可以将该事件currentPrice1所产生的日志中的所有字段均作为上述的事件级对象，譬如前述的From字段、To字段、Topic字段、Log Data字段等。那么，当该事件currentPrice1对应于特殊事件函数时，相当于该事件currentPrice1对应的所有收据内容(比如产生的日志)在满足预设条件的情况下均以明文形式存储。
事件级对象还可以包括状态变量。从状态变量的维度而言，上述的代码示例33可以解释为：事件currentPrice1引用了状态变量price和price1、事件currentPrice2引用了状态变量price1；由于通过在事件currentPrice1之前添加暴露标识符“plain”，可以将该事件currentPrice1所引用的状态变量price和price1作为上述的事件级对象，使得当该事件currentPrice1对应于特殊事件函数时，在该事件currentPrice1产生的日志Logs中，与状态变量price和price1相关的收据内容在满足预设条件的情况下以明文形式进行存储。而对于代码示例33所含的另一事件currentPrice2，由于并未针对该事件currentPrice2添加暴露标识符，因而不论该事件currentPrice2对应于特殊事件函数或普通事件函数，在该事件currentPrice2所产生的日志Logs中，与状态变量price1相关的收据内容均以密文形式存储。
当事件级对象包括状态变量时，还可以具体指示为事件所引用的一个或多个状态变量。例如，可以将上述的代码示例29调整为下述的代码示例34：
Contract Example{
int price；
int price1
event currentPrice1(plain int price，int price1)；
event currentPrice2(int price)；
…
在上述的代码示例34中，在事件currentPrice1对应的事件函数中，包含添加在 状态变量price的类型int之前的暴露标识符plain，使得该状态变量price被配置为事件级对象，该事件级对象仅适用于该事件currentPrice1。由于暴露标识符plain位于事件currentPrice1对应的事件函数中，而事件currentPrice2对应的事件函数虽然引用了状态变量price但是并未标注暴露标识符plain，因而事件currentPrice2对应的事件函数与事件级对象无关。因此，即便事件currentPrice1和事件currentPrice2均对应于特殊事件函数，也只有在事件currentPrice1产生的日志中，将作为事件级对象的状态变量price对应的收据内容在满足预设条件的情况下以明文形式存储，而事件currentPrice2产生的日志均以密文形式存储。类似地，虽然事件currentPrice1引用了状态变量price1，但是由于该状态变量price1并未被暴露标识符进行标注，因而该状态变量price1并不属于事件级对象，即便事件currentPrice1对应于特殊事件函数，但在事件currentPrice1产生的日志中，该状态变量price1对应的收据内容仍以密文形式存储。
需要指出的是：在上述的代码示例32～34对应的实施例中，即对于事件级对象而言，可以通过特殊事件函数列表或者类型标识符的方式识别智能合约所含的事件函数是否为特殊事件函数，此处不再一一赘述。
在图3所示实施例的基础上，本说明书可以进一步兼顾识别交易发起方的用户类型、交易的交易类型和智能合约所含的事件函数，从而同时根据暴露标识符、交易发起方的用户类型、对应于该交易类型的暴露字段和智能合约所含的特殊事件函数，确定对收据数据的存储方式。因此，上述的步骤308可以改进为：第一区块链节点存储所述收据数据，以在交易发起方属于预设用户类型时，使对应于所述特殊事件函数的日志中的至少一部分收据内容以明文形式存储、所述收据数据的其余内容以密文形式存储，所述至少一部分收据内容匹配于所述暴露标识符标明的暴露字段。
前述的代码示例可以基于交易发起方的用户类型、对应于该交易类型的暴露字段和智能合约所含的特殊事件函数实现改进。例如，在上述的代码示例2中，在智能合约的代码最前方添加暴露标识符plain，使得智能合约的代码被执行后，当交易发起方属于预设用户类型时，对于收据数据中由特殊事件函数产生的日志，允许该智能合约所属交易的交易类型对应的暴露字段对应的收据内容以明文形式进行存储，比如当日志中的From字段属于暴露字段、To字段并不属于暴露字段时，可以将收据数据中所有日志的From字段以明文形式存储、To字段以密文形式存储，那么后续可以针对该From字段中的收据内容实施检索操作，比如可以统计某一账户所发起的交易量等。
由于暴露标识符为智能合约的编程语言中所定义的全局性标识，因而只要在智 能合约中写入暴露标识符后，就难以修改该暴露标识符所标明的字段。而用户类型则取决于交易发起方、与编程语言无关，使得不同交易发起方即便调用同一智能合约时，对收据数据的存储方式(密文或明文)也可能存在不同。交易类型也可以由交易发起方根据需求而选取，以表明交易发起方的实际需求。同时，特殊事件函数的定义并不一定基于编程语言实现，比如在基于特殊事件函数列表等方式记录特殊事件函数时，即便智能合约中包含的某一事件函数原本属于特殊事件函数，也可以通过对特殊事件函数列表进行更改的方式，将原有的特殊事件函数更新为普通事件函数，从而避免该事件函数产生的日志以明文形式存储，或者将原有的普通事件函数更新为特殊事件函数，使得该事件函数产生的日志中的至少一部分内容以明文形式存储。因此，通过由不同用户对智能合约进行调用，或者发起不同类型的交易，或者调整智能合约所含事件函数的类型，可以跳脱暴露标识符的限制，调整需要明文或密文存储的收据内容。
以上述的代码示例2为例：假定事件currentPrice原本并未记录于特殊事件函数列表中，即事件currentPrice对应于普通事件函数，那么即便在智能合约的代码中添加了暴露标识符plain且交易发起方属于预设用户类型，事件currentPrice产生的日志中的各个字段(包括暴露字段)仍以密文形式存储。但是，如果将事件currentPrice添加至特殊事件函数列表中，那么代码示例2不需要调整的情况下，当交易发起方属于预设用户类型时，可使事件currentPrice对应的日志中的暴露字段以明文形式存储。
需要指出的是：在上述的代码示例2中，通过在代码最前方声明“plain”，该暴露标识符“plain”所标明的字段为收据数据中的所有字段，且这些字段均为合约级字段，使得在交易发起方属于预设用户类型且该合约级字段属于暴露字段时，使事件currentPrice产生的日志中对应于该合约级字段的收据内容，均被允许以明文形式存储。当然，如果代码示例2中通过暴露标识符标注了譬如From字段，那么该From字段为上述的合约级字段，当该From字段进一步属于交易类型对应的暴露字段时，可在交易发起方属于预设用户类型的情况下，使第一区块链节点在存储收据数据时，收据数据中所有对应于该From字段的收据内容，均被允许以明文形式存储。
尤其是，当智能合约的代码中包含多个事件函数时，在多个事件函数分别产生的各自对应的Logs字段中，均可能存在合约级字段所对应的收据内容；进一步地，可以通过识别交易发起方所属的用户类型、交易的交易类型对应的暴露字段以及各个事件函数的类型为普通事件函数或特殊事件函数，从而在交易发起方属于预设用户类型且合约级字段属于暴露字段的情况下，将所有特殊事件函数所产生的日志中对应于合约级字 段的收据内容以明文形式存储。例如，智能合约可以包括下述的代码示例35：
plain Contract Example{
int price；
int price1；
event currentPrice1(int price)；
event currentPrice2(int price1)；
…
在上述的代码示例35中，与代码示例2相类似地，暴露标识符“plain”位于智能合约的代码最前方，使得收据数据中的所有字段均被标注为合约级字段；同时，智能合约中包含了事件currentPrice1和事件currentPrice2：假定事件currentPrice1对应于特殊事件函数列表中定义的特殊事件函数、事件currentPrice2对应于普通事件函数，那么在交易发起方属于预设用户类型且From字段属于暴露字段的情况下，在事件currentPrice1和事件currentPrice2分别产生的日志Log1、Log2中，日志Log1包含的From字段以明文形式存储、日志Log2包含的From字段以密文形式存储；类似地，日志Log1中属于暴露字段的其他字段也以明文形式存储、非暴露字段以密文形式存储，而日志Log2的所有字段均以密文形式存储。并且，如果通过对特殊事件函数列表进行更新后，将事件currentPrice2更新为对应于特殊事件函数，那么日志Log2包含的属于暴露字段的所有字段将以明文形式存储，而无需对智能合约的代码做任何变动。
对于上述的合约级字段而言，可以通过前述的类型标识符来标明智能合约所含的事件函数是否为特殊事件函数。例如，可以将上述的代码示例35调整为下述的代码示例36：
plain Contract Example{
int price；
int price1；
event currentPrice1 expose(int price)；
event currentPrice2(int price1)；
…
在上述的代码示例36中，与代码示例2相类似地，合约级字段包括收据数据中 的所有字段；同时，智能合约中包含了事件currentPrice1和事件currentPrice2：由于事件currentPrice1在包含如前所述的类型标识符expose，使得该事件currentPrice1被标注为对应于特殊事件函数，而事件currentPrice2并未包含类型标识符expose，使得事件currentPrice2被标注为对应于普通事件函数，那么在交易发起方属于预设用户类型的情况下，在事件currentPrice1和事件currentPrice2分别产生的日志Log1、Log2中，日志Log1中对应于交易类型的所有暴露字段均以明文形式存储、日志Log2包含的所有字段均以密文形式存储。
除了合约级字段之外，暴露标识符标明的字段可以包括：对应于智能合约中定义的至少一个事件的事件级字段，使得在交易发起方属于预设用户类型且该事件级字段属于暴露字段的情况下，第一区块链节点将特殊事件函数产生的收据内容中对应于该事件级字段的部分以明文形式存储。尤其是，当智能合约中包含多个事件时，可以针对至少一部分事件设定上述的事件级字段，使得这部分事件产生的日志中对应于上述事件级字段的收据内容以明文形式存储，而这部分事件产生的日志中的其余收据内容、其余事件对应的收据内容均以密文形式存储。以From字段为例，可以将上述的代码示例36调整为下述的代码示例37：
Contract Example{
int price；
int price1；
event currentPrice1(“from”,int price)；
event currentPrice2(int price1)；
…
在上述的代码示例37中，事件currentPrice1虽然未添加暴露标识符“plain”，但是包含了内容“from”，该内容“from”对应于From字段，用于表明事件currentPrice1所产生日志中的From字段需要以明文形式存储，因而该内容“from”既属于上述的暴露标识符，又标明了需要明文存储的From字段。并且，由于内容“from”位于事件currentPrice1中，因而From字段为事件级字段，使得在交易发起方属于预设用户类型且From字段属于暴露字段的情况下，当该事件currentPrice1对应于特殊事件函数时，在该事件currentPrice1对应产生的日志Logs中，From字段将以明文形式进行存储、其他字段以密文形式存储。而对于代码示例37所含的另一事件currentPrice2，由于并未针对该事件currentPrice2添加暴露标识符，因而不论该事件currentPrice2对应于特殊事件 函数或普通事件函数，所产生的日志Logs均以密文形式存储。该代码示例37对应的实施例中，即对于事件级字段而言，可以通过特殊事件函数列表或者类型标识符的方式识别智能合约所含的事件函数是否为特殊事件函数，此处不再一一赘述。
在图3所示实施例的基础上，本说明书可以进一步兼顾识别交易发起方的用户类型、交易的交易类型和收据数据中满足预设条件的收据内容，从而同时根据暴露标识符、交易发起方的用户类型、对应于该交易类型的暴露字段和收据内容对预设条件的满足情况，确定对收据数据的存储方式。因此，上述的步骤308可以改进为：第一区块链节点存储所述收据数据，当交易发起方属于预设用户类型时，使所述收据数据中由所述暴露标识符标明且满足预设条件的暴露字段以明文形式存储、其余收据字段以密文形式存储。
前述的代码示例可以基于交易发起方的用户类型、对应于该交易类型的暴露字段和收据内容对预设条件的满足情况实现改进。在上述的代码示例2中，通过在智能合约的代码最前方添加暴露标识符plain，使得智能合约的代码被执行后，在交易发起方属于预设用户类型的情况下，对于该智能合约所属交易的交易类型对应的暴露字段，产生的收据数据中对应于上述暴露字段且满足预设条件的收据内容均以明文形式进行存储。
当然，在其他实施例中，也可以具体指明需要明文存储的字段。比如，通过暴露标识符对From字段进行标注时，可以仅对该From字段进行判断：如果交易发起方属于预设用户类型且From字段为该智能合约所属交易的交易类型对应的暴露字段，那么在智能合约的代码被执行后，产生的收据数据中的From字段在满足预设条件的情况下以明文形式进行存储，而后续可以针对上述From字段实施检索操作，比如可以统计某一账户所发起的交易量等；而除了From字段之前的其他字段，则均以密文形式存储。
需要指出的是：在上述的代码示例2及其相关实施例中，由暴露标识符“plain”所标明的字段(所有字段或From字段)为合约级字段，使得第一区块链节点在存储收据数据时，如果交易发起方属于预设用户类型且该合约级字段为暴露字段，那么第一区块链节点会将收据数据中对应于该合约级字段且满足预设条件的所有收据内容以明文形式存储。尤其是，当智能合约的代码中包含多个事件时，合约级字段可以适用于智能合约中的所有事件，那么以From字段为例：当交易发起方属于预设用户类型、From字段为合约级字段以及交易类型对应的暴露字段时，对于多个事件分别的产生各自对应的Logs字段，每一Logs字段所含的From字段均会采用明文形式进行存储，而无需针对每一事件分别添加暴露标识符。
除了合约级字段之外，暴露标识符标明的字段可以包括：对应于智能合约中定义的至少一个事件的事件级字段，使得第一区块链节点在存储收据数据时，如果交易发起方属于预设用户类型且事件级字段属于交易类型对应的暴露字段，可以确定出收据数据中对应于该至少一个事件的日志，并将确定出的日志中对应于上述事件级字段的收据内容与预设条件进行比较，从而将满足该预设条件的收据内容以明文形式存储。尤其是，当智能合约中包含多个事件时，可以针对至少一部分事件设定上述的事件级字段，使得这部分事件对应的收据内容中对应于事件级字段且满足预设条件的部分以明文形式存储，而这部分事件对应的收据内容中的剩余部分、其余事件对应的收据内容等均以密文形式存储。以From字段为例，在上述的代码示例5中，通过在事件currentPrice对应的事件函数“event currentPrice(int price)”中添加From字段对应的字符from，并且该字符from所采用的暴露标识符区别于前述的plain，而是通过引号对该字符from进行修饰，则代码示例5中的引号相当于前述的暴露标识符，将From字段配置为事件级字段，使得From字段被标记为事件级字段，因而当交易发起方属于预设用户类型且From字段属于交易类型对应的暴露字段时，在该事件对应产生的Logs字段中，From字段在满足预设条件时将以明文形式进行存储。除了上述事件currentPrice之外，如果智能合约的代码还包含另一事件，那么上述的“from”不会影响该另一事件、该另一事件对应的收据内容将以密文形式进行存储。而在上述的代码示例6中，通过在事件currentPrice对应的事件函数“event currentPrice(int price)”之前添加关键字“plain”，使得事件级字段包括该事件currentPrice对应的日志Logs中的所有字段，譬如前述的From字段、To字段、Topic字段、Log Data字段等，当交易发起方属于预设用户类型时，可以根据交易类型确定出这些字段中的暴露字段，并将确定出的暴露字段与预设条件进行比较，从而将满足预设条件的暴露字段以明文形式存储。因此，如果上述的From字段、To字段、Topic字段、Log Data字段等均满足预设条件时，相当于将事件currentPrice产生的所有收据内容均以明文形式存储。
在图3所示实施例的基础上，本说明书可以进一步兼顾识别交易的交易类型、智能合约所含的事件函数和收据数据中满足预设条件的收据内容，从而同时根据暴露标识符、对应于该交易类型的暴露字段、智能合约所含的特殊事件函数和收据内容对预设条件的满足情况，确定对收据数据的存储方式。因此，上述的步骤308可以改进为：第一区块链节点存储所述收据数据，使对应于所述特殊事件函数的日志中的至少一部分收据内容以明文形式存储、所述收据数据的其余内容以密文形式存储，所述至少一部分收据内容包括由所述暴露标识符标明且满足预设条件的暴露字段。在智能合约的代码中， 暴露标识符可以标明一个或多个字段，这些字段在收据数据中存在对应的收据内容。不同类型的交易往往存在不同的隐私保护需求，可以允许相应的暴露字段以明文形式存储。而特殊事件函数被执行后，收据数据中包含对应于特殊事件函数的日志，该日志实际为收据数据中的部分收据内容。同时，交易发起方可以根据实际需求，选择希望采用的预设条件，收据数据中可能存在至少一部分满足该预设条件的收据内容。因而本说明书中通过对暴露标识符、交易类型、特殊事件函数和预设条件进行综合考量，可以筛选出上述四部分收据内容的交叉内容，并针对该交叉内容实施明文存储，收据数据的其余内容均采用密文存储。
除了上述的预设条件之外，交易类型与编程语言无关，可由用户根据实际需求进行选择；同时，特殊事件函数的定义也不一定基于编程语言实现，比如在基于特殊事件函数列表等方式记录特殊事件函数时，即便智能合约中包含的某一事件函数原本属于特殊事件函数，也可以通过对特殊事件函数列表进行更改的方式，将原有的特殊事件函数更新为普通事件函数，从而避免该事件函数产生的日志以明文形式存储，或者将原有的普通事件函数更新为特殊事件函数，使得该事件函数产生的日志中的至少一部分内容以明文形式存储。
以上述的代码示例2为例：假定事件currentPrice原本并未记录于特殊事件函数列表中，即事件currentPrice对应于普通事件函数，那么即便在智能合约的代码中添加了暴露标识符plain且From字段属于暴露字段，事件currentPrice产生的日志中的各个字段(包括暴露字段)仍以密文形式存储。但是，如果将事件currentPrice添加至特殊事件函数列表中，那么代码示例2不需要调整的情况下，即可使得事件currentPrice对应的日志中的暴露字段以明文形式存储；比如，当From字段和To字段为暴露字段时，事件currentPrice所产生日志中的From字段和To字段将以明文形式存储，而其余字段则以密文形式存储。
需要指出的是：在上述的代码示例2中，通过在代码最前方声明“plain”，该暴露标识符“plain”所标明的字段为收据数据中的所有字段，且这些字段均为合约级字段，使得第一区块链节点在存储收据数据时，收据数据中所有对应于该合约级字段的收据内容，均被允许以明文形式存储。当然，如果代码示例2中通过暴露标识符标注了譬如From字段，那么该From字段为上述的合约级字段，当该From字段进一步属于交易类型对应的暴露字段时，可使第一区块链节点在存储收据数据时，收据数据中所有对应于该From字段且满足预设条件的收据内容，均被允许以明文形式存储。
当智能合约的代码中包含多个事件函数时，在多个事件函数分别产生的各自对应的Logs字段中，均可能存在属于合约级字段的暴露字段；进一步地，可以通过识别各个事件函数的类型为普通事件函数或特殊事件函数，从而将所有特殊事件函数所产生的日志中属于合约级字段的暴露字段以明文形式存储。例如，智能合约可以包括下述的代码示例38：
plain Contract Example{
int price；
int price1；
event currentPrice1(int price)；
event currentPrice2(int price1)；
…
在上述的代码示例38中，与代码示例2相类似地，暴露标识符“plain”位于智能合约的代码最前方，使得收据数据中的所有字段均被标注为合约级字段；同时，智能合约中包含了事件currentPrice1和事件currentPrice2：假定From字段为交易类型对应的暴露字段，并且事件currentPrice1对应于特殊事件函数列表中定义的特殊事件函数、事件currentPrice2对应于普通事件函数，那么在事件currentPrice1和事件currentPrice2分别产生的日志Log1、Log2中，日志Log1包含的From字段在满足预设条件时以明文形式存储、日志Log2包含的From字段以密文形式存储；类似地，日志Log1中属于暴露字段的其他字段也以明文形式存储、非暴露字段以密文形式存储，而日志Log2的所有字段均以密文形式存储。并且，如果通过对特殊事件函数列表进行更新后，将事件currentPrice2更新为对应于特殊事件函数，那么日志Log2包含的属于暴露字段且满足预设条件的所有字段将以明文形式存储，而无需对智能合约的代码做任何变动。
对于上述的合约级字段而言，可以通过前述的类型标识符来标明智能合约所含的事件函数是否为特殊事件函数。例如，可以将上述的代码示例38调整为下述的代码示例39：
plain Contract Example{
int price；
int price1；
event currentPrice1 expose(int price)；
event currentPrice2(int price1)；
…
在上述的代码示例39中，与代码示例2相类似地，合约级字段包括收据数据中的所有字段；同时，智能合约中包含了事件currentPrice1和事件currentPrice2：由于事件currentPrice1在包含如前所述的类型标识符expose，使得该事件currentPrice1被标注为对应于特殊事件函数，而事件currentPrice2并未包含类型标识符expose，使得事件currentPrice2被标注为对应于普通事件函数，那么在事件currentPrice1和事件currentPrice2分别产生的日志Log1、Log2中，日志Log1中对应于交易类型的所有暴露字段在满足预设条件的情况下均以明文形式存储、日志Log2包含的所有字段均必然以密文形式存储。
虽然类型标识符与暴露标识符相类似的，都是智能合约的编程语言中所定义的全局性标识，但是暴露标识符作用于合约级字段、类型标识符作用于事件函数，使得通过将暴露标识符与类型标识符配合使用，仅需单次添加暴露标识符即可设定形成上述的合约级字段，并且进而可以灵活地标注希望对合约级字段进行明文存储的事件函数，尤其是当智能合约中包含的事件函数的数量较多、事件函数中涉及的字段的数量较多时，仅需添加类似于上述的“plain”即可，无需针对每一事件函数分别实施设定操作，可以简化代码逻辑、防止错标或漏标。
除了合约级字段之外，暴露标识符标明的字段可以包括：对应于智能合约中定义的至少一个事件的事件级字段，使得第一区块链节点在存储收据数据时，可以确定出所述至少一个事件对应的特殊事件函数产生的日志，并将确定出的日志中属于事件级字段且满足预设条件的暴露字段以明文形式存储。尤其是，当智能合约中包含多个事件时，可以针对至少一部分事件设定上述的事件级字段，使得这部分事件对应的日志中属于事件级字段且满足预设条件的暴露字段以明文形式存储，而这部分事件对应的日志中的其他字段、其余事件对应的收据内容均以密文形式存储。以From字段为例，可以将上述的代码示例39调整为下述的代码示例40：
Contract Example{
int price；
int price1；
event currentPrice1(“from”,int price)；
event currentPrice2(int price1)；
…
在上述的代码示例40中，事件currentPrice1虽然未添加暴露标识符“plain”，但是包含了内容“from”，该内容“from”对应于From字段，用于表明事件currentPrice1所产生日志中的From字段需要以明文形式存储，因而该内容“from”既属于上述的暴露标识符，又标明了需要明文存储的From字段。并且，由于内容“from”位于事件currentPrice1中，因而From字段为事件级字段，使得当From字段为交易类型对应的暴露字段且该事件currentPrice1对应于特殊事件函数时，在该事件currentPrice1对应产生的日志Logs中，From字段在满足预设条件的情况下将以明文形式进行存储、在未满足预设条件的情况下以密文形式进行存储，而其他字段必然以密文形式存储。而对于代码示例40所含的另一事件currentPrice2，由于并未针对该事件currentPrice2添加暴露标识符，因而不论该事件currentPrice2对应于特殊事件函数或普通事件函数，所产生的日志Logs均以密文形式存储。
上述的关键词“from”指明了将From字段设定为事件级字段；而在其他实施例中，也可以并不指明具体的字段。例如，可以将上述的代码示例39调整为下述的代码示例41：
Contract Example{
int price；
int price1；
plain event currentPrice1(int price)；
event currentPrice2(int price1)；
…
在上述的代码示例41中，通过在事件currentPrice1之前添加暴露标识符“plain”，可以将该事件currentPrice1所产生的日志中的所有字段均作为上述的事件级字段，譬如前述的From字段、To字段、Topic字段、Log Data字段等。那么，当该事件currentPrice1对应于特殊事件函数时，可以从该事件currentPrice1所产生日志中的确定出既属于上述的事件级字段又属于交易类型对应的暴露字段的日志字段，并在确定出的日志字段满足预设条件时采用明文形式存储；如果上述的From字段、To字段、Topic字段、Log Data字段等均为暴露字段且满足预设条件，那么相当于将该事件currentPrice1对应的所有收 据内容(比如产生的日志)均以明文形式存储。
在上述的代码示例40-41对应的实施例中，即对于事件级字段而言，可以通过特殊事件函数列表或者类型标识符的方式识别智能合约所含的事件函数是否为特殊事件函数，此处不再一一赘述。
在图3所示实施例的基础上，本说明书可以进一步兼顾识别交易发起方的用户类型、智能合约所含的事件函数和收据数据中满足预设条件的收据内容，从而同时根据暴露标识符、交易发起方的用户类型、智能合约所含的特殊事件函数和收据内容对预设条件的满足情况，确定对收据数据的存储方式。因此，上述的步骤308可以改进为：第一区块链节点存储所述收据数据，以在交易发起方属于预设用户类型时，使对应于所述特殊事件函数的日志中的至少一部分收据内容以明文形式存储、所述收据数据的其余内容以密文形式存储，所述至少一部分收据内容匹配于所述暴露标识符标明的字段且满足预设条件。
在图3所示实施例的基础上，本说明书可以进一步兼顾识别交易发起方的用户类型、交易的交易类型、智能合约所含的事件函数和收据数据中满足预设条件的收据内容，从而同时根据暴露标识符、交易发起方的用户类型、对应于该交易类型的暴露字段、智能合约所含的特殊事件函数和收据内容对预设条件的满足情况，确定对收据数据的存储方式。因此，上述的步骤308可以改进为：第一区块链节点存储所述收据数据，以在交易发起方属于预设用户类型时，使对应于所述特殊事件函数的日志中的至少一部分收据内容以明文形式存储、所述收据数据的其余内容以密文形式存储，所述至少一部分收据内容匹配于所述暴露标识符标明的暴露字段且满足预设条件。本说明书通过综合考虑交易发起方所属的用户类型、交易类型对应的暴露字段、暴露标识符标明的字段、特殊事件函数产生的日志和收据内容对预设条件的满足情况，可以准确选取用于明文存储的收据内容，即同时满足“交易发起方属于预设用户类型”、“属于交易类型对应的暴露字段”、“匹配于暴露标识符标明的字段”、“属于特殊事件函数产生的日志”和“满足预设条件”的收据内容，从而在满足上述功能扩展需求的同时，确保绝大部分的用户隐私能够得到保护。尤其是，当第一区块链节点是根据区块链网络上记载的信息(如特殊事件函数列表)来识别特殊事件函数时，可以在智能合约已经创建之后，通过对“特殊事件函数”进行更新，以调整收据数据的存储方式，比如将原本明文存储的收据内容改为密文存储，或者将原本密文存储的收据内容改为明文存储。
前述的代码示例可以基于交易发起方的用户类型、对应于该交易类型的暴露字 段、智能合约所含的特殊事件函数和收据内容对预设条件的满足情况实现改进。例如，在上述的代码示例2中，在智能合约的代码最前方添加暴露标识符plain，使得智能合约的代码被执行后，当交易发起方属于预设用户类型时，对于收据数据中由特殊事件函数产生的日志，允许该智能合约所属交易的交易类型对应的暴露字段且满足预设条件的收据内容以明文形式进行存储，比如当日志中的From字段属于暴露字段、To字段并不属于暴露字段时，可以将收据数据中所有日志的From字段在满足预设条件时以明文形式存储、To字段以密文形式存储，那么后续可以针对该From字段中的收据内容实施检索操作，比如可以统计某一账户所发起的交易量等。
由于暴露标识符为智能合约的编程语言中所定义的全局性标识，因而只要在智能合约中写入暴露标识符后，就难以修改该暴露标识符所标明的字段。而用户类型则取决于交易发起方、与编程语言无关，使得不同交易发起方即便调用同一智能合约时，对收据数据的存储方式(密文或明文)也可能存在不同。交易类型也可以由交易发起方根据需求而选取，以表明交易发起方的实际需求。预设条件可以由交易发起方根据实际需求而选取，与编程语言无关。同时，特殊事件函数的定义并不一定基于编程语言实现，比如在基于特殊事件函数列表等方式记录特殊事件函数时，即便智能合约中包含的某一事件函数原本属于特殊事件函数，也可以通过对特殊事件函数列表进行更改的方式，将原有的特殊事件函数更新为普通事件函数，从而避免该事件函数产生的日志以明文形式存储，或者将原有的普通事件函数更新为特殊事件函数，使得该事件函数产生的日志中的至少一部分内容以明文形式存储。因此，通过由不同用户对智能合约进行调用，或者发起不同类型的交易，或者调整智能合约所含事件函数的类型，或者选用不同的预设条件，可以跳脱暴露标识符的限制，调整需要明文或密文存储的收据内容。
以上述的代码示例2为例：假定事件currentPrice原本并未记录于特殊事件函数列表中，即事件currentPrice对应于普通事件函数，那么即便在智能合约的代码中添加了暴露标识符plain且交易发起方属于预设用户类型，事件currentPrice产生的日志中的各个字段(包括暴露字段)仍以密文形式存储。但是，如果将事件currentPrice添加至特殊事件函数列表中，那么代码示例2不需要调整的情况下，当交易发起方属于预设用户类型时，可使事件currentPrice对应的日志中的暴露字段在满足预设条件的情况下以明文形式存储。
需要指出的是：在上述的代码示例2中，通过在代码最前方声明“plain”，该暴露标识符“plain”所标明的字段为收据数据中的所有字段，且这些字段均为合约级字 段，使得在交易发起方属于预设用户类型且该合约级字段属于暴露字段时，使事件currentPrice产生的日志中对应于该合约级字段且满足预设条件的收据内容均被允许以明文形式存储。当然，如果代码示例2中通过暴露标识符标注了譬如From字段，那么该From字段为上述的合约级字段，当该From字段进一步属于交易类型对应的暴露字段时，可在交易发起方属于预设用户类型的情况下，使第一区块链节点在存储收据数据时，收据数据中所有对应于该From字段且满足预设条件的收据内容，均被允许以明文形式存储。
尤其是，当智能合约的代码中包含多个事件函数时，在多个事件函数分别产生的各自对应的Logs字段中，均可能存在合约级字段所对应的收据内容；进一步地，可以通过识别交易发起方所属的用户类型、交易的交易类型对应的暴露字段、各个事件函数的类型为普通事件函数或特殊事件函数以及收据内容对预设条件的满足情况，从而在交易发起方属于预设用户类型且合约级字段属于暴露字段的情况下，将所有特殊事件函数所产生的日志中对应于合约级字段且满足预设条件的收据内容以明文形式存储。例如，智能合约可以包括下述的代码示例42：
plain Contract Example{
int price；
int price1；
event currentPrice1(int price)；
event currentPrice2(int price1)；
…
在上述的代码示例42中，与代码示例2相类似地，暴露标识符“plain”位于智能合约的代码最前方，使得收据数据中的所有字段均被标注为合约级字段；同时，智能合约中包含了事件currentPrice1和事件currentPrice2：假定事件currentPrice1对应于特殊事件函数列表中定义的特殊事件函数、事件currentPrice2对应于普通事件函数，那么在交易发起方属于预设用户类型且From字段属于暴露字段的情况下，在事件currentPrice1和事件currentPrice2分别产生的日志Log1、Log2中，日志Log1包含的From字段在满足预设条件的情况下以明文形式存储、在未满足预设条件的情况下以密文形式存储，而日志Log2包含的From字段必然以密文形式存储；类似地，日志Log1中属于暴露字段的其他字段在满足预设条件时也以明文形式存储、非暴露字段以密文形式存储，而日志Log2的所有字段均以密文形式存储。并且，如果通过对特殊事件函数列表 进行更新后，将事件currentPrice2更新为对应于特殊事件函数，那么日志Log2包含的属于暴露字段的所有字段可以在满足预设条件的情况下以明文形式存储、在未满足预设条件的情况下以密文形式存储，而无需对智能合约的代码做任何变动。
对于上述的合约级字段而言，可以通过前述的类型标识符来标明智能合约所含的事件函数是否为特殊事件函数。例如，可以将上述的代码示例42调整为下述的代码示例43：
plain Contract Example{
int price；
int price1；
event currentPrice1 expose(int price)；
event currentPrice2(int price1)；
…
在上述的代码示例43中，与代码示例2相类似地，合约级字段包括收据数据中的所有字段；同时，智能合约中包含了事件currentPrice1和事件currentPrice2：由于事件currentPrice1在包含如前所述的类型标识符expose，使得该事件currentPrice1被标注为对应于特殊事件函数，而事件currentPrice2并未包含类型标识符expose，使得事件currentPrice2被标注为对应于普通事件函数，那么在交易发起方属于预设用户类型的情况下，在事件currentPrice1和事件currentPrice2分别产生的日志Log1、Log2中，日志Log1中对应于交易类型的所有暴露字段在满足预设条件的情况下以明文形式存储、在未满足预设条件的情况下以密文形式存储，而日志Log2包含的所有字段必然以密文形式存储。
除了合约级字段之外，暴露标识符标明的字段可以包括：对应于智能合约中定义的至少一个事件的事件级字段，使得在交易发起方属于预设用户类型且该事件级字段属于暴露字段的情况下，第一区块链节点将特殊事件函数产生的收据内容中对应于该事件级字段且满足预设条件的部分以明文形式存储。尤其是，当智能合约中包含多个事件时，可以针对至少一部分事件设定上述的事件级字段，使得这部分事件产生的日志中对应于上述事件级字段且满足预设条件的收据内容以明文形式存储，而这部分事件产生的日志中的其余收据内容、其余事件对应的收据内容均以密文形式存储。以From字段为例，可以将上述的代码示例43调整为下述的代码示例44：
Contract Example{
int price；
int price1；
event currentPrice1(“from”,int price)；
event currentPrice2(int price1)；
…
在上述的代码示例44中，事件currentPrice1虽然未添加暴露标识符“plain”，但是包含了内容“from”，该内容“from”对应于From字段，用于表明事件currentPrice1所产生日志中的From字段需要以明文形式存储，因而该内容“from”既属于上述的暴露标识符，又标明了需要明文存储的From字段。并且，由于内容“from”位于事件currentPrice1中，因而From字段为事件级字段，使得在交易发起方属于预设用户类型且From字段属于暴露字段的情况下，当该事件currentPrice1对应于特殊事件函数时，在该事件currentPrice1对应产生的日志Logs中，From字段在满足预设条件的情况下以明文形式进行存储、在未满足预设条件的情况下以密文形式存储，而其他字段必然以密文形式存储。而对于代码示例44所含的另一事件currentPrice2，由于并未针对该事件currentPrice2添加暴露标识符，因而不论该事件currentPrice2对应于特殊事件函数或普通事件函数，所产生的日志Logs均以密文形式存储。该代码示例44对应的实施例中，即对于事件级字段而言，可以通过特殊事件函数列表或者类型标识符的方式识别智能合约所含的事件函数是否为特殊事件函数，此处不再一一赘述。
通过在计算设备(物理机或虚拟机)上运行区块链的程序代码(以下简称为链代码)，可以将该计算设备配置为区块链网络中的区块链节点，比如上述的第一区块链节点等。换言之，第一区块链节点通过运行上述的链代码，以实现相应的功能逻辑。因此，可以在创建区块链网络时，将与暴露标识符相关的收据数据存储逻辑写入链代码中，使得各个区块链节点均可以实现该收据数据存储逻辑。
譬如在图3所示的实施例中，该与暴露标识符相关的收据数据存储逻辑可以包括：基于暴露标识符对收据内容进行存储的逻辑。其中，该基于暴露标识符对收据内容进行存储的逻辑用于指示第一区块链节点：针对暴露标识符标明的对象、未标明的对象，分别采用何种方式存储相应的收据内容。比如：对暴露标识符标明的对象，采用明文形式存储对应的收据内容，而对未由暴露标识符标明的对象，采用密文形式存储对应的收据内容。
如前所述，在图3所示实施例的基础上，本说明书还可以进一步考量下述因素中至少之一：交易发起方的用户类型、交易的交易类型、收据数据中满足预设条件的收据内容和智能合约所含的事件函数。上述的一个或多个因素可以与暴露标识符相结合，以得到相应的收据数据存储逻辑。
当收据数据存储逻辑与交易发起方的用户类型相关时，该收据数据存储逻辑包括：对用户类型的识别逻辑。对用户类型的识别逻辑用于指示第一区块链节点：识别交易发起方的用户类型。比如：系统合约中可以记录有预定义的外部账户与用户类型之间的关联关系，或者系统合约中可以记录有用户类型字段的取值与用户类型之间的对应关系。具体可以参考上文中识别用户类型的相关描述，此处不再赘述。
当收据数据存储逻辑与交易的交易类型相关时，该收据数据存储逻辑包括：对交易类型的识别逻辑。对交易类型的识别逻辑用于指示第一区块链节点：识别交易发起方所发起的交易的类型。比如：根据交易所含的交易类型字段的取值，确定该交易对应的交易类型。具体可以参考上文中识别交易类型的相关描述，此处不再赘述。
当收据数据存储逻辑与收据数据中满足预设条件的收据内容相关时，该收据数据存储逻辑包括：对事件函数的识别逻辑。对事件函数的识别逻辑用于指示第一区块链节点：识别交易对应的智能合约所含的事件函数的类型。比如：根据事件函数所含的类型标识符进行识别，或者根据区块链网络中记载的特殊事件函数列表进行识别。具体可以参考上文中识别特殊事件函数的相关描述，此处不再赘述。
当收据数据存储逻辑与智能合约所含的事件函数相关时，该收据数据存储逻辑包括：对预设条件的确定逻辑。对预设条件的确定逻辑用于指示第一区块链节点：获取暴露标识符标明的对象所对应的收据内容所适用的预设条件。比如：获取适用于所有收据字段的通用条件，或者获取适用于暴露标识符标明的对象所对应的收据内容的所处字段的专用条件等。具体可以参考上文中预设条件的相关描述，此处不再赘述。
然而，链代码的升级更新相对较为困难，使得采用链代码实现对收据数据的存储存在灵活性低、可扩展性不足的问题。为了实现对链代码的功能扩展，如图4所示，可以采用链代码与系统合约相结合的方式：链代码用于实现区块链网络的基础功能，而运行过程中的功能扩展可以通过系统合约的方式实现。与上述的智能合约相类似的，系统合约包括譬如字节码形式的代码，第一区块链节点可以通过运行系统合约的代码(比如，根据唯一对应的地址“0x53a98…”来读取该系统合约中的代码)，实现对链代码的功能补充。相应地，第一区块链节点可以读取系统合约的代码，该系统合约的代码中 定义了上述与暴露标识符相关的收据数据存储逻辑；然后，第一区块链节点可以执行系统合约的代码，从而基于上述与暴露标识符相关的收据数据存储逻辑，将暴露标识符标明的对象在收据数据中对应的至少一部分收据内容以明文形式存储、收据数据的其余内容以密文形式存储。
区别于上述由用户发布至区块链的智能合约，系统合约无法由用户自由发布。第一区块链节点读取的系统合约可以包括配置于区块链网络的创世块中的预置系统合约；以及，区块链网络中的管理员(即上述的管理用户)可以具有针对系统合约的更新权限，从而针对诸如上述的预置系统合约进行更新，则上述第一区块链节点读取的系统合约还可以包括相应的更新后系统合约。当然，更新后系统合约可以由管理员对预置系统合约实施一次更新后得到；或者，更新后系统合约可以由管理员对预置系统合约实施多次迭代更新后得到，比如由预置系统合约更新得到系统合约1、对系统合约1更新得到系统合约2、对系统合约2更新得到系统合约3，该系统合约1、系统合约2、系统合约3均可以视为更新后系统合约，但第一区块链节点通常会以最新版本的系统合约为准，比如第一区块链节点会以系统合约3中的代码为准，而非系统合约1或系统合约2中的代码。
除了创世块中包含的预置系统合约之外，管理员还可以在后续区块内发布系统合约，以及针对所发布的系统合约进行更新。总之，应当通过诸如权限管理等方式，对系统合约的发布和更新实施一定程度的限制，以确保区块链网络的功能逻辑能够正常运作，并且避免对任何用户造成不必要的损失。
以下结合图5介绍本说明书一种基于代码标注的对象级收据存储节点的实施例，包括：
接收单元51，接收经过加密的对应于智能合约的交易，所述智能合约的代码中包括通过暴露标识符标明的对象；
解密单元52，在可信执行环境中解密所述交易，以获得所述智能合约的代码；
执行单元53，在所述可信执行环境中执行所述智能合约的代码，得到收据数据；
存储单元54，存储所述收据数据，使所述暴露标识符标明的对象对应的至少一部分收据内容以明文形式存储、其余收据内容以密文形式存储。
可选的，第一区块链节点接收的交易对应的智能合约，包括：
高级语言编写的智能合约；或，
字节码形式的智能合约。
可选的，当第一区块链节点接收的交易对应的智能合约为高级语言编写的智能合约时，所述装置还包括：
编译单元55，通过编译器对所述高级语言编写的智能合约进行编译，生成字节码形式的智能合约，以在所述可信执行环境中执行。
可选的，当第一区块链节点接收的交易对应的智能合约为字节码形式的智能合约时，所述字节码形式的智能合约由客户端通过编译器对高级语言编写的智能合约进行编译而得到，所述高级语言编写的智能合约由用户在所述客户端上编写得到。
可选的，所述高级语言编写的智能合约与所述字节码形式的智能合约具有相同或对应的暴露标识符。
可选的，第一区块链节点接收的交易对应的智能合约，包括：
用户在第一区块链节点上生成的智能合约；或，
用户在客户端上生成的智能合约；或，
所述客户端通过第二区块链节点发来的交易中的智能合约。
可选的，所述暴露标识符标明的对象包括：收据字段和/或状态变量。
可选的，所述暴露标识符标明的对象包括：适用于所述智能合约中定义的所有事件的合约级对象；所述存储单元54具体用于：
在存储所述收据数据时，将所述收据数据中对应于所述合约级对象的至少一部分收据内容以明文形式存储。
可选的，所述暴露标识符标明的对象包括：对应于所述智能合约中定义的至少一个事件的事件级对象；所述存储单元54具体用于：
在存储所述收据数据时，确定出所述收据数据中对应于所述至少一个事件的收据内容，并将确定出的收据内容中对应于所述事件级对象的至少一部分以明文形式存储。
可选的，所述存储单元54具体用于：
存储所述收据数据，使交易发起方属于预设用户类型的情况下，所述暴露标识符标明的对象对应的至少一部分收据内容以明文形式存储、其余收据内容以密文形式存 储。
可选的，所述存储单元54通过下述方式确定所述交易发起方所属的用户类型：
确定所述交易发起方对应的外部账户；
查询区块链上记录的所述外部账户对应的用户类型，以作为所述交易发起方所属的用户类型。
可选的，所述外部账户包括记录于区块链上的用户类型字段，所述用户类型字段的取值对应于所述用户类型。
可选的，在创建所述外部账户时，所述用户类型被配置为关联至所述外部账户，使所述用户类型与所述外部账户之间的关联关系被记录于区块链中。
可选的，还包括：
更改单元56，根据管理用户发起的更改请求，更改所述外部账户对应的用户类型。
可选的，以明文形式存储的所述至少一部分收据内容包括下述至少之一：
所述至少一部分收据内容对应于所述暴露标识符标明的暴露字段，所述暴露字段与所述交易的交易类型相匹配；
所述至少一部分收据内容由所述智能合约所含的特殊事件函数所产生；
所述至少一部分收据内容所含的信息满足预设条件。
可选的，所述交易包括交易类型字段，所述交易类型字段的取值用于标明相应的交易类型。
可选的，区块链中存储有预定义的交易类型与暴露字段之间的映射关系，所述映射关系被用于确定所述交易的交易类型对应的暴露字段。
可选的，所述交易的交易类型包括：存证类型、资产转移类型、合约创建类型、合约调用类型。
可选的，所述智能合约中的事件函数包含类型标识符，所述类型标识符用于将所述事件函数标记为特殊事件函数。
可选的，当所述智能合约包含的事件函数位于区块链上记录的特殊函数列表中时，所述智能合约包含的事件函数被判定为特殊事件函数。
可选的，所述预设条件包括以下至少之一：相应的收据内容中包含预设内容、相应的收据内容的取值属于预设数值区间。
可选的，
所述预设条件包括所述收据数据中的所有收据字段对应的通用条件；或，
所述预设条件包括所述收据数据中的每一收据字段分别对应的专用条件。
可选的，
所述预设条件位于所述交易中；或，
所述预设条件位于所述交易对应的智能合约中，或所述交易对应的智能合约所调用的另一智能合约中；或，
所述预设条件位于系统合约或链代码中。
可选的，所述存储单元54具体用于：
读取系统合约的代码，所述系统合约的代码中定义了与暴露标识符相关的收据数据存储逻辑；
执行所述系统合约的代码，使所述暴露标识符标明的对象对应的至少一部分收据内容以明文形式存储、其余收据内容以密文形式存储。
可选的，所述系统合约包括：记录于创世块中的预置系统合约，或所述预置系统合约对应的更新后系统合约。
可选的，所述存储单元54具体用于：
在所述可信执行环境之外执行存储功能代码，以将所述收据数据存储至所述可信执行环境之外的外部存储空间。
可选的，所述交易用于创建和/或调用所述智能合约。
可选的，第一区块链节点对所述收据字段进行加密的密钥包括：对称加密算法的密钥或非对称加密算法的密钥。
可选的，所述对称加密算法的密钥包括所述客户端提供的初始密钥；或，所述对称加密算法的密钥包括所述初始密钥与影响因子生成的衍生密钥。
可选的，所述交易由所述初始密钥进行加密，且所述初始密钥被非对称加密算法的公钥进行加密；所述解密单元52具体用于：
第一区块链节点用所述非对称加密算法的私钥解密得到所述初始密钥，并用所述初始密钥对所述交易进行解密得到所述智能合约的代码。
可选的，所述初始密钥由客户端生成；或，所述初始密钥由密钥管理服务器发送至所述客户端。
可选的，所述影响因子与所述交易相关。
可选的，所述影响因子包括：所述交易的哈希值的指定位。
在20世纪90年代，对于一个技术的改进可以很明显地区分是硬件上的改进(例如，对二极管、晶体管、开关等电路结构的改进)还是软件上的改进(对于方法流程的改进)。然而，随着技术的发展，当今的很多方法流程的改进已经可以视为硬件电路结构的直接改进。设计人员几乎都通过将改进的方法流程编程到硬件电路中来得到相应的硬件电路结构。因此，不能说一个方法流程的改进就不能用硬件实体模块来实现。例如，可编程逻辑器件(Programmable Logic Device,PLD)(例如现场可编程门阵列(Field Programmable Gate Array，FPGA))就是这样一种集成电路，其逻辑功能由用户对器件编程来确定。由设计人员自行编程来把一个数字系统“集成”在一片PLD上，而不需要请芯片制造厂商来设计和制作专用的集成电路芯片。而且，如今，取代手工地制作集成电路芯片，这种编程也多半改用“逻辑编译器(logic compiler)”软件来实现，它与程序开发撰写时所用的软件编译器相类似，而要编译之前的原始代码也得用特定的编程语言来撰写，此称之为硬件描述语言(Hardware Description Language，HDL)，而HDL也并非仅有一种，而是有许多种，如ABEL(Advanced Boolean Expression Language)、AHDL(Altera Hardware Description Language)、Confluence、CUPL(Cornell University Programming Language)、HDCal、JHDL(Java Hardware Description Language)、Lava、Lola、MyHDL、PALASM、RHDL(Ruby Hardware Description Language)等，目前最普遍使用的是VHDL(Very-High-Speed Integrated Circuit Hardware Description Language)与Verilog。本领域技术人员也应该清楚，只需要将方法流程用上述几种硬件描述语言稍作逻辑编程并编程到集成电路中，就可以很容易得到实现该逻辑方法流程的硬件电路。
控制器可以按任何适当的方式实现，例如，控制器可以采取例如微处理器或处理器以及存储可由该(微)处理器执行的计算机可读程序代码(例如软件或固件)的计算机可读介质、逻辑门、开关、专用集成电路(Application Specific Integrated Circuit，ASIC)、可编程逻辑控制器和嵌入微控制器的形式，控制器的例子包括但不限于以下微 控制器：ARC 625D、Atmel AT91SAM、Microchip PIC18F26K20以及Silicone Labs C8051F320，存储器控制器还可以被实现为存储器的控制逻辑的一部分。本领域技术人员也知道，除了以纯计算机可读程序代码方式实现控制器以外，完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件，而对其内包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至，可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。
上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机。具体的，计算机例如可以为个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任何设备的组合。
为了描述的方便，描述以上装置时以功能分为各种单元分别描述。当然，在实施本说明书时可以把各单元的功能在同一个或多个软件和/或硬件中实现。
本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
本说明书可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本说明书，在这些分布式 计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。在一个典型的配置中，计算机包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带、磁盘存储、量子存储器、基于石墨烯的存储介质或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。
还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围 内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。
在本说明书一个或多个实施例使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本说明书一个或多个实施例。在本说明书一个或多个实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。
应当理解，尽管在本说明书一个或多个实施例可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本说明书一个或多个实施例范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。
以上所述仅为本说明书一个或多个实施例的较佳实施例而已，并不用以限制本说明书一个或多个实施例，凡在本说明书一个或多个实施例的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本说明书一个或多个实施例保护的范围之内。

Claims (36)

  1. 一种基于代码标注的对象级收据存储方法，包括：
    第一区块链节点接收经过加密的对应于智能合约的交易，所述智能合约的代码中包括通过暴露标识符标明的对象；
    第一区块链节点在可信执行环境中解密所述交易，以获得所述智能合约的代码；
    第一区块链节点在所述可信执行环境中执行所述智能合约的代码，得到收据数据；
    第一区块链节点存储所述收据数据，使所述暴露标识符标明的对象对应的至少一部分收据内容以明文形式存储、其余收据内容以密文形式存储。
  2. 根据权利要求1所述的方法，第一区块链节点接收的交易对应的智能合约，包括：
    高级语言编写的智能合约；或，
    字节码形式的智能合约。
  3. 根据权利要求2所述的方法，当第一区块链节点接收的交易对应的智能合约为高级语言编写的智能合约时，所述方法还包括：
    第一区块链节点通过编译器对所述高级语言编写的智能合约进行编译，生成字节码形式的智能合约，以在所述可信执行环境中执行。
  4. 根据权利要求2所述的方法，当第一区块链节点接收的交易对应的智能合约为字节码形式的智能合约时，所述字节码形式的智能合约由客户端通过编译器对高级语言编写的智能合约进行编译而得到，所述高级语言编写的智能合约由用户在所述客户端上编写得到。
  5. 根据权利要求2所述的方法，所述高级语言编写的智能合约与所述字节码形式的智能合约具有相同或对应的暴露标识符。
  6. 根据权利要求1所述的方法，第一区块链节点接收的交易对应的智能合约，包括：
    用户在第一区块链节点上生成的智能合约；或，
    用户在客户端上生成的智能合约；或，
    所述客户端通过第二区块链节点发来的交易中的智能合约。
  7. 根据权利要求1所述的方法，所述暴露标识符标明的对象包括：收据字段和/或状态变量。
  8. 根据权利要求1所述的方法，所述暴露标识符标明的对象包括：适用于所述智能合约中定义的所有事件的合约级对象；第一区块链节点存储所述收据数据，包括：
    第一区块链节点在存储所述收据数据时，将所述收据数据中对应于所述合约级对象的至少一部分收据内容以明文形式存储。
  9. 根据权利要求1所述的方法，所述暴露标识符标明的对象包括：对应于所述智能合约中定义的至少一个事件的事件级对象；第一区块链节点存储所述收据数据，包括：
    第一区块链节点在存储所述收据数据时，确定出所述收据数据中对应于所述至少一个事件的收据内容，并将确定出的收据内容中对应于所述事件级对象的至少一部分以明文形式存储。
  10. 根据权利要求1所述的方法，第一区块链节点存储所述收据数据，包括：
    第一区块链节点存储所述收据数据，使交易发起方属于预设用户类型的情况下，所述暴露标识符标明的对象对应的至少一部分收据内容以明文形式存储、其余收据内容以密文形式存储。
  11. 根据权利要求10所述的方法，第一区块链节点通过下述方式确定所述交易发起方所属的用户类型：
    第一区块链节点确定所述交易发起方对应的外部账户；
    第一区块链节点查询区块链上记录的所述外部账户对应的用户类型，以作为所述交易发起方所属的用户类型。
  12. 根据权利要求11所述的方法，所述外部账户包括记录于区块链上的用户类型字段，所述用户类型字段的取值对应于所述用户类型。
  13. 根据权利要求11所述的方法，在创建所述外部账户时，所述用户类型被配置为关联至所述外部账户，使所述用户类型与所述外部账户之间的关联关系被记录于区块链中。
  14. 根据权利要求13所述的方法，还包括：
    第一区块链节点根据管理用户发起的更改请求，更改所述外部账户对应的用户类型。
  15. 根据权利要求1所述的方法，以明文形式存储的所述至少一部分收据内容满足下述规则中至少之一：
    所述至少一部分收据内容对应于所述暴露标识符标明的暴露字段，所述暴露字段与所述交易的交易类型相匹配；
    所述至少一部分收据内容由所述智能合约所含的特殊事件函数所产生；
    所述至少一部分收据内容所含的信息满足预设条件。
  16. 根据权利要求15所述的方法，所述交易包括交易类型字段，所述交易类型字 段的取值用于标明相应的交易类型。
  17. 根据权利要求15所述的方法，区块链中存储有预定义的交易类型与暴露字段之间的映射关系，所述映射关系被用于确定所述交易的交易类型对应的暴露字段。
  18. 根据权利要求15所述的方法，所述交易的交易类型包括：存证类型、资产转移类型、合约创建类型、合约调用类型。
  19. 根据权利要求15所述的方法，所述智能合约中的事件函数包含类型标识符，所述类型标识符用于将所述事件函数标记为特殊事件函数。
  20. 根据权利要求15所述的方法，当所述智能合约包含的事件函数位于区块链上记录的特殊函数列表中时，所述智能合约包含的事件函数被判定为特殊事件函数。
  21. 根据权利要求15所述的方法，所述预设条件包括以下至少之一：相应的收据内容中包含预设内容、相应的收据内容的取值属于预设数值区间。
  22. 根据权利要求15所述的方法，
    所述预设条件包括所述收据数据中的所有收据字段对应的通用条件；或，
    所述预设条件包括所述收据数据中的每一收据字段分别对应的专用条件。
  23. 根据权利要求15所述的方法，
    所述预设条件位于所述交易中；或，
    所述预设条件位于所述交易对应的智能合约中，或所述交易对应的智能合约所调用的另一智能合约中；或，
    所述预设条件位于系统合约或链代码中。
  24. 根据权利要求1所述的方法，第一区块链节点存储所述收据数据，包括：
    第一区块链节点读取系统合约的代码，所述系统合约的代码中定义了与暴露标识符相关的收据数据存储逻辑；
    第一区块链节点执行所述系统合约的代码，使所述暴露标识符标明的对象对应的至少一部分收据内容以明文形式存储、其余收据内容以密文形式存储。
  25. 根据权利要求24所述的方法，所述系统合约包括：记录于创世块中的预置系统合约，或所述预置系统合约对应的更新后系统合约。
  26. 根据权利要求1所述的方法，第一区块链节点存储所述收据数据，包括：
    第一区块链节点在所述可信执行环境之外执行存储功能代码，以将所述收据数据存储至所述可信执行环境之外的外部存储空间。
  27. 根据权利要求1所述的方法，所述交易用于创建和/或调用所述智能合约。
  28. 根据权利要求1所述的方法，第一区块链节点对所述收据字段进行加密的密钥 包括：对称加密算法的密钥或非对称加密算法的密钥。
  29. 根据权利要求28所述的方法，所述对称加密算法的密钥包括所述客户端提供的初始密钥；或，所述对称加密算法的密钥包括所述初始密钥与影响因子生成的衍生密钥。
  30. 根据权利要求29所述的方法，所述交易由所述初始密钥进行加密，且所述初始密钥被非对称加密算法的公钥进行加密；第一区块链节点在可信执行环境中解密所述交易中的所述智能合约的代码，包括：
    第一区块链节点用所述非对称加密算法的私钥解密得到所述初始密钥，并用所述初始密钥对所述交易进行解密得到所述智能合约的代码。
  31. 根据权利要求29所述的方法，所述初始密钥由客户端生成；或，所述初始密钥由密钥管理服务器发送至所述客户端。
  32. 根据权利要求29所述的方法，所述影响因子与所述交易相关。
  33. 根据权利要求32所述的方法，所述影响因子包括：所述交易的哈希值的指定位。
  34. 一种基于代码标注的对象级收据存储节点，包括：
    接收单元，接收经过加密的对应于智能合约的交易，所述智能合约的代码中包括通过暴露标识符标明的对象；
    解密单元，在可信执行环境中解密所述交易，以获得所述智能合约的代码；
    执行单元，在所述可信执行环境中执行所述智能合约的代码，得到收据数据；
    存储单元，存储所述收据数据，使所述暴露标识符标明的对象对应的至少一部分收据内容以明文形式存储、其余收据内容以密文形式存储。
  35. 一种电子设备，包括：
    处理器；
    用于存储处理器可执行指令的存储器；
    其中，所述处理器通过运行所述可执行指令以实现如权利要求1-33中任一项所述的方法。
  36. 一种计算机可读存储介质，其上存储有计算机指令，该指令被处理器执行时实现如权利要求1-33中任一项所述方法的步骤。
PCT/CN2020/089381 2019-05-20 2020-05-09 基于代码标注的对象级收据存储方法和节点 WO2020233421A1 (zh)

Applications Claiming Priority (30)

Application Number Priority Date Filing Date Title
CN201910420668.4A CN110264198B (zh) 2019-05-20 2019-05-20 结合代码标注与交易类型的有条件的收据存储方法和节点
CN201910419755.8 2019-05-20
CN201910419897.4 2019-05-20
CN201910419887.0 2019-05-20
CN201910420663.1A CN110245946B (zh) 2019-05-20 2019-05-20 结合代码标注与多类型维度的收据存储方法和节点
CN201910419907.4 2019-05-20
CN201910419898.9 2019-05-20
CN201910420666.5A CN110263091B (zh) 2019-05-20 2019-05-20 结合代码标注与用户、事件类型的收据存储方法和节点
CN201910419900.2 2019-05-20
CN201910419897.4A CN110278193B (zh) 2019-05-20 2019-05-20 结合代码标注与交易、事件类型的收据存储方法和节点
CN201910420668.4 2019-05-20
CN201910420679.2 2019-05-20
CN201910420679.2A CN110266644B (zh) 2019-05-20 2019-05-20 结合代码标注与交易类型的收据存储方法和节点
CN201910419755.8A CN110263543B (zh) 2019-05-20 2019-05-20 基于代码标注的对象级收据存储方法和节点
CN201910419924.8A CN110247895B (zh) 2019-05-20 2019-05-20 收据存储方法、节点、设备及存储介质
CN201910419928.6A CN110245945B (zh) 2019-05-20 2019-05-20 结合代码标注与用户类型的收据存储方法和节点
CN201910419907.4A CN110263088B (zh) 2019-05-20 2019-05-20 结合代码标注与事件类型的有条件的收据存储方法和节点
CN201910419900.2A CN110245490B (zh) 2019-05-20 2019-05-20 有条件的结合代码标注与类型维度的收据存储方法和节点
CN201910420666.5 2019-05-20
CN201910419893.6A CN110264196B (zh) 2019-05-20 2019-05-20 结合代码标注与用户类型的有条件的收据存储方法和节点
CN201910419893.6 2019-05-20
CN201910419898.9A CN110263087B (zh) 2019-05-20 2019-05-20 基于多维度信息且具有条件限制的收据存储方法和节点
CN201910420663.1 2019-05-20
CN201910419908.9A CN110223172B (zh) 2019-05-20 2019-05-20 有条件的结合代码标注与类型维度的收据存储方法和节点
CN201910419908.9 2019-05-20
CN201910419924.8 2019-05-20
CN201910419913.X 2019-05-20
CN201910419887.0A CN110264195B (zh) 2019-05-20 2019-05-20 结合代码标注与交易、用户类型的收据存储方法和节点
CN201910419928.6 2019-05-20
CN201910419913.XA CN110245503B (zh) 2019-05-20 2019-05-20 结合代码标注与判断条件的收据存储方法和节点

Publications (1)

Publication Number Publication Date
WO2020233421A1 true WO2020233421A1 (zh) 2020-11-26

Family

ID=73459358

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2020/089381 WO2020233421A1 (zh) 2019-05-20 2020-05-09 基于代码标注的对象级收据存储方法和节点

Country Status (1)

Country Link
WO (1) WO2020233421A1 (zh)

Citations (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107770182A (zh) * 2017-10-30 2018-03-06 中国联合网络通信集团有限公司 家庭网关的数据存储方法及家庭网关
CN108235772A (zh) * 2017-12-29 2018-06-29 深圳前海达闼云端智能科技有限公司 基于区块链的数据处理方法、装置、存储介质及电子设备
US20180349617A1 (en) * 2017-06-06 2018-12-06 City University Of Hong Kong Electronic storage system and a method of data management
CN109525671A (zh) * 2018-11-26 2019-03-26 远光软件股份有限公司 基于区块链的数据存储方法、电子设备及存储介质
CN109547477A (zh) * 2018-12-27 2019-03-29 石更箭数据科技(上海)有限公司 一种数据处理方法及其装置、介质、终端
CN110223172A (zh) * 2019-05-20 2019-09-10 阿里巴巴集团控股有限公司 有条件的结合代码标注与类型维度的收据存储方法和节点
CN110245946A (zh) * 2019-05-20 2019-09-17 阿里巴巴集团控股有限公司 结合代码标注与多类型维度的收据存储方法和节点
CN110245490A (zh) * 2019-05-20 2019-09-17 阿里巴巴集团控股有限公司 有条件的结合代码标注与类型维度的收据存储方法和节点
CN110247895A (zh) * 2019-05-20 2019-09-17 阿里巴巴集团控股有限公司 结合代码标注与事件函数类型的收据存储方法和节点
CN110245503A (zh) * 2019-05-20 2019-09-17 阿里巴巴集团控股有限公司 结合代码标注与判断条件的收据存储方法和节点
CN110245945A (zh) * 2019-05-20 2019-09-17 阿里巴巴集团控股有限公司 结合代码标注与用户类型的收据存储方法和节点
CN110263543A (zh) * 2019-05-20 2019-09-20 阿里巴巴集团控股有限公司 基于代码标注的对象级收据存储方法和节点
CN110263088A (zh) * 2019-05-20 2019-09-20 阿里巴巴集团控股有限公司 结合代码标注与事件类型的有条件的收据存储方法和节点
CN110263091A (zh) * 2019-05-20 2019-09-20 阿里巴巴集团控股有限公司 结合代码标注与用户、事件类型的收据存储方法和节点
CN110264195A (zh) * 2019-05-20 2019-09-20 阿里巴巴集团控股有限公司 结合代码标注与交易、用户类型的收据存储方法和节点
CN110264196A (zh) * 2019-05-20 2019-09-20 阿里巴巴集团控股有限公司 结合代码标注与用户类型的有条件的收据存储方法和节点
CN110264198A (zh) * 2019-05-20 2019-09-20 阿里巴巴集团控股有限公司 结合代码标注与交易类型的有条件的收据存储方法和节点
CN110266644A (zh) * 2019-05-20 2019-09-20 阿里巴巴集团控股有限公司 结合代码标注与交易类型的收据存储方法和节点
CN110263087A (zh) * 2019-05-20 2019-09-20 阿里巴巴集团控股有限公司 基于多维度信息且具有条件限制的收据存储方法和节点
CN110278193A (zh) * 2019-05-20 2019-09-24 阿里巴巴集团控股有限公司 结合代码标注与交易、事件类型的收据存储方法和节点

Patent Citations (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180349617A1 (en) * 2017-06-06 2018-12-06 City University Of Hong Kong Electronic storage system and a method of data management
CN107770182A (zh) * 2017-10-30 2018-03-06 中国联合网络通信集团有限公司 家庭网关的数据存储方法及家庭网关
CN108235772A (zh) * 2017-12-29 2018-06-29 深圳前海达闼云端智能科技有限公司 基于区块链的数据处理方法、装置、存储介质及电子设备
CN109525671A (zh) * 2018-11-26 2019-03-26 远光软件股份有限公司 基于区块链的数据存储方法、电子设备及存储介质
CN109547477A (zh) * 2018-12-27 2019-03-29 石更箭数据科技(上海)有限公司 一种数据处理方法及其装置、介质、终端
CN110245945A (zh) * 2019-05-20 2019-09-17 阿里巴巴集团控股有限公司 结合代码标注与用户类型的收据存储方法和节点
CN110263088A (zh) * 2019-05-20 2019-09-20 阿里巴巴集团控股有限公司 结合代码标注与事件类型的有条件的收据存储方法和节点
CN110245490A (zh) * 2019-05-20 2019-09-17 阿里巴巴集团控股有限公司 有条件的结合代码标注与类型维度的收据存储方法和节点
CN110247895A (zh) * 2019-05-20 2019-09-17 阿里巴巴集团控股有限公司 结合代码标注与事件函数类型的收据存储方法和节点
CN110245503A (zh) * 2019-05-20 2019-09-17 阿里巴巴集团控股有限公司 结合代码标注与判断条件的收据存储方法和节点
CN110223172A (zh) * 2019-05-20 2019-09-10 阿里巴巴集团控股有限公司 有条件的结合代码标注与类型维度的收据存储方法和节点
CN110263543A (zh) * 2019-05-20 2019-09-20 阿里巴巴集团控股有限公司 基于代码标注的对象级收据存储方法和节点
CN110245946A (zh) * 2019-05-20 2019-09-17 阿里巴巴集团控股有限公司 结合代码标注与多类型维度的收据存储方法和节点
CN110263091A (zh) * 2019-05-20 2019-09-20 阿里巴巴集团控股有限公司 结合代码标注与用户、事件类型的收据存储方法和节点
CN110264195A (zh) * 2019-05-20 2019-09-20 阿里巴巴集团控股有限公司 结合代码标注与交易、用户类型的收据存储方法和节点
CN110264196A (zh) * 2019-05-20 2019-09-20 阿里巴巴集团控股有限公司 结合代码标注与用户类型的有条件的收据存储方法和节点
CN110264198A (zh) * 2019-05-20 2019-09-20 阿里巴巴集团控股有限公司 结合代码标注与交易类型的有条件的收据存储方法和节点
CN110266644A (zh) * 2019-05-20 2019-09-20 阿里巴巴集团控股有限公司 结合代码标注与交易类型的收据存储方法和节点
CN110263087A (zh) * 2019-05-20 2019-09-20 阿里巴巴集团控股有限公司 基于多维度信息且具有条件限制的收据存储方法和节点
CN110278193A (zh) * 2019-05-20 2019-09-24 阿里巴巴集团控股有限公司 结合代码标注与交易、事件类型的收据存储方法和节点

Similar Documents

Publication Publication Date Title
WO2020233644A1 (zh) 有条件的结合代码标注与类型维度的收据存储方法和节点
WO2020233616A1 (zh) 结合代码标注与交易、用户类型的收据存储方法和节点
WO2020233642A1 (zh) 有条件的结合代码标注与类型维度的收据存储方法和节点
WO2020233643A1 (zh) 基于多维度信息且具有条件限制的收据存储方法和节点
WO2020233638A1 (zh) 结合代码标注与交易类型的收据存储方法和节点
WO2020233613A1 (zh) 结合代码标注与交易类型的有条件的收据存储方法和节点
WO2020233612A1 (zh) 结合代码标注与交易、事件类型的收据存储方法和节点
WO2020233622A1 (zh) 结合代码标注与多类型维度的收据存储方法和节点
WO2020233609A1 (zh) 结合代码标注与用户类型的有条件的收据存储方法和节点
WO2020233637A1 (zh) 结合代码标注与用户类型的收据存储方法和节点
WO2020233610A1 (zh) 结合代码标注与用户、事件类型的收据存储方法和节点
WO2020233640A1 (zh) 结合代码标注与判断条件的收据存储方法和节点
WO2020233623A1 (zh) 结合交易类型和判断条件的收据存储方法和节点
WO2020233614A1 (zh) 结合代码标注与事件类型的有条件的收据存储方法和节点
WO2020233626A1 (zh) 结合交易与用户类型的条件限制的收据存储方法和节点
WO2020233639A1 (zh) 结合代码标注与事件函数类型的收据存储方法和节点
WO2020233635A1 (zh) 结合多类型维度的条件限制的收据存储方法和节点
WO2020233625A1 (zh) 结合用户类型和判断条件的收据存储方法和节点
WO2020233615A1 (zh) 结合用户类型与事件函数类型的收据存储方法和节点
WO2020233628A1 (zh) 结合事件函数类型和判断条件的收据存储方法和节点
WO2020233630A1 (zh) 基于用户类型的收据存储方法和节点
WO2020233624A1 (zh) 结合交易类型和事件函数类型的收据存储方法和节点
WO2020233619A1 (zh) 结合用户类型与交易类型的收据存储方法和节点
WO2020233629A1 (zh) 基于代码标注的对象级收据存储方法和节点
WO2020233627A1 (zh) 多类型维度的收据存储方法和节点

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 20808969

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 20808969

Country of ref document: EP

Kind code of ref document: A1