WO2020233625A1 - 结合用户类型和判断条件的收据存储方法和节点 - Google Patents

结合用户类型和判断条件的收据存储方法和节点 Download PDF

Info

Publication number
WO2020233625A1
WO2020233625A1 PCT/CN2020/091398 CN2020091398W WO2020233625A1 WO 2020233625 A1 WO2020233625 A1 WO 2020233625A1 CN 2020091398 W CN2020091398 W CN 2020091398W WO 2020233625 A1 WO2020233625 A1 WO 2020233625A1
Authority
WO
WIPO (PCT)
Prior art keywords
transaction
receipt
preset
user type
blockchain node
Prior art date
Application number
PCT/CN2020/091398
Other languages
English (en)
French (fr)
Inventor
刘琦
闫莺
魏长征
Original Assignee
创新先进技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 创新先进技术有限公司 filed Critical 创新先进技术有限公司
Publication of WO2020233625A1 publication Critical patent/WO2020233625A1/zh

Links

Images

Classifications

    • 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
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3823—Payment protocols; Details thereof insuring higher security of transaction combining multiple encryption tools for a transaction
    • 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
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange

Definitions

  • One or more embodiments of this specification relate to the field of blockchain technology, and more particularly to a receipt storage method and node that combines user types and 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 that combine user types and judgment conditions.
  • a receipt storage method combining user type and 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.
  • the receipt 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 receipt data is stored in cipher text.
  • a receipt storage node combining user types and 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 in the trusted execution environment to obtain receipt data
  • the storage unit stores the receipt data.
  • the receipt fields in the receipt data that meet the preset conditions are stored in plain text, and the rest of the receipt fields are stored in cipher text.
  • the receipt data 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 in combination with user types and 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 combining user types and judgment conditions according to 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 contents of the above-mentioned receipt fields contained in the receipt data, without privacy protection settings and capabilities.
  • 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.
  • Not only mobile devices, cloud devices, and data centers have put forward more needs for TEE.
  • the concept of TEE has also been rapidly developed and expanded. Compared with the originally proposed concept, TEE is a broader TEE. For example, server chip manufacturers Intel, AMD, etc. have successively introduced hardware-assisted TEE and enriched the concept and characteristics of TEE, which has been widely recognized in the industry.
  • Intel Software Protection Extensions (SGX) and other TEE technologies isolate code execution, remote attestation, secure configuration, secure storage of data, and trusted paths for code execution.
  • the applications running in the TEE are protected by security and are almost impossible to be accessed by third parties.
  • SGX provides an enclave (also called an enclave), which is an encrypted trusted execution area in the memory, and the CPU protects data from being stolen.
  • enclave also called an enclave
  • the CPU protects data from being stolen.
  • a part of the area EPC Enclave Page Cache, enclave page cache or enclave page cache
  • the encryption engine MEE Memory Encryption Engine
  • SGX users can distrust the operating system, VMM (Virtual Machine Monitor), and even BIOS (Basic Input Output System). They only need to trust the CPU to ensure that private data will not leakage.
  • the private data can be encrypted and transmitted to the circle in cipher text, and the corresponding secret key can also be transmitted to the circle through remote certification. Then, the data is used for calculation under the encryption protection of the CPU, and the result will be returned in ciphertext. In this mode, you can use powerful computing power without worrying about data leakage.
  • the block chain is a data set stored in a database of a node and organized by a specific logic.
  • the database may be a storage medium, such as a persistent storage medium, on a physical carrier.
  • different users have different privacy protection requirements for receipt data. For example, some users may pay more attention to privacy protection, so you can try to store the receipt data generated by the transaction initiated by the user in cipher text; another part of users may pay more attention to the availability of data, such as wishing to support receipt data Retrieval operations, such as DAPP (Decentralized Application, distributed application) client to perform related processing operations.
  • DAPP Decentralized Application, distributed application
  • 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 competing 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.
  • the receipt fields that meet the preset conditions in the receipt data are stored in plain text, and the remaining receipt fields are in cipher text. Storage, 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 Type 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 Type 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 corresponding receipt field contains the preset content, the value of the corresponding receipt field belongs to a preset numerical interval, and so on.
  • the preset content may include: one or more specified keywords.
  • 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 field contains When the state variable, event function, or transaction execution result is used as a keyword, it can be determined that the receipt field meets a preset condition.
  • the transaction execution result can include: “success” means the transaction is successful, “fail” means the transaction failed; when the keyword is "success”, the receipt field containing "success” is allowed to be stored in plain text (you can When the transaction initiator belongs to the preset user type, it is stored in clear text), and the receipt field 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 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.
  • 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 condition may include a general condition corresponding to all receipt fields in the receipt data, that is, all receipt fields in the receipt data are used for comparison with the preset condition. For example, when the preset condition is "contains preset keywords", all receipt fields in the receipt data can be compared with the keywords contained in the preset conditions to determine the receipt fields containing the keywords, as Receipt 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, 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. 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).
  • 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 used as the Stored in plain text).
  • the preset conditions may be located in the transaction, so that the preset conditions adopted by different exchanges may be different to meet the differences in demand faced by different exchanges; of course, different transactions may also use the same preset conditions.
  • the difference in the preset conditions may be expressed as a difference 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 judging whether the receipt fields meet the preset conditions.
  • 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 preset condition may be located in the system contract or chain code, so that the preset condition is a global condition applicable to all transactions on the blockchain, and is different from the foregoing transaction or the preset contained in the smart contract.
  • Set conditions so that even if the smart contract invoked by the transaction or transaction does not contain preset conditions, the storage of the receipt field can be determined based on the preset conditions defined in the system contract or chain code and combined with the user type of the transaction initiator the way.
  • 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.
  • 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 creating a blockchain network, the above-mentioned receipt data storage logic related to user types and preset conditions 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 first blockchain node can read the code of the system contract, which defines the receipt data storage logic related to user types and preset conditions; accordingly, the first blockchain node executes all
  • the code of the system contract is used to store the receipt fields that meet the preset conditions in the receipt data in plain text and the rest of the receipt fields in cipher text when the transaction initiator belongs to the preset user type.
  • the receipt data is stored in cipher text.
  • the receipt data storage logic related to user types and preset conditions may include: recognition logic for user types, judgment logic for meeting preset conditions, and processing logic for receipt fields that meet or do not meet preset conditions. Wait.
  • 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 or block chain can record the association relationship between the predefined external account and the user type, or the system contract or block chain can record the value and value of the user type field. Correspondence between user types. For details, please refer to the relevant description of identifying user types above, which will not be repeated here.
  • the judgment logic for the satisfaction of the preset condition is used to instruct the first blockchain node to judge whether the receipt field meets the preset condition. For example: acquiring the content of the preset condition, comparing the receipt field applicable to the preset condition with the content of the preset condition, and determining whether the receipt field meets the preset condition according to the comparison result.
  • the processing logic for the receipt fields that meet or do not meet the preset conditions is used to instruct the first blockchain node to store the receipt fields that meet the preset conditions in plain text when the transaction initiator belongs to the preset user type, and store the rest The content of the receipt is stored in cipher text.
  • the system contract read by the first blockchain node may include a preset system contract configured in the genesis block of the blockchain network; and, the administrator in the blockchain network (ie, the aforementioned management user) may have The update authority of the system contract, so as to update the preset system contract such as the foregoing, the system contract read by the foregoing 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 first blockchain node encrypts the receipt field 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 field 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 field, avoiding Irrelevant users and even criminals decrypt the encrypted receipt field.
  • 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 receipt field.
  • 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 receipt field.
  • 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 receipt field by 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 adopt an asymmetric encryption method, that is, encrypt the receipt field with the public key of the asymmetric encryption algorithm, and accordingly, the client may use the private encryption algorithm of the asymmetric encryption algorithm.
  • the key decrypts the above encrypted receipt field.
  • the key of the 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 field 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 field in plain text that needs to be stored in plain text, and the receipt field 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 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.
  • 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 in the trusted execution environment to obtain receipt data
  • the storage unit 64 stores the receipt data.
  • the receipt 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 receipt data is stored in cipher text.
  • the transaction initiator has a corresponding external account
  • the user type to which the transaction initiator belongs includes: the user type corresponding to the external account recorded on the blockchain.
  • 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 preset condition includes at least one of the following: the corresponding receipt field contains preset content, and the value of the corresponding receipt field belongs to a preset numerical interval.
  • the preset conditions include general conditions corresponding to all receipt fields in the receipt data; or,
  • the preset condition includes a dedicated condition corresponding to each receipt field in the receipt data.
  • the preset condition is in the transaction; or,
  • the preset condition is located in the smart contract called by the transaction, or in another smart contract called by the smart contract called by the transaction; or,
  • the preset conditions are located in the system contract or chain code.
  • the storage unit 64 is specifically used for:
  • the code of the system contract is executed to store the receipt fields that meet the preset conditions in the receipt data in plain text and the remaining receipt fields in cipher text when the transaction initiator belongs to the preset user type.
  • the receipt data is stored in cipher text.
  • the system contract includes: a preset system contract recorded in the genesis block, or an updated system contract corresponding to the preset system contract.
  • the storage unit 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
  • 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

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Engineering & Computer Science (AREA)
  • Finance (AREA)
  • Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Development Economics (AREA)
  • Technology Law (AREA)
  • Marketing (AREA)
  • Economics (AREA)
  • Computer Security & Cryptography (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

一种结合用户类型和判断条件的收据存储方法和节点，该方法包括：第一区块链节点接收经过加密的交易（202）；第一区块链节点在可信执行环境中解密所述交易并执行获得的交易内容，得到收据数据（204）；第一区块链节点存储所述收据数据，当交易发起方属于预设用户类型时，所述收据数据中满足预设条件的收据字段以明文形式存储、其余收据字段以密文形式存储，当交易发起方不属于所述预设用户类型时，所述收据数据以密文形式存储（206）。

Description

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

Claims (20)

  1. 一种结合用户类型和判断条件的收据存储方法，包括：
    第一区块链节点接收经过加密的交易；
    第一区块链节点在可信执行环境中解密所述交易并执行获得的交易内容，得到收据数据；
    第一区块链节点存储所述收据数据，当交易发起方属于预设用户类型时，所述收据数据中满足预设条件的收据字段以明文形式存储、其余收据字段以密文形式存储，当交易发起方不属于所述预设用户类型时，所述收据数据以密文形式存储。
  2. 根据权利要求1所述的方法，所述交易发起方存在对应的外部账户，所述交易发起方所属的用户类型包括：区块链上记录的所述外部账户对应的用户类型。
  3. 根据权利要求2所述的方法，所述外部账户包括记录于区块链上的用户类型字段，所述用户类型字段的取值对应于所述用户类型。
  4. 根据权利要求2所述的方法，在创建所述外部账户时，所述用户类型被配置为关联至所述外部账户，使所述用户类型与所述外部账户之间的关联关系被记录于区块链中。
  5. 根据权利要求4所述的方法，还包括：
    第一区块链节点根据管理用户发起的更改请求，更改所述外部账户对应的用户类型。
  6. 根据权利要求1所述的方法，所述预设条件包括以下至少之一：相应的收据字段中包含预设内容、相应的收据字段的取值属于预设数值区间。
  7. 根据权利要求1所述的方法，
    所述预设条件包括所述收据数据中的所有收据字段对应的通用条件；或，
    所述预设条件包括所述收据数据中的每一收据字段分别对应的专用条件。
  8. 根据权利要求1所述的方法，
    所述预设条件位于所述交易中；或，
    所述预设条件位于所述交易调用的智能合约中，或所述交易调用的智能合约所调用的另一智能合约中；或，
    所述预设条件位于系统合约或链代码中。
  9. 根据权利要求1所述的方法，第一区块链节点存储所述收据数据，包括：
    第一区块链节点读取系统合约的代码，所述系统合约的代码中定义了与用户类型和预设条件相关的收据数据存储逻辑；
    第一区块链节点执行所述系统合约的代码，以在交易发起方属于预设用户类型时， 将所述收据数据中满足预设条件的收据字段以明文形式存储、其余收据字段以密文形式存储，当交易发起方不属于所述预设用户类型时，将所述收据数据以密文形式存储。
  10. 根据权利要求9所述的方法，所述系统合约包括：记录于创世块中的预置系统合约，或所述预置系统合约对应的更新后系统合约。
  11. 根据权利要求1所述的方法，第一区块链节点存储所述收据数据，包括：
    第一区块链节点在所述可信执行环境之外执行存储功能代码，以将所述收据数据存储至所述可信执行环境之外的外部存储空间。
  12. 根据权利要求1所述的方法，第一区块链节点对所述收据数据进行加密的密钥包括：对称加密算法的密钥或非对称加密算法的密钥。
  13. 根据权利要求12所述的方法，所述对称加密算法的密钥包括所述客户端提供的初始密钥；或，所述对称加密算法的密钥包括所述初始密钥与影响因子生成的衍生密钥。
  14. 根据权利要求13所述的方法，所述交易由所述初始密钥进行加密，且所述初始密钥被非对称加密算法的公钥进行加密；第一区块链节点在可信执行环境中解密所述交易，包括：
    第一区块链节点用所述非对称加密算法的私钥解密得到所述初始密钥，并用所述初始密钥对所述交易进行解密，以得到所述交易内容。
  15. 根据权利要求13所述的方法，所述初始密钥由客户端生成；或，所述初始密钥由密钥管理服务器发送至所述客户端。
  16. 根据权利要求13所述的方法，所述影响因子与所述交易相关。
  17. 根据权利要求16所述的方法，所述影响因子包括：所述交易的哈希值的指定位。
  18. 一种结合用户类型和判断条件的收据存储节点，包括：
    接收单元，接收经过加密的交易；
    解密单元，在可信执行环境中解密所述交易，得到交易内容；
    执行单元，在所述可信执行环境中执行所述交易内容，得到收据数据；
    存储单元，存储所述收据数据，当交易发起方属于预设用户类型时，所述收据数据中满足预设条件的收据字段以明文形式存储、其余收据字段以密文形式存储，当交易发起方不属于所述预设用户类型时，所述收据数据以密文形式存储。
  19. 一种电子设备，包括：
    处理器；
    用于存储处理器可执行指令的存储器；
    其中，所述处理器通过运行所述可执行指令以实现如权利要求1-17中任一项所述的方法。
  20. 一种计算机可读存储介质，其上存储有计算机指令，该指令被处理器执行时实现如权利要求1-17中任一项所述方法的步骤。
PCT/CN2020/091398 2019-05-20 2020-05-20 结合用户类型和判断条件的收据存储方法和节点 WO2020233625A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201910419136.9A CN110245942B (zh) 2019-05-20 2019-05-20 结合用户类型和判断条件的收据存储方法和节点
CN201910419136.9 2019-05-20

Publications (1)

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

Family

ID=67884377

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2020/091398 WO2020233625A1 (zh) 2019-05-20 2020-05-20 结合用户类型和判断条件的收据存储方法和节点

Country Status (2)

Country Link
CN (1) CN110245942B (zh)
WO (1) WO2020233625A1 (zh)

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110263089B (zh) * 2019-05-20 2021-05-04 创新先进技术有限公司 结合交易与事件类型的条件限制的收据存储方法和节点
CN110245942B (zh) * 2019-05-20 2021-05-04 创新先进技术有限公司 结合用户类型和判断条件的收据存储方法和节点
WO2020233425A1 (zh) * 2019-05-20 2020-11-26 创新先进技术有限公司 基于判断条件的收据存储方法和节点
WO2020233422A1 (zh) * 2019-05-20 2020-11-26 创新先进技术有限公司 基于用户类型的收据存储方法和节点
CN110942302B (zh) * 2019-11-26 2024-04-02 深圳前海微众银行股份有限公司 一种区块链凭证撤销、验证方法、签发节点、验证节点
CN110995757B (zh) * 2019-12-19 2022-03-11 肖光昱 加密装置、加密系统和数据的加密方法
CN113269636B (zh) * 2020-12-28 2024-07-05 上海零数众合信息科技有限公司 一种面向区块链的嵌套交易方法
CN112738280B (zh) * 2021-03-30 2021-07-23 支付宝(杭州)信息技术有限公司 一种用于区块链与链下设备之间的通信方法和装置
CN116760651A (zh) * 2023-08-22 2023-09-15 中国航空结算有限责任公司 一种数据加密方法、装置、电子设备和可读存储介质

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160379212A1 (en) * 2015-06-26 2016-12-29 Intel Corporation System, apparatus and method for performing cryptographic operations in a trusted execution environment
CN109033855A (zh) * 2018-07-18 2018-12-18 腾讯科技（深圳）有限公司 一种基于区块链的数据传输方法、装置及存储介质
CN109544137A (zh) * 2018-11-05 2019-03-29 深圳市恒达移动互联科技有限公司 基于tee及nfc的数字钱包生成方法及系统
CN110245942A (zh) * 2019-05-20 2019-09-17 阿里巴巴集团控股有限公司 结合用户类型和判断条件的收据存储方法和节点
CN110263544A (zh) * 2019-05-20 2019-09-20 阿里巴巴集团控股有限公司 结合交易类型和判断条件的收据存储方法和节点
CN110264192A (zh) * 2019-05-20 2019-09-20 阿里巴巴集团控股有限公司 基于交易类型的收据存储方法和节点

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102143482B (zh) * 2011-04-13 2013-11-13 中国工商银行股份有限公司 一种手机银行客户端信息认证方法
CN106559211B (zh) * 2016-11-22 2019-12-13 中国电子科技集团公司第三十研究所 一种区块链中隐私保护智能合约方法
CN107342858B (zh) * 2017-07-05 2019-09-10 武汉凤链科技有限公司 一种基于可信环境的智能合约保护方法和系统
US20190080304A1 (en) * 2017-09-12 2019-03-14 Northwestern University On-chain fees in a blockchain distribution network
CN108389130B (zh) * 2018-03-02 2020-02-14 合肥学院 一种生成多交易模式联盟链的方法

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160379212A1 (en) * 2015-06-26 2016-12-29 Intel Corporation System, apparatus and method for performing cryptographic operations in a trusted execution environment
CN109033855A (zh) * 2018-07-18 2018-12-18 腾讯科技（深圳）有限公司 一种基于区块链的数据传输方法、装置及存储介质
CN109544137A (zh) * 2018-11-05 2019-03-29 深圳市恒达移动互联科技有限公司 基于tee及nfc的数字钱包生成方法及系统
CN110245942A (zh) * 2019-05-20 2019-09-17 阿里巴巴集团控股有限公司 结合用户类型和判断条件的收据存储方法和节点
CN110263544A (zh) * 2019-05-20 2019-09-20 阿里巴巴集团控股有限公司 结合交易类型和判断条件的收据存储方法和节点
CN110264192A (zh) * 2019-05-20 2019-09-20 阿里巴巴集团控股有限公司 基于交易类型的收据存储方法和节点

Also Published As

Publication number Publication date
CN110245942B (zh) 2021-05-04
CN110245942A (zh) 2019-09-17

Similar Documents

Publication Publication Date Title
WO2020233623A1 (zh) 结合交易类型和判断条件的收据存储方法和节点
WO2020233625A1 (zh) 结合用户类型和判断条件的收据存储方法和节点
WO2020233616A1 (zh) 结合代码标注与交易、用户类型的收据存储方法和节点
WO2020233630A1 (zh) 基于用户类型的收据存储方法和节点
WO2020233626A1 (zh) 结合交易与用户类型的条件限制的收据存储方法和节点
WO2020233644A1 (zh) 有条件的结合代码标注与类型维度的收据存储方法和节点
WO2020233642A1 (zh) 有条件的结合代码标注与类型维度的收据存储方法和节点
WO2020233615A1 (zh) 结合用户类型与事件函数类型的收据存储方法和节点
WO2020233643A1 (zh) 基于多维度信息且具有条件限制的收据存储方法和节点
WO2020233628A1 (zh) 结合事件函数类型和判断条件的收据存储方法和节点
WO2020233635A1 (zh) 结合多类型维度的条件限制的收据存储方法和节点
WO2020233619A1 (zh) 结合用户类型与交易类型的收据存储方法和节点
CN110032885B (zh) 区块链中实现隐私保护的方法、节点和存储介质
WO2020233638A1 (zh) 结合代码标注与交易类型的收据存储方法和节点
WO2020233612A1 (zh) 结合代码标注与交易、事件类型的收据存储方法和节点
WO2020233610A1 (zh) 结合代码标注与用户、事件类型的收据存储方法和节点
WO2020233637A1 (zh) 结合代码标注与用户类型的收据存储方法和节点
WO2020233613A1 (zh) 结合代码标注与交易类型的有条件的收据存储方法和节点
WO2020233622A1 (zh) 结合代码标注与多类型维度的收据存储方法和节点
WO2020233609A1 (zh) 结合代码标注与用户类型的有条件的收据存储方法和节点
CN110020549B (zh) 区块链中实现隐私保护的方法、节点和存储介质
WO2020233640A1 (zh) 结合代码标注与判断条件的收据存储方法和节点
WO2020233624A1 (zh) 结合交易类型和事件函数类型的收据存储方法和节点
WO2020233631A1 (zh) 基于交易类型的收据存储方法和节点
WO2020233614A1 (zh) 结合代码标注与事件类型的有条件的收据存储方法和节点

Legal Events

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

Ref document number: 20809026

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

Country of ref document: EP

Kind code of ref document: A1