WO2020233637A1 - Procédé de stockage de reçu combinant un marquage de code avec un type d'utilisateur, et nœud - Google Patents

Procédé de stockage de reçu combinant un marquage de code avec un type d'utilisateur, et nœud Download PDF

Info

Publication number
WO2020233637A1
WO2020233637A1 PCT/CN2020/091419 CN2020091419W WO2020233637A1 WO 2020233637 A1 WO2020233637 A1 WO 2020233637A1 CN 2020091419 W CN2020091419 W CN 2020091419W WO 2020233637 A1 WO2020233637 A1 WO 2020233637A1
Authority
WO
WIPO (PCT)
Prior art keywords
smart contract
transaction
blockchain node
code
receipt
Prior art date
Application number
PCT/CN2020/091419
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
Application filed by 创新先进技术有限公司 filed Critical 创新先进技术有限公司
Publication of WO2020233637A1 publication Critical patent/WO2020233637A1/fr

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/3825—Use of electronic signatures
    • 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/3827—Use of message hashing
    • 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/3829—Payment protocols; Details thereof insuring higher security of transaction involving key management
    • 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
    • G06Q30/00—Commerce
    • G06Q30/04—Billing or invoicing

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 code annotation and user type.
  • 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 combining code labeling and user type.
  • a receipt storage method combining code labeling and user type including:
  • the first blockchain node receives an encrypted transaction corresponding to a smart contract, and the code of the smart contract includes an object marked by an exposed identifier;
  • the first blockchain node decrypts the transaction in the trusted execution environment to obtain the code of the smart contract
  • the first blockchain node executes the code of the smart contract in the trusted execution environment to obtain receipt data
  • the first blockchain node stores the receipt data, and when the transaction initiator belongs to a preset user type, the content of the receipt corresponding to the object indicated by the exposure identifier is stored in plain text, and the rest of the receipt content is stored in cipher text.
  • a receipt storage node combining code labeling and user type including:
  • the receiving unit receives an encrypted transaction corresponding to a smart contract, and the code of the smart contract includes an object marked by an exposed identifier;
  • the execution unit executes the code of the smart contract in the trusted execution environment to obtain receipt data
  • the storage unit stores the receipt data.
  • the receipt content corresponding to the object indicated by the exposure identifier is stored in plain text, and the rest of the receipt content is stored in cipher text.
  • an electronic device including:
  • a memory for storing processor executable instructions
  • the processor implements the method according to the first aspect by running the executable instruction.
  • a computer-readable storage medium is provided, and computer instructions are stored thereon, which, when executed by a processor, implement the steps of the method described in the first aspect.
  • Fig. 1 is a schematic diagram of creating a smart contract according to an exemplary embodiment.
  • Fig. 2 is a schematic diagram of invoking a smart contract provided by an exemplary embodiment.
  • Fig. 3 is a flowchart of a receipt storage method combining code labeling and user type according to an exemplary embodiment.
  • Fig. 4 is a schematic diagram of implementing privacy protection on blockchain nodes according to an exemplary embodiment.
  • Fig. 5 is a 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 node combining code labeling and user type 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.
  • a smart contract on the blockchain is a contract that can be triggered and executed by a transaction on the blockchain system.
  • Smart contracts can be defined in the form of codes.
  • EVM Ethereum Virtual Machine
  • bytecode virtual machine code
  • the EVM of node 1 can execute the transaction and generate a corresponding contract instance.
  • "0x6f8ae93" in the figure 1 represents the address of this contract, the data field of the transaction can be stored in bytecode, and the to field of the transaction is empty.
  • the contract is successfully created and can be called in the subsequent process.
  • a contract account corresponding to the smart contract appears on the blockchain and has a specific address, and the contract code will be stored in the contract account.
  • the behavior of the smart contract is controlled by the contract code.
  • smart contracts enable virtual accounts containing contract codes and account storage (Storage) to be generated on the blockchain.
  • the EVM of a certain node can execute the transaction and generate a corresponding contract instance.
  • the from field of the transaction in Figure 2 is the address of the account of the transaction initiator (ie Bob), the "0x6f8ae93" in the to field represents the address of the called smart contract, and the value field in Ethereum is the value of Ether ,
  • the method and parameters of calling the smart contract are stored in the data field of the transaction. Smart contracts are executed independently on each node in the blockchain network in a prescribed manner. All execution records and data are stored on the blockchain, so when the transaction is completed, the blockchain will be stored on the blockchain that cannot be tampered with. Lost transaction certificate.
  • the receipt data obtained by a node executing a transaction can include the following:
  • the Result field indicates the execution result of the transaction
  • the Gas used field indicates the gas value consumed by the transaction
  • the Logs field indicates the log generated by the transaction.
  • the log can further include the From field, To field, Topic field, and Log data field, among which the From field indicates the account address of the initiator of the call, and the To field indicates the called object (such as a smart contract)
  • the account address and Topic field indicate the subject of the log, and the Log data field indicates the log data;
  • the Output field indicates the output of the transaction.
  • the receipt data generated after the transaction is executed is stored in plain text, and anyone can see the contents of the above-mentioned receipt fields contained in the receipt data, without privacy protection settings and capabilities.
  • the block chain is a data set stored in a database of a node and organized by a specific logic.
  • the database as described later, may be a storage medium, such as a persistent storage medium, on a physical carrier.
  • only part of the content of the receipt data may be sensitive, while other content is not sensitive. Only sensitive content needs to be protected for privacy, other content can be disclosed, and in some cases it may even be necessary to retrieve some content to drive Implementation of related operations, the implementation of privacy protection for this part of the content will affect the implementation of retrieval operations.
  • the first blockchain node receives an encrypted transaction corresponding to a smart contract, and the code of the smart contract includes an object marked by an exposed identifier.
  • the user when the user writes the code of the smart contract, he can add an exposure identifier to the code to mark one or more objects, so that the receipt content corresponding to this part of the object in the receipt data can be stored in plain text, then The contents of the receipts corresponding to the remaining objects without an exposed identifier need to be stored in cipher text to achieve corresponding privacy protection.
  • the data field can store the bytecode of the smart contract.
  • the bytecode consists of a series of bytes, and each byte can identify an operation. Based on many considerations such as development efficiency and readability, developers can choose a high-level language to write smart contract code instead of directly writing bytecode.
  • the code of a smart contract written in a high-level language is compiled by a compiler to generate bytecode, and then the bytecode can be deployed on the blockchain.
  • Solidity language As an example, the contract written in it is very similar to the class in the object-oriented programming language. A variety of members can be declared in a contract, including state variables, functions, function modifiers, and events. The following is a simple smart contract code example 1 written in Solidity language:
  • one or more objects can be marked by exposing identifiers, so that the receipt content corresponding to this part of the object in the receipt data can be stored in plain text, while the rest of the receipt content is encrypted Document storage.
  • one or more objects can also be marked by exposing identifiers to realize the plaintext storage of the relevant receipt content.
  • the exposure identifier may be a receipt field dedicated to indicating that plain text storage is required.
  • the keyword plain may be used to characterize the exposure identifier. Then, for the receipt content that you want to store in plain text, you can add plain before the corresponding object (or, you can also associate with the corresponding object in other ways).
  • the object marked by the exposure identifier can include receipt fields, such as the Result field, Gas used field, Logs field, Output field, etc., as described above, or the From field, To field, Topic field, and Log data field further contained in the Logs field Wait.
  • receipt fields such as the Result field, Gas used field, Logs field, Output field, etc., as described above, or the From field, To field, Topic field, and Log data field further contained in the Logs field Wait.
  • the code sample 1 above can be adjusted to the following code sample 2:
  • the fields that need to be stored in plaintext can also be specified.
  • the From field is marked by the exposed identifier
  • the code of the smart contract is executed, if the transaction initiator belongs to the preset user type, the content of the receipt corresponding to the From field in the generated receipt data is in plain text.
  • the objects (all fields or From fields) marked by the exposed identifier "plain" are contract-level objects, so that the first blockchain node is storing
  • the contract-level object can be applied to all events in the smart contract. Take the From field as an example: when the transaction initiator belongs to the preset user type, for multiple events The corresponding Logs fields are generated separately, and the From field contained in each Logs field will be stored in plain text, without the need to add an exposure identifier for each event.
  • the exposed identifier can also be used to identify other objects.
  • the object indicated by the exposure identifier may include a state variable, and the state variable may also be a contract-level object. Taking the state variable "price" as an example, the above code example 1 can be adjusted to the following code example 3:
  • each Logs field (such as the Topic field in the Logs field) will store the receipt content related to the state variable "price” in clear text, and the Output field will also be stored in clear text with the state variable "price” "Related receipt content, there is no need to add an exposure identifier for the state variable "price” in each event.
  • a smart contract can include the following code example 4:
  • the objects indicated by the exposure identifier may include: event-level objects corresponding to at least one event defined in the smart contract, so that when the first blockchain node stores receipt data, if the transaction initiator belongs to the pre- Assuming the user type, the receipt content corresponding to the at least one event in the receipt data can be stored in plain text.
  • the above event-level objects can be set for at least some of the events, so that the content of the receipt corresponding to this part of the event is stored in plain text, and the content of the receipt corresponding to the remaining events is stored in cipher text .
  • 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 in the character from is different from the aforementioned plain, but modify the character from with quotation marks.
  • the quotation marks in code example 5 are equivalent to the aforementioned exposed identifier.
  • Event-level objects can also include state variables. Taking the state variable "price" as an example, the above code example 1 can be adjusted to the following code example 6:
  • the event-level object may include fields, which is similar to the above-mentioned From field. However, since no specific fields are specified, all fields in the log generated by the event currentPrice can be regarded as the above event-level objects, such as the aforementioned From field, To field, Topic field, Log Data field, etc., so that the transaction is initiated When the party belongs to the preset user type, all the contents of the receipt corresponding to the event currentPrice are stored in plain text.
  • event-level objects can include state variables.
  • the above code example 6 defines the state variable "price”
  • the event currentPrice refers to the state variable "price”, which corresponds to adding the exposure identifier "plain” before the event function "event currentPrice(int price)”
  • the state variable "price” can be used as the above-mentioned event-level object, so that when the transaction initiator belongs to the preset user type, all receipts related to the state variable "price” generated by the event are stored in plain text.
  • the state variable "price” belongs to the event-level object in Code Example 6, when the code of the smart contract also contains another event event1 that references the state variable "price”, if no level of exposure is added to the event event1 Identifier, even if the event event1 references the state variable "price", the content of the receipt generated by the event event1 will still be stored in cipher text, not in plain text.
  • the above event-level object may include all the state variables referenced.
  • the 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, so when the transaction initiator belongs to the preset user type, all receipts related to the state variables "price” and "price1” generated by the event will be Store in clear 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 currentPrice event and not applicable to other events included in the smart contract, that is: on the premise that the transaction initiator belongs to the preset user type , Only the receipt content related to the state variable "price” generated by the event currentPrice is stored in plain text. Unless other events also add an exposure identifier for the state variable "price", other events even if the state variable "price” is applied ", the generated receipt content is still stored in cipher text.
  • the event currentPrice references the state variables "price” and “price1" at the same time
  • the state variable "price” can be configured by adding the exposure identifier plain before the type int of the state variable "price” It is an event-level object, and the state variable "price1" without the exposed identifier plain is not an event-level object, so that the event generated by the event is related to the state variable "price” on the premise that the transaction initiator belongs to the preset user type
  • the receipt content of is stored in plain text, and the receipt content related to the state variable "price1" is still 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 with the client, so that the client can submit the above-mentioned transaction to the first blockchain node.
  • the user can use a high-level language to write a smart contract on the client, and then the client uses a compiler to compile the smart contract in the high-level language to obtain the corresponding smart contract in bytecode form.
  • the client can directly send a smart contract written in a high-level language to the first blockchain node, so that the first blockchain node is compiled into a bytecode smart contract by a compiler.
  • the smart contract corresponding to the transaction received by the first blockchain node can be the smart contract in the transaction sent by the client through the second blockchain node.
  • the smart contract is usually in the form of bytecode; of course, the smart contract It can also be a smart contract written in a high-level language, and the first blockchain node can be compiled into a bytecode smart contract by a compiler.
  • the smart contract written in a high-level language and the smart contract in the form of bytecode may have the same exposure identifier.
  • the bytecode can use an exposed identifier different from a high-level language.
  • the code of a smart contract written in a high-level language contains the first identifier and the code of the smart contract in the form of bytecode. If the second identifier is included, there is a corresponding relationship between the first identifier and the second identifier to ensure that after being compiled into bytecode by a high-level language, the function of exposing the identifier will not be affected.
  • Step 304 The first blockchain node decrypts the transaction in the trusted execution environment to obtain the code of the smart contract.
  • the foregoing transaction may be encrypted by a symmetric encryption algorithm, or may be encrypted by an asymmetric algorithm.
  • the encryption algorithm used by symmetric encryption such as DES algorithm, 3DES algorithm, TDEA algorithm, Blowfish algorithm, RC5 algorithm, IDEA algorithm, etc.
  • Asymmetric encryption algorithms such as RSA, Elgamal, knapsack algorithm, Rabin, D-H, ECC (elliptic curve encryption algorithm), etc.
  • the foregoing transaction may be encrypted by a combination of a symmetric encryption algorithm and an asymmetric encryption algorithm.
  • the client can use a symmetric encryption algorithm to encrypt the transaction content, that is, use the symmetric encryption algorithm key to encrypt the transaction content, and use an asymmetric encryption algorithm to encrypt the symmetric encryption algorithm
  • the key used for example, the key used in the public key encryption symmetric encryption algorithm using an asymmetric encryption algorithm.
  • the first blockchain node after the first blockchain node receives the encrypted transaction, it can first decrypt it with the private key of the asymmetric encryption algorithm to obtain the key of the symmetric encryption algorithm, and then decrypt it with the key of the symmetric encryption algorithm to obtain the transaction content.
  • the transaction content can include the code of the smart contract that needs to be created; when the transaction is used to call a smart contract, the transaction content can include the account address of the smart contract being called, and the required input Methods and parameters, etc.
  • a transaction When a transaction is used to call a smart contract, it can be a call of multiple nested structures. For example, the transaction directly calls smart contract 1, and the code of smart contract 1 calls smart contract 2, and the code in smart contract 2 points to the contract address of smart contract 3, so that the transaction actually calls the code of smart contract 3 indirectly , And the code in smart contract 3 can include objects marked by exposed identifiers. In this way, it is equivalent to that the smart contract 1 contains the object identified by the exposed identifier.
  • the specific implementation process is similar to the above process, and will not be repeated here.
  • Step 306 The first blockchain node executes the code of the smart contract in the trusted execution environment to obtain receipt data.
  • the transaction received by the first blockchain node may be, for example, a transaction for creating and/or invoking a smart contract.
  • a transaction for creating and/or invoking a smart contract For example, in Ethereum, after the first blockchain node receives the transaction to create and/or call the smart contract from the client, it can check whether the transaction is valid, the format is correct, and the signature of the transaction is legal.
  • the nodes in Ethereum are generally nodes that compete for the right to bookkeeping. Therefore, the first blockchain node as the node that competes for the right to bookkeeping can execute the transaction locally. If one of the nodes competing for the accounting right wins in the current round of the accounting right, it becomes the accounting node. If the first blockchain node wins this round of competition for accounting rights, it becomes the accounting node; of course, if the first blockchain node does not win in this round of competition for accounting rights, it is not Accounting nodes, and other nodes may become accounting nodes.
  • a smart contract is similar to a class in object-oriented programming.
  • the result of execution generates a contract instance corresponding to the smart contract, similar to the object corresponding to the generated class.
  • the process of executing the code used to create a smart contract in a transaction will create a contract account and deploy the contract in the account space.
  • the address of the smart contract account is generated from the sender's address ("0xf5e -- in Figure 1-2) and the transaction nonce (nonce) as input, and is generated by an encryption algorithm, such as in Figure 1-2
  • the contract address "0x6f8ae93" is generated from the sender's address "0xf5e" and the nonce in the transaction through an encryption algorithm.
  • consensus algorithms such as Proof of Work (POW), Proof of Stake (POS), and Delegated Proof of Stake (DPOS) are adopted in blockchain networks that support smart contracts. All nodes competing for the right to account can execute the transaction after receiving the transaction including the creation of a smart contract. One of the nodes competing for the right to bookkeeping may win this round and become the bookkeeping node.
  • the accounting node can package the transaction containing the smart contract with other transactions and generate a new block, and send the generated new block to other nodes for consensus.
  • the nodes with the right to book accounts have been agreed before this round of bookkeeping. Therefore, after the first blockchain node receives the above transaction, if it is not the accounting node of this round, it can send the transaction to the accounting node.
  • accounting nodes which can be the first blockchain node
  • the accounting node packages the transaction (or other transactions together) and generates a new block
  • the generated new block or block header is sent to other nodes for consensus.
  • the accounting nodes in this round can package and package the transaction. Generate a new block, and send the header of the new block to other nodes for consensus. If other nodes receive the block and verify that there is no problem, they can append the new block to the end of the original block chain to complete the accounting process and reach a consensus; if the transaction is used to create a smart contract, then The deployment of the smart contract on the blockchain network is completed. If the transaction is used to call the smart contract, the call and execution of the smart contract are completed. In the process of verifying the new block or block header sent by the accounting node, other nodes may also execute the transaction in the block.
  • the execution process can generally be executed by a virtual machine. Taking Ethereum as an example, it supports users to create and/or call some complex logic in the Ethereum network. This is the biggest challenge that distinguishes Ethereum from Bitcoin blockchain technology.
  • the core of Ethereum as a programmable blockchain is the Ethereum Virtual Machine (EVM), and every Ethereum node can run EVM.
  • EVM is a Turing complete virtual machine, which means that various complex logic can be implemented through it. Users publish and call smart contracts in Ethereum run on the EVM.
  • the first blockchain node can execute the decrypted smart contract code in a Trusted Execution Environment (TEE).
  • TEE Trusted Execution Environment
  • the first blockchain node can be divided into a regular execution environment (on the left in the figure) and TEE, and transactions submitted by the client (as described above, transactions can have other sources; here, the client submits Take the transaction as an example to illustrate)
  • First enter the "transaction/query interface" in the regular execution environment for identification.
  • Transactions that do not require privacy processing can be left in the regular execution environment for processing (here can be based on the user type of the transaction initiator , Transaction type, identifier contained in the exchange, etc.
  • TEE is isolated from the conventional execution environment.
  • the transaction is encrypted before entering the TEE, and it is decrypted into the transaction content in the clear in the trusted execution environment, so that the transaction content in the clear text can be efficiently processed in the TEE and in the TEE under the premise of ensuring data security.
  • the receipt data in plaintext is generated in.
  • TEE is a secure extension based on CPU hardware and a trusted execution environment completely isolated from the outside.
  • TEE was first proposed by Global Platform to solve the security isolation of resources on mobile devices, and parallel to the operating system to provide a trusted and secure execution environment for applications.
  • ARM's Trust Zone technology is the first to realize the real commercial TEE technology.
  • security requirements are getting higher and higher.
  • Not only mobile devices, cloud devices, and data centers have put forward more needs for TEE.
  • the concept of TEE has also been rapidly developed and expanded. Compared with the originally proposed concept, TEE is a broader TEE. For example, server chip manufacturers Intel, AMD, etc. have successively introduced hardware-assisted TEE and enriched the concept and characteristics of TEE, which has been widely recognized in the industry.
  • Intel Software Protection Extensions (SGX) and other TEE technologies isolate code execution, remote attestation, secure configuration, secure storage of data, and trusted paths for code execution.
  • the applications running in the TEE are protected by security and are almost impossible to be accessed by third parties.
  • SGX provides an enclave (also called an enclave), which is an encrypted trusted execution area in the memory, and the CPU protects data from being stolen.
  • enclave also called an enclave
  • the CPU protects data from being stolen.
  • a part of the area EPC Enclave Page Cache, enclave page cache or enclave page cache
  • the encryption engine MEE Memory Encryption Engine
  • SGX users can distrust the operating system, VMM (Virtual Machine Monitor), and even BIOS (Basic Input Output System). They only need to trust the CPU to ensure that private data will not leakage.
  • the private data can be encrypted and transmitted to the circle in cipher text, and the corresponding secret key can also be transmitted to the circle through remote certification. Then, the data is used for calculation under the encryption protection of the CPU, and the result will be returned in ciphertext. In this mode, you can use powerful computing power without worrying about data leakage.
  • the transaction contains the code of the smart contract
  • the first blockchain node can decrypt the transaction in the TEE to obtain the code of the smart contract contained therein, and then Execute this code in TEE.
  • the first blockchain node can execute the code in the TEE (if the called smart contract handles the encryption state, the smart contract needs to be executed in the TEE first. Decrypt to get the corresponding code).
  • the first blockchain node may use the newly added processor instructions in the CPU to allocate a part of the area EPC in the memory, and encrypt the above-mentioned plaintext code and store it in the EPC through the encryption engine MEE in the CPU.
  • the encrypted content in EPC is decrypted into plain text after entering the CPU.
  • the CPU perform operations on the plaintext code to complete the execution process.
  • the plaintext code for executing smart contracts can load the EVM into the enclosure.
  • the key management server can calculate the hash value of the local EVM code and compare it with the hash value of the EVM code loaded in the first blockchain node. The correct comparison result is a necessary condition for passing remote certification. , So as to complete the measurement of the code loaded in the SGX circle of the first blockchain node. After measurement, the correct EVM can execute the above smart contract code in SGX.
  • Step 308 The first blockchain node stores the receipt data.
  • the transaction initiator belongs to the preset user type
  • the content of the receipt corresponding to the object indicated by the exposure identifier is stored in plain text
  • the rest of the receipt content is stored in cipher text. Form storage.
  • the user has a corresponding external account on the blockchain, and initiates transactions or performs other operations based on the external account. Then, the user type to which the transaction initiator belongs, that is, the user type to which the external account belongs. Therefore, the first blockchain node can determine the external account corresponding to the transaction initiator, and query the user type corresponding to the external account recorded on the blockchain as the user type to which the transaction initiator belongs.
  • the external account may include a type field (such as a Type field) recorded on the blockchain, and the value of the type field corresponds to the user type. For example, when the value of the type field is 00, the user type is ordinary user, when the value of the type field is 01, the user type is advanced user, and when the value of the type field is 11, the user type is administrative user, etc. . Therefore, the first blockchain node can determine the corresponding user type based on the value by reading the type field of the external account mentioned above.
  • a type field such as a Type field
  • the user type when creating the above-mentioned external account, can be configured to be associated with the external account, so that the association relationship between the user type and the external account is recorded in the blockchain, such as through the user type and The account address of the external account is used to establish the above-mentioned association relationship, so that the data structure of the external account does not need to be changed, that is, the external account does not need to include the above type field. Therefore, the first blockchain node can determine the above-mentioned preset user type corresponding to the external account by reading the association relationship recorded on the blockchain and based on the external account corresponding to the transaction initiator.
  • the user type of the external account can be modified under certain conditions.
  • the management user may have a modification right item, so that the first blockchain node can change the user type corresponding to the above-mentioned external account according to the change request initiated by the management user.
  • the management user can correspond to the external account preset in the genesis block with management authority, so that the management user can make type changes to other ordinary users, advanced users, etc., such as changing ordinary users to advanced users, and changing advanced users For ordinary users, etc.
  • the first blockchain node can determine the strength of the transaction initiator’s privacy protection needs by identifying the user type to which the transaction initiator belongs: when it belongs to the preset user type, it can be determined that the transaction initiator’s privacy protection needs are relatively weak , Can accept the exposure of receipt data to a certain extent to achieve corresponding function expansion; when it does not belong to the preset user type, it can be determined that the transaction initiator has relatively strong privacy protection requirements and cannot accept the exposure of receipt data. Therefore, based on the identification of the user type to which the transaction initiator belongs, the storage method for the receipt data can meet the actual needs of the transaction initiator, and it can take into account privacy protection and function expansion. For example, ordinary users have relatively lower requirements for privacy protection and higher requirements for function expansion based on receipt data.
  • the first blockchain node can store the content of the receipt corresponding to the object indicated by the exposure identifier in plain text when the transaction initiator belongs to the preset user type, and store the remaining content of the receipt in cipher text
  • Receipt data can be stored in plaintext or ciphertext flexibly, so that the receipt content stored in ciphertext form can meet the privacy needs of users, and the receipt content stored in plaintext form can meet the user's search function expansion needs.
  • the log in the receipt data (such as the entire Logs field; or at least one of the From field, To field, Topic field, and Log data field) is stored in plain text, it can support subsequent retrieval of the log content, thereby For example, it implements event-driven based on log content, such as driving DAPP (Decentralized Application, distributed application) clients to perform related processing operations.
  • DAPP Decentralized Application, distributed application
  • the computing device By running the program code of the blockchain (hereinafter referred to as the chain code) on the computing device (physical machine or virtual machine), the computing device can be configured as a blockchain node in the blockchain network, such as the first Blockchain nodes, etc.
  • the first blockchain node runs the above chain code to realize the corresponding functional logic. Therefore, when the blockchain network is created, the receipt data storage logic related to the exposed identifier and user type can be written into the chain code, so that each blockchain node can implement the receipt data storage logic;
  • the receipt data storage logic related to the exposed identifier and the user type may include: identification logic for the user type, and logic for storing the content of the receipt based on the exposed identifier.
  • 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.
  • the relevant description of identifying user types above please refer to the relevant description of identifying user types above, which will not be repeated here.
  • the logic of storing the content of the receipt based on the exposed identifier is used to instruct the first blockchain node: for the objects marked by the exposed identifier and the unmarked objects, how to store the corresponding receipt content respectively.
  • the corresponding receipt content is stored in plain text for objects marked by the exposed identifier
  • the corresponding receipt content is stored in cipher text for objects not marked by the exposed identifier. The contents of the receipt.
  • 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 the exposed identifier and user type; then, the first blockchain node can execute the system The code of the contract, based on the receipt data storage logic related to the exposed identifier and user type, in the case that the transaction initiator belongs to the preset user type, the corresponding receipt content in the receipt data of the object marked by the exposed identifier is written in plain text Form storage, the rest of the receipt data 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 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 first blockchain node encrypts at least a part of the receipt content through the 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 can use the aforementioned initial key to encrypt the content of the receipt. Different transactions can use the same initial key, so that all transactions submitted by the same user are encrypted with this initial key, or different transactions can use different initial keys. For example, the client can randomly generate an initial key for each transaction. Key to improve security.
  • the first blockchain node can generate a derived key according to the initial key and the impact factor, and encrypt the content of the receipt through the derived key.
  • the derived key can increase the degree of randomness, thereby increasing the difficulty of being compromised and helping to optimize the security protection of data.
  • the impact factor can be related to the transaction; for example, the impact factor can include the specified bits of the transaction hash value.
  • the first blockchain node can associate the initial key with the first 16 bits (or the first 32 bits and the last 16 bits) of the transaction hash value. Bits, last 32 bits, or other bits) are spliced, and the spliced string is hashed to generate a derived key.
  • the first blockchain node can also use an asymmetric encryption method, that is, use the public key of the asymmetric encryption algorithm to encrypt the content of the receipt, and accordingly, the client can use the private key of the asymmetric encryption algorithm to decrypt the encrypted The contents of the receipt.
  • the key of an asymmetric encryption algorithm for example, can be that the client generates a pair of public and private keys, and sends the public key to the first blockchain node in advance, so that the first blockchain node can use the receipt content Public key encryption.
  • the first blockchain node realizes the function by running the code used to realize the function. Therefore, for the functions that need to be implemented in the TEE, the relevant code also needs to be executed. For the code executed in the TEE, it needs to comply with the relevant specifications and requirements of the TEE; accordingly, for the code used to implement a certain function in the related technology, the code needs to be rewritten in combination with the specifications and requirements of the TEE. Large amount of development, and easy to produce loopholes (bugs) in the process of rewriting, affecting the reliability and stability of function implementation.
  • the first blockchain node can execute the storage function code outside the TEE to store the receipt data generated in the TEE (including the receipt content in plain text that needs to be stored in plain text, and the receipt content in cipher text that needs to be stored in cipher text.
  • TEE Is stored in an external storage space outside the TEE, so that the storage function code can be the code used to implement the storage function in the related technology, and does not need to be rewritten in conjunction with the specifications and requirements of the TEE to achieve safe and reliable receipt data
  • the storage of TEE can not only reduce the amount of related code development without affecting security and reliability, but also reduce TCB (Trusted Computing Base) by reducing the related code of TEE, making TEE technology and regional In the process of combining block chain technology, the additional security risks caused are in a controllable range.
  • TCB Trusted Computing Base
  • the first blockchain node may execute the write cache function code in the TEE to store the above-mentioned receipt data in the write cache in the TEE.
  • the write cache may correspond to the one shown in FIG. 2 "Cache".
  • the first blockchain node outputs the data in the write cache from the trusted execution environment to be stored in the external storage space.
  • the write cache function code can be stored in the TEE in plain text, and the cache function code in the plain text can be directly executed in the TEE; or, the write cache function code can be stored outside the TEE in cipher text, such as the above External storage space (such as the "package + storage” shown in Figure 2, where "package” means that the first blockchain node packs the transaction into blocks outside the trusted execution environment), the ciphertext form
  • the write cache function code is read into the TEE, decrypted into the plaintext code in the TEE, and the plaintext code is executed.
  • Write cache refers to a "buffer" mechanism provided to avoid “impact” to the external storage space when data is written to the external storage space.
  • the above-mentioned write cache can be implemented by using buffer; of course, the write cache can also be implemented by using cache, which is not limited in this specification.
  • the write cache mechanism can be used to write the data in the cache to the external storage space in batches, thereby reducing the gap between the TEE and the external storage space. The number of interactions increases the efficiency of data storage.
  • TEE may need to retrieve the generated data.
  • the data to be called happens to be in the write cache, the data can be read directly from the write cache.
  • the interaction between the external storage space eliminates the decryption process of the data read from the external storage space, thereby improving the data processing efficiency in the TEE.
  • the write cache can also be established outside the TEE.
  • the first blockchain node can execute the write cache function code outside the TEE, so as to store the above receipt data in the write cache outside the TEE, and further write The data in the cache is stored in an external storage space.
  • the receiving unit 61 receives an encrypted transaction corresponding to a smart contract, the code of the smart contract includes an object marked by an exposed identifier;
  • the decryption unit 62 decrypts the transaction in a trusted execution environment to obtain the code of the smart contract
  • the execution unit 63 executes the code of the smart contract in the trusted execution environment to obtain receipt data
  • the storage unit 64 stores the receipt data.
  • the receipt content corresponding to the object indicated by the exposure identifier is stored in plain text, and the rest of the receipt content is stored in cipher text.
  • the smart contract corresponding to the transaction received by the receiving unit 61 includes:
  • the node when the smart contract corresponding to the transaction received by the first blockchain node is a smart contract written in a high-level language, the node further includes:
  • the compiling unit 65 compiles the smart contract written in the high-level language through a compiler, and generates the smart contract in the form of bytecode for execution in the trusted execution environment.
  • the smart contract in the form of bytecode is a smart contract written in a high-level language by the client through a compiler It is obtained by compiling, and the smart contract written in the high-level language is written by the user on the client.
  • the smart contract written in the high-level language and the smart contract in bytecode form have the same or corresponding exposure identifier.
  • the smart contract corresponding to the transaction received by the receiving unit 61 includes:
  • the smart contract generated by the user on the first blockchain node or,
  • the smart contract generated by the user on the client or,
  • the objects indicated by the exposure identifier include: receipt fields and/or state variables.
  • the objects indicated by the exposure identifier include: contract-level objects; the storage unit 64 is specifically used for:
  • the objects indicated by the exposure identifier include: event-level objects corresponding to at least one event defined in the smart contract; the storage unit 64 is specifically configured to:
  • the receipt content corresponding to the at least one event in the receipt data is stored in plain text.
  • the first blockchain node determines the user type to which the transaction initiator belongs in the following manner:
  • the external account includes a type field recorded on the blockchain, and the value of the 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 66 changes the user type corresponding to the external account according to the change request initiated by the management user.
  • the storage unit 64 is specifically used for:
  • the code of the system contract defines the receipt data storage logic related to the exposed identifier and user type
  • the code of the system contract is executed to store the content of the receipt corresponding to the object indicated by the exposure identifier in plain text when the transaction initiator belongs to the preset user type, and the rest of the receipt content in cipher text , And when the transaction initiator does not belong 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 used for:
  • the storage function code is executed outside the trusted execution environment to store the receipt data in an external storage space outside the trusted execution environment.
  • the transaction is used to create and/or call the smart contract.
  • the key used by the first blockchain node to encrypt the receipt field includes: a key of a symmetric encryption algorithm or a key of an asymmetric encryption algorithm.
  • the key of the symmetric encryption algorithm includes an initial key provided by the client; or, the key of the symmetric encryption algorithm includes a derived key generated by the initial key and an influence factor.
  • the transaction is encrypted by the initial key, and the initial key is encrypted by the 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
  • 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 can be in 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)
  • Physics & Mathematics (AREA)
  • Finance (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

L'invention porte sur un procédé de stockage de reçu, combinant un marquage de code avec un type d'utilisateur, et sur un nœud. Le procédé comprend les étapes suivantes : un premier nœud de chaîne de blocs reçoit une transaction chiffrée correspondant à un contrat intelligent, le code du contrat intelligent comprenant un objet identifié par un identifiant exposé (302) ; le premier nœud de chaîne de blocs déchiffre la transaction dans un environnement d'exécution de confiance pour acquérir le code du contrat intelligent (304) ; le premier nœud de chaîne de blocs exécute le code du contrat intelligent dans l'environnement d'exécution de confiance pour obtenir des données de reçu (306) ; le premier nœud de chaîne de blocs stocke les données de reçu de telle sorte que, lorsque la partie d'initiation de transaction appartient à un type d'utilisateur prédéfini, le contenu de reçu correspondant à l'objet identifié par l'identifiant exposé est stocké dans un format de texte en clair et le contenu de reçu restant est stocké dans un format de texte chiffré (308).
PCT/CN2020/091419 2019-05-20 2020-05-20 Procédé de stockage de reçu combinant un marquage de code avec un type d'utilisateur, et nœud WO2020233637A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201910419928.6A CN110245945B (zh) 2019-05-20 2019-05-20 结合代码标注与用户类型的收据存储方法和节点
CN201910419928.6 2019-05-20

Publications (1)

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

Family

ID=67884371

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2020/091419 WO2020233637A1 (fr) 2019-05-20 2020-05-20 Procédé de stockage de reçu combinant un marquage de code avec un type d'utilisateur, et nœud

Country Status (2)

Country Link
CN (1) CN110245945B (fr)
WO (1) WO2020233637A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112948499A (zh) * 2021-03-31 2021-06-11 北京金山云网络技术有限公司 信息获取方法和装置、电子设备和存储介质

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110263543B (zh) * 2019-05-20 2021-06-01 创新先进技术有限公司 基于代码标注的对象级收据存储方法和节点
CN110245503B (zh) * 2019-05-20 2021-04-27 创新先进技术有限公司 结合代码标注与判断条件的收据存储方法和节点
CN110245945B (zh) * 2019-05-20 2021-03-23 创新先进技术有限公司 结合代码标注与用户类型的收据存储方法和节点
WO2020233422A1 (fr) * 2019-05-20 2020-11-26 创新先进技术有限公司 Procédé et nœud de stockage de reçu basé sur un type d'utilisateur
CN110266644B (zh) * 2019-05-20 2021-04-06 创新先进技术有限公司 结合代码标注与交易类型的收据存储方法和节点
WO2020233421A1 (fr) * 2019-05-20 2020-11-26 创新先进技术有限公司 Procédé de stockage de reçu au niveau d'un objet et nœud basé sur un marquage de code
CN110263089B (zh) * 2019-05-20 2021-05-04 创新先进技术有限公司 结合交易与事件类型的条件限制的收据存储方法和节点
CN110580412B (zh) * 2019-11-08 2020-03-06 支付宝(杭州)信息技术有限公司 基于链代码的权限查询配置方法及装置

Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105653973A (zh) * 2015-12-16 2016-06-08 金蝶软件（中国）有限公司 基于业务平台的数据加密方法和装置
WO2017090041A1 (fr) * 2015-11-24 2017-06-01 Ben-Ari Adi Système et procédé pour la confidentialité de données par contrat intelligent de chaînes de blocs
CN107342858A (zh) * 2017-07-05 2017-11-10 武汉凤链科技有限公司 一种基于可信环境的智能合约保护方法和系统
CN108052321A (zh) * 2017-12-28 2018-05-18 杭州趣链科技有限公司 一种基于配置信息自动生成区块链智能合约的方法
CN109034814A (zh) * 2018-09-14 2018-12-18 百度在线网络技术（北京）有限公司 基于以太坊虚拟机的智能合约处理方法和装置
CN109040133A (zh) * 2018-09-27 2018-12-18 上海点融信息科技有限责任公司 在区块链网络中安装智能合约的方法、装置及存储介质
CN110245945A (zh) * 2019-05-20 2019-09-17 阿里巴巴集团控股有限公司 结合代码标注与用户类型的收据存储方法和节点
CN110266644A (zh) * 2019-05-20 2019-09-20 阿里巴巴集团控股有限公司 结合代码标注与交易类型的收据存储方法和节点
CN110264196A (zh) * 2019-05-20 2019-09-20 阿里巴巴集团控股有限公司 结合代码标注与用户类型的有条件的收据存储方法和节点

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11209815B2 (en) * 2016-04-01 2021-12-28 Intel Corporation Drone control registration
CN106559211B (zh) * 2016-11-22 2019-12-13 中国电子科技集团公司第三十研究所 一种区块链中隐私保护智能合约方法
CN107507091A (zh) * 2017-09-07 2017-12-22 复旦大学 基于区块链和智能合约的增强型数据权益保护方法
WO2019127531A1 (fr) * 2017-12-29 2019-07-04 深圳前海达闼云端智能科技有限公司 Procédé et appareil de traitement de données basés sur une chaîne de blocs, support d'informations et dispositif électronique
CN108922012B (zh) * 2018-07-11 2020-05-19 北京大账房网络科技股份有限公司 基于区块链技术不泄露原始信息的发票查验方法
CN109033855B (zh) * 2018-07-18 2020-02-11 腾讯科技（深圳）有限公司 一种基于区块链的数据传输方法、装置及存储介质
CN109214903A (zh) * 2018-08-10 2019-01-15 海南高灯科技有限公司 一种基于区块链的发票报销系统及报销方法
CN108961030B (zh) * 2018-08-15 2023-01-03 深圳市智税链科技有限公司 关于电子票据的数据处理方法、装置、系统、介质和设备
CN109523267A (zh) * 2018-10-30 2019-03-26 苏宁易购集团股份有限公司 一种基于区块链的交易数据的验证方法、装置及系统
CN109766722B (zh) * 2019-01-22 2020-11-10 苏州同济区块链研究院有限公司 一种区块链中构建智能合约的方法
CN109756582B (zh) * 2019-03-15 2022-08-12 腾讯科技（深圳）有限公司 区块链网络中的信息记录方法、装置、节点及存储介质

Patent Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017090041A1 (fr) * 2015-11-24 2017-06-01 Ben-Ari Adi Système et procédé pour la confidentialité de données par contrat intelligent de chaînes de blocs
CN105653973A (zh) * 2015-12-16 2016-06-08 金蝶软件（中国）有限公司 基于业务平台的数据加密方法和装置
CN107342858A (zh) * 2017-07-05 2017-11-10 武汉凤链科技有限公司 一种基于可信环境的智能合约保护方法和系统
CN108052321A (zh) * 2017-12-28 2018-05-18 杭州趣链科技有限公司 一种基于配置信息自动生成区块链智能合约的方法
CN109034814A (zh) * 2018-09-14 2018-12-18 百度在线网络技术（北京）有限公司 基于以太坊虚拟机的智能合约处理方法和装置
CN109040133A (zh) * 2018-09-27 2018-12-18 上海点融信息科技有限责任公司 在区块链网络中安装智能合约的方法、装置及存储介质
CN110245945A (zh) * 2019-05-20 2019-09-17 阿里巴巴集团控股有限公司 结合代码标注与用户类型的收据存储方法和节点
CN110266644A (zh) * 2019-05-20 2019-09-20 阿里巴巴集团控股有限公司 结合代码标注与交易类型的收据存储方法和节点
CN110264196A (zh) * 2019-05-20 2019-09-20 阿里巴巴集团控股有限公司 结合代码标注与用户类型的有条件的收据存储方法和节点

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112948499A (zh) * 2021-03-31 2021-06-11 北京金山云网络技术有限公司 信息获取方法和装置、电子设备和存储介质

Also Published As

Publication number Publication date
CN110245945A (zh) 2019-09-17
CN110245945B (zh) 2021-03-23

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
WO2020233642A1 (fr) Procédé de stockage de reçu conditionnel et nœud qui combinent un marquage de code et une dimension de type
WO2020233637A1 (fr) Procédé de stockage de reçu combinant un marquage de code avec un type d'utilisateur, et nœud
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
WO2020233644A1 (fr) Procédé de stockage de reçu conditionnel et nœud combinant des dimensions de type de code et d'annotation
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
WO2020233613A1 (fr) Procédé et noeud de stockage de reçu conditionnel qui combinent le marquage de code avec un type de transaction
WO2020233609A1 (fr) Procédé de stockage de réception conditionnel et nœud combinant le marquage de code avec le type d'utilisateur
WO2020233643A1 (fr) Procédé et nœud de stockage de reçu utilisant des informations multidimensionnelles et ayant une restriction
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
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
WO2020233623A1 (fr) Procédé de stockage de reçu et nœud combinant un type de transaction et un état d'évaluation
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
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
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
WO2020233626A1 (fr) Procédé et nœud de stockage de reçu combinés à une limitation conditionnelle de types de transactions et d'utilisateurs
WO2020233625A1 (fr) Procédé de stockage de reçus combinant un type d'utilisateur, des conditions de détermination et un nœud
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
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
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
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
WO2020233632A1 (fr) Procédé et nœud de stockage de reçu basés sur un type de fonction d'événement

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

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

Country of ref document: EP

Kind code of ref document: A1