CN111612462B - Method, node and storage medium for implementing privacy protection in blockchain - Google Patents
Method, node and storage medium for implementing privacy protection in blockchain Download PDFInfo
- Publication number
- CN111612462B CN111612462B CN202010451357.7A CN202010451357A CN111612462B CN 111612462 B CN111612462 B CN 111612462B CN 202010451357 A CN202010451357 A CN 202010451357A CN 111612462 B CN111612462 B CN 111612462B
- Authority
- CN
- China
- Prior art keywords
- transaction
- plaintext
- receipt data
- execution environment
- trusted execution
- Prior art date
- Legal status (The legal status 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 status listed.)
- Active
Links
- 238000000034 method Methods 0.000 title claims abstract description 68
- 238000003860 storage Methods 0.000 title claims abstract description 55
- 238000004422 calculation algorithm Methods 0.000 claims description 53
- 238000013175 transesophageal echocardiography Methods 0.000 description 33
- 230000006870 function Effects 0.000 description 26
- 238000005516 engineering process Methods 0.000 description 21
- 230000008569 process Effects 0.000 description 19
- 238000012545 processing Methods 0.000 description 17
- 238000010586 diagram Methods 0.000 description 8
- 238000004590 computer program Methods 0.000 description 7
- 230000006872 improvement Effects 0.000 description 7
- 238000007726 management method Methods 0.000 description 7
- 230000008520 organization Effects 0.000 description 7
- 230000007246 mechanism Effects 0.000 description 6
- 238000011161 development Methods 0.000 description 5
- 230000003993 interaction Effects 0.000 description 4
- 239000000872 buffer Substances 0.000 description 3
- 230000005540 biological transmission Effects 0.000 description 2
- 238000002955 isolation Methods 0.000 description 2
- 238000004519 manufacturing process Methods 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 238000012856 packing Methods 0.000 description 2
- OTZZZISTDGMMMX-UHFFFAOYSA-N 2-(3,5-dimethylpyrazol-1-yl)-n,n-bis[2-(3,5-dimethylpyrazol-1-yl)ethyl]ethanamine Chemical compound N1=C(C)C=C(C)N1CCN(CCN1C(=CC(C)=N1)C)CCN1C(C)=CC(C)=N1 OTZZZISTDGMMMX-UHFFFAOYSA-N 0.000 description 1
- OKTJSMMVPCPJKN-UHFFFAOYSA-N Carbon Chemical compound [C] OKTJSMMVPCPJKN-UHFFFAOYSA-N 0.000 description 1
- 241001441724 Tetraodontidae Species 0.000 description 1
- 230000009471 action Effects 0.000 description 1
- 238000013475 authorization Methods 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000008901 benefit Effects 0.000 description 1
- 230000003139 buffering effect Effects 0.000 description 1
- 238000004364 calculation method Methods 0.000 description 1
- 230000001413 cellular effect Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 238000004891 communication Methods 0.000 description 1
- 238000013500 data storage Methods 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 230000004069 differentiation Effects 0.000 description 1
- 229910021389 graphene Inorganic materials 0.000 description 1
- 230000000977 initiatory effect Effects 0.000 description 1
- 238000005304 joining Methods 0.000 description 1
- 238000005259 measurement Methods 0.000 description 1
- 230000005055 memory storage Effects 0.000 description 1
- 229920001296 polysiloxane Polymers 0.000 description 1
- 230000004044 response Effects 0.000 description 1
- 239000010979 ruby Substances 0.000 description 1
- 229910001750 ruby Inorganic materials 0.000 description 1
- 230000035939 shock Effects 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
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/3829—Payment protocols; Details thereof insuring higher security of transaction involving key management
-
- 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/62—Protecting access to data via a platform, e.g. using keys or access control rules
- G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
- G06F21/6245—Protecting personal data, e.g. for financial or medical purposes
Landscapes
- Engineering & Computer Science (AREA)
- Business, Economics & Management (AREA)
- Theoretical Computer Science (AREA)
- Health & Medical Sciences (AREA)
- Bioethics (AREA)
- General Health & Medical Sciences (AREA)
- Accounting & Taxation (AREA)
- Computer Security & Cryptography (AREA)
- General Physics & Mathematics (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Computer Hardware Design (AREA)
- Databases & Information Systems (AREA)
- Medical Informatics (AREA)
- Finance (AREA)
- Strategic Management (AREA)
- General Business, Economics & Management (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
- Storage Device Security (AREA)
Abstract
One or more embodiments of the present specification provide a method, node, and storage medium for implementing privacy protection in a blockchain, the method may include: the first block link point executes the transaction received from the client to obtain plaintext receipt data; and when the first blockchain node determines that the transaction is a private transaction, encrypting the plaintext receipt data into ciphertext receipt data by using a secret key, and then storing the ciphertext receipt data.
Description
Technical Field
One or more embodiments of the present specification relate to the field of blockchain technology, and in particular, to a method, a node, and a storage medium for implementing privacy protection in a blockchain.
Background
Blockchain technology builds on top of transport networks (e.g., point-to-point networks). Network nodes in the transport network utilize the chained data structures to validate and store data and employ distributed node consensus algorithms to generate and update data. Nodes in these blockchain networks sometimes need to be added.
The biggest two challenges in the current enterprise-level blockchain platform technology are privacy and performance, which are often difficult to solve simultaneously. Most solutions trade off performance for privacy, or do not consider privacy much to pursue performance. Common encryption technologies for solving privacy problems have high complexity such as homomorphic encryption (Homomorphic encryption) and Zero-knowledge proof (Zero-knowledgeproof), have poor generality, and may also bring about serious performance loss.
In addressing privacy, trusted execution environments (Trusted Execution Environment, TEE) are another solution. The TEE may act as a black box in the hardware, and code and data executed in the TEE cannot be peeped by the operating system layer, and can only be operated through a predefined interface in the code. In terms of efficiency, due to the black box property of the TEE, plaintext data is operated in the TEE instead of complex cryptographic operation in homomorphic encryption, and efficiency loss is avoided in the calculation process, so that the safety and privacy of the blockchain can be improved to a large extent on the premise of small performance loss by combining the TEE. The current industry is concerned with TEE solutions, with almost all mainstream chip and software alliances having their own TEE solutions, including TPM (Trusted Platform Module ) on software and Intel SGX (Software Guard Extensions, software protection extension), ARMTrustzone (trust zone) and AMD PSP (Platform Security Processor ) on hardware.
Disclosure of Invention
In view of this, one or more embodiments of the present specification provide a method, node, and storage medium for implementing privacy protection in a blockchain.
In order to achieve the above object, one or more embodiments of the present disclosure provide the following technical solutions:
according to a first aspect of one or more embodiments of the present specification, there is provided a method of implementing privacy protection in a blockchain, comprising:
the first block link point executes the transaction received from the client to obtain plaintext receipt data;
and when the first blockchain node determines that the transaction is a private transaction, encrypting the plaintext receipt data into ciphertext receipt data by using a secret key, and then storing the ciphertext receipt data.
According to a second aspect of one or more embodiments of the present specification, there is provided a node in a blockchain that implements privacy protection, comprising:
an execution unit for executing the transaction received from the client to obtain plain text receipt data;
and the storage unit is used for encrypting the plaintext receipt data into ciphertext receipt data by using a secret key when the transaction is determined to be the private transaction, and then storing the ciphertext receipt data.
According to a third aspect of one or more embodiments of the present description, a computer-readable storage medium is presented, on which computer instructions are stored, which instructions, when executed by a processor, implement the steps of the method according to the first aspect.
Drawings
FIG. 1 is a flowchart of a method for implementing privacy protection in a blockchain provided in an exemplary embodiment.
Fig. 2 is a schematic diagram of a transaction scenario provided by an exemplary embodiment.
Fig. 3 is a block diagram of nodes implementing privacy protection in a blockchain in accordance with an exemplary embodiment.
Detailed Description
Reference will now be made in detail to exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, the same numbers in different drawings refer to the same or similar elements, unless otherwise indicated. The implementations described in the following exemplary embodiments do not represent all implementations consistent with one or more embodiments of the present specification. Rather, they are merely examples of apparatus and methods consistent with aspects of one or more embodiments of the present description as detailed in the accompanying claims.
It should be noted that: in other embodiments, the steps of the corresponding method are not necessarily performed in the order shown and described in this specification. In some other embodiments, the method may include more or fewer steps than described in this specification. Furthermore, individual steps described in this specification, in other embodiments, may be described as being split into multiple steps; while various steps described in this specification may be combined into a single step in other embodiments.
Blockchains are generally divided into three types: public chains (Public Blockchain), private chains (Private Blockchain) and federated chains (Consortium Blockchain). In addition, there are many types of combinations, such as different combinations of private chain+federation chain, federation chain+public chain, and the like. Among them, the highest degree of decentralization is the public chain. The public chain is represented by bitcoin and ethernet, and participants joining the public chain can read data records on the chain, participate in transactions, compete for accounting rights of new blocks, and the like. Moreover, each participant (i.e., node) is free to join and leave the network and perform related operations. The private chain is the opposite, the write rights of the network are controlled by an organization or organization, and the data read rights are specified by the organization. In short, the private chain may be a weakly centralized system with few and strict restrictions on participating nodes. This type of blockchain is more suitable for use within a particular organization. The alliance chain is a block chain between public and private chains, and can realize 'partial decentralization'. Each node in the federation chain typically has an entity organization or organization corresponding thereto; participants join the network by authorization and form a benefit-related federation, collectively maintaining blockchain operation.
Whether public, private, or alliance, corresponding receipt (receipt) data may be generated after the transaction is performed for recording receipt information associated with the transaction. Taking ethernet as an example, receipt data from a node executing a transaction may include the following fields:
a blockHash field representing a hash value of a block in which the exchange is located;
a block number field, which indicates the sequence number of the block where the transaction is located;
a transactionHash field representing a hash value of the transaction;
a transactionIndex field, representing the sequence number of the transaction in the block at which it is located;
a from field representing an account address of the transaction generator;
a To field representing an account address of the transaction object (when the transaction is used To create a smart contract, the To field is empty);
a condactaddress field representing an address of the created smart contract when the transaction is used to create the smart contract, otherwise empty;
logs field, representing a log of transactions.
When each transaction contained in a certain block is executed by a node, corresponding receipt data is generated after each transaction is executed, and the node can organize the receipt data corresponding to each transaction contained in the block according to a predefined tree structure and processing logic to form a receipt tree. By organizing the generation of the receipt tree, when inquiring or verifying receipt data, the corresponding inquiring or verifying efficiency can be greatly improved. For example, the above-mentioned receipt tree is generated in the ethernet by adopting the MPT (Merkle Patricia Tree) structure organization, the leaf of the receipt tree is the hash value of the receipt data corresponding to each transaction contained in the block, and the receipt tree root (receipts root) is the root hash sequentially generated upward according to the hash value of the receipt data at the leaf. Of course, other types of tree structures may be employed in other blockchain networks.
The following describes, with reference to fig. 1, an implementation procedure of a method embodiment for implementing privacy protection in this specification:
in step 102, the first block link point performs the transaction received from the client, resulting in plain receipt data.
The transaction may be submitted by the client to the first blockchain node. For example, after the user generates the transaction at the client through the corresponding account, the transaction is submitted to the first blockchain node through the client. Taking fig. 2 as an example, the first blockchain node includes a transaction/query interface that interfaces with a client such that the client can submit a transaction to the first blockchain node.
After the first block link point executes the transaction, in addition to obtaining the corresponding transaction execution result, receipt data is generated, where the receipt data is in a plaintext form, that is, the plaintext receipt data.
Based on different privacy protection requirements, transactions may be classified into clear text transactions of clear text type, privacy transactions of privacy type. A type field may be added to the transaction so that the first blockchain node may identify the transaction type as either a clear text transaction or a private transaction based thereon. In the related art, for example, in an ethernet network, a transaction typically contains fields such as to, value, data. On the basis of the related technology, the embodiment adds a type field, such as a type field, in the transaction, and indicates the type of the related transaction based on the value of the type field; for example, when the type field is a first value, the related transaction is indicated as a clear text transaction, and when the type field is a second value, the related transaction is indicated as a private transaction.
All contents of the plaintext transaction are in a plaintext form, namely all fields of the transaction are in a plaintext form, so that the first blockchain node can directly read all the fields of the plaintext transaction to implement related processing; at the same time, the plaintext transaction is packed into blocks in plaintext form, which are then recorded in the blockchain in plaintext form. Besides the type field adopts a plaintext form, other fields adopt a ciphertext form, so that on one hand, a first blockchain node can quickly identify the transaction type under the condition that decryption is not needed, and therefore differentiation processing is implemented for the plaintext transaction and the privacy transaction, and on the other hand, the privacy transaction can only be decrypted and read by an object with a secret key by adopting the ciphertext form, so that leakage of transaction information is avoided, and the privacy transaction is packaged into blocks in the ciphertext form, and is recorded in a blockchain in the ciphertext form.
All transactions in the ethernet network are plain text transactions. The first blockchain node can expand a mixed processing scheme which gives consideration to plaintext transactions and private transactions on the basis of the first blockchain node. For example, as shown in fig. 2, the first blockchain node may be divided into a regular execution environment and a trusted execution environment, where transactions submitted by clients first enter a "transaction/query interface" in the regular execution environment for type identification (e.g., identifying the type field described above), leave identified plain-text transactions in the regular execution environment for processing, and pass identified private transactions to the trusted execution environment for processing. When the first blockchain node encrypts the plaintext receipt data in the trusted execution environment, in order to ensure smooth implementation of encryption operation, plaintext transactions may be transferred into the trusted execution environment for execution in some scenarios, and the distinction between the first blockchain node and the private transaction is only that the plaintext transactions do not need to be decrypted and the corresponding plaintext execution results do not need to be encrypted.
When the conventional execution environment processes the plaintext transaction, the whole processing process completely adopts a plaintext mode, namely, the plaintext transaction is processed by the first blockchain node to obtain the plaintext receipt data, and the plaintext receipt data is directly stored in the conventional execution environment. The trusted execution environment and the conventional execution environment are isolated from each other, the private transaction is in an encrypted state (except the type field) before entering the trusted execution environment, and the private transaction is decrypted into plaintext transaction content in the trusted execution environment, so that the plaintext transaction content can be efficiently processed in the trusted execution environment and corresponding plaintext receipt data is generated in the trusted execution environment on the premise of ensuring data security; further, when the plaintext receipt data is stored, it needs to be encrypted into corresponding ciphertext receipt data, and then stored in a conventional execution environment, for example, the plaintext receipt data corresponding to the plaintext transaction is stored in the same location, which may be a "package+store" module as shown in fig. 2.
The transactions in this specification may be used to implement relatively simple processing logic, such as transfer logic similar to that in the related art. In this case, either the plain or private transaction described above may be independent of the smart contract.
The transactions in this specification may also be used to implement relatively complex processing logic, which may be implemented here by means of the smart contracts described above. Taking the ethernet as an example, support users create and/or invoke some complex logic in the ethernet network, which is the biggest challenge for ethernet to distinguish from the bitcoin blockchain technology. At the heart of the ethernet as a programmable blockchain is an Ethernet Virtual Machine (EVM), which can be run by each ethernet node. The EVM is a graphics-complete virtual machine, meaning that various complex logic can be implemented by it. The user's issuing and invoking of the smart contract in the ethernet is running on the EVM. In practice, the virtual machine runs directly on virtual machine code (virtual machine bytecode, hereinafter "bytecode"). The intelligent contracts deployed on the blockchain may be in the form of bytecodes.
In one embodiment, the smart contracts of the present specification may be divided into plaintext contracts of plaintext type, privacy contracts of privacy type. The contract code and the contract state of the plaintext contract are both stored at the node in plaintext form, while the contract code and the contract state of the privacy contract are both stored at the node in ciphertext form, such that the privacy contract has relatively higher privacy. When a transaction is used to create and/or invoke a smart contract, the smart contract may be considered to correspond to the transaction.
Because the first blockchain node processes the plaintext transaction outside the trusted execution environment and directly stores the plaintext execution result (such as the changed contract state) obtained by the processing into the external storage space, when the plaintext transaction is used for creating the intelligent contract, the intelligent contract is necessarily stored in the external storage space in a plaintext form, and therefore the intelligent contract is necessarily a plaintext contract. Meanwhile, when the smart contract is invoked by the plaintext transaction, the smart contract invoked by the plaintext transaction can only be the plaintext contract because the privacy contract can only be decrypted in the trusted execution environment.
The first blockchain node may decrypt the private transaction in a trusted execution environment (Trusted Execution Environment, TEE). TEE is a trusted execution environment based on a secure extension of CPU hardware and completely isolated from the outside. TEE was originally proposed by Global Platform for resolving secure isolation of resources on mobile devices, providing a trusted and secure execution environment for applications in parallel to the operating system. The ARM Trust Zone technology has at the earliest realized the true commercial TEE technology.
Along with the high-speed development of the internet, the requirements for security are higher and higher, and the requirements for the TEE are more provided for mobile equipment, cloud equipment and data centers. The TEE concept has also been developed and expanded at a high rate. The TEE now has been a more generalized TEE than the originally proposed concept. For example, server chip manufacturers Intel, AMD, etc. have successively introduced hardware-assisted TEEs and enriched the concepts and characteristics of TEEs, which have been widely accepted in the industry. The TEE now lifted is often more directed to such hardware assisted TEE technology. Unlike the mobile terminal, the cloud access needs remote access, and the terminal user is invisible to the hardware platform, so that the first step of using the TEE is to confirm the true credibility of the TEE. Therefore, the existing TEE technology introduces a remote attestation mechanism, and a hardware manufacturer (mainly a CPU manufacturer) endorses and ensures that a user can verify the TEE state through a digital signature technology. Meanwhile, the security requirement which cannot be met by only secure resource isolation is met, and further data privacy protection is also proposed. Commercial TEEs, including Intel SGX, AMD SEV, also provide memory encryption techniques that limit trusted hardware to the CPU, and the data on the bus and memory are ciphertext to prevent malicious users from snooping. TEE technology, such as intel's software protection extension (SGX), isolates code execution, remote attestation, security configuration, secure storage of data, and trusted paths for executing code. Applications running in the TEE are secured and are almost impossible to access by third parties.
Taking Intel SGX technology as an example, SGX provides an enclosure (also called enclave), i.e., an encrypted trusted execution area in memory, that protects data from theft by the CPU. Taking the first block link point as an example, a CPU supporting SGX is adopted, and with a newly added processor instruction, a part of region EPC (Enclave Page Cache, enclosure page cache or enclave page cache) can be allocated in the memory, and the data in the region EPC is encrypted by an encryption engine MEE (Memory Encryption Engine) in the CPU. The encrypted content in the EPC is decrypted into plaintext only after entering the CPU. Thus, in SGX, a user may not trust the operating system, VMM (Virtual Machine Monitor ), or even BIOS (Basic Input Output System, basic input output System), but only trust the CPU to ensure that private data does not leak. In practical application, the privacy data can be encrypted and then transmitted to the enclosure in a ciphertext mode, and the corresponding secret key is also transmitted to the enclosure through remote certification. Then, the data is used for operation under the encryption protection of the CPU, and the result is returned in the form of ciphertext. In this mode, a strong computational power can be utilized without worrying about data leakage.
Since the private transaction is executed in the TEE, the intelligent contract corresponding to the private transaction may be a private contract, for example, the private transaction may create an intelligent contract in the TEE, and the contract code and contract state of the intelligent contract may be encrypted in the TEE, thereby creating a corresponding private contract; for another example, a privacy transaction may invoke a privacy contract that is decrypted and executed approximately in the TEE, and the contract state that is updated after execution may be updated and stored re-encrypted; for another example, a privacy transaction may invoke a clear text contract that, after being executed in the TEE, the contract state in which the update occurred is still stored in clear text.
Assuming that the private transaction described above is generated at a client, the client may first generate the plaintext transaction content and then encrypt the plaintext transaction content with a key. The encryption can be symmetric encryption or asymmetric encryption. Accordingly, the first blockchain node may decrypt the private transaction with the corresponding key to obtain the plaintext transaction content. If the client encrypts the plaintext transaction content in a symmetric encryption manner, i.e., with a symmetric key of a symmetric encryption algorithm, the first blockchain node may decrypt the private transaction with the symmetric key of the symmetric encryption algorithm accordingly. The encryption algorithm adopted by the symmetric encryption is, for example, a DES algorithm, a 3DES algorithm, a TDEA algorithm, a Blowfish algorithm, an RC5 algorithm, an IDEA algorithm and the like. The symmetric key of the symmetric encryption algorithm may be generated by the generating party of the private transaction, or determined by negotiation between the client and the first block link point, or transmitted by the key management server.
If the plaintext transaction content is encrypted in an asymmetric encryption manner, i.e., with a public key of an asymmetric encryption algorithm, the first blockchain node may decrypt the private transaction with a private key of the asymmetric encryption algorithm accordingly. Asymmetric encryption algorithms such as RSA, elgamal, knapsack algorithm, rabin, D-H, ECC (elliptic Curve encryption algorithm) and the like. The key of the asymmetric encryption algorithm may be, for example, a pair of public key and private key generated by the first block link point and sent to the client in advance, so that the client may encrypt the plaintext transaction content with the public key.
The keys of the asymmetric encryption algorithm may also be generated by a key management server. The key management server sends the private key to the first blockchain node by way of remote attestation, which may specifically be in the enclosure of the incoming first blockchain node. The first blockchain node may include a plurality of enclosures, and the private key may be passed into a security enclosure of the enclosures; for example, the safety enclosure may be a QE (Quoting Enclave) enclosure instead of a AE (Application Enclave) enclosure. For asymmetric encrypted public keys, the key management server may send to the client. The client may then encrypt the plaintext transaction content using the public key, and the first blockchain node may decrypt the private transaction using the private key accordingly to obtain the plaintext transaction content that the private transaction comprises.
The client may also use a combination of symmetric encryption and asymmetric encryption. For example, the client encrypts the plaintext transaction content using a symmetric encryption algorithm, i.e., a symmetric key of the symmetric encryption algorithm is used to encrypt the plaintext transaction content, and an asymmetric encryption algorithm is used to encrypt the symmetric key used in the symmetric encryption algorithm. In general, a public key of an asymmetric encryption algorithm is used to encrypt a symmetric key used in the symmetric encryption algorithm. Thus, after the first block link point receives the encrypted transaction, the first block link point can firstly adopt the private key of the asymmetric encryption algorithm to decrypt, so as to obtain the symmetric key of the symmetric encryption algorithm, and further use the symmetric key of the symmetric encryption algorithm to decrypt, so as to obtain the plaintext transaction content.
For example, the key management server may send the private key of the asymmetric encryption algorithm to the enclosure of the first blockchain node and send the private key of the asymmetric encryption algorithm to the client through remote attestation. Thus, the client may encrypt the plaintext transaction content using the symmetric key of the symmetric encryption algorithm, i.e., the symmetric key of the symmetric encryption algorithm, and encrypt the symmetric key employed in the symmetric encryption algorithm using the public key of the asymmetric encryption algorithm. Further, the client may send the private transaction and an encrypted private key (obtained by encrypting a symmetric key employed in the symmetric encryption algorithm with a public key of the asymmetric encryption algorithm) to a first blockchain node. After the first block link point receives the private transaction and the encrypted private key, the private key of the asymmetric encryption algorithm can be firstly used for decrypting the encrypted private key to obtain a symmetric key of the symmetric encryption algorithm, and then the symmetric key of the symmetric encryption algorithm is used for decrypting the private transaction to obtain plaintext transaction content. The encryption scheme is generally referred to herein as digital envelope encryption.
And after the first blockchain node decrypts the private transaction, obtaining the plaintext transaction content. The clear text transaction content may contain code for an intelligent contract for creating the intelligent contract in the blockchain; the plaintext transaction content may contain a contract address of a smart contract that has been created in the blockchain for invoking the smart contract.
Whether used to create or invoke a smart contract, the first block link point may complete the transaction by executing the code of the smart contract. The first blockchain node may execute code of the smart contract in a trusted execution environment. When the code of the intelligent contract is positioned in the privacy transaction, the first block link point decrypts the privacy transaction to obtain the plaintext transaction content, wherein the plaintext transaction content comprises the code of the intelligent contract in plaintext; when the intelligent contract is created in advance and the privacy transaction is used for calling the intelligent contract, if the intelligent contract is stored in advance by the first block link point in an encrypted mode, the first block link point can read the code of the encrypted intelligent contract into a trusted execution environment and decrypt the code of the encrypted intelligent contract to obtain the code of the decrypted intelligent contract. Multiple nested structures can be realized among intelligent contracts; for example, the code in smart contract 1 calls smart contract 2, while the code in smart contract 2 points to contract address 3 generated by creating the smart contract code, such that when the private transaction calls the code in smart contract 1, the smart contract code in contract address 3 is indirectly called.
When a private transaction is used to create a smart contract, the private transaction includes the code of the smart contract, and the first blockchain node may decrypt the private transaction in the trusted execution environment to obtain the code of the smart contract that it includes, and then execute the plaintext code in the trusted execution environment. When a privacy transaction is used to invoke a privacy-type smart contract, the first blockchain node may decrypt the smart contract in a trusted execution environment to obtain a corresponding plaintext code, and then execute the plaintext code in the trusted execution environment. When a private transaction is used to invoke a clear text type smart contract, a first block link point directly reads the clear text code of the smart contract and executes the clear text code in a trusted execution environment. Specifically, the first blockchain node may allocate a part of the region EPC in the memory by using a newly added processor instruction in the CPU, and encrypt the plaintext code by using an encryption engine MEE in the CPU and store the plaintext code in the EPC. The encrypted content in the EPC is decrypted into plaintext after entering the CPU. And in the CPU, the plaintext codes are operated to finish the execution process.
In SGX technology, executing the plain text code of the smart contract, EVM may be loaded into the enclosure. In the remote proving process, the key management server can calculate the hash value of the local EVM code, compare the hash value with the hash value of the EVM code loaded in the first block chain link point, and the comparison result is correct as a necessary condition for passing the remote proving, so that the measurement of the code loaded on the first block chain node SGX enclosure is completed. Through the metrics, the correct EVM may execute the smart contract code in the SGX.
Step 104, when the first blockchain node determines that the transaction is a private transaction, encrypting the plaintext receipt data into ciphertext receipt data by using a secret key, and then storing the ciphertext receipt data.
After the CPU executes the plaintext code, plaintext receipt data is generated in addition to the corresponding plaintext execution result. The content of the plain receipt data may include information contained in several of the fields described above, or other extension information, which is not limiting in this specification.
The first blockchain node encrypts the plaintext receipt data so that only a portion of the objects (e.g., the transaction-initiating clients) can decrypt the plaintext receipt data to obtain corresponding plaintext receipt data, thereby avoiding exposing the plaintext receipt data. For example, when a user initiates a transaction to a first blockchain node through a client, the transaction is used for inquiring the value of a certain contract state, and although the value of the contract state is not changed after the transaction is executed, receipt data generated after the transaction is executed exposes the user to implement related inquiry operation, so that the privacy of the user can be protected by encrypting clear text receipt data.
Similar to the process of generating a receipt tree in the related art, the above-described cryptographically correct receipt data is also used to calculate the root of the receipt tree, and the root is contained in the block header of the block where the transaction is located. For example, when using an MPT tree structure, the hash value of the ciphertext receipt data described above would be used to construct the leaves of the receipt tree; of course, in some cases, the plain text receipt data may also be stored directly, and then the hash values of these plain text receipt data are also used to construct the leaves of the receipt tree, as will be described in more detail below.
The first block link point first generates plaintext receipt data and then encrypts the plaintext receipt data with a key. The encryption can be symmetric encryption or asymmetric encryption. If the first blockchain node encrypts the plaintext receipt data with a symmetric encryption scheme, i.e., with a symmetric key of a symmetric encryption algorithm, the client (or other object holding the key) may decrypt the ciphertext receipt data with the symmetric key of the symmetric encryption algorithm.
The first blockchain node encrypts the plaintext receipt data with a symmetric key of a symmetric encryption algorithm that may be pre-provided by the client to the first blockchain node. Then, only the client (actually the user corresponding to the logged account on the client) and the first block link point master the symmetric key, so that only the client can decrypt the corresponding encrypted receipt data, and the encrypted receipt data is prevented from being decrypted by unrelated users and even lawbreakers.
For example, when the client initiates a transaction to the first block link point, if the transaction is a private transaction, the client may encrypt plaintext transaction content with an initial key of a symmetric encryption algorithm to obtain the private transaction; accordingly, the first blockchain node may be configured to encrypt the plaintext receipt data directly or indirectly by obtaining the initial key. For example, the initial key may be pre-negotiated with the first blockchain node by the client, or sent to the client and the first blockchain node by the key management server, or sent to the first blockchain node by the client. When the initial key is sent to the first blockchain node by the client, the client can encrypt the initial key through the public key of the asymmetric encryption algorithm and then send the encrypted initial key to the first blockchain 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, namely the digital envelope encryption is described above, and details are omitted here.
The first blockchain node may encrypt the plain-text receipt data using the initial key as described above. The initial keys adopted by different transactions may be the same, so that all transactions submitted by the same user are encrypted by adopting the initial keys, or the initial keys adopted by different transactions may be different, for example, the client may randomly generate an initial key for each transaction, so as to improve security.
The first blockchain node may generate a derivative key from the initial key and the influencing factor and encrypt the plaintext receipt data with the derivative key. Compared with the encryption by directly adopting the initial key, the derivative key can increase the randomness, thereby improving the difficulty of being broken and being beneficial to optimizing the safety protection of the data. The impact factor may be related to the transaction; for example, the influencing factor may include a specified bit of the transaction hash value, such as the first blockchain node may concatenate the initial key with the first 16 bits (or the first 32 bits, the last 16 bits, the last 32 bits, or other bits) of the transaction hash value and hash the concatenated string to generate the derivative key.
The first blockchain node may also encrypt the plaintext receipt data using an asymmetric encryption scheme, i.e., using a public key of an asymmetric encryption algorithm, and accordingly, the client may decrypt the ciphertext receipt data using a private key of the asymmetric encryption algorithm. The key of the asymmetric encryption algorithm may be, for example, a pair of public and private keys generated by the client and sent in advance to the first blockchain node so that the first blockchain node can encrypt the plaintext receipt data with the public key.
Although the first blockchain node may encrypt the plain text receipt data corresponding to all transactions, the needs of different users are often different, for example, a part of users are relatively more focused on efficiency and can accept to store the plain text receipt data, another part of users are relatively more focused on privacy and can accept the influence of encryption and decryption of the receipt data on efficiency, so that whether the plain text receipt data needs to be encrypted or not can be determined according to different scenes.
The first blockchain node may determine whether to encrypt the plain text receipt data based on the transaction type. Based on the above description, the first blockchain node may identify whether the transaction submitted by the client is of the plaintext type or the privacy type. For a private transaction, the first blockchain node may encrypt plaintext receipt data corresponding to the private transaction using a key. For example, after the first block link receives the transaction, the identified private transaction may be transferred to the trusted execution environment through the "transaction/query interface" module as shown in fig. 2, so that the private transaction is executed in the trusted execution environment, and plaintext receipt data is generated, and then the plaintext receipt data is encrypted in the trusted execution environment, so as to obtain ciphertext receipt data. And for a plaintext transaction, the first blockchain node may directly store the corresponding plaintext receipt data. For example, after the first block link point receives the transaction, the identified plaintext transaction may be executed in a conventional execution environment outside of the trusted execution environment via a "transaction/query interface" module as shown in fig. 2, and then stored in plaintext form.
The first blockchain node obtains corresponding plaintext receipt data by executing a transaction, encrypts the plaintext receipt data into corresponding ciphertext receipt data by a secret key, and can actively feed back the ciphertext receipt data to a client side initiating the transaction to serve as a receipt of the transaction. The first blockchain node may store the cryptogram receipt data such that the client may request and obtain the cryptogram receipt data from the first blockchain node at any time. Of course, if the plaintext receipt data corresponding to the transaction does not need to be encrypted, the first blockchain node may return the plaintext receipt data to the client, or the first blockchain node may store the plaintext receipt data and return the plaintext receipt data based on the response of the client.
The first blockchain node implements a function by running code for implementing the function. Thus, for functions that need to be implemented in a trusted execution environment, the relevant code also needs to be executed. And for code executing in a trusted execution environment, the code needs to meet the relevant specifications and requirements of the trusted execution environment; accordingly, for the code for implementing a certain function in the related art, code writing needs to be re-performed in combination with specifications and requirements of a trusted execution environment, so that a relatively large development amount exists, and loopholes (bugs) are easily generated in the re-writing process, thereby influencing the reliability and stability of the implementation of the function.
Therefore, the first blockchain node may store the ciphertext receipt data generated in the trusted execution environment to an external storage space outside the trusted execution environment by executing the storage function code outside the trusted execution environment (of course, the storage function code may not need encryption, and the storage function code may also store the part of plaintext receipt data to the external storage space; taking the storage process of the ciphertext receipt data as an example here for illustration), so that the storage function code may be code for implementing the storage function in the related art, and may implement safe and reliable storage for the ciphertext receipt data without combining with the specification and the requirement of the trusted execution environment, thereby not only reducing the development amount of relevant code on the basis of not affecting the safety and reliability, but also reducing the TCB (Trusted Computing Base ) by reducing the relevant code of the trusted execution environment, and enabling the additional safety risk caused in the process of combining the TEE technology with the blockchain technology to be in a controllable range.
In one embodiment, the first blockchain node may execute write caching function code within the trusted execution environment to store the plaintext receipt data in a write cache within the trusted execution environment, such as the write cache may correspond to a "cache" as shown in FIG. 2. Further, the first block link point encrypts the data in the write cache and outputs the encrypted data from the trusted execution environment to store the encrypted data in the external storage space. The write cache function code can be stored in a plaintext form in the trusted execution environment, and the cache function code in the plaintext form can be directly executed in the trusted execution environment; or, the write cache function code may be stored outside the trusted execution environment in a ciphertext form, such as in the above-mentioned external storage space (such as "packing+storing" shown in fig. 2, where "packing" indicates that the first blockchain node packs the transaction into blocks outside the trusted execution environment), and the write cache function code in the ciphertext form may be read into the trusted execution environment, decrypted into plaintext code in the trusted execution environment, and executed.
Write caching refers to a "buffering" mechanism provided to avoid causing a "shock" to the external storage space when writing data to the external storage space. For example, the write cache described above may be implemented using buffers; of course, the write cache may also be implemented by using a cache, which is not limited in this specification. In practice, since the trusted execution environment is an isolated safe environment and the external storage space is located outside the trusted execution environment, the data in the cache can be written into the external storage space in batches by adopting a write cache mechanism, so that the interaction times between the trusted execution environment and the external storage space are reduced, and the data storage efficiency is improved. Meanwhile, the trusted execution environment may need to call the generated data in the process of continuously executing each piece of plaintext transaction content, if the data to be called is just in the write cache, the data can be directly read from the write cache, so that interaction with an external storage space can be reduced, and on the other hand, the decryption process of the data read from the external storage space is omitted, thereby improving the data processing efficiency in the trusted execution environment.
Of course, the write cache may also be established outside the trusted execution environment, for example, the first blockchain node may execute the write cache function code outside the trusted execution environment, thereby storing the ciphertext receipt data into the write cache outside the trusted execution environment, and further storing the data in the write cache into the external storage space.
In one embodiment, the first blockchain node may encrypt the plaintext receipt data according to a query request initiated by a client and output the encrypted plaintext receipt data from a trusted execution environment for return to the client.
For example, the first blockchain node may read the ciphertext receipt data from the external storage space and return the encrypted plaintext receipt data to the client via the transaction/inquiry interface shown in fig. 2.
For another example, the first blockchain node may read the plaintext receipt data from a read cache within the trusted execution environment and encrypt the plaintext receipt data for output from the trusted execution environment; and the plaintext receipt data is read from the external storage space into the plaintext receipt data, and then read into the trusted execution environment and stored into the read cache. In other words, after the first blockchain node reads the ciphertext receipt data from the external storage space and decrypts the ciphertext receipt data into the plaintext receipt data, the plaintext receipt data may be stored in a read cache in the trusted execution environment by executing a read cache function code in the trusted execution environment, for example, the read cache may correspond to the "cache" shown in fig. 2; further, for the query request initiated by the client or for the data required by the trusted execution environment when executing the plaintext transaction content, the data can be preferentially read from the read cache, and if the related data can be read, the data does not need to be read from the external storage space, so that the interaction times with the external storage space are reduced, and the data decryption process is avoided.
The read cache refers to that after data is read into the trusted execution environment from the external storage space, in order to reduce the number of interactions with the external storage space, the read data can be stored in a plaintext form in the read cache space in the trusted execution environment. For example, the above-mentioned read cache may be implemented by using a cache; of course, the read buffer may also be implemented by using buffer, which is not limited in this specification.
The first blockchain node may support both the read caching mechanism and the write caching mechanism described above. With the continuous development of the cache technology, the same cache may not only be used to implement data reading or data writing, but also support data reading and writing operations at the same time, so that the boundary between the read cache and the write cache is sometimes not quite clear, and thus, fig. 2 only illustrates the cache, but does not specifically distinguish the specific types thereof, and may be configured and adjusted according to actual requirements.
Of course, the above-mentioned caching mechanism in the trusted execution environment may be applied to a conventional execution environment, for example, implemented by "caching" in the conventional execution environment shown in fig. 2, where, however, data reading and writing only involves plaintext reading and writing, and data encryption and decryption operations need not be implemented, which is not repeated herein.
An embodiment of a node for implementing a hybrid transaction in a blockchain is described in this specification with reference to fig. 3, including:
an execution unit 301 for executing the transaction received from the client to obtain plain text receipt data;
and a storage unit 302, configured to encrypt the plaintext receipt data into ciphertext receipt data using a key when the transaction is determined to include an encryption identifier, and then store the ciphertext receipt data.
In the 90 s of the 20 th century, improvements to one technology could clearly be distinguished as improvements in hardware (e.g., improvements to circuit structures such as diodes, transistors, switches, etc.) or software (improvements to the process flow). However, with the development of technology, many improvements of the current method flows can be regarded as direct improvements of hardware circuit structures. Designers almost always obtain corresponding hardware circuit structures by programming improved method flows into hardware circuits. Therefore, an improvement of a method flow cannot be said to be realized by a hardware entity module. For example, a programmable logic device (Programmable Logic Device, PLD) (e.g., field programmable gate array (Field Programmable Gate Array, FPGA)) is an integrated circuit whose logic function is determined by the programming of the device by a user. A designer programs to "integrate" a digital system onto a PLD without requiring the chip manufacturer to design and fabricate application-specific integrated circuit chips. Moreover, nowadays, instead of manually manufacturing integrated circuit chips, such programming is mostly implemented by using "logic compiler" software, which is similar to the software compiler used in program development and writing, and the original code before the compiling is also written in a specific programming language, which is called hardware description language (Hardware Description Language, HDL), but not just one of the hdds, but a plurality of kinds, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java HardwareDescription Language), lava, lola, myHDL, PALASM, RHDL (Ruby Hardware Description Language), etc., VHDL (Very-High-Speed Integrated Circuit Hardware Description Language) and Verilog are currently most commonly used. It will also be apparent to those skilled in the art that a hardware circuit implementing the logic method flow can be readily obtained by merely slightly programming the method flow into an integrated circuit using several of the hardware description languages described above.
The controller may be implemented in any suitable manner, for example, the controller may take the form of, for example, a microprocessor or processor and a computer readable medium storing computer readable program code (e.g., software or firmware) executable by the (micro) processor, logic gates, switches, application specific integrated circuits (Application Specific Integrated Circuit, ASIC), programmable logic controllers, and embedded microcontrollers, examples of which include, but are not limited to, the following microcontrollers: ARC 625D, atmel AT91SAM, microchip PIC18F26K20, and Silicone Labs C8051F320, the memory controller may also be implemented as part of the control logic of the memory. Those skilled in the art will also appreciate that, in addition to implementing the controller in a pure computer readable program code, it is well possible to implement the same functionality by logically programming the method steps such that the controller is in the form of logic gates, switches, application specific integrated circuits, programmable logic controllers, embedded microcontrollers, etc. Such a controller may thus be regarded as a kind of hardware component, and means for performing various functions included therein may also be regarded as structures within the hardware component. Or even means for achieving the various functions may be regarded as either software modules implementing the methods or structures within hardware components.
The system, apparatus, module or unit set forth in the above embodiments may be implemented in particular by a computer chip or entity, or by a product having a certain function. One typical implementation is a computer. In particular, the computer may be, for example, a personal computer, a laptop computer, a cellular telephone, 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 a combination of any of these devices.
For convenience of description, the above devices are described as being functionally divided into various units, respectively. Of course, the functions of each element may be implemented in one or more software and/or hardware elements when implemented in the present specification.
It will be appreciated by those skilled in the art that embodiments of the present invention may be provided as a method, system, or computer program product. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present invention may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.
The present invention is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the invention. It will be understood that each flow and/or block of the flowchart illustrations and/or block diagrams, and combinations of flows and/or blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
The description may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. The specification may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.
These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks. In a typical configuration, a computer includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.
The memory may include volatile memory in a computer-readable medium, random Access Memory (RAM) and/or nonvolatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of computer-readable media.
Computer readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of storage media for a computer 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, read only compact disc read only memory (CD-ROM), digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic disk storage, quantum memory, graphene-based storage or other magnetic storage devices, or any other non-transmission medium, which can be used to store information that can be accessed by the computing device. Computer-readable media, as defined herein, does not include transitory computer-readable media (transmission media), such as modulated data signals and carrier waves.
It should also be noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one … …" does not exclude the presence of other like elements in a process, method, article or apparatus that comprises the element.
The foregoing describes specific embodiments of the present disclosure. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims can be performed in a different order than in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.
The terminology used in the one or more embodiments of the specification is for the purpose of describing particular embodiments only and is not intended to be limiting of the one or more embodiments of the specification. As used in this specification, one or more embodiments and the appended claims, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should also be understood that the term "and/or" as used herein refers to and encompasses any or all possible combinations of one or more of the associated listed items.
It should be understood that although the terms first, second, third, etc. may be used in one or more embodiments of the present description to describe various information, these information should not be limited to these terms. These terms are only used to distinguish one type of information from another. For example, first information may also be referred to as second information, and similarly, second information may also be referred to as first information, without departing from the scope of one or more embodiments of the present description. The word "if" as used herein may be interpreted as "at … …" or "at … …" or "responsive to a determination", depending on the context.
The foregoing description of the preferred embodiment(s) is (are) merely intended to illustrate the embodiment(s) of the present invention, and it is not intended to limit the embodiment(s) of the present invention to the particular embodiment(s) described.
Claims (21)
1. A method of implementing privacy protection in a blockchain, comprising:
the block chain link point executes the transaction submitted by the client to obtain plaintext receipt data;
the blockchain node executes write cache function code in a trusted execution environment to store the plaintext receipt data into a write cache within the trusted execution environment;
the blockchain node encrypting the plaintext receipt data into ciphertext receipt data using a key and storing the ciphertext receipt data when determining that the transaction is a private transaction, comprising: encrypting the plaintext receipt data in the write cache into ciphertext receipt data using a key, and outputting the ciphertext receipt data from the trusted execution environment for storage in an external storage space outside the trusted execution environment.
2. The method of claim 1, the block link point performing a client-submitted transaction, comprising:
When the transaction is a private transaction, the block link point transmits the private transaction from a conventional execution environment to a trusted execution environment for decryption to obtain corresponding plaintext transaction content, and executes the plaintext transaction content in the trusted execution environment;
when the transaction is a plaintext transaction, the blockchain node executes the plaintext transaction in the conventional execution environment.
3. The method of claim 2, further comprising:
the blockchain node determines the type of the transaction according to the value of a type field in a plaintext form in the transaction; wherein the first value of the type field is used to indicate that the transaction is a clear text transaction and the second value of the type field is used to indicate that the transaction is a private transaction.
4. The method according to claim 2,
the executing the plaintext transaction content in the trusted execution environment comprises: executing the plaintext transaction content through a virtual machine deployed within the trusted execution environment;
the executing the plain text transaction in the conventional execution environment includes: and executing the plaintext transaction by a virtual machine deployed in the conventional execution environment.
5. The method of claim 1, the encrypting the plain text receipt data into ciphertext receipt data using a key, comprising:
The plaintext receipt data is encrypted into ciphertext receipt data using a key in a trusted execution environment.
6. The method of claim 1, further comprising:
the blockchain node stores the plaintext receipt data when the transaction is determined to be a plaintext transaction.
7. The method of claim 1, the block link point performing a client-submitted transaction, comprising:
the blockchain node performs the plaintext transaction in or outside of a trusted execution environment when the transaction is determined to be a plaintext transaction.
8. The method of claim 1, the key comprising a key of a symmetric encryption algorithm or a key of an asymmetric encryption algorithm.
9. The method of claim 8, the key of the symmetric encryption algorithm comprising an initial key provided by the client; or, the key of the symmetric encryption algorithm comprises the initial key and a derivative key generated by an influence factor.
10. The method of claim 9, when the transaction is a private transaction, the private transaction is encrypted by the initial key and the initial key is encrypted by a public key of an asymmetric encryption algorithm; the method further comprises the steps of:
The blockchain node decrypts the initial key by using the private key of the asymmetric encryption algorithm, and decrypts the private transaction by using the initial key.
11. The method of claim 9, the impact factor being related to the transaction.
12. The method of claim 11, the impact factor comprising: the hash value of the transaction is specified in bits.
13. The method of claim 1, the storing ciphertext receipt data comprising:
the blockchain node executes storage function code outside of the trusted execution environment to store the cryptograph receipt data to an external storage space outside of the trusted execution environment.
14. The method of claim 1, the write cache function code being stored in plain text form in the trusted execution environment; or, the write cache function code is stored outside the trusted execution environment in a ciphertext form.
15. The method of claim 1, the cryptogram receipt data being used to calculate a root of a receipt tree, the root being contained in a block header of a block in which the exchange is located.
16. The method of claim 1, the transaction being for creating and/or invoking a smart contract.
17. The method of claim 1, the transaction being a private transaction for creating a privacy contract, the block link point executing a client-submitted transaction, comprising:
decrypting the privacy transaction by the blockchain node in a trusted execution environment to obtain a contract code and a contract state of the privacy contract;
the blockchain node encrypts the contract code and the contract state of the privacy contract in the trusted execution environment to create a corresponding privacy contract based on the encrypted contract code and contract state.
18. The method of claim 1, the transaction to invoke a privacy contract, a contract code of the privacy contract being encrypted; the block link point performs a transaction submitted by a client, comprising:
decrypting contract code of the privacy contract in a trusted execution environment by the blockchain node;
executing the decrypted contract code in the trusted execution environment, and encrypting and storing the contract state updated after execution.
19. The method of claim 1, the transaction for invoking a clear text contract; the block link point performs a transaction submitted by a client, comprising:
The blockchain node executing the plaintext contract in a trusted execution environment;
the contract state in which the update occurs is stored in a plaintext form.
20. A node apparatus implementing privacy protection in a blockchain, comprising:
the execution unit is used for executing the transaction submitted by the client to obtain plaintext receipt data; and, executing write caching function code in a trusted execution environment to store the plaintext receipt data in a write cache within the trusted execution environment;
a storage unit configured to encrypt the plain text receipt data into ciphertext receipt data using a key and store the ciphertext receipt data when the transaction is determined to be a private transaction; the encrypting the plaintext receipt data into ciphertext receipt data using a key and storing the ciphertext receipt data includes: encrypting the plaintext receipt data in the write cache into ciphertext receipt data using a key, and outputting the ciphertext receipt data from the trusted execution environment for storage in an external storage space outside the trusted execution environment.
21. A computer readable storage medium having stored thereon computer instructions which, when executed by a processor, implement the steps of the method of any of claims 1-19.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010451357.7A CN111612462B (en) | 2019-02-19 | 2019-02-19 | Method, node and storage medium for implementing privacy protection in blockchain |
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910123012.6A CN110033266B (en) | 2019-02-19 | 2019-02-19 | Method, node and storage medium for implementing privacy protection in block chain |
| CN202010451357.7A CN111612462B (en) | 2019-02-19 | 2019-02-19 | Method, node and storage medium for implementing privacy protection in blockchain |
Related Parent Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201910123012.6A Division CN110033266B (en) | 2019-02-19 | 2019-02-19 | Method, node and storage medium for implementing privacy protection in block chain |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN111612462A CN111612462A (en) | 2020-09-01 |
| CN111612462B true CN111612462B (en) | 2023-08-22 |
Family
ID=67235626
Family Applications (2)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202010451357.7A Active CN111612462B (en) | 2019-02-19 | 2019-02-19 | Method, node and storage medium for implementing privacy protection in blockchain |
| CN201910123012.6A Active CN110033266B (en) | 2019-02-19 | 2019-02-19 | Method, node and storage medium for implementing privacy protection in block chain |
Family Applications After (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201910123012.6A Active CN110033266B (en) | 2019-02-19 | 2019-02-19 | Method, node and storage medium for implementing privacy protection in block chain |
Country Status (1)
| Country | Link |
|---|---|
| CN (2) | CN111612462B (en) |
Families Citing this family (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113065951A (en) * | 2020-01-02 | 2021-07-02 | 苏州同济区块链研究院有限公司 | Transaction method, system, device, equipment and medium based on block chain |
| CN111090888B (en) * | 2020-03-18 | 2020-07-07 | 支付宝(杭州)信息技术有限公司 | Contract verification method and device |
| WO2021203260A1 (en) * | 2020-04-08 | 2021-10-14 | 云图技术有限公司 | Node matching method, apparatus, device and system |
| US12126716B2 (en) * | 2021-09-10 | 2024-10-22 | International Business Machines Corporation | Anonymous private shared partitions in a global total order broadcast domain networks using random symmetric encryption keys |
| CN113781245B (en) * | 2021-09-10 | 2023-10-13 | 杭州宇链科技有限公司 | Privacy computing system and method for enabling safe production insurance |
| CN114553612B (en) * | 2022-04-27 | 2022-07-26 | 深圳市一航网络信息技术有限公司 | Data encryption and decryption method and device, storage medium and electronic equipment |
| CN117675216A (en) * | 2022-08-31 | 2024-03-08 | 华为云计算技术有限公司 | Data processing method and related equipment |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2010078222A1 (en) * | 2009-01-05 | 2010-07-08 | Sandisk Corporation | Non-volatile memory and method with write cache partitioning |
| CN107294709A (en) * | 2017-06-27 | 2017-10-24 | 阿里巴巴集团控股有限公司 | A kind of block chain data processing method, apparatus and system |
| CN107342858A (en) * | 2017-07-05 | 2017-11-10 | 武汉凤链科技有限公司 | A kind of intelligent contract guard method and system based on trusted context |
| CN109241022A (en) * | 2018-09-11 | 2019-01-18 | 天津理工大学 | A kind of archive management system and its ant search algorithm based on blue-ray storage |
Family Cites Families (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2017091530A1 (en) * | 2015-11-24 | 2017-06-01 | Gartland & Mellina Group | Blockchain solutions for financial services and other transaction-based industries |
| WO2019127531A1 (en) * | 2017-12-29 | 2019-07-04 | 深圳前海达闼云端智能科技有限公司 | Block chain-based data processing method and apparatus, storage medium and electronic device |
| CN109063109A (en) * | 2018-07-27 | 2018-12-21 | 电子科技大学 | A kind of data query system based on ether mill |
| CN109146688A (en) * | 2018-08-30 | 2019-01-04 | 广州立趣信息科技有限公司 | A kind of supply chain financial application method based on block chain alliance chain technology |
-
2019
- 2019-02-19 CN CN202010451357.7A patent/CN111612462B/en active Active
- 2019-02-19 CN CN201910123012.6A patent/CN110033266B/en active Active
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2010078222A1 (en) * | 2009-01-05 | 2010-07-08 | Sandisk Corporation | Non-volatile memory and method with write cache partitioning |
| CN107294709A (en) * | 2017-06-27 | 2017-10-24 | 阿里巴巴集团控股有限公司 | A kind of block chain data processing method, apparatus and system |
| CN107342858A (en) * | 2017-07-05 | 2017-11-10 | 武汉凤链科技有限公司 | A kind of intelligent contract guard method and system based on trusted context |
| CN109241022A (en) * | 2018-09-11 | 2019-01-18 | 天津理工大学 | A kind of archive management system and its ant search algorithm based on blue-ray storage |
Non-Patent Citations (1)
| Title |
|---|
| 翟社平 ; 杨媛媛 ; 张海燕 ; 赵江明 ; .区块链中的隐私保护技术.西安邮电大学学报.2018,(05),全文. * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN111612462A (en) | 2020-09-01 |
| CN110033266B (en) | 2020-04-07 |
| CN110033266A (en) | 2019-07-19 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN109936626B (en) | Method, node and storage medium for implementing privacy protection in block chain | |
| CN110033267B (en) | Method, node, system and storage medium for implementing privacy protection in block chain | |
| CN110032885B (en) | Method, node and storage medium for implementing privacy protection in block chain | |
| CN110020855B (en) | Method, node and storage medium for realizing privacy protection in block chain | |
| CN110020549B (en) | Method, node and storage medium for implementing privacy protection in block chain | |
| CN111612462B (en) | Method, node and storage medium for implementing privacy protection in blockchain | |
| CN110032876B (en) | Method, node and storage medium for implementing privacy protection in block chain | |
| CN110060054B (en) | Method, node, system and storage medium for implementing privacy protection in block chain | |
| CN110032884B (en) | Method for realizing privacy protection in block chain, node and storage medium | |
| CN109886682B (en) | Method, node and storage medium for realizing contract calling in block chain | |
| CN110008735B (en) | Method, node and storage medium for realizing contract calling in block chain | |
| CN110263544B (en) | Receipt storage method and node combining transaction type and judgment condition | |
| CN111639362B (en) | Method, node and storage medium for implementing privacy protection in blockchain | |
| CN110245942B (en) | Receipt storage method and node combining user type and judgment condition | |
| CN110020856B (en) | Method, node and storage medium for realizing mixed transaction in block chain | |
| CN110245944B (en) | Receipt storage method and node based on user type | |
| CN110245947B (en) | Receipt storage method and node combining conditional restrictions of transaction and user types | |
| WO2020233615A1 (en) | Receipt storage method combining user type and event function type and node | |
| CN110264193B (en) | Receipt storage method and node combining user type and transaction type | |
| WO2020233628A1 (en) | Receipt storage method and node based on combination of event function type and judgment condition | |
| WO2020233350A1 (en) | Receipt storage method, node and system based on plaintext logs | |
| WO2020233635A1 (en) | Receipt storage method combining conditional restrictions of multiple types of dimensions and node | |
| WO2020233624A1 (en) | Receipt storage method and node employing transaction type in combination with event function type | |
| WO2020233632A1 (en) | Receipt storage method and node based on event function type | |
| CN110263543B (en) | Object-level receipt storage method and node based on code labeling |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| TA01 | Transfer of patent application right | ||
| TA01 | Transfer of patent application right |
Effective date of registration: 20201012 Address after: Cayman Enterprise Centre, 27 Hospital Road, George Town, Grand Cayman Islands Applicant after: Innovative advanced technology Co.,Ltd. Address before: Cayman Enterprise Centre, 27 Hospital Road, George Town, Grand Cayman Islands Applicant before: Advanced innovation technology Co.,Ltd. Effective date of registration: 20201012 Address after: Cayman Enterprise Centre, 27 Hospital Road, George Town, Grand Cayman Islands Applicant after: Advanced innovation technology Co.,Ltd. Address before: A four-storey 847 mailbox in Grand Cayman Capital Building, British Cayman Islands Applicant before: Alibaba Group Holding Ltd. |
|
| REG | Reference to a national code |
Ref country code: HK Ref legal event code: DE Ref document number: 40036821 Country of ref document: HK |
|
| GR01 | Patent grant | ||
| GR01 | Patent grant | ||
| TR01 | Transfer of patent right | ||
| TR01 | Transfer of patent right |
Effective date of registration: 20240920 Address after: Guohao Times City # 20-01, 128 Meizhi Road, Singapore Patentee after: Ant Chain Technology Co.,Ltd. Country or region after: Singapore Address before: Cayman Enterprise Centre, 27 Hospital Road, George Town, Grand Cayman Islands Patentee before: Innovative advanced technology Co.,Ltd. Country or region before: Cayman Islands |