WO2020233425A1 - Procédé et nœud de stockage de reçu basés sur une condition de détermination - Google Patents

Procédé et nœud de stockage de reçu basés sur une condition de détermination Download PDF

Info

Publication number
WO2020233425A1
WO2020233425A1 PCT/CN2020/089386 CN2020089386W WO2020233425A1 WO 2020233425 A1 WO2020233425 A1 WO 2020233425A1 CN 2020089386 W CN2020089386 W CN 2020089386W WO 2020233425 A1 WO2020233425 A1 WO 2020233425A1
Authority
WO
WIPO (PCT)
Prior art keywords
transaction
receipt
event
content
field
Prior art date
Application number
PCT/CN2020/089386
Other languages
English (en)
Chinese (zh)
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 CN201910419170.6A external-priority patent/CN110245943B/zh
Priority claimed from CN201910420680.5A external-priority patent/CN110245947B/zh
Priority claimed from CN201910419925.2A external-priority patent/CN110263089B/zh
Priority claimed from CN201910419913.XA external-priority patent/CN110245503B/zh
Priority claimed from CN201910419893.6A external-priority patent/CN110264196B/zh
Priority claimed from CN201910420668.4A external-priority patent/CN110264198B/zh
Priority claimed from CN201910419943.0A external-priority patent/CN110245504B/zh
Priority claimed from CN201910420675.4A external-priority patent/CN110263544B/zh
Priority claimed from CN201910419900.2A external-priority patent/CN110245490B/zh
Priority claimed from CN201910419898.9A external-priority patent/CN110263087B/zh
Priority claimed from CN201910419908.9A external-priority patent/CN110223172B/zh
Priority claimed from CN201910419907.4A external-priority patent/CN110263088B/zh
Priority claimed from CN201910419136.9A external-priority patent/CN110245942B/zh
Priority claimed from CN201910419959.1A external-priority patent/CN110264197B/zh
Application filed by 创新先进技术有限公司 filed Critical 创新先进技术有限公司
Publication of WO2020233425A1 publication Critical patent/WO2020233425A1/fr

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • 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 a method and node for storing receipts based on judgment conditions.
  • 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 a receipt storage method and node based on judgment conditions.
  • a method for storing receipts based on judgment conditions including:
  • the first blockchain node receives the encrypted transaction
  • the first blockchain node decrypts the transaction in the trusted execution environment and executes the obtained transaction content to obtain receipt data
  • the first blockchain node stores the receipt data, so that at least part of the receipt content that meets the preset condition in the receipt data is stored in plain text, and the rest of the receipt content is stored in cipher text.
  • a receipt storage node based on judgment conditions including:
  • the receiving unit receives encrypted transactions
  • the decryption unit decrypts the transaction in the trusted execution environment to obtain the transaction content
  • the execution unit executes the transaction content to obtain receipt data
  • the storage unit stores the receipt data so that at least a part of the receipt content that meets the preset condition in the receipt data 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 implementing privacy protection on blockchain nodes according to an exemplary embodiment.
  • Fig. 2 is a flowchart of a method for storing receipts based on judgment conditions according to an exemplary embodiment.
  • Fig. 3 is a schematic diagram of creating a smart contract according to an exemplary embodiment.
  • Fig. 4 is a schematic diagram of invoking a smart contract provided by an exemplary embodiment.
  • Fig. 5 is a schematic diagram of the functional logic of implementing a blockchain network through a system contract and a chain code provided by an exemplary embodiment.
  • Fig. 6 is a block diagram of a receipt storage device based on judgment conditions 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.
  • 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 forms a receipt tree.
  • the receipt tree is generated through organization, so that when querying or verifying receipt data, the corresponding query or verification efficiency can be greatly improved.
  • the MPT Merkle Patricia Tree
  • the leaf of the receipt tree is the hash value of the receipt data corresponding to each transaction contained in the block, and the receiptRoot is Root hashes generated sequentially upwards according to the hash value of the receipt data at the leaf.
  • other types of tree structures can also be used in other blockchain networks.
  • the receipt data generated after the transaction is executed is stored in plain text, and anyone can see the receipt content corresponding to the above-mentioned receipt fields contained in the receipt data, and there is no privacy protection setting and ability.
  • the receipt data needs to be stored in cipher text.
  • the first blockchain node includes the conventional environment on the left (on the left in the figure) and TEE.
  • the transaction submitted by the client (or other sources) first enters the "transaction/query interface" in the conventional environment , And then pass the transaction to the TEE for processing.
  • TEE is isolated from the normal environment. For example, when a transaction is encrypted, the transaction needs to be transferred to the TEE for decryption as the transaction content in clear text, so that the transaction content in the clear text can be efficiently processed in the TEE and in the TEE under the premise of ensuring data security.
  • the receipt data in plaintext is generated in.
  • TEE is a secure extension based on CPU hardware and a trusted execution environment completely isolated from the outside.
  • TEE was first proposed by Global Platform to solve the security isolation of resources on mobile devices, and parallel to the operating system to provide a trusted and secure execution environment for applications.
  • ARM's Trust Zone technology is the first to realize the real commercial TEE technology.
  • security requirements are getting higher and higher.
  • mobile devices, cloud devices, but also data centers have put forward more demands on 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 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.
  • the privacy protection needs of users in different situations may be different, which often depends on the actual situation of the receipt content. Take the transfer scenario as an example.
  • the user may allow the transfer amount to be exposed, so it is stored in clear text to drive the client such as DAPP (Decentralized Application) to perform related processing operations;
  • DAPP Decentralized Application
  • the user may not allow the transfer amount to be exposed, but may be stored in cipher text to achieve privacy protection.
  • step 202 the first blockchain node receives the encrypted transaction.
  • the user can directly generate a transaction on the first blockchain node; or, the user can generate a transaction on the client, and send the transaction to the first blockchain node through the client; or, the client
  • the terminal can send the above transaction to the second blockchain node, and the second blockchain node sends the transaction to the first blockchain node.
  • the transactions in this manual can be used to implement relatively simple processing logic, such as similar to the deposit logic and transfer logic in related technologies, that is, the relevant transactions are deposit transactions, transfer transactions, etc. At this time, the above transaction may not be related to the smart contract.
  • 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 3 represents the address of this contract, the data field of the transaction can be stored in bytecode, and the to field of the transaction is empty.
  • 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 transaction content can include the code of the smart contract that needs to be created; when the transaction is used to call a smart contract, the transaction content can include the account address of the smart contract that is called, and the required input Methods and parameters, etc.
  • Step 204 The first blockchain node decrypts the transaction in the trusted execution environment and executes the obtained transaction content to obtain receipt data.
  • the encrypted transaction can be kept in a state of privacy protection, and the transaction content can be prevented from being exposed.
  • the transaction content may contain information such as the account address of the transaction initiator and the account address of the transaction target. Encryption processing can ensure that these transaction contents cannot be directly read.
  • 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.
  • 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 .
  • the specific implementation process is similar to the above process, and will not be repeated here.
  • 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 3-4) and the transaction nonce (nonce) as input, and is generated by an encryption algorithm, such as in Figure 3-4
  • the contract address "0x6f8ae93" is generated from the sender's address "0xf5e" and the nonce in the transaction through an encryption algorithm.
  • 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 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 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 206 The first blockchain node stores the receipt data so that at least a part of the receipt content that meets the preset condition in the receipt data is stored in plain text, and the rest of the receipt content is stored in cipher text.
  • the privacy protection requirement of the content of the receipt is relatively low.
  • DAPP Decentralized Application, distributed application
  • the privacy protection requirements of the receipt content are relatively high.
  • the privacy protection requirement of the receipt content can be identified from the dimension of the field.
  • the content of the receipt corresponding to each receipt field of the receipt data can be determined separately and matched with the aforementioned preset condition to determine the satisfaction of each receipt field to the preset condition.
  • the receipt data can also be divided from other dimensions, such as state variables, etc. This specification does not limit this.
  • the preset conditions may include global conditions applicable to all transactions.
  • the receipt data storage logic related to preset conditions can be predefined in the code of the system contract, so that the first blockchain node can execute the code of the system contract to realize the receipt data related to the preset conditions.
  • Storage logic so that at least part of the receipt content that meets the preset condition in the receipt data is stored in plain text, and the rest of the receipt content is stored in cipher text.
  • Receipt data storage logic related to preset conditions may include: content of preset conditions, content of receipts to which preset conditions apply, processing logic for judging whether the content of receipt meets preset conditions, and whether the content of receipt meets preset conditions The judgment result implements the logic of the storage operation, etc.
  • the content of the preset condition may include 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 content may include: one or more designated keywords.
  • the keywords may include predefined state variables, predefined event functions, information indicating the results of transaction execution, and so on.
  • the preset content may include: a preset value, for example, the preset value may be a numerical value, and the numerical value may be compared with the value of a state variable, etc., to determine whether the value of the state variable meets expectations; for another example, the preset value may be It is a string composed of numerical values, letters, special symbols, etc., which can be compared with the account address of the transaction initiator, the account address of the transaction target, and the content of the event function to identify the specific transaction initiator, specific The transaction target party or specific event function, etc.
  • the preset value range can indicate the privacy protection requirements of the relevant receipt content.
  • 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 content 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 condition may include a general condition corresponding to all receipt content (that is, all receipt fields) in the receipt data, that is, all receipt content in the receipt data is used for comparison with the preset condition. For example, when the preset condition is "contains preset keywords", all receipt content in the receipt data can be compared with the keywords contained in the preset condition to determine the receipt content that contains the keywords, as Receipt content that meets the above preset conditions.
  • 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, and each receipt field is used to correspond to The preset conditions are compared.
  • 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 and the To field may be "whether the preset content is included", and the preset content may be a preset account address, indicating a transaction initiated by or directed to the account address. You can store the From field or To field in plain text.
  • the preset condition corresponding to the Topic field can be "whether it belongs to the preset value range", and the value of the state variable referenced by the related event can be recorded in the Topic field.
  • it can include a value representing "transfer amount"
  • the state variable indicates that when the transfer amount is in the preset value range (usually it can be a small value interval corresponding to a smaller amount), the transfer amount can be stored in plain text.
  • 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 preset conditions described above can be written into the chain code, so that each blockchain node can implement the receipt data storage logic.
  • chain code is used to realize the basic functions of the blockchain network, and the function expansion during operation can be achieved through the system Realized by way of contract.
  • 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 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 logic of the storage operation is implemented according to the judgment result of whether the content of the receipt meets the preset condition.
  • the preset conditions can be defined and used according to user needs and are not forced to be applied globally.
  • the preset condition may include: the content of the preset condition, the content of the receipt to which the preset condition is applicable, the processing logic for judging whether the content of the receipt meets the preset condition, and so on.
  • the preset conditions may be located in the transaction, so that the preset conditions adopted by different exchanges may be different, so as to meet the difference in demand faced by different exchanges.
  • the difference in the preset conditions may be expressed as a difference in at least one dimension in the content of the preset conditions, the content of the receipt to which the preset conditions apply, and the processing logic for determining whether the content of the receipt meets the preset conditions.
  • the two can contain preset conditions of different dimensions, for example, the content of the receipt applicable to the preset conditions is different; or ,
  • the preset conditions contained in the two it can default to the default conditions contained in the exchange, or the preset conditions contained in the chain code or system contract, depending on the predefined choice logic.
  • the preset condition may be located in the smart contract called by the transaction, or the preset condition may be located in another smart contract called by the smart contract called by the transaction, so that the transaction can be selected by selecting the called smart contract to Determine whether to use the corresponding preset conditions.
  • the smart contract can be pre-created by the transaction initiator or any other user; of course, if the smart contract has a corresponding calling condition, then the above-mentioned transaction can call the smart contract only when the calling condition is met.
  • 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 two can respectively contain preset conditions of different dimensions, such as the content of the receipt to which the preset conditions apply Different; or, when there is a conflict between the preset conditions contained in the two, the preset conditions contained in the smart contract called by the transaction may be preferentially used by default, or the preset conditions contained in the chain code or system contract may be preferentially used. This depends on the predefined selection logic.
  • the first blockchain node encrypts the receipt content that meets the preset conditions by using a key.
  • the encryption may be symmetric encryption or asymmetric encryption. If the first blockchain node uses symmetric encryption, that is, the symmetric key of the symmetric encryption algorithm is used to encrypt the content of the receipt, the client (or other object holding the key) can use the symmetric key pair of the symmetric encryption algorithm The encrypted receipt content is decrypted.
  • 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 may use the aforementioned initial key to encrypt the content of the receipt.
  • Different transactions can use the same initial key, so that all transactions submitted by the same user are encrypted with this initial key, or different transactions can use different initial keys.
  • the client can randomly generate an initial key for each transaction. Key to improve security.
  • the first blockchain node may generate a derived key according to the initial key and the impact factor, and encrypt the content of the receipt through the derived key.
  • 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 may also use an asymmetric encryption method, that is, use the public key of the asymmetric encryption algorithm to encrypt the content of the receipt, and accordingly, the client may use the private key of the asymmetric encryption algorithm.
  • the key decrypts the encrypted receipt content.
  • the key of an asymmetric encryption algorithm for example, can be that the client generates a pair of public and private keys, and sends the public key to the first blockchain node in advance, so that the first blockchain node can use the receipt content Public key encryption.
  • the first blockchain node realizes the function by running the code used to realize the function. Therefore, for the functions that need to be implemented in the TEE, the relevant code also needs to be executed. For the code executed in the TEE, it needs to comply with the relevant specifications and requirements of the TEE; accordingly, for the code used to implement a certain function in the related technology, the code needs to be rewritten in combination with the specifications and requirements of the TEE. Large amount of development, and easy to produce loopholes (bugs) in the process of rewriting, affecting the reliability and stability of function implementation.
  • 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. 1 "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 4, where "package” means that the first blockchain node packages the transaction into blocks outside of the trusted execution environment), the cipher text form
  • the write cache function code is read into the TEE, decrypted into the plaintext code in the TEE, and the plaintext code is executed.
  • Write cache refers to a "buffer" mechanism provided to avoid “impact” to the external storage space when data is written to the external storage space.
  • 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 exposed identifier contained in the code of the smart contract corresponding to the transaction, so as to simultaneously meet the preset conditions according to the content of the receipt and the object indicated by the exposed identifier. Determine how to store receipt data. Therefore, the above step 206 can be improved as follows: 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 user when the user writes the code of the smart contract, he can mark one or more objects by adding an exposure identifier to the code, so that the receipt content corresponding to this part of the object in the receipt data can be stored in plain text ( It is actually necessary to determine whether to store it in plain text based on its satisfaction with the preset conditions), and the content of the receipt corresponding to the remaining objects without an exposed identifier must be stored in cipher text to achieve corresponding privacy protection.
  • 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, and the rest of the receipt content must be Stored in cipher text.
  • 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 allowed.
  • 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 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 can include a state variable, and the state variable can 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:
  • the state variable price can be marked as Contract-level objects.
  • the various fields of the receipt data generated after the code of the smart contract is executed usually including Topic field, Output field, etc.
  • if there is a receipt content corresponding to the state variable price (usually the value of the state variable price is recorded) )
  • each log Logs (such as the Topic field in the log Logs, etc.) 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.
  • 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, 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.
  • the above 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.
  • 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". By adding the exposure identifier "plain" before the event currentPrice, 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. Suppose 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 above code sample 4 can be adjusted to the following code sample 7:
  • the event function "event currentPrice(int price, int price1)" corresponding to the event currentPrice refers to the state variables "price” and "price1", and by adding the exposure identifier plain before the event, The quoted state variables "price” and “price1” will both be affected. All receipts related to the state variables "price” and "price1” generated by the event will be stored in plain text if the preset conditions are met. Those that 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. 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, 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 related to the state variable "price"
  • Receipt content 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 refers to the state variables "price” and "price1" at the same time, and passes before the type int of the state variable "price” Adding the exposed identifier plain, the state variable “price” can be configured as an event-level object, while the state variable “price1" without the exposed identifier plain is not an event-level object, making the event currentPrice generated and the state variable "price”
  • the content of the related receipt is stored in clear text when the preset conditions are met, and the content of the receipt related to the state variable "price1" must be stored in cipher text.
  • 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 to 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.
  • 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 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.
  • 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. Storage, and other From fields are stored in cipher text to avoid leakage of privacy.
  • 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 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 preset conditions are not necessarily implemented based on the programming language in the smart contract where the identifier is exposed, for example:
  • the preset condition can be located in the transaction (not in the code of the smart contract included in the exchange, the preset condition can be set when the transaction is created), so that different transactions even when calling the same smart contract Under circumstances, the preset conditions used can also be different to meet the differences in demand faced by 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.
  • 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 manual can further identify the user type of the transaction initiator, so as to determine the storage method of the receipt data according to the satisfaction of the preset conditions of the receipt content and the user type of the transaction initiator. . Therefore, the above step 206 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 receipt fields in the receipt data that meet the preset conditions are stored in plain text, The remaining receipt fields are stored in cipher text. When the transaction initiator does not belong to the preset user type, the receipt data is stored in cipher text.
  • the user has a corresponding external account on the blockchain, and initiates transactions or performs other operations on the blockchain based on the external account. For example, when a user initiates a transaction on the blockchain, the transaction is actually initiated through the user’s corresponding external account, so the transaction initiator corresponding to the transaction can be considered the user or the user The corresponding external account.
  • each user type has corresponding privacy protection requirements.
  • Users can be divided into corresponding multiple types according to the differences in privacy protection requirements; or, first, multiple user types are formed according to a certain factor, and then the corresponding privacy protection requirements are configured for each user type.
  • a corresponding relationship can be established between user types and privacy protection requirements, so that the first blockchain node can determine whether it is necessary to implement clear text storage for receipt fields that meet preset conditions based on the user type of the transaction initiator.
  • the user type to which the transaction initiator belongs that is, the user type to which the corresponding 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 user types corresponding to external accounts can be recorded on the blockchain in various forms:
  • 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 value of the user type field corresponds to the user type. For example, when the value of the user type field is 00, the user type is ordinary user, when the value of the user type field is 01, the user type is advanced user, and when the value of the user type field is 11, the user type is Manage users, etc. Therefore, the first blockchain node can determine the corresponding user type based on the value by reading the user type field of the external account mentioned above.
  • the user type when creating the aforementioned external account, the user type may be configured to be associated with the external account, and the association relationship between the user type and the external account may be recorded in the blockchain, for example, the association relationship may include the user Type and account address of external account.
  • the data structure of the external account does not need to be changed, that is, the external account does not need to include the aforementioned user type field. Therefore, the first blockchain node can determine the 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 relationship between the user type and the external account can be recorded in the system contract or chain code, especially when the external account is a preset account of the blockchain network, in the process of creating the system contract or writing the chain code , You can learn about the external account and add the corresponding relationship to the system contract or chain code; or, when the external account is not a preset account, you can update the system contract or chain code when the external account is subsequently created , Add the association relationship corresponding to the external account to the system contract or chain code.
  • 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.
  • different users can implement differentiated storage operations for receipt fields that meet preset conditions according to the differentiated needs of different users for the degree of privacy protection.
  • High flexibility For example, ordinary users have relatively lower requirements for privacy protection and higher requirements for triggering operations based on receipt data.
  • the receipt fields that meet the preset conditions can be in plain text. Store in order to retrieve the contents of receipts stored in plaintext and trigger relatively more types of associated operations.
  • the privacy protection requirements of advanced users are relatively higher, and the requirements for triggering operations based on receipt data are relatively lower.
  • all receipt fields can be stored in ciphertext To meet its privacy needs.
  • the receipt fields that meet the preset conditions can be regarded as the receipt content that may need to be stored in plain text, so that when the transaction initiator belongs to the preset user type, it is stored in plain text.
  • the receipt fields that do not meet the preset conditions must be stored in cipher text.
  • the content of the preset condition may include at least one of the following: the content of the corresponding receipt includes the preset content, the value of the content of the corresponding receipt belongs to a preset numerical interval, and so on.
  • the aforementioned preset content may include: one or more specified keywords, for example, the keywords may include predefined state variables, predefined event functions, information used to indicate the results of transaction execution, etc., so that when a certain receipt When the content contains state variables, event functions, or transaction execution results as keywords, it can be determined that the receipt content meets the preset conditions.
  • the keywords may include predefined state variables, predefined event functions, information used to indicate the results of transaction execution, etc., so that when a certain receipt When the content contains state variables, event functions, or transaction execution results as keywords, it can be determined that the receipt content meets the preset conditions.
  • the transaction execution result can include: "success” means the transaction is successful, “fail” means the transaction failed; when the keyword is "success”, the content of the receipt containing "success” is allowed to be stored in plain text (can When the transaction initiator belongs to the preset user type, it is stored in clear text), and the content of the receipt containing "fail” is not allowed to be stored in clear text to ensure that successful transactions can be viewed and subsequent operations are triggered.
  • the foregoing 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. String, which can be compared with the account address of the transaction initiator, the account address of the transaction target, the content of the event function, etc. to identify the specific transaction initiator, specific transaction target or specific event function, etc. .
  • the To field can be stored in plain text (it can be stored in the transaction initiator When the user type is preset, it is stored in clear text), and when a transaction is initiated for other transaction targets, the To field is not allowed to be stored in clear text to avoid privacy leakage.
  • this specification can further identify the exposed fields corresponding to the transaction type, so as to determine the storage method of the receipt data according to the satisfaction of the preset conditions of the receipt content and the exposed fields corresponding to the transaction type. . Therefore, the above step 206 can be improved as follows: the first blockchain node stores the receipt data, so that the exposed fields in the receipt data that meet the preset conditions are stored in plain text, and the remaining receipt fields are stored in cipher text.
  • 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 may respectively have corresponding exposed fields.
  • the exposed field is one or more fields specified in the receipt data.
  • the content of the receipt corresponding to the exposed field can be selectively combined with the satisfaction of the preset conditions by the exposed field Store in plaintext, so that subsequent operations such as retrieval can be performed on the content of the receipt stored in plaintext.
  • 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.
  • 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.
  • differentiated storage operations can be implemented for exposed fields that meet preset conditions according to the differentiated requirements of different types of transactions for privacy protection. Have high flexibility.
  • the exposed fields that meet the preset conditions can be stored in plain text, while the exposed fields or other receipt fields that do not meet the preset conditions must be stored in cipher text.
  • the content of the preset condition may include at least one of the following: the content of the corresponding receipt includes the preset content, the value of the content of the corresponding receipt belongs to a preset numerical interval, and so on.
  • the above-mentioned preset content may include: one or more specified keywords, for example, the keywords may include predefined state variables, predefined event functions, information used to indicate the result of transaction execution, etc., so that when a certain exposure When a field contains a state variable, event function, or transaction execution result as a keyword, it can be determined that the exposed field meets the preset conditions.
  • the transaction execution result can include: "success” means the transaction is successful, "fail” means the transaction failed; when the keyword is "success”, the exposed fields containing "success” will be stored in plain text, and The contents of exposed fields containing "fail” and other types of receipts are not allowed to be stored in clear text to ensure that successful transactions will be viewed and subsequent operations will be triggered.
  • the foregoing 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. String, which can be compared with the account address of the transaction initiator, the account address of the transaction target, the content of the event function, etc. to identify the specific transaction initiator, specific transaction target or specific event function, etc. .
  • the user can use the To field when the user initiates a transaction for a specific transaction target and the exposed field corresponding to the transaction type includes the To field. It is stored in plain text, and when a transaction is initiated for other transaction targets, the To field is not allowed to be stored in plain text to avoid privacy leakage.
  • this specification can further identify the special event function contained in the smart contract corresponding to the transaction, so as to simultaneously satisfy the preset conditions according to the content of the receipt and the special event function contained in the smart contract. Determine how to store receipt data. Therefore, the above step 206 can be improved as: the first blockchain node stores the receipt data so that at least one log field in the log corresponding to the special event function that satisfies the preset condition is stored in plain text, and the receipt The rest of the 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 the smart contract can be divided into special event functions and ordinary event functions.
  • the logs generated by the ordinary event functions are stored in cipher text to achieve privacy protection; the special event functions generated Logs need to store at least part of the log fields (such as the exposed log fields below) in plain text on the premise of meeting the privacy protection requirements, so that the content of this part of the log fields can be retrieved to drive the implementation of related operations .
  • the special event function may be a predefined global event function in the blockchain network.
  • the event function belonging to the "special event function” can be recorded, for example, it can be recorded in the special event function list; accordingly, by combining the event function contained in the smart contract with By comparing the above special event function list, it can be determined whether the event function included in the smart contract is the above special event function.
  • 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 included in the smart contract is as follows:
  • Event buy_candy1 expose(who,candy_num);
  • the smart contract defines 2 events: event buy_candy1 and event buy_candy2.
  • event buy_candy1 By adding the type identifier "expose" to the event buy_candy1, the event buy_candy1 can be marked as the above special event function; correspondingly, since the event buy_candy2 does not contain the type identifier "expose", the event buy_candy2 is a normal event function Instead of the special event function mentioned above.
  • High-level languages supported by Ethereum such as Solidity, Serpent, and LLL languages
  • 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.
  • a corresponding Logs field is generated respectively, that is, a log corresponding to each event function is generated.
  • the log corresponding to the special event function can be further determined, and when at least a part of the log fields corresponding to the special event function meets the preset condition, the at least part of the log fields are allowed to be stored in plain text.
  • all log fields of the log can be compared with corresponding preset conditions, and all log fields that meet the preset conditions are stored in plain text .
  • log fields corresponding to special event functions but satisfying preset conditions, logs corresponding to ordinary event functions, and other receipt contents in receipt data are all stored in cipher text.
  • the exposure log field corresponding to the special event function can be determined, and the exposure log field can be compared with the corresponding preset conditions, so as to satisfy the preset
  • the exposure log field of the condition is stored in clear text.
  • Exposure log fields often involve relatively little privacy content, or do not involve core privacy content, and the risk of storing in plaintext is relatively low; non-exposed log fields may involve relatively more or relatively more important privacy content. Storing in cipher text can ensure that it does not deviate from the core purpose of privacy protection. By judging in combination with preset conditions, it is possible to further filter out the private content that may be contained in the exposed log fields that are not suitable for disclosure, so as to ensure that the retrieval operation can be completed while achieving privacy protection as much as possible.
  • the special event function includes a marked exposure log field.
  • the first blockchain node may determine one or more log fields indicated by the identifier included in the special event function as the aforementioned exposed log field.
  • the code examples of the special event functions included in the smart contract are as follows:
  • Event buy_candy4 show_to(who,candy_num);
  • the smart contract defines 2 events: event buy_candy3 and event buy_candy4.
  • the event buy_candy3 contains the type identifier "expose”. According to the above, the event buy_candy3 can be determined as a special event function. Further, after the type identifier "expose”, the identifier "_from” is included, and the identifier "_from” is used to indicate the log field From, so that in the log Logs generated corresponding to the event buy_candy3, the From field will be stored in plain text. The remaining To field, Topic field, Log data field, etc. are stored in cipher text.
  • the event buy_candy4 does not contain the type identifier "expose”; however, if the event buy_candy4 is the aforementioned predefined special event function, for example, the event buy_candy4 is in the aforementioned special event function list, then it can be determined that the event buy_candy4 is a special event function. Further, the event buy_candy4 contains the identifier "show_to", the identifier "show_to” is used to indicate the log field to, so that in the log Logs generated corresponding to the event buy_candy4, the To field will be stored in plain text, and the remaining From fields , Topic field, Log data field, etc. are stored in cipher text.
  • the special event function can include the encrypted log field indicated by the identifier, and the exposed log field is the remaining log fields.
  • the code examples of the special event functions included in the smart contract are as follows:
  • Event buy_candy5 expose_hide_from(who,candy_num);
  • the smart contract defines 2 events: event buy_candy5 and event buy_candy6.
  • the event buy_candy5 contains the type identifier "expose”. According to the above, the event buy_candy5 can be determined as a special event function. Further, after the type identifier "expose”, the identifier "hide_from” is included, and the identifier "hide_from” is used to indicate the log field From, so that in the log Logs generated corresponding to the event buy_candy5, the From field will be stored in cipher text , And the remaining To field, Topic field, Log data field, etc. are exposed log fields, which are all stored in plain text.
  • the event buy_candy6 does not contain the type identifier "expose”; however, if the event buy_candy6 is the aforementioned predefined special event function, for example, the event buy_candy6 is in the aforementioned special event function list, then it can be determined that the event buy_candy6 is a special event function. Further, the event buy_candy6 contains the identifier "hide_to", and the identifier "hide_to” is used to indicate the log field to, so that in the log Logs generated corresponding to the event buy_candy6, the To field will be stored in cipher text, and the rest of From Fields, Topic fields, Log data fields, etc. are exposed log fields, which are all stored in plain text.
  • identifiers are in high-level languages and smart contracts in the form of bytecodes.
  • the code can be the same, or the smart contract code of the high-level language is the first type of identifier, the bytecode form of the smart contract code is the second type of identifier, and the first type of identifier is the same as the second type of identifier.
  • the identifiers can correspond to each other.
  • the mapping relationship between the special event function and the exposure log field, or the mapping between the special event function and the encrypted log field can be predefined Relationship, so that the first blockchain node can obtain the predefined mapping relationship, and determine the exposure log field corresponding to the special event function according to the special event function included in the smart contract and the mapping relationship.
  • mapping relationship includes “Event buy_candy7-from_to", “Event buy_candy8-topic” and other content
  • the above mapping relationship "Event buy_candy7-from_to” can be queried. Then it can be determined that the exposure log fields corresponding to the event "Event buy_candy7" are the From field and the To field. If the event "Event buy_candy8" is included in the smart contract, the above mapping relationship "Event buy_candy8-topic" can be found by querying The exposure log field corresponding to the event "Event buy_candy8" is the Topic field.
  • the smart contract under the premise of protecting user privacy, by identifying the event functions contained in the smart contract, it is possible to determine the exposed log fields that can be stored in plain text according to the differentiated requirements of different types of event functions for privacy protection , And further according to the satisfaction of the preset conditions by the exposure log field, the corresponding differentiated requirements are reflected in the storage process, and it has high flexibility.
  • the exposure log fields that meet the preset conditions can be stored in plaintext, and the exposure log fields that do not meet the preset conditions or other receipt content can be stored It must be stored in ciphertext.
  • the content of the preset condition may include at least one of the following: the corresponding log field contains the preset content, the value of the corresponding log field belongs to the preset numerical interval, and so on.
  • the aforementioned preset content may include: one or more specified keywords, for example, the keywords may include predefined state variables, predefined intermediate variables, etc., so that when a certain exposed log field contains a state variable as a keyword Or intermediate variables, it can be determined that the exposure log field meets the preset conditions.
  • the foregoing 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.
  • the user can store the To field in plain text when the user initiates a transaction against the account address and the exposure log field corresponding to the transaction type includes the To field. , And when a transaction is initiated against another account address, the To field is not allowed to be stored in plain text to avoid leaking privacy.
  • 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. Therefore, when the value of the exposure log field is within the preset numerical range, the exposure log field can be stored in plain text.
  • the preset conditions may include general conditions corresponding to all log fields, that is, in the log corresponding to the special event function in the receipt data, all log fields contained in the log have a unified preset condition, so that the All exposure log fields contained in the log need to be compared with this unified preset condition.
  • the preset condition is "contains preset keywords”
  • all the exposure log fields in the log corresponding to the special event function can be compared with the keywords contained in the preset condition to determine that the keyword is included
  • the exposure log field of is used as the exposure log field that meets the above preset conditions.
  • the preset condition may include a dedicated condition corresponding to each log field, that is, in the log corresponding to the special event function in the receipt data, each log field contained in the log has a corresponding preset condition. , So that each exposure log field contained in the log is used for comparison with the corresponding preset conditions.
  • the preset conditions corresponding to different log fields are independent of each other, but may be the same or different.
  • the preset condition corresponding to the From field and the To field may be "whether the preset content is included", and the preset content may be a preset account address, indicating a transaction initiated by or directed to the account address.
  • the preset condition corresponding to the Topic field can be "whether it belongs to the preset value range", and the value of the state variable referenced by the related event can be recorded in the Topic field.
  • it can include a value representing "transfer amount” State variable, indicating that when the transfer amount is in the preset value range (usually the small value range corresponding to a smaller amount), the transfer amount is allowed to be stored in plain text (it can be in plain text when the Topic field is an exposure log field) storage).
  • this specification can further identify the exposed identifier contained in the code of the smart contract corresponding to the transaction and the user type of the transaction initiator, thereby simultaneously meeting the preset conditions according to the content of the receipt, Expose the object identified by the identifier and the user type of the transaction initiator, and determine the storage method of the receipt data. Therefore, the above step 206 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 first blockchain node can further identify the user type to which the transaction initiator belongs, so that when the transaction initiator belongs to the preset user type, the above code example 2 ⁇
  • the content of the receipt that was originally determined to need to be stored in plaintext in 9 adopts the storage form of plaintext, and the storage form of ciphertext is adopted for the rest of the receipt content, and in the case that the transaction initiator does not belong to the preset user type, all receipt data is adopted
  • the storage form of the ciphertext is adopted.
  • 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 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.
  • this specification can further identify the exposure identifier contained in the smart contract code corresponding to the transaction and the exposure field corresponding to the transaction type, so as to simultaneously meet the preset conditions according to the content of the receipt,
  • the object indicated by the exposure identifier and the exposed field corresponding to the transaction type determine the storage method of the receipt data. Therefore, the above step 206 can be improved as follows: 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 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.
  • event-level field is the From field, so all the fields in the log generated by the event currentPrice can be used as the aforementioned event-level fields, such as the aforementioned From field, To field, Topic field, Log Data field, etc.
  • the fields are all used to compare with preset conditions, so that the fields that meet the preset conditions are stored in plain text, and the fields that do not meet the preset conditions are stored in cipher text; if the aforementioned From field, To field, Topic field, If the Log Data fields meet the preset conditions, these fields are stored in plain text, which is equivalent to storing all the contents of the receipt corresponding to the event currentPrice in plain text.
  • 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 depends on the transaction selected by the user and has nothing to do with the programming language, so that even when the same smart contract is called for different transactions, 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.
  • this specification can further identify the exposure identifier contained in the code of the smart contract corresponding to the transaction and the special event function contained in the smart contract, thereby simultaneously satisfying preset conditions based on the content of the receipt Circumstances, the object indicated by the exposure identifier and the special event function contained in the smart contract determine the storage method of the receipt data. Therefore, the above step 206 can be improved to: the first blockchain node stores the receipt data, so that at least part of the receipt content in the log corresponding to the special event function is stored in plaintext, and the rest of the receipt data 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 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 receipt content that meets the preset conditions can be selected from the receipt data.
  • the cross content of the above three parts of receipt content can be filtered out, and the cross content can be stored in plaintext.
  • the rest of the receipt data is encrypted. Document storage.
  • the exposed identifier is a global identifier defined in the programming language of the smart contract and is applicable to all smart contracts written in this programming language. Therefore, by defining the exposure identifier in a programming language, so that the code of any smart contract uses the exposure identifier, the storage control of the receipt data can be realized. For example, when a user writes the code of a smart contract, he can mark one or more objects by adding an exposure identifier to the code to indicate that the user wants the receipt content corresponding to this part of the object in the receipt data to be stored in plain text, and the remaining The content of the receipt corresponding to the object marked with the exposed identifier is not allowed to be stored in plain text, and must be stored in cipher text to achieve corresponding privacy protection.
  • the corresponding receipt content is allowed to be stored in plain text; however, this specification can further consider the event functions and preset conditions contained in the smart contract. And from the dimensions of programming language, event function and preset conditions, it is determined whether to store the content of the receipt corresponding to the object marked by the exposure identifier 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 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 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 10, 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 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 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 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 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 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.
  • 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 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 14 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.
  • 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 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 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 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 manual exposes the content of the receipt to a certain extent to realize the driver of the DAPP client or other function extensions.
  • this manual comprehensively considers the object indicated by the exposure identifier, the log generated by the special event function, and the preset conditions, and can accurately select the receipt content for plaintext storage, that is, at the same time satisfying "matching to the object indicated by the exposure identifier", The "logs generated by the special event function” and the receipt content "satisfy the preset conditions", so as to meet the above-mentioned function expansion requirements while ensuring that most user privacy can be protected.
  • 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.
  • this specification can further identify the user type of the transaction initiator and the exposed fields corresponding to the transaction type, so as to simultaneously meet the preset conditions according to the content of the receipt, the user type of the transaction initiator and The exposed field corresponding to the transaction type determines the storage method of the receipt data. Therefore, the above step 206 can be improved as follows: the first blockchain node stores the receipt data, and when the transaction initiator belongs to the preset user type, the exposed fields in the receipt data that meet the preset conditions are stored in plain text, The remaining receipt fields are stored in cipher text.
  • the exposed fields that allow plaintext storage can be determined according to the differentiated needs of different types of transactions for privacy protection; further, the needs of different types of users for privacy protection It is not the same.
  • the transaction initiator belongs to the preset user type
  • it is allowed to trigger the DAPP client to implement related follow-up operations by exposing part of the receipt content to improve convenience, while other types of users may not be allowed to expose private information;
  • the privacy protection requirements can be reflected in the storage process according to the satisfaction of the preset conditions by the exposed fields.
  • Differentiated requirements and processing for protection for example: By comparing the exposed fields in the receipt data with preset conditions, the exposed fields that meet the preset conditions can be stored in plain text, and the exposed fields that do not meet the preset conditions or other The receipt field must be stored in ciphertext.
  • the content of the preset condition may include at least one of the following: the corresponding receipt field contains the preset content, the value of the corresponding receipt field belongs to 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 used to indicate the result of transaction execution, etc., so that when an exposed field contains When the state variable, event function, or transaction execution result is used as a keyword, it can be determined that the exposed field meets the preset conditions.
  • the transaction execution result can include: “success” means the transaction is successful, “fail” means the transaction failed; on the premise that the transaction initiator belongs to the preset user type, when the keyword is "success", it includes The exposed fields of "success” will be stored in clear text, while the exposed fields containing "fail” and other types of receipt fields are not allowed to be stored in clear text to ensure that successful transactions will be viewed and subsequent operations will be triggered.
  • 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. String, which can be compared with the account address of the transaction initiator, the account address of the transaction target, the content of the event function, etc. to identify the specific transaction initiator, specific transaction target or specific event function, etc. .
  • the user can initiate a transaction for a specific transaction target with the transaction type provided that the transaction initiator belongs to the preset user type
  • the corresponding exposed fields include the To field
  • the To field is stored in clear text
  • the To field is not allowed to be stored in clear text to avoid privacy leakage.
  • 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. Therefore, under the premise that the transaction initiator belongs to the preset user type, when the value of the exposed field is within the preset numerical range, the exposed field can be stored in plain text.
  • the preset condition may include a general condition corresponding to all receipt fields in the receipt data, that is, when any receipt field in the receipt data is identified as an exposed field, it is used for comparison with the preset condition.
  • the preset condition is "Contains preset keywords”
  • all the exposed fields in the receipt data can be compared with the keywords contained in the preset conditions to determine the exposed fields containing the keywords, as The exposed fields that meet the above preset conditions.
  • the preset condition may include a dedicated condition corresponding to each receipt field in the receipt data, that is, each receipt field in the receipt data has a corresponding preset condition, so that each determined exposed field is Used to compare with the corresponding preset conditions.
  • the preset conditions corresponding to different receipt fields are independent of each other, but may be the same or different.
  • the preset condition corresponding to the From field and the To field may be "whether the preset content is included", and the preset content may be a preset account address, indicating a transaction initiated by or directed to the account address. It is allowed to store the From field or To field in plain text (it can be stored in plain text when the transaction initiator belongs to the preset user type and the From field or To field is an exposed field).
  • the preset condition corresponding to the Topic field can be "whether it belongs to the preset value range", and the value of the state variable referenced by the related event can be recorded in the Topic field.
  • it can include a value representing "transfer amount” State variable, indicating that when the transfer amount is in the preset value range (usually the small value range corresponding to the smaller amount), the transfer amount is allowed to be stored in plain text (it can be used when the transaction initiator belongs to the preset user type and Topic When the field is an exposed field, it is stored in plain text).
  • this manual can further identify the user type of the transaction initiator and the special event function contained in the smart contract corresponding to the transaction, so as to simultaneously meet the preset conditions and the transaction initiation according to the content of the receipt
  • the user type of the party and the special event function contained in the smart contract determine the storage method of the receipt data. Therefore, the above step 206 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 the log corresponding to the special event function meets the preset condition One log field is stored in plain text, and the rest of the receipt data is stored in cipher text. When the transaction initiator does not belong to the preset user type, the receipt data is stored in cipher text.
  • this specification can further identify the exposed fields corresponding to the transaction type and the special event function contained in the smart contract corresponding to the transaction, so as to simultaneously meet the preset conditions and transaction type according to the content of the receipt
  • the corresponding exposed fields and special event functions contained in the smart contract determine the storage method of the receipt data. Therefore, the above step 206 can be improved as: the first blockchain node stores the receipt data, so that the exposed fields in the log corresponding to the special event function that meet the preset conditions are stored in plaintext, and the receipt data The rest of the content is stored in cipher text.
  • the exposed fields allowed to be stored in plaintext can be determined according to the differentiated requirements of different types of transactions for privacy protection; further, because different event functions often involve different information , So that different event functions correspond to different privacy protection requirements.
  • the privacy protection requirements of event functions related to the transfer amount are relatively high, and the privacy protection requirements of event functions related to evidence are relatively low (here only for example ;
  • the privacy protection requirement of the related event function may also be relatively low, and when the deposit content is more important, the privacy protection requirement of the related event function may also be relatively high
  • the event function with relatively low privacy protection requirements can be configured as the above special event function, and when the above exposed field is included in the log generated by the special event function, the receipt content corresponding to the exposed field is allowed to be exposed; furthermore, even For the exposed fields in the logs generated by the special event function, there are still differentiated privacy protection requirements in different scenarios.
  • the difference in privacy protection can be reflected in the storage process according to the satisfaction of the preset conditions by the exposed fields Modification requirements and processing:
  • the exposed fields that meet the preset conditions can be stored in plaintext, while the exposed fields or other receipt fields that do not meet the preset conditions are inevitable Stored in cipher text.
  • a special event function involves a deposit operation
  • the exposed field can be Store in plain text, otherwise store in cipher text.
  • the content of the preset condition may include at least one of the following: the corresponding receipt field contains the preset content, the value of the corresponding receipt field belongs to the preset numerical interval, and so on.
  • the preset content may include: one or more specified keywords, for example, the keyword may include predefined state variables, predefined intermediate variables, etc., so that when a certain exposed field contains a state variable or intermediate variable as a keyword It can be determined that the exposed field 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.
  • the exposed field corresponding to the transaction type includes the To field
  • the log generated by the special event function includes the To field
  • the To field in the log generated by the special event function is stored in plain text
  • the To field in the log generated by the ordinary event function is stored in cipher text
  • the To field in all logs is stored in cipher text to avoid leakage of privacy.
  • 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. Therefore, for the log generated by the special event function, when the value of the exposed field in the log is within the preset numerical interval, the exposed field can be stored in plain text.
  • the preset condition may include a general condition corresponding to all receipt fields in the receipt data, that is, when any receipt field in the receipt data is identified as an exposed field, it is used for comparison with the preset condition.
  • a general condition corresponding to all receipt fields in the receipt data that is, when any receipt field in the receipt data is identified as an exposed field, it is used for comparison with the preset condition.
  • the preset condition is "contains preset keywords”
  • all exposed fields in the log generated by the special event function can be compared with the keywords contained in the preset condition to determine that the key is included
  • the exposed field of the word is used as the exposed field that meets the above preset conditions.
  • the preset condition may include a dedicated condition corresponding to each receipt field in the receipt data, that is, each receipt field in the receipt data has a corresponding preset condition, so that each determined exposed field is Used to compare with the corresponding preset conditions.
  • the preset conditions corresponding to different receipt fields are independent of each other, but may be the same or different.
  • the preset condition corresponding to the From field may be "whether the preset content is included”
  • the preset content may be a preset account address, indicating a transaction initiated by the account address
  • the preset condition corresponding to the Topic field may be "Whether 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 log generated by the special event function contains the From field and the Topic field as exposed fields, the From field is suitable for comparison with the preset condition "Does it contain preset content", and the Topic field is suitable for comparing with the preset condition" Whether it belongs to the preset value range" for comparison.
  • this specification can further identify the exposed identifier contained in the code of the smart contract corresponding to the transaction, the user type of the transaction initiator, and the exposed field corresponding to the transaction type, so as to simultaneously compare the contents of the receipt
  • the satisfaction of the preset conditions, the object indicated by the exposure identifier, the user type of the transaction initiator, and the exposure field corresponding to the transaction type determine the storage method of the receipt data. Therefore, the above step 206 can be improved as: 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 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.
  • the exposed identifier is a global identifier defined in the programming language of the smart contract, it is difficult to modify the fields marked by the exposed identifier as long as the exposed identifier is written in the smart contract. Therefore, by combining the consideration of user types, transaction types, and preset conditions, it is possible to more accurately select and use plain text based on the user type of the transaction initiator, the exposure field corresponding to the transaction type, and the satisfaction of the preset conditions by the content of the receipt.
  • the fields stored in the form are not only determined based on the exposed identifier, so that when different users call the same smart contract, or call the same smart contract through different types of transactions, or use differentiated preset conditions, the plaintext stored
  • the fields are matched with user types, transaction types and preset conditions, so that the storage method of receipt data can meet the actual needs in different situations, and can take into account privacy protection and function expansion. It can be seen that by exposing the content of the receipt to a certain extent, this manual can be used to drive the DAPP client or expand other functions. In addition, this manual can accurately select the fields for clear text storage by comprehensively considering the fields indicated by the exposure identifier, the exposed fields corresponding to the transaction type, the user type of the transaction initiator and the content of the receipt to meet the preset conditions. At the same time, it satisfies the fields of "indicated by the exposed identifier", "matched to the transaction type” and "satisfy the preset conditions", so as to meet the above functional expansion requirements while ensuring that most user privacy can
  • 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. Users can choose to initiate different types of transactions based on actual conditions, that is, transaction types have nothing to do with programming languages.
  • 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.
  • this specification can further identify the exposure identifier contained in the code of the smart contract corresponding to the transaction, the user type of the transaction initiator, and the special event function contained in the smart contract corresponding to the transaction.
  • the storage method of the receipt data is determined. Therefore, the above step 206 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 rest of the receipt data is stored in cipher text.
  • the at least a part of the receipt content matches the object indicated by the exposure identifier and meets preset conditions.
  • the transaction initiator does not belong to the preset In the case of the user type, the receipt data is stored in cipher text.
  • this specification can further identify the exposed identifier contained in the code of the smart contract corresponding to the transaction, the exposed field corresponding to the transaction type, and the special event function contained in the smart contract corresponding to the transaction.
  • the object indicated by the exposure identifier, 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 206 can be improved to: the first blockchain node stores the receipt data, so that at least part of the receipt content in the log corresponding to the special event function is stored in plaintext, and the rest of the receipt data It is stored in a ciphertext form, and the at least a part of the receipt content includes exposed fields that are marked by the exposure identifier and meet a preset condition.
  • the exposed identifier plain is added to the front of the code of the smart contract. From the perspective of the programming language, the exposed identifier plain indicates that after the code of the smart contract is executed, the generated receipt data All fields of are allowed to be stored in plain text, so subsequent retrieval operations can be performed on the receipt content in these fields. For example, for the From field, it can be used to count the transaction volume initiated by an account. By further combining dimensions such as transaction type, event function, and preset conditions, the storage scheme for receipt data may be different.
  • the From field in the receipt data may not all be stored in plain text, but the event currentPrice
  • the From field in the log generated by the event currentPrice is stored in plain text, otherwise it is stored in cipher text.
  • the exposed identifier can indicate one or more fields, and these fields have corresponding receipt content in the receipt data. Different types of transactions often have different privacy protection requirements, and the corresponding exposed fields can be allowed to be stored in plain text.
  • 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.
  • 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; at the same time, 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.
  • the code of a smart contract contains multiple event functions
  • the exposed identifier "plain" is located at the forefront of the code of the smart contract, so that all fields in the receipt data are marked as contract-level fields; at the same time, smart The contract contains the event currentPrice1 and event currentPrice2: Assume that the From field is the exposed field corresponding to the transaction type, and the event currentPrice1 corresponds to the special event function defined in the special event function list, and the event currentPrice2 corresponds to the normal event function.
  • the From field contained in log Log1 is stored in plain text when the preset conditions are met, and the From field contained in log Log2 is stored in cipher text; similarly, the exposed fields in log Log1 Other fields are also stored in plain text, non-exposed fields are stored in cipher text, and all fields of log Log2 are stored in cipher text.
  • the event currentPrice2 is updated to correspond to the special event function after the special event function list is updated, then all the fields contained in the log Log2 that belong to the exposed fields and meet the preset conditions will be stored in plain text, without the need for smart Make any changes to the contract code.
  • the aforementioned type identifier can be used to indicate whether the event function included in the smart contract is a special event function.
  • the contract-level fields include all fields in the receipt data; at the same time, the smart contract contains the event currentPrice1 and the event currentPrice2: because the event currentPrice1 contains the same as before
  • the type identifier expose mentioned above makes the event currentPrice1 marked as corresponding to the special event function, while the event currentPrice2 does not contain the type identifier expose, so that the event currentPrice2 is marked as corresponding to the normal event function, then the event currentPrice1 and event currentPrice2 In the generated logs Log1 and Log2, all the exposed fields corresponding to the transaction type in the log Log1 are stored in plain text when the preset conditions are met, and all the fields contained in the log Log2 must be stored in cipher text.
  • 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 From field Take the From field as an example.
  • the event currentPrice1 does not add the exposed identifier "plain", it contains the content "from”.
  • the content "from” corresponds to the From field and is used to indicate the event currentPrice1.
  • the From field in the generated log needs to be stored in plain text, so the content "from” not only belongs to the above exposed identifier, but also indicates the From field that needs to be stored in plain text. Moreover, since the content "from" is in the event currentPrice1, the From field is an event-level field, so that when the From field is an exposed field corresponding to the transaction type and the event currentPrice1 corresponds to a special event function, the log generated in the event currentPrice1 corresponds to In Logs, the From field will be stored in plain text when the preset conditions are met, and in cipher text when the preset conditions are not met, and other fields must be stored in cipher text.
  • the above keyword "from” indicates that the From field is set as an event-level field; however, in other embodiments, the specific field may not be specified.
  • the above code sample 4 can be adjusted to the following code sample 17:
  • the generated logs are stored in plain text.
  • whether the event function contained in the smart contract is a special event function can be identified by means of a special event function list or type identifier. Do not repeat them one by one.
  • this manual can further identify 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 corresponding to the transaction, so as to set preset values based on the content of the receipt.
  • the satisfaction of the conditions, the user type of the transaction initiator, the exposed fields corresponding to the transaction type, and the special event function contained in the smart contract determine the storage method of the receipt data. Therefore, the above step 206 can be improved to: the first blockchain node stores the receipt data, and when the transaction initiator belongs to the preset user type, the log corresponding to the special event function is exposed to the preset condition.
  • the fields are stored in plain text, and the rest of the receipt data is stored in cipher text.
  • this specification can further identify the exposed identifier contained in the smart contract code corresponding to the transaction, the user type of the transaction initiator, the exposed field corresponding to the transaction type, and the smart contract location corresponding to the transaction.
  • the special event function included so as to determine at the same time according to the content of the receipt to meet the preset conditions, the object indicated by the exposure identifier, 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 How to store receipt data.
  • the above step 206 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 exposed identifier plain is added to the front of the smart contract code, so that after the smart contract code is executed, when the transaction initiator belongs to the preset user type, the receipt data is generated by the special event function
  • the log allows the exposed field corresponding to the transaction type of the transaction to which the smart contract belongs and the content of the receipt meeting preset conditions is stored in clear text.
  • the From field of all logs in the receipt data can be stored in plain text when the preset conditions are met, and the To field is stored in cipher text. Then, subsequent retrieval operations can be performed on the receipt content in the From field, for example, a certain account can be counted The volume of transactions initiated, etc.
  • the exposed identifier can indicate one or more fields, and these fields have corresponding receipt content in the receipt data.
  • the exposed fields corresponding to the transaction type may be one or more fields in the receipt data, and these fields 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 receipt content that meets the preset condition in the receipt data can be filtered out.
  • the cross content of the above four parts of receipt content can be filtered out. And implement clear text storage for the cross content, and the rest of the receipt data is stored in cipher text.
  • 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.
  • the user who is the transaction initiator belongs to the preset user type and the To field is an exposed field
  • the user can When the address initiates the transaction and the To field is marked by the exposed identifier, the To field in the log can be stored in plain text when the preset conditions are met, and stored in cipher text when the preset conditions are not met, and other The From field must be stored in cipher text to avoid privacy leakage.
  • 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 field marked 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 field 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 field indicated by the exposure identifier belongs to 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 field 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 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.
  • the code of the smart contract contains multiple event functions
  • the respective Logs fields generated by the multiple event functions there may be the receipt content corresponding to the contract-level field;
  • the transaction can be identified by The user type to which the initiator belongs, the exposed fields corresponding to the transaction type of the transaction, the type of each event function is ordinary event function or special event function, and the content of the receipt meets the preset conditions, so that the transaction initiator belongs to the preset user type
  • the contract-level field is an exposed field, the contents of the receipt corresponding to the contract-level field and satisfying the preset conditions in the logs generated by all special event functions are stored in plain text.
  • the exposed identifier "plain" is located at the forefront of the code of the smart contract, so that all fields in the receipt data are marked as contract-level fields; at the same time, smart The contract contains the event currentPrice1 and the event currentPrice2: assuming that the event currentPrice1 corresponds to the special event function defined in the special event function list, and the event currentPrice2 corresponds to the normal event function, then the transaction initiator belongs to the preset user type and the From field is an exposed field
  • the From field contained in the log Log1 is stored in plain text when the preset conditions are met, and in cipher text when the preset conditions are not met
  • the From field contained in log Log2 must be stored in cipher text; similarly, other fields in log Log1 that are exposed fields are also stored in plain text when the preset conditions are met, and non-exposed fields are stored in cipher text.
  • All the fields of the log Log2 are stored in cipher text. Moreover, if the event currentPrice2 is updated to correspond to the special event function after updating the list of special event functions, all the fields belonging to the exposed fields contained in the log Log2 can be stored in plain text under the condition that the preset conditions are met. If the preset conditions are not met, it is stored in ciphertext form, without any changes to the code of the smart contract.
  • the aforementioned type identifier can be used to indicate whether the event function included in the smart contract is a special event function.
  • the contract-level fields include all fields in the receipt data; at the same time, the smart contract contains the event currentPrice1 and the event currentPrice2: because the event currentPrice1 contains the same as before
  • the type identifier expose mentioned above makes the event currentPrice1 be marked as corresponding to the special event function, and the event currentPrice2 does not contain the type identifier expose, so that the event currentPrice2 is marked as corresponding to the normal event function, then the event currentPrice2 is marked as corresponding to the normal event function.
  • 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. Take the From field as an example.
  • the event currentPrice1 does not add the exposed identifier "plain", it contains the content "from”.
  • the content "from” corresponds to the From field and is used to indicate the event currentPrice1.
  • the From field in the generated log needs to be stored in plain text, so the content "from” not only belongs to the above exposed identifier, but also indicates the From field that needs to be stored in plain text. Moreover, since the content "from" is in the event currentPrice1, the From field is an event-level field, so that when the transaction initiator belongs to the preset user type and the From field is an exposed field, when the event currentPrice1 corresponds to a special event function In the log Logs corresponding to the event currentPrice1, the From field is stored in plain text when the preset conditions are met, and stored in cipher text when the preset conditions are not met, and other fields must be stored in cipher text Form storage.
  • the generated log Logs are in the form of ciphertext storage.
  • this code example 14 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 manual exposes the content of the receipt to a certain extent to realize the driver of the DAPP client or other function extensions.
  • this manual considers the user type of the transaction initiator, the exposed field corresponding to the transaction type, the field indicated by the exposure identifier, the log generated by the special event function, and the content of the receipt to meet the preset conditions, and can accurately select the application.
  • the content of the receipt stored in plaintext meets the requirements of "transaction initiator belongs to the preset user type", “belongs to the exposed field corresponding to the transaction type", “matches the field indicated by the exposure identifier”, and “belongs to the log generated by the special event function” "” and “meeting the preset conditions”, so as to meet the above-mentioned function expansion requirements, while ensuring that most of the user privacy can be protected.
  • the first blockchain node recognizes the special event function based on the information recorded on the blockchain network (such as the list of special event functions), it can perform the "special event function" after the smart contract has been created. Update to adjust the storage method of receipt data, such as changing the original receipt content stored in plain text to cipher text storage, or changing the original receipt content stored in cipher text to plain text storage.
  • the above-expanded embodiments can also implement corresponding logic functions through chain codes, or adopt a combination of chain codes and system contracts.
  • the embodiment shown in FIG. 2 adopts receipt data storage logic related to receipt content that meets preset conditions in receipt data
  • the expanded embodiment described above further considers at least one of the following factors on this basis : Expose the object indicated by the identifier, the user type of the transaction initiator, the transaction type, and the event function contained in the smart contract.
  • One or more of the above factors can be combined with the user type to obtain the corresponding receipt data storage logic.
  • the receipt data storage logic When the receipt data storage logic is related to the object indicated by the exposure identifier, the receipt data storage logic includes logic for storing the content of the receipt based on the exposure identifier, and the logic is used to instruct the first blockchain node: to indicate the exposure identifier The corresponding receipt content should be stored in the fields of, and fields not marked by the exposed identifier.
  • 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 type field contained in the exchange, determine the transaction type corresponding to the transaction. For details, please refer to the relevant description of identifying transaction types above, which will not be repeated here.
  • the 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: identification logic for the event function.
  • the identification logic of the event function is used to instruct the first blockchain node to identify the type of event function contained in the smart contract corresponding to the transaction. For example: according to the type identifier contained in the event function, or according to the list of special event functions recorded in the blockchain network. For details, please refer to the relevant description of identifying special event functions above, which will not be repeated here.
  • the receiving unit 61 receives the encrypted transaction
  • the decryption unit 62 decrypts the transaction in the trusted execution environment to obtain the transaction content
  • the execution unit 63 executes the transaction content to obtain receipt data
  • the storage unit 64 stores the receipt data, so that at least part of the receipt content that meets the preset conditions in the receipt data is stored in plain text, and the rest of the receipt content is stored in cipher text.
  • the storage unit 64 is specifically configured to:
  • the code of the system contract is executed to store at least part of the receipt content that meets the preset condition in the receipt data in plain text, and the rest of the receipt content 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 preset condition is in the transaction; or,
  • the preset condition is located in the smart contract called by the transaction; or,
  • the preset condition is located in another smart contract called by the smart contract called by the transaction.
  • 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 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 storage unit 64 is specifically used for:
  • the receipt data is stored so that the transaction initiator belongs to a preset user type
  • at least a part of the receipt content that meets the preset condition in the receipt data is stored in plain text
  • the rest of the receipt content is stored in cipher text.
  • the user type to which the transaction initiator belongs is determined 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 65 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 meets at least one of the following rules:
  • the at least a part of the receipt content corresponds to the exposed field corresponding to 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 corresponding to the transaction;
  • the at least a part of the receipt content corresponds to the object indicated by the exposure identifier contained in the code of the smart contract.
  • the 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 smart contract corresponding to the transaction received by the receiving unit 61 includes:
  • the smart contract written in the high-level language and the smart contract in bytecode form have the same or corresponding exposure identifier.
  • the objects indicated by the exposure identifier include: receipt fields and/or state variables.
  • the object indicated by the exposure identifier includes at least one of the following: a contract-level object applicable to all events defined in the smart contract, and an event-level object corresponding to at least one event defined in the smart contract Object.
  • the storage unit 64 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 key used by the first blockchain node to encrypt the receipt data includes: a key of a symmetric encryption algorithm or a key of an asymmetric encryption algorithm.
  • 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 62 is specifically configured to:
  • 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
  • VHDL Very-High-Speed Integrated Circuit Hardware Description Language
  • 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. Examples of controllers include but are not limited to the following microcontrollers: ARC625D, Atmel AT91SAM, Microchip PIC18F26K20 and Silicon Labs C8051F320, the memory controller can also be implemented as part of the memory control logic.
  • 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”.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Computing Systems (AREA)
  • Finance (AREA)
  • Data Mining & Analysis (AREA)
  • General Engineering & Computer Science (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

L'invention concerne un procédé et un nœud de stockage de reçu basés sur une condition de détermination. Ledit procédé peut comprendre les étapes suivantes : un premier nœud de chaîne de blocs reçoit une transaction chiffrée (202) ; le premier nœud de chaîne de blocs déchiffre la transaction dans un environnement d'exécution de confiance et exécute le contenu de transaction obtenu pour obtenir des données de réception (204) ; et le premier nœud de chaîne de blocs stocke les données de réception de telle sorte qu'au moins une partie du contenu de reçu dans les données de reçu satisfaisant une condition prédéfinie est stockée sous forme de texte en clair, et le contenu de réception restant est stocké sous forme de texte chiffré (206).
PCT/CN2020/089386 2019-05-20 2020-05-09 Procédé et nœud de stockage de reçu basés sur une condition de détermination WO2020233425A1 (fr)

Applications Claiming Priority (28)

Application Number Priority Date Filing Date Title
CN201910419925.2A CN110263089B (zh) 2019-05-20 2019-05-20 结合交易与事件类型的条件限制的收据存储方法和节点
CN201910419913.XA CN110245503B (zh) 2019-05-20 2019-05-20 结合代码标注与判断条件的收据存储方法和节点
CN201910419900.2A CN110245490B (zh) 2019-05-20 2019-05-20 有条件的结合代码标注与类型维度的收据存储方法和节点
CN201910420668.4A CN110264198B (zh) 2019-05-20 2019-05-20 结合代码标注与交易类型的有条件的收据存储方法和节点
CN201910420675.4A CN110263544B (zh) 2019-05-20 2019-05-20 结合交易类型和判断条件的收据存储方法和节点
CN201910419959.1 2019-05-20
CN201910419908.9A CN110223172B (zh) 2019-05-20 2019-05-20 有条件的结合代码标注与类型维度的收据存储方法和节点
CN201910419170.6A CN110245943B (zh) 2019-05-20 2019-05-20 基于判断条件的收据存储方法和节点
CN201910419898.9A CN110263087B (zh) 2019-05-20 2019-05-20 基于多维度信息且具有条件限制的收据存储方法和节点
CN201910420680.5A CN110245947B (zh) 2019-05-20 2019-05-20 结合交易与用户类型的条件限制的收据存储方法和节点
CN201910419900.2 2019-05-20
CN201910419907.4A CN110263088B (zh) 2019-05-20 2019-05-20 结合代码标注与事件类型的有条件的收据存储方法和节点
CN201910419136.9A CN110245942B (zh) 2019-05-20 2019-05-20 结合用户类型和判断条件的收据存储方法和节点
CN201910419943.0 2019-05-20
CN201910419893.6 2019-05-20
CN201910420675.4 2019-05-20
CN201910419908.9 2019-05-20
CN201910419907.4 2019-05-20
CN201910419170.6 2019-05-20
CN201910419898.9 2019-05-20
CN201910419959.1A CN110264197B (zh) 2019-05-20 2019-05-20 结合事件函数类型和判断条件的收据存储方法和节点
CN201910419943.0A CN110245504B (zh) 2019-05-20 2019-05-20 结合多类型维度的条件限制的收据存储方法和节点
CN201910419893.6A CN110264196B (zh) 2019-05-20 2019-05-20 结合代码标注与用户类型的有条件的收据存储方法和节点
CN201910419925.2 2019-05-20
CN201910420680.5 2019-05-20
CN201910419136.9 2019-05-20
CN201910420668.4 2019-05-20
CN201910419913.X 2019-05-20

Publications (1)

Publication Number Publication Date
WO2020233425A1 true WO2020233425A1 (fr) 2020-11-26

Family

ID=73458348

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2020/089386 WO2020233425A1 (fr) 2019-05-20 2020-05-09 Procédé et nœud de stockage de reçu basés sur une condition de détermination

Country Status (1)

Country Link
WO (1) WO2020233425A1 (fr)

Citations (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107294709A (zh) * 2017-06-27 2017-10-24 阿里巴巴集团控股有限公司 一种区块链数据处理方法、装置及系统
CN107342858A (zh) * 2017-07-05 2017-11-10 武汉凤链科技有限公司 一种基于可信环境的智能合约保护方法和系统
CN108021821A (zh) * 2017-11-28 2018-05-11 北京航空航天大学 多中心区块链交易隐私保护系统及方法
US20180343114A1 (en) * 2015-11-24 2018-11-29 Adi BEN-ARI A system and method for blockchain smart contract data privacy
CN110223172A (zh) * 2019-05-20 2019-09-10 阿里巴巴集团控股有限公司 有条件的结合代码标注与类型维度的收据存储方法和节点
CN110245490A (zh) * 2019-05-20 2019-09-17 阿里巴巴集团控股有限公司 有条件的结合代码标注与类型维度的收据存储方法和节点
CN110245942A (zh) * 2019-05-20 2019-09-17 阿里巴巴集团控股有限公司 结合用户类型和判断条件的收据存储方法和节点
CN110245504A (zh) * 2019-05-20 2019-09-17 阿里巴巴集团控股有限公司 结合多类型维度的条件限制的收据存储方法和节点
CN110245947A (zh) * 2019-05-20 2019-09-17 阿里巴巴集团控股有限公司 结合交易与用户类型的条件限制的收据存储方法和节点
CN110245503A (zh) * 2019-05-20 2019-09-17 阿里巴巴集团控股有限公司 结合代码标注与判断条件的收据存储方法和节点
CN110245943A (zh) * 2019-05-20 2019-09-17 阿里巴巴集团控股有限公司 基于判断条件的收据存储方法和节点
CN110264196A (zh) * 2019-05-20 2019-09-20 阿里巴巴集团控股有限公司 结合代码标注与用户类型的有条件的收据存储方法和节点
CN110263088A (zh) * 2019-05-20 2019-09-20 阿里巴巴集团控股有限公司 结合代码标注与事件类型的有条件的收据存储方法和节点
CN110264197A (zh) * 2019-05-20 2019-09-20 阿里巴巴集团控股有限公司 结合事件函数类型和判断条件的收据存储方法和节点
CN110264198A (zh) * 2019-05-20 2019-09-20 阿里巴巴集团控股有限公司 结合代码标注与交易类型的有条件的收据存储方法和节点
CN110263544A (zh) * 2019-05-20 2019-09-20 阿里巴巴集团控股有限公司 结合交易类型和判断条件的收据存储方法和节点
CN110263089A (zh) * 2019-05-20 2019-09-20 阿里巴巴集团控股有限公司 结合交易与事件类型的条件限制的收据存储方法和节点
CN110263087A (zh) * 2019-05-20 2019-09-20 阿里巴巴集团控股有限公司 基于多维度信息且具有条件限制的收据存储方法和节点

Patent Citations (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180343114A1 (en) * 2015-11-24 2018-11-29 Adi BEN-ARI A system and method for blockchain smart contract data privacy
CN107294709A (zh) * 2017-06-27 2017-10-24 阿里巴巴集团控股有限公司 一种区块链数据处理方法、装置及系统
CN107342858A (zh) * 2017-07-05 2017-11-10 武汉凤链科技有限公司 一种基于可信环境的智能合约保护方法和系统
CN108021821A (zh) * 2017-11-28 2018-05-11 北京航空航天大学 多中心区块链交易隐私保护系统及方法
CN110245947A (zh) * 2019-05-20 2019-09-17 阿里巴巴集团控股有限公司 结合交易与用户类型的条件限制的收据存储方法和节点
CN110264196A (zh) * 2019-05-20 2019-09-20 阿里巴巴集团控股有限公司 结合代码标注与用户类型的有条件的收据存储方法和节点
CN110245942A (zh) * 2019-05-20 2019-09-17 阿里巴巴集团控股有限公司 结合用户类型和判断条件的收据存储方法和节点
CN110245504A (zh) * 2019-05-20 2019-09-17 阿里巴巴集团控股有限公司 结合多类型维度的条件限制的收据存储方法和节点
CN110223172A (zh) * 2019-05-20 2019-09-10 阿里巴巴集团控股有限公司 有条件的结合代码标注与类型维度的收据存储方法和节点
CN110245503A (zh) * 2019-05-20 2019-09-17 阿里巴巴集团控股有限公司 结合代码标注与判断条件的收据存储方法和节点
CN110245943A (zh) * 2019-05-20 2019-09-17 阿里巴巴集团控股有限公司 基于判断条件的收据存储方法和节点
CN110245490A (zh) * 2019-05-20 2019-09-17 阿里巴巴集团控股有限公司 有条件的结合代码标注与类型维度的收据存储方法和节点
CN110263088A (zh) * 2019-05-20 2019-09-20 阿里巴巴集团控股有限公司 结合代码标注与事件类型的有条件的收据存储方法和节点
CN110264197A (zh) * 2019-05-20 2019-09-20 阿里巴巴集团控股有限公司 结合事件函数类型和判断条件的收据存储方法和节点
CN110264198A (zh) * 2019-05-20 2019-09-20 阿里巴巴集团控股有限公司 结合代码标注与交易类型的有条件的收据存储方法和节点
CN110263544A (zh) * 2019-05-20 2019-09-20 阿里巴巴集团控股有限公司 结合交易类型和判断条件的收据存储方法和节点
CN110263089A (zh) * 2019-05-20 2019-09-20 阿里巴巴集团控股有限公司 结合交易与事件类型的条件限制的收据存储方法和节点
CN110263087A (zh) * 2019-05-20 2019-09-20 阿里巴巴集团控股有限公司 基于多维度信息且具有条件限制的收据存储方法和节点

Similar Documents

Publication Publication Date Title
WO2020233616A1 (fr) Procédé de stockage de reçu et nœud utilisant un marquage de code en combinaison avec un type de transaction et un type d'utilisateur
WO2020233644A1 (fr) Procédé de stockage de reçu conditionnel et nœud combinant des dimensions de type de code et d'annotation
WO2020233642A1 (fr) Procédé de stockage de reçu conditionnel et nœud qui combinent un marquage de code et une dimension de type
WO2020233612A1 (fr) Procédé et nœud de stockage de reçu combinant une annotation de code avec des types de transaction et d'événement
WO2020233643A1 (fr) Procédé et nœud de stockage de reçu utilisant des informations multidimensionnelles et ayant une restriction
WO2020233613A1 (fr) Procédé et noeud de stockage de reçu conditionnel qui combinent le marquage de code avec un type de transaction
WO2020233638A1 (fr) Procédé et nœud de mémorisation de reçus basés sur un marquage de codes et sur un type de transaction
WO2020233623A1 (fr) Procédé de stockage de reçu et nœud combinant un type de transaction et un état d'évaluation
WO2020233609A1 (fr) Procédé de stockage de réception conditionnel et nœud combinant le marquage de code avec le type d'utilisateur
WO2020233610A1 (fr) Procédé de stockage de reçu combinant un marquage de code avec un type d'utilisateur et d'événement, et nœud
WO2020233622A1 (fr) Procédé de stockage de reçus et nœud sur la base d'un étiquetage de code et de multiples types de dimensions
WO2020233637A1 (fr) Procédé de stockage de reçu combinant un marquage de code avec un type d'utilisateur, et nœud
WO2020233640A1 (fr) Procédé de mémorisation de reçus et nœud basés sur un marquage de code et condition de détermination
WO2020233626A1 (fr) Procédé et nœud de stockage de reçu combinés à une limitation conditionnelle de types de transactions et d'utilisateurs
WO2020233614A1 (fr) Procédé et nœud de stockage de reçu conditionnel combinant un étiquetage de code avec un type d'événement
WO2020233635A1 (fr) Procédé de stockage de reçu combinant des restrictions conditionnelles de multiples types de dimensions et nœud
WO2020233625A1 (fr) Procédé de stockage de reçus combinant un type d'utilisateur, des conditions de détermination et un nœud
WO2020233630A1 (fr) Procédé et nœud de mémorisation de reçus en fonction du type d'utilisateur
WO2020233615A1 (fr) Procédé de stockage de reçu combinant un type d'utilisateur et un type de fonction d'événement et nœud
WO2020233628A1 (fr) Procédé et nœud de stockage de reçu basés sur une combinaison d'un type de fonction d'événement et d'une condition d'évaluation
WO2020233639A1 (fr) Procédé de stockage de reçus et nœud basés sur l'étiquetage de code et le type de fonction d'événement
WO2020233624A1 (fr) Procédé de mémorisation de reçus et nœud utilisant un type de transaction en combinaison avec un type de fonction d'événement
WO2020233619A1 (fr) Procédé et nœud de stockage de reçu en combinaison avec un type d'utilisateur et un type de transaction
WO2020233627A1 (fr) Procédé et nœud de stockage de reçu basés sur de multiples types de dimensions
WO2020233629A1 (fr) Procédé et nœud de stockage de reçu au niveau d'un objet sur la base d'un marquage de code

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

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

Country of ref document: EP

Kind code of ref document: A1