WO2020233634A1 - Procédé et noeud destinés à une mémoire de réception associant des restrictions de condition de type de transaction et d'événement - Google Patents
Procédé et noeud destinés à une mémoire de réception associant des restrictions de condition de type de transaction et d'événement Download PDFInfo
- Publication number
- WO2020233634A1 WO2020233634A1 PCT/CN2020/091415 CN2020091415W WO2020233634A1 WO 2020233634 A1 WO2020233634 A1 WO 2020233634A1 CN 2020091415 W CN2020091415 W CN 2020091415W WO 2020233634 A1 WO2020233634 A1 WO 2020233634A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- transaction
- smart contract
- contract
- receipt
- blockchain node
- Prior art date
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/602—Providing cryptographic facilities or services
-
- 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 combine transaction and event type constraints.
- 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 the present specification provide a receipt storage method and node that combine transaction and event type constraints.
- a receipt storage method combining transaction and event types with conditional restrictions including:
- the first blockchain node receives an encrypted transaction calling the smart contract, and the transaction type of the transaction has a corresponding exposed field;
- the first blockchain node decrypts the transaction in a trusted execution environment to obtain the smart contract, and the smart contract includes a special event function;
- the first blockchain node executes the smart contract in the trusted execution environment to obtain receipt data, where the receipt data includes a log corresponding to the special event function;
- the first blockchain node stores the receipt data so that the exposed fields in the log corresponding to the special event function that meet the preset conditions are stored in plain text, and the rest of the receipt data is stored in cipher text.
- a receipt storage node that combines transaction and event type constraints is proposed, including:
- the receiving unit receives an encrypted transaction that calls the smart contract, and the transaction type of the transaction has a corresponding exposed field;
- a decryption unit decrypting the transaction in a trusted execution environment to obtain the smart contract, the smart contract including a special event function
- the storage unit stores the receipt data so that the exposed fields in the log corresponding to the special event function satisfying preset conditions are stored in plain text, and the rest of 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 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 flow chart of a method for storing receipts in combination with conditional restrictions of transaction and event types 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 that combines transaction and event types with conditional restrictions 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.
- log is a function provided in Ethereum.
- the logs generated by each event contained in the code can be recorded.
- the log allows to record the details of the event.
- the From and To fields mentioned above can indicate the accounts of both parties involved in the transaction, and the Topic field can contain the value of the state variables referenced by the event after the code is executed, etc. Therefore, not only can the log be used as relevant evidence after the transaction is executed on the blockchain, it can also be used to drive related operations.
- the callback function of JavaScript can be used to monitor events, and the corresponding log can be generated when the event is triggered. Therefore, by retrieving the log content, the DAPP (Decentralized Application) client can be driven to perform related execution when the preset log content is retrieved Processing operations, etc.
- DAPP Decentralized Application
- 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.
- Step 302 The first blockchain node receives an encrypted transaction for invoking the smart contract, and the transaction type of the transaction has a corresponding exposed field.
- 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 transaction content may include the account address of the smart contract being called, the methods and parameters that need to be passed in, and so on.
- the transaction may include a transaction type field (such as a Type field), and the value of the transaction type field is used to indicate the corresponding transaction type. Therefore, by reading the value of the transaction type field in the exchange, the transaction type can be determined, such as the type of deposit certificate, the type of asset transfer (such as transfer), the type of contract creation, and the type of contract invocation. This manual does not limit this .
- different types of transactions may respectively have corresponding exposed fields.
- the exposed field is one or more fields specified in the receipt data.
- the special event function contained in the smart contract and the exposure field’s satisfaction of the preset conditions can be selected.
- the mapping relationship between each transaction type and the exposed field may be predefined, and the mapping relationship may be recorded in the blockchain, so that the first blockchain node can obtain the predefined mapping relationship, And further determine the exposed fields in the receipt data according to the transaction type of the above-mentioned transaction and the mapping relationship.
- the exposed field corresponding to the attestation type may include all fields except the above-mentioned From field
- the exposed field corresponding to the asset transfer type may include the above-mentioned To field
- the exposed field corresponding to the contract creation type and contract invocation type may include the above-mentioned From field. All the fields except for the other transaction types will not be repeated here.
- mapping relationship can be specifically recorded in the system contract.
- the mapping relationship can also be recorded in the chain code of the blockchain network.
- Step 304 The first blockchain node decrypts the transaction in a trusted execution environment to obtain the smart contract, and the smart contract includes a special event function.
- the smart contract may include one or more events, and each event is used to implement predefined related processing logic. After each event contained in the smart contract is called and executed, the corresponding Logs field will be generated. For example, when the smart contract contains event 1 and event 2, event 1 can generate the corresponding Logs field, and event 2 can generate the corresponding Logs field. , So that the receipt data corresponding to the smart contract contains multiple Logs fields at the same time.
- the events contained in the smart contract can be divided into special event functions and ordinary event functions.
- the logs generated by the ordinary event functions are stored in cipher text to achieve privacy protection; the special event functions generated Logs need to store at least part of the log fields (such as the exposed fields described above) in plain text on the premise of meeting the privacy protection requirements, so that the content of this part of the log fields can be retrieved to drive related operations.
- this specification further refers to the predefined relevant conditions (ie, preset conditions), which can be used to judge and identify the location of the exposed fields.
- Privacy level with content When the exposed field meets the preset condition, it indicates that the privacy level is relatively low and can be stored in plain text. When the exposed field does not meet the preset condition, it indicates that the privacy level is relatively high and should be used. Stored in cipher text.
- the special event function may be a predefined global event function in the blockchain network.
- the event function belonging to the "special event function” can be recorded, for example, it can be recorded in the special event function list; accordingly, by combining the event function contained in the smart contract with By comparing the above special event function list, it can be determined whether the event function included in the smart contract is the above special event function.
- the special event function can be any function defined in the smart contract, and by adding a type identifier for the event function in the smart contract, the event function can be marked as a special event function.
- the code example of the event function included in the smart contract is as follows:
- the smart contract defines 2 events: event buy_candy1 and event buy_candy2.
- event buy_candy1 By adding the type identifier "expose" to the event buy_candy1, the event buy_candy1 can be marked as the above special event function; correspondingly, since the event buy_candy2 does not contain the type identifier "expose", the event buy_candy2 is a normal event function Instead of the special event function mentioned above.
- High-level languages supported by Ethereum such as Solidity, Serpent, and LLL languages
- a smart contract written in a high-level language can be compiled into a corresponding bytecode through a compiler, and the first blockchain node will finally execute the smart contract in the form of bytecode in the EVM virtual machine.
- the above-mentioned type identifier can be the same in high-level language and bytecode smart contract code, or the first type identifier in high-level language smart contract code, and the second type in bytecode smart contract code Type identifier, the first type identifier and the second type identifier can correspond to each other.
- 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 , And smart contract 3 includes a certain event function. In this way, it is equivalent to the event function included in smart contract 1.
- the specific implementation process is similar to the above process, and will not be repeated here.
- Step 306 The first blockchain node executes the smart contract in the trusted execution environment to obtain receipt data, where the receipt data includes a log corresponding to the special event function.
- a corresponding Logs field will be generated, that is, a log corresponding to each event function will be generated.
- the special event function it is possible to further determine the log corresponding to the special event function, so that at least a part of the log fields corresponding to the special event function (for example, the above-mentioned exposed fields) are used in plain text or Stored in ciphertext form.
- the first blockchain node after receiving a transaction invoking a smart contract from a client, the first blockchain node 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 by the encryption algorithm from the sender's address "0xf5e" and the nonce in the transaction.
- consensus algorithms such as Proof of Work (POW), Proof of Stake (POS), and Delegated Proof of Stake (DPOS) are adopted in blockchain networks that support smart contracts. All nodes competing for the right to account can execute the transaction after receiving the transaction including the creation of a smart contract. One of the nodes competing for the right to bookkeeping may win this round and become the bookkeeping node.
- the accounting node can package the transaction containing the smart contract with other transactions and generate a new block, and send the generated new block to other nodes for consensus.
- the nodes with the right to book accounts have been agreed before this round of bookkeeping. Therefore, after the first blockchain node receives the above transaction, if it is not the accounting node of this round, it can send the transaction to the accounting node.
- accounting nodes which can be the first blockchain node
- the accounting node packages the transaction (or other transactions together) and generates a new block
- the generated new block or block header is sent to other nodes for consensus.
- the accounting nodes in this round can package and package the transaction. Generate a new block, and send the header of the generated new block to other nodes for consensus. If other nodes receive the block and verify that there is no problem, they can append the new block to the end of the original block chain to complete the accounting process and reach a consensus; if the transaction is used to create a smart contract, then The deployment of the smart contract on the blockchain network is completed. If the transaction is used to call the smart contract, the call and execution of the smart contract are completed. In the process of verifying the new block or block header sent by the accounting node, other nodes may also execute the transaction in the block.
- the execution process can generally be executed by a virtual machine. Taking Ethereum as an example, it supports users to create and/or call some complex logic in the Ethereum network. This is the biggest challenge that distinguishes Ethereum from Bitcoin blockchain technology.
- the core of Ethereum as a programmable blockchain is the Ethereum Virtual Machine (EVM), and every Ethereum node can run EVM.
- EVM is a Turing complete virtual machine, which means that various complex logic can be implemented through it. Users publish and call smart contracts in Ethereum run on the EVM.
- the first blockchain node can execute the decrypted smart contract code in a Trusted Execution Environment (TEE).
- TEE Trusted Execution Environment
- the first blockchain node can be divided into a regular execution environment (on the left in the figure) and TEE, and transactions submitted by the client (as described above, transactions can have other sources; here, the client submits Take the transaction as an example to illustrate)
- First enter the "transaction/query interface" in the regular execution environment for identification.
- Transactions without privacy processing requirements can be left in the regular execution environment for processing (here it 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 plaintext code for executing smart contracts can load the EVM into the enclosure.
- the key management server can calculate the hash value of the local EVM code and compare it with the hash value of the EVM code loaded in the first blockchain node. The correct comparison result is a necessary condition for passing remote certification. , So as to complete the measurement of the code loaded in the SGX circle of the first blockchain node. After measurement, the correct EVM can execute the above smart contract code in SGX.
- Step 308 The first blockchain node stores the receipt data so that the exposed fields in the log corresponding to the special event function that meet the preset conditions are stored in plain text, and the rest of the receipt data is stored in cipher text. .
- the exposed fields allowed to be stored in plaintext can be determined according to the differentiated requirements of different types of transactions for privacy protection; further, because different event functions often involve different information , So that different event functions correspond to different privacy protection requirements.
- the privacy protection requirements of event functions related to the transfer amount are relatively high, and the privacy protection requirements of event functions related to evidence are relatively low (here only for example ;
- the privacy protection requirement of the related event function may also be relatively low, and when the deposit content is more important, the privacy protection requirement of the related event function may also be relatively high
- the event function with relatively low privacy protection requirements can be configured as the above special event function, and when the above exposed field is included in the log generated by the special event function, the receipt content corresponding to the exposed field is allowed to be exposed; furthermore, even For the exposed fields in the logs generated by the special event function, there are still differentiated privacy protection requirements in different scenarios.
- the difference in privacy protection can be reflected in the storage process according to the satisfaction of the preset conditions by the exposed fields Modification requirements and processing:
- the exposed fields that meet the preset conditions can be stored in plaintext, while the exposed fields or other receipt fields that do not meet the preset conditions are inevitable Stored in cipher text.
- a special event function involves a deposit operation
- the exposed field can be Store in plain text, otherwise store in cipher text.
- the content of the preset condition may include at least one of the following: the corresponding receipt field contains the preset content, the value of the corresponding receipt field belongs to the preset numerical interval, and so on.
- the preset content may include: one or more specified keywords, for example, the keyword may include predefined state variables, predefined intermediate variables, etc., so that when a certain exposed field contains a state variable or intermediate variable as a keyword It can be determined that the exposed field meets the preset conditions.
- the preset content may include: preset values.
- the preset value can be a numeric value, which can be compared with the value of a state variable, etc., to determine whether the value of the state variable meets expectations; for another example, the preset value can be composed of numeric values, letters, special symbols, etc.
- a character string which can be compared with the account address of the transaction initiator, the account address of the transaction target, the log subject, etc. to identify a specific transaction initiator, a specific transaction target, or a specific log subject, etc.
- the exposed field corresponding to the transaction type includes the To field
- the log generated by the special event function includes the To field
- the To field in the log generated by the special event function is stored in plain text
- the To field in the log generated by the ordinary event function is stored in cipher text
- the To field in all logs is stored in cipher text to avoid leakage of privacy.
- the preset value range can indicate the privacy protection requirements of the relevant receipt fields.
- the preset value range can be a value range with a smaller value and a lower privacy protection requirement, so that even if the relevant receipt field is disclosed, it will not cause Serious user privacy leakage, but it can be used to automatically trigger related operations such as DAPP client, so as to achieve a certain balance between privacy protection and convenience. Therefore, for the log generated by the special event function, when the value of the exposed field in the log is within the preset numerical interval, the exposed field can be stored in plain text.
- the preset condition may include a general condition corresponding to all receipt fields in the receipt data, that is, when any receipt field in the receipt data is identified as an exposed field, it is used for comparison with the preset condition.
- a general condition corresponding to all receipt fields in the receipt data that is, when any receipt field in the receipt data is identified as an exposed field, it is used for comparison with the preset condition.
- the preset condition is "contains preset keywords”
- all exposed fields in the log generated by the special event function can be compared with the keywords contained in the preset condition to determine that the key is included
- the exposed field of the word is used as the exposed field that meets the above preset conditions.
- the preset condition may include a dedicated condition corresponding to each receipt field in the receipt data, that is, each receipt field in the receipt data has a corresponding preset condition, so that each determined exposed field is Used to compare with the corresponding preset conditions.
- the preset conditions corresponding to different receipt fields are independent of each other, but may be the same or different.
- the preset condition corresponding to the From field may be "whether the preset content is included”
- the preset content may be a preset account address, indicating a transaction initiated by the account address
- the preset condition corresponding to the Topic field may be "Whether it belongs to the preset value range", and the value of the state variable referenced by the related event can be recorded in the Topic field.
- the state variable representing "transfer amount” can be included, indicating that the transfer amount is within the preset value range ; Then: when the log generated by the special event function contains the From field and the Topic field as exposed fields, the From field is suitable for comparison with the preset condition "Does it contain preset content", and the Topic field is suitable for comparing with the preset condition" Whether it belongs to the preset value range" for comparison.
- 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 can be expressed as: differences in at least one dimension in the content of the preset conditions, the receipt fields to which the preset conditions apply, and the processing logic for determining whether the exposed 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 called by the transaction or transaction does not contain preset conditions, it can be based on the preset conditions defined in the system contract or chain code, combined with the exposed fields contained in the log generated by the special event function To determine the storage method of the exposed field.
- 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 transaction types, event functions, and preset conditions can be written into the chain code, so that each blockchain node can implement the receipt Data storage logic.
- Receipt data storage logic related to transaction types, event functions and preset conditions may include: recognition logic for transaction types, confirmation logic for exposed fields, recognition logic for special event functions, determination logic for preset conditions, Processing logic of exposed fields, etc.
- the identification logic of the transaction type is used to instruct the first blockchain node: to identify the type of transaction initiated by the transaction initiator. For example, according to the value of the transaction type field contained in the exchange, the transaction type corresponding to the transaction is determined. For details, please refer to the relevant description of identifying transaction types above, which will not be repeated here.
- the confirmation logic for the exposed field is used to instruct the first blockchain node to determine the corresponding exposed field according to the transaction type. For example: according to the mapping relationship between the transaction type and the exposed field recorded in the chain code or system contract or block, combined with the transaction type of the current initiated transaction, determine the corresponding exposed field. For details, please refer to the relevant description of the exposed field corresponding to the known transaction type above, which will not be repeated here.
- the recognition logic of the special event function is used to instruct the first blockchain node to identify the special event function contained in the smart contract.
- the system contract can record a list of predefined special event functions, or the system contract can record the processing logic for identifying special event functions based on type identifiers. For details, please refer to the relevant description of identifying special event functions above, which will not be repeated here.
- the determination logic for the preset condition is used to instruct the first blockchain node to obtain the preset condition applicable to the exposed field. For example: obtaining general conditions applicable to all receipt fields, or obtaining special conditions applicable to exposed fields, etc. For details, please refer to the relevant description of the preset conditions above, which will not be repeated here.
- the processing logic for the exposed field is used to instruct the first blockchain node: to store the receipt content corresponding to the exposed field in the receipt data.
- the content of the receipt corresponding to the exposed field in the log can be compared with a preset condition, so that the content of the receipt meeting the preset condition is stored in plain text, and the Receipt content corresponding to exposed fields and non-exposed fields in the log that do not meet preset conditions are stored in cipher text, and other receipt content in receipt data (such as receipt content corresponding to ordinary event functions) is stored in cipher text Form storage.
- a preset condition so that the content of the receipt meeting the preset condition is stored in plain text
- the Receipt content corresponding to exposed fields and non-exposed fields in the log that do not meet preset conditions are stored in cipher text
- other receipt content in receipt data (such as receipt content corresponding to ordinary event functions) is stored in cipher text Form storage.
- 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 transaction types, event functions, and preset conditions; then, the first blockchain node The code of the system contract can be executed, and based on the receipt data storage logic related to the transaction type, event function and preset conditions, if the exposed field in the log corresponding to the special event function meets the preset condition, the exposed field It is stored in plain text, and 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 the non-exposed fields in the special event function and the receipt content corresponding to the non-special event function by using 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 may use the aforementioned initial key to encrypt the content of the receipt.
- Different transactions can use the same initial key, so that all transactions submitted by the same user are encrypted with this initial key, or different transactions can use different initial keys.
- the client can randomly generate an initial key for each transaction. Key to improve security.
- the first blockchain node may generate a derived key according to the initial key and the impact factor, and encrypt the content of the receipt through the derived key.
- the derived key can increase the degree of randomness, thereby increasing the difficulty of being compromised and helping to optimize the security protection of data.
- the impact factor can be related to the transaction; for example, the impact factor can include the specified bits of the transaction hash value.
- the first blockchain node can associate the initial key with the first 16 bits (or the first 32 bits and the last 16 bits) of the transaction hash value. Bits, last 32 bits, or other bits) are spliced, and the spliced string is hashed to generate a derived key.
- the first blockchain node may also use an asymmetric encryption method, that is, use the public key of the asymmetric encryption algorithm to encrypt the content of the receipt, and accordingly, the client may use the private key of the asymmetric encryption algorithm.
- the key decrypts the encrypted receipt content.
- the key of an asymmetric encryption algorithm for example, can be that the client generates a pair of public and private keys, and sends the public key to the first blockchain node in advance, so that the first blockchain node can use the receipt content Public key encryption.
- the first blockchain node realizes the function by running the code used to realize the function. Therefore, for the functions that need to be implemented in the TEE, the relevant code also needs to be executed. For the code executed in the TEE, it needs to meet 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 conjunction with the specifications and requirements of the TEE. Large amount of development, and easy to produce loopholes (bugs) in the process of rewriting, affecting the reliability and stability of function implementation.
- the first blockchain node can execute the storage function code outside the TEE to store the receipt data generated in the TEE (including the receipt content in plain text that needs to be stored in plain text, and the receipt content in cipher text that needs to be stored in cipher text.
- TEE Is stored in an external storage space outside the TEE, so that the storage function code can be the code used to implement the storage function in the related technology, and does not need to be rewritten in conjunction with the specifications and requirements of the TEE to achieve safe and reliable receipt data
- the storage of TEE can not only reduce the amount of related code development without affecting security and reliability, but also reduce TCB (Trusted Computing Base) by reducing the related code of TEE, making TEE technology and regional In the process of combining block chain technology, the additional security risks caused are in a controllable range.
- TCB Trusted Computing Base
- the first blockchain node may execute the write cache function code in the TEE to store the above-mentioned receipt data in the write cache in the TEE.
- the write cache may correspond to the one shown in FIG. 1 "Cache".
- the first blockchain node outputs the data in the write cache from the trusted execution environment to be stored in the external storage space.
- the write cache function code can be stored in the TEE in plain text, and the cache function code in the plain text can be directly executed in the TEE; or, the write cache function code can be stored outside the TEE in cipher text, such as the above External storage space (such as the "package + storage” shown in Figure 4, where "package” means that the first blockchain node packages the transaction into blocks outside of the trusted execution environment), the cipher text form
- the write cache function code is read into the TEE, decrypted into the plaintext code in the TEE, and the plaintext code is executed.
- Write cache refers to a "buffer" mechanism provided to avoid “impact” to the external storage space when data is written to the external storage space.
- the above-mentioned write cache can be implemented by using buffer; of course, the write cache can also be implemented by using cache, which is not limited in this specification.
- the write cache mechanism can be used to write the data in the cache to the external storage space in batches, thereby reducing the gap between the TEE and the external storage space. The number of interactions increases the efficiency of data storage.
- TEE may need to retrieve the generated data.
- the data to be called happens to be in the write cache, the data can be read directly from the write cache.
- the interaction between the external storage space eliminates the decryption process of the data read from the external storage space, thereby improving the data processing efficiency in the TEE.
- the write cache can also be established outside the TEE.
- the first blockchain node can execute the write cache function code outside the TEE, so as to store the above receipt data in the write cache outside the TEE, and further write The data in the cache is stored in an external storage space.
- the receiving unit 61 receives an encrypted transaction that calls the smart contract, and the transaction type of the transaction has a corresponding exposed field;
- a decryption unit 62 decrypting the transaction in a trusted execution environment to obtain the smart contract, the smart contract including a special event function;
- the execution unit 63 executes the smart contract in the trusted execution environment to obtain receipt data, where the receipt data includes a log corresponding to the special event function;
- the storage unit 64 stores the receipt data so that the exposed fields in the log corresponding to the special event function satisfying preset conditions are stored in plain text, and the rest of the receipt data is stored in cipher text.
- the transaction includes a transaction type field, and the value of the transaction type field is used to indicate the corresponding transaction type.
- the transaction type of the transaction includes: deposit certificate type, asset transfer type, contract creation type, contract call type.
- a predefined mapping relationship between the transaction type and the exposed field is stored in the blockchain, and the mapping relationship is used to determine the exposed field corresponding to the transaction type of the transaction.
- the event function in the smart contract includes a type identifier, and the type identifier is used to mark the event function as a special event function.
- the event function included in the smart contract is in the special function list recorded on the blockchain, the event function included in the smart contract is determined to be a special event function.
- the preset condition includes at least one of the following: the corresponding receipt 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 exposed fields meeting preset conditions in the log corresponding to the special event function in plain text, and the remaining content of the receipt data 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 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 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
- 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
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Business, Economics & Management (AREA)
- Physics & Mathematics (AREA)
- Finance (AREA)
- Accounting & Taxation (AREA)
- Databases & Information Systems (AREA)
- General Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Bioethics (AREA)
- Computing Systems (AREA)
- Computer Security & Cryptography (AREA)
- Data Mining & Analysis (AREA)
- Computer Hardware Design (AREA)
- General Health & Medical Sciences (AREA)
- Health & Medical Sciences (AREA)
- Development Economics (AREA)
- Economics (AREA)
- Marketing (AREA)
- Strategic Management (AREA)
- Technology Law (AREA)
- General Business, Economics & Management (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
L'invention concerne un procédé et un nœud destinés à une mémoire de réception associant des restrictions de condition de type de transaction et d'événement, le procédé comprenant les étapes suivantes : un premier nœud de chaîne de blocs reçoit une transaction chiffrée faisant appel à un contrat intelligent, un type de transaction de la transaction étant enregistré dans un champ exposé correspondant (302) ; le premier nœud de chaîne de blocs déchiffre la transaction dans un environnement d'exécution de confiance afin d'obtenir le contrat intelligent, le contrat intelligent comportant une fonction d'événement spécial (304) ; le premier nœud de chaîne de blocs exécute le contrat intelligent dans l'environnement d'exécution de confiance, et obtient des données de réception, les données de réception comportant un registre correspondant à la fonction d'événement spécial (306) ; le premier nœud de chaîne de blocs mémorise les données de réception, de telle sorte qu'un champ exposé, satisfaisant à une condition prédéfinie, du registre correspondant à la fonction d'événement spécial, est stocké sous forme de texte en clair, et le contenu restant des données de réception est stocké sous forme de cryptogramme (308).
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201910419925.2A CN110263089B (zh) | 2019-05-20 | 2019-05-20 | 结合交易与事件类型的条件限制的收据存储方法和节点 |
CN201910419925.2 | 2019-05-20 |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2020233634A1 true WO2020233634A1 (fr) | 2020-11-26 |
Family
ID=67914793
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/CN2020/091415 WO2020233634A1 (fr) | 2019-05-20 | 2020-05-20 | Procédé et noeud destinés à une mémoire de réception associant des restrictions de condition de type de transaction et d'événement |
Country Status (2)
Country | Link |
---|---|
CN (1) | CN110263089B (fr) |
WO (1) | WO2020233634A1 (fr) |
Families Citing this family (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2020233424A1 (fr) * | 2019-05-20 | 2020-11-26 | 创新先进技术有限公司 | Procédé de stockage de reçu sur la base d'un type de fonction d'événement et nœud associé |
CN110263089B (zh) * | 2019-05-20 | 2021-05-04 | 创新先进技术有限公司 | 结合交易与事件类型的条件限制的收据存储方法和节点 |
WO2020233425A1 (fr) * | 2019-05-20 | 2020-11-26 | 创新先进技术有限公司 | Procédé et nœud de stockage de reçu basés sur une condition de détermination |
CN114116166A (zh) * | 2021-06-02 | 2022-03-01 | 支付宝(杭州)信息技术有限公司 | 基于智能合约的任务执行方法及装置 |
Citations (33)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN106506467A (zh) * | 2016-10-31 | 2017-03-15 | 国云科技股份有限公司 | 一种基于区块链的身份证明记录方法 |
CN107342858A (zh) * | 2017-07-05 | 2017-11-10 | 武汉凤链科技有限公司 | 一种基于可信环境的智能合约保护方法和*** |
CN108235772A (zh) * | 2017-12-29 | 2018-06-29 | 深圳前海达闼云端智能科技有限公司 | 基于区块链的数据处理方法、装置、存储介质及电子设备 |
CN108776936A (zh) * | 2018-06-05 | 2018-11-09 | 中国平安人寿保险股份有限公司 | 保险理赔方法、装置、计算机设备和存储介质 |
CN110223172A (zh) * | 2019-05-20 | 2019-09-10 | 阿里巴巴集团控股有限公司 | 有条件的结合代码标注与类型维度的收据存储方法和节点 |
CN110245944A (zh) * | 2019-05-20 | 2019-09-17 | 阿里巴巴集团控股有限公司 | 基于用户类型的收据存储方法和节点 |
CN110245504A (zh) * | 2019-05-20 | 2019-09-17 | 阿里巴巴集团控股有限公司 | 结合多类型维度的条件限制的收据存储方法和节点 |
CN110245503A (zh) * | 2019-05-20 | 2019-09-17 | 阿里巴巴集团控股有限公司 | 结合代码标注与判断条件的收据存储方法和节点 |
CN110245947A (zh) * | 2019-05-20 | 2019-09-17 | 阿里巴巴集团控股有限公司 | 结合交易与用户类型的条件限制的收据存储方法和节点 |
CN110245490A (zh) * | 2019-05-20 | 2019-09-17 | 阿里巴巴集团控股有限公司 | 有条件的结合代码标注与类型维度的收据存储方法和节点 |
CN110245942A (zh) * | 2019-05-20 | 2019-09-17 | 阿里巴巴集团控股有限公司 | 结合用户类型和判断条件的收据存储方法和节点 |
CN110247895A (zh) * | 2019-05-20 | 2019-09-17 | 阿里巴巴集团控股有限公司 | 结合代码标注与事件函数类型的收据存储方法和节点 |
CN110245943A (zh) * | 2019-05-20 | 2019-09-17 | 阿里巴巴集团控股有限公司 | 基于判断条件的收据存储方法和节点 |
CN110245946A (zh) * | 2019-05-20 | 2019-09-17 | 阿里巴巴集团控股有限公司 | 结合代码标注与多类型维度的收据存储方法和节点 |
CN110245489A (zh) * | 2019-05-20 | 2019-09-17 | 阿里巴巴集团控股有限公司 | 基于明文日志的收据存储方法、节点和*** |
CN110245945A (zh) * | 2019-05-20 | 2019-09-17 | 阿里巴巴集团控股有限公司 | 结合代码标注与用户类型的收据存储方法和节点 |
CN110266644A (zh) * | 2019-05-20 | 2019-09-20 | 阿里巴巴集团控股有限公司 | 结合代码标注与交易类型的收据存储方法和节点 |
CN110263090A (zh) * | 2019-05-20 | 2019-09-20 | 阿里巴巴集团控股有限公司 | 多类型维度的收据存储方法和节点 |
CN110263091A (zh) * | 2019-05-20 | 2019-09-20 | 阿里巴巴集团控股有限公司 | 结合代码标注与用户、事件类型的收据存储方法和节点 |
CN110264198A (zh) * | 2019-05-20 | 2019-09-20 | 阿里巴巴集团控股有限公司 | 结合代码标注与交易类型的有条件的收据存储方法和节点 |
CN110263544A (zh) * | 2019-05-20 | 2019-09-20 | 阿里巴巴集团控股有限公司 | 结合交易类型和判断条件的收据存储方法和节点 |
CN110264193A (zh) * | 2019-05-20 | 2019-09-20 | 阿里巴巴集团控股有限公司 | 结合用户类型与交易类型的收据存储方法和节点 |
CN110263089A (zh) * | 2019-05-20 | 2019-09-20 | 阿里巴巴集团控股有限公司 | 结合交易与事件类型的条件限制的收据存储方法和节点 |
CN110263543A (zh) * | 2019-05-20 | 2019-09-20 | 阿里巴巴集团控股有限公司 | 基于代码标注的对象级收据存储方法和节点 |
CN110264195A (zh) * | 2019-05-20 | 2019-09-20 | 阿里巴巴集团控股有限公司 | 结合代码标注与交易、用户类型的收据存储方法和节点 |
CN110264196A (zh) * | 2019-05-20 | 2019-09-20 | 阿里巴巴集团控股有限公司 | 结合代码标注与用户类型的有条件的收据存储方法和节点 |
CN110264194A (zh) * | 2019-05-20 | 2019-09-20 | 阿里巴巴集团控股有限公司 | 基于事件函数类型的收据存储方法和节点 |
CN110263087A (zh) * | 2019-05-20 | 2019-09-20 | 阿里巴巴集团控股有限公司 | 基于多维度信息且具有条件限制的收据存储方法和节点 |
CN110263088A (zh) * | 2019-05-20 | 2019-09-20 | 阿里巴巴集团控股有限公司 | 结合代码标注与事件类型的有条件的收据存储方法和节点 |
CN110263086A (zh) * | 2019-05-20 | 2019-09-20 | 阿里巴巴集团控股有限公司 | 结合用户类型与事件函数类型的收据存储方法和节点 |
CN110264197A (zh) * | 2019-05-20 | 2019-09-20 | 阿里巴巴集团控股有限公司 | 结合事件函数类型和判断条件的收据存储方法和节点 |
CN110278193A (zh) * | 2019-05-20 | 2019-09-24 | 阿里巴巴集团控股有限公司 | 结合代码标注与交易、事件类型的收据存储方法和节点 |
CN110276684A (zh) * | 2019-05-20 | 2019-09-24 | 阿里巴巴集团控股有限公司 | 结合交易类型和事件函数类型的收据存储方法和节点 |
Family Cites Families (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN106559211B (zh) * | 2016-11-22 | 2019-12-13 | 中国电子科技集团公司第三十研究所 | 一种区块链中隐私保护智能合约方法 |
CN107451175B (zh) * | 2017-05-23 | 2020-01-31 | 创新先进技术有限公司 | 一种基于区块链的数据处理方法及设备 |
CN108418783B (zh) * | 2017-09-01 | 2021-03-19 | 矩阵元技术(深圳)有限公司 | 一种保护区块链智能合约隐私的方法、介质 |
CN109254975A (zh) * | 2018-09-21 | 2019-01-22 | 上海点融信息科技有限责任公司 | 基于区块链实现图书共享的方法、设备及可读存储介质 |
CN109040139B (zh) * | 2018-10-12 | 2021-05-18 | 重庆邮电大学 | 一种基于区块链与智能合约的身份认证***及方法 |
CN109299217B (zh) * | 2018-11-02 | 2019-10-18 | 符安文 | 一种基于区块链的安全存储和检索方法 |
CN109639632B (zh) * | 2018-11-02 | 2021-06-22 | 远光软件股份有限公司 | 基于区块链的用户信息管理方法、电子设备及存储介质 |
CN109583889B (zh) * | 2018-11-09 | 2023-10-31 | 阮静 | 基于区块链的***或签名识别*** |
CN110471952B (zh) * | 2018-12-07 | 2023-05-26 | 深圳市智税链科技有限公司 | 在区块链网络中确定记账节点的方法、代理节点和介质 |
CN109547477B (zh) * | 2018-12-27 | 2021-04-23 | 石更箭数据科技(上海)有限公司 | 一种数据处理方法及其装置、介质、终端 |
CN109754250B (zh) * | 2018-12-27 | 2021-06-08 | 石更箭数据科技(上海)有限公司 | 数据交易方法及***、平台、存储介质 |
-
2019
- 2019-05-20 CN CN201910419925.2A patent/CN110263089B/zh active Active
-
2020
- 2020-05-20 WO PCT/CN2020/091415 patent/WO2020233634A1/fr active Application Filing
Patent Citations (33)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN106506467A (zh) * | 2016-10-31 | 2017-03-15 | 国云科技股份有限公司 | 一种基于区块链的身份证明记录方法 |
CN107342858A (zh) * | 2017-07-05 | 2017-11-10 | 武汉凤链科技有限公司 | 一种基于可信环境的智能合约保护方法和*** |
CN108235772A (zh) * | 2017-12-29 | 2018-06-29 | 深圳前海达闼云端智能科技有限公司 | 基于区块链的数据处理方法、装置、存储介质及电子设备 |
CN108776936A (zh) * | 2018-06-05 | 2018-11-09 | 中国平安人寿保险股份有限公司 | 保险理赔方法、装置、计算机设备和存储介质 |
CN110223172A (zh) * | 2019-05-20 | 2019-09-10 | 阿里巴巴集团控股有限公司 | 有条件的结合代码标注与类型维度的收据存储方法和节点 |
CN110245944A (zh) * | 2019-05-20 | 2019-09-17 | 阿里巴巴集团控股有限公司 | 基于用户类型的收据存储方法和节点 |
CN110245504A (zh) * | 2019-05-20 | 2019-09-17 | 阿里巴巴集团控股有限公司 | 结合多类型维度的条件限制的收据存储方法和节点 |
CN110245503A (zh) * | 2019-05-20 | 2019-09-17 | 阿里巴巴集团控股有限公司 | 结合代码标注与判断条件的收据存储方法和节点 |
CN110245947A (zh) * | 2019-05-20 | 2019-09-17 | 阿里巴巴集团控股有限公司 | 结合交易与用户类型的条件限制的收据存储方法和节点 |
CN110245490A (zh) * | 2019-05-20 | 2019-09-17 | 阿里巴巴集团控股有限公司 | 有条件的结合代码标注与类型维度的收据存储方法和节点 |
CN110245942A (zh) * | 2019-05-20 | 2019-09-17 | 阿里巴巴集团控股有限公司 | 结合用户类型和判断条件的收据存储方法和节点 |
CN110247895A (zh) * | 2019-05-20 | 2019-09-17 | 阿里巴巴集团控股有限公司 | 结合代码标注与事件函数类型的收据存储方法和节点 |
CN110245943A (zh) * | 2019-05-20 | 2019-09-17 | 阿里巴巴集团控股有限公司 | 基于判断条件的收据存储方法和节点 |
CN110245946A (zh) * | 2019-05-20 | 2019-09-17 | 阿里巴巴集团控股有限公司 | 结合代码标注与多类型维度的收据存储方法和节点 |
CN110245489A (zh) * | 2019-05-20 | 2019-09-17 | 阿里巴巴集团控股有限公司 | 基于明文日志的收据存储方法、节点和*** |
CN110245945A (zh) * | 2019-05-20 | 2019-09-17 | 阿里巴巴集团控股有限公司 | 结合代码标注与用户类型的收据存储方法和节点 |
CN110266644A (zh) * | 2019-05-20 | 2019-09-20 | 阿里巴巴集团控股有限公司 | 结合代码标注与交易类型的收据存储方法和节点 |
CN110263090A (zh) * | 2019-05-20 | 2019-09-20 | 阿里巴巴集团控股有限公司 | 多类型维度的收据存储方法和节点 |
CN110263091A (zh) * | 2019-05-20 | 2019-09-20 | 阿里巴巴集团控股有限公司 | 结合代码标注与用户、事件类型的收据存储方法和节点 |
CN110264198A (zh) * | 2019-05-20 | 2019-09-20 | 阿里巴巴集团控股有限公司 | 结合代码标注与交易类型的有条件的收据存储方法和节点 |
CN110263544A (zh) * | 2019-05-20 | 2019-09-20 | 阿里巴巴集团控股有限公司 | 结合交易类型和判断条件的收据存储方法和节点 |
CN110264193A (zh) * | 2019-05-20 | 2019-09-20 | 阿里巴巴集团控股有限公司 | 结合用户类型与交易类型的收据存储方法和节点 |
CN110263089A (zh) * | 2019-05-20 | 2019-09-20 | 阿里巴巴集团控股有限公司 | 结合交易与事件类型的条件限制的收据存储方法和节点 |
CN110263543A (zh) * | 2019-05-20 | 2019-09-20 | 阿里巴巴集团控股有限公司 | 基于代码标注的对象级收据存储方法和节点 |
CN110264195A (zh) * | 2019-05-20 | 2019-09-20 | 阿里巴巴集团控股有限公司 | 结合代码标注与交易、用户类型的收据存储方法和节点 |
CN110264196A (zh) * | 2019-05-20 | 2019-09-20 | 阿里巴巴集团控股有限公司 | 结合代码标注与用户类型的有条件的收据存储方法和节点 |
CN110264194A (zh) * | 2019-05-20 | 2019-09-20 | 阿里巴巴集团控股有限公司 | 基于事件函数类型的收据存储方法和节点 |
CN110263087A (zh) * | 2019-05-20 | 2019-09-20 | 阿里巴巴集团控股有限公司 | 基于多维度信息且具有条件限制的收据存储方法和节点 |
CN110263088A (zh) * | 2019-05-20 | 2019-09-20 | 阿里巴巴集团控股有限公司 | 结合代码标注与事件类型的有条件的收据存储方法和节点 |
CN110263086A (zh) * | 2019-05-20 | 2019-09-20 | 阿里巴巴集团控股有限公司 | 结合用户类型与事件函数类型的收据存储方法和节点 |
CN110264197A (zh) * | 2019-05-20 | 2019-09-20 | 阿里巴巴集团控股有限公司 | 结合事件函数类型和判断条件的收据存储方法和节点 |
CN110278193A (zh) * | 2019-05-20 | 2019-09-24 | 阿里巴巴集团控股有限公司 | 结合代码标注与交易、事件类型的收据存储方法和节点 |
CN110276684A (zh) * | 2019-05-20 | 2019-09-24 | 阿里巴巴集团控股有限公司 | 结合交易类型和事件函数类型的收据存储方法和节点 |
Also Published As
Publication number | Publication date |
---|---|
CN110263089B (zh) | 2021-05-04 |
CN110263089A (zh) | 2019-09-20 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
WO2020233616A1 (fr) | Procédé de stockage de reçu et nœud utilisant un marquage de code en combinaison avec un type de transaction et un type d'utilisateur | |
WO2020233642A1 (fr) | Procédé de stockage de reçu conditionnel et nœud qui combinent un marquage de code et une dimension de type | |
WO2020233644A1 (fr) | Procédé de stockage de reçu conditionnel et nœud combinant des dimensions de type de code et d'annotation | |
WO2020233623A1 (fr) | Procédé de stockage de reçu et nœud combinant un type de transaction et un état d'évaluation | |
WO2020233635A1 (fr) | Procédé de stockage de reçu combinant des restrictions conditionnelles de multiples types de dimensions et nœud | |
WO2020233643A1 (fr) | Procédé et nœud de stockage de reçu utilisant des informations multidimensionnelles et ayant une restriction | |
WO2020233625A1 (fr) | Procédé de stockage de reçus combinant un type d'utilisateur, des conditions de détermination et un 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 | |
WO2020233630A1 (fr) | Procédé et nœud de mémorisation de reçus en fonction du type d'utilisateur | |
WO2020233613A1 (fr) | Procédé et noeud de stockage de reçu conditionnel qui combinent le marquage de code avec un type de transaction | |
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 | |
WO2020233626A1 (fr) | Procédé et nœud de stockage de reçu combinés à une limitation conditionnelle de types de transactions et d'utilisateurs | |
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 | |
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 | |
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 | |
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 | |
WO2020233609A1 (fr) | Procédé de stockage de réception conditionnel et nœud combinant le marquage de code avec le type d'utilisateur | |
WO2020233637A1 (fr) | Procédé de stockage de reçu combinant un marquage de code avec un type d'utilisateur, et nœud | |
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 | |
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 | |
WO2020233619A1 (fr) | Procédé et nœud de stockage de reçu en combinaison avec un type d'utilisateur et un type de transaction | |
WO2020233614A1 (fr) | Procédé et nœud de stockage de reçu conditionnel combinant un étiquetage de code avec un type d'événement | |
WO2020233631A1 (fr) | Procédé et nœud de stockage de reçu basés sur le type de transaction | |
WO2020233627A1 (fr) | Procédé et nœud de stockage de reçu basés sur de multiples types de dimensions | |
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: 20808987 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: 20808987 Country of ref document: EP Kind code of ref document: A1 |