CN115758333A - Transaction grouping method and block link point - Google Patents

Abstract

A transaction grouping method and blockchain node, the method being performed by a node in a blockchain system, the node including a trusted execution environment, TEE, therein, the method comprising: receiving a plurality of transactions, including non-private transactions and private transactions; generating a read-write set of non-private transactions outside the TEE; the TEE decrypts the ciphertext corresponding to the private transaction, and generates a read-write set of the private transaction based on the plaintext obtained through decryption; grouping the plurality of transactions within the TEE based on the read-write set of private transactions and the read-write set of non-private transactions.

Description

Transaction grouping method and block link point

Technical Field

The embodiment of the specification belongs to the technical field of block chains, and particularly relates to a transaction grouping method and a block chain link point.

Background

The Blockchain (Blockchain) is a novel application mode of computer technologies such as distributed data storage, point-to-point transmission, a consensus mechanism, an encryption algorithm and the like. In the block chain system, data blocks are combined into a chain data structure in a sequential connection mode according to a time sequence, and a distributed account book which is not falsified and forged is guaranteed in a cryptology mode. Because the blockchain has the characteristics of decentralization, information non-tampering, autonomy and the like, the blockchain is also paid more and more attention and is applied by people.

A Trusted Execution Environment (TEE) may be introduced into the blockchain for protecting private data. The TEE can ensure the safety, confidentiality and integrity of codes and data put in the TEE, and meanwhile, operation is carried out on the TEE based on plaintext data, so that the calculation efficiency is high.

Disclosure of Invention

The invention aims to provide a transaction grouping scheme to realize parallel execution of a plurality of transactions including private transactions.

A first aspect of the present specification provides a transaction grouping method, which is performed by a node in a blockchain system, where the node includes a trusted execution environment TEE, and the method includes:

receiving a plurality of transactions, including non-private transactions and private transactions;

generating a read-write set of the non-private transaction outside of the TEE;

the TEE decrypts the ciphertext corresponding to the private transaction and generates a read-write set of the private transaction based on the plaintext obtained through decryption;

grouping the plurality of transactions within the TEE based on the read-write set of private transactions and the read-write set of non-private transactions.

A second aspect of the present specification provides a block link point, where the block link point includes a trusted execution environment TEE therein, and the block link node further includes:

the system comprises a receiving unit, a processing unit and a processing unit, wherein the receiving unit is used for receiving a plurality of transactions, and the plurality of transactions comprise non-privacy transactions and privacy transactions;

a first generating unit, configured to generate a read-write set of the non-private transaction outside the TEE;

the second generation unit is used for decrypting the ciphertext corresponding to the private transaction in the TEE and generating a read-write set of the private transaction based on the plaintext obtained through decryption;

a grouping unit to group the transactions within the TEE based on the read-write set of the private transaction and the read-write set of the non-private transaction.

A third aspect of the present specification provides a computer readable storage medium having stored thereon a computer program which, when executed on a computer, causes the computer to perform the method of the first aspect.

A fourth aspect of the present specification provides a block link point comprising a memory and a processor, wherein the memory stores executable code, and the processor executes the executable code to implement the method of the first aspect.

In the embodiment of the description, the private transactions are subjected to read-write set analysis in the TEE, and the non-private transactions are subjected to read-write set analysis outside the TEE, so that the multiple transactions can be grouped based on the read-write sets of all transactions in the TEE while the private data of the private transactions are protected, the multiple transactions can be executed in parallel, and the transaction execution efficiency in the blockchain system is improved.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments in the present specification, the drawings required to be used in the description of the embodiments will be briefly introduced below, and it is obvious that the drawings in the following description are only some embodiments described in the present specification, and it is obvious for those skilled in the art that other drawings may be obtained according to these drawings without inventive labor.

FIG. 1 illustrates a block chain architecture diagram in one embodiment;

FIG. 2 is a schematic diagram of a process for performing transactions in a blockchain in an embodiment of the present description;

FIG. 3 is a schematic diagram of a transaction processing procedure in an embodiment of the present description;

FIG. 4 is a flow diagram of a transaction grouping method in an embodiment of the present description;

FIG. 5 is a flow diagram of a method for determining whether a transaction is a private transaction in an embodiment of the present disclosure;

fig. 6 is an architecture diagram of a block link point in an embodiment of the present disclosure.

Detailed Description

In order to make those skilled in the art better understand the technical solutions in the present specification, the technical solutions in the embodiments of the present specification will be clearly and completely described below with reference to the drawings in the embodiments of the present specification, and it is obvious that the described embodiments are only a part of the embodiments of the present specification, and not all of the embodiments. All other embodiments obtained by a person skilled in the art based on the embodiments in the present specification without any inventive step should fall within the scope of protection of the present specification.

FIG. 1 illustrates a block chain architecture diagram in one embodiment. In the blockchain architecture diagram shown in fig. 1, a blockchain 100 includes N nodes, which are schematically shown as nodes 1-8 in fig. 1. The connecting lines between the nodes schematically represent P2P (Peer to Peer) connections, which may be, for example, TCP connections or the like, for transmitting data between the nodes. The nodes may have a full ledger stored on them, i.e. the status of all blocks and all accounts. Wherein each node in the blockchain can generate the same state in the blockchain by performing the same transaction, and each node in the blockchain can store the same state database.

A transaction in the blockchain domain may refer to a unit of task that is performed in the blockchain and recorded in the blockchain. The transaction typically includes a send field (From), a receive field (To), and a Data field (Data). Where the transaction is a transfer transaction, the From field indicates the address of the account From which the transaction was initiated (i.e., from which a transfer task To another account was initiated), the To field indicates the address of the account From which the transaction was received (i.e., from which a transfer was received), and the Data field includes the transfer amount.

The block chain may provide the functionality of an intelligent contract. An intelligent contract on a blockchain is a contract that can be executed on a blockchain system triggered by a transaction. An intelligent contract may be defined in the form of code. Calling the intelligent contract in the blockchain initiates a transaction pointing to the address of the intelligent contract, so that each node in the blockchain runs the intelligent contract code in a distributed mode.

In the scenario of contract deployment, for example, bob sends a transaction containing information to create an intelligent contract (i.e., a deployment contract) into the blockchain as shown in fig. 1, the data field of the transaction includes the code (e.g., bytecode or machine code) of the contract to be created, and the to field of the transaction is null to indicate that the transaction is for use in deploying the contract. After agreement is achieved among nodes through a consensus mechanism, determining contract addresses '0 x6f8ae93 \8230' of contracts, adding contract accounts corresponding to the contract addresses of the intelligent contracts in a state database by each node, allocating state storage corresponding to the contract accounts, storing contract codes, and storing hash values of the contract codes in the state storage of the contracts, so that the contracts are successfully created.

In the scenario of invoking a contract, for example, bob sends a transaction for invoking a smart contract into the blockchain as shown in fig. 1, where the from field of the transaction is the address of the account of the transaction initiator (i.e., bob), the to field is "0x6f8ae93 \8230", as described above, i.e., the address of the invoked smart contract, and the data field of the transaction includes the method and parameters for invoking the smart contract. After the transaction is identified in the blockchain, each node in the blockchain can execute the transaction respectively, so that the contract is executed respectively, and the state database is updated based on the execution of the contract.

TEE may be introduced in the blockchain for protecting private data. A TEE is a trusted execution environment that is based on a secure extension of the CPU hardware and is completely isolated from the outside. The industry is concerned about TEE solutions, and almost all mainstream chip and Software alliances have their own TEE solutions, such as TPM (Trusted Platform Module) in Software and Intel SGX (Software Guard Extensions) in hardware, ARM Trustzone (Trusted zone) and AMD PSP (Platform Security Processor) in hardware. The TEE can function as a black box, and codes and data executed in the TEE cannot be peeped even by an operating system layer and can be operated only through an interface predefined in the codes. In terms of efficiency, due to the black-box nature of the TEE, the plaintext data is operated on in the TEE, rather than the complex cryptographic operations in homomorphic encryption, and little efficiency is lost in the calculation process. Therefore, the adoption of the TEE technology can meet the trusted computing requirement under the block chain scene to a great extent on the premise of relatively small performance loss.

The TEE technique is described by taking an Intel SGX (Intel Software Guard Extension, hereinafter referred to as SGX) technique as an example. The blockchain node may create enclave (enclosure or enclave) based on SGX technology as a TEE for performing blockchain transactions. The block link point may allocate a part of an EPC (envelope Page Cache, a ring Page Cache, or an Enclave Page Cache) in the memory by using a newly added processor instruction in the CPU, so as to reside the envelope. The Memory area corresponding to the EPC is encrypted by a Memory Encryption Engine MEE (Memory Encryption Engine) inside the CPU, the content (code and data in the enclave) in the Memory area can be decrypted only in the CPU core, and a key for Encryption and decryption is generated only when the EPC is started and is stored in the CPU. It can be seen that the security boundary of Enclave only includes itself and CPU, and neither privileged software nor non-privileged software can access Enclave, and even a Virtual Machine Monitor (VMM) or Hypervisor (operating system administrator) cannot affect code and data in Enclave, so that it has very high security. On the premise of the security guarantee, the CPU can process the data in the Enclave, and has extremely high operation efficiency, thereby taking both data security and calculation efficiency into consideration. In addition, data entering and exiting the TEE can be encrypted, so that the privacy of the data is guaranteed.

After the TEE is created in a blockchain node (e.g., node 1 in fig. 1), the specified program code may be loaded into the TEE. Such as program code including program code for performing a transfer transaction, program code for performing a virtual machine (EVM) for a contract transaction, etc. A Key Management Server (KMS) may initiate a remote authentication process for a TEE, which may obtain a public-private key pair for encryption. The process is described in detail below.

Before the CPU supporting the SGX leaves the factory, a manufacturer burns a deployment Key (Provisioning Key) and an envelope Key (Sealing Key) into a fuse (fuse) register in the CPU. A fuse register is a one-time programmable register that blows a fuse once data is burned in, so that the contents of the subsequent register are only readable and no longer writable. The key that Intel promises to burn into the fuse register is randomly generated; in addition, it is also guaranteed that all the backup of the burnt key will be destroyed after burning, i.e. even the Intel itself does not know the burnt key. A Provisioning Key may represent partial information in a CPU, such as the CPU's code (e.g., sixth generation core, seventh generation core, etc.), model (e.g., desktop, mobile, etc.), and the like. For security, regarding operations such as encryption and signature, the Provisioning Key is not directly used, but is derived from the Provisioning Key (authentication Key), so that the Provisioning Key plays a role in deployment.

Before the KMS initiates remote authentication for a TEE in a block link point, a CPU in a block chain node may detect whether an authentication key is present. If not, initialization is initiated. During initialization, an EPID (Enhanced Privacy IDentification) may be generated based on a Key generation protocol through interaction with an Intel server and according to a generation rule of Provisioning Key, and the EPID may be used as an authentication Key and generally used as the private Key sk1 in the asymmetric encryption Key. The generated EPID may be stored in the TEE for subsequent signing operations. Therefore, the Intel server can obtain the public key pk1 corresponding to the EPID through an interaction process. In particular, the public key pk1 corresponding to the EPID is not public, but is kept by the Intel server. Such a feature is suitable for subsequent authentication by an Intel's Server (also known as IAS, intel attention Server) in a remote Attestation process.

After the TEE prepares the private key sk1 and the public key pk1 for signature, the private key sk2 and the public key pk2 for asymmetric encryption may be obtained by the following steps:

step 1: the KMS challenges the TEE in node 1 to ask it to present a report to prove that the program code included therein is the correct code, in particular, the report is used to prove that the EVM code in the TEE is the correct EVM code;

step 2: after receiving the challenge, the TEE in the node 1 calculates hash1 of a local code, generates a report quote, the report quote comprises the hash1, signs the quote by using the key sk1 to obtain a signature sig1, and sends the quote and the signature sig1 thereof to the KMS;

the TEE and the KMS in the node 1 may also negotiate a public key pk2 through Diffie-Hellman key Exchange (DH) algorithm or Elliptic Curve Diffie-Hellman key Exchange (ECDH) algorithm in step 1 and step 2, in which case, a hash value hash2 of the public key pk2 may also be included in the quote;

and 3, step 3: since the KMS does not have the public key pk1 corresponding to sk1, after receiving the quote and the signature sig1 thereof, the KMS sends the quote and the signature sig1 thereof to the IAS;

and 4, step 4: the IAS verifies the signature sig1 of the quote by using the public key pk1 and returns a verification result to the KMS, wherein in order to prevent the verification result from being intercepted or modified, the IAS can use a private key of the IAS to sign the verification result to obtain a signature sig2 and send the verification result and the signature sig2 thereof to the KMS;

and 5: after the KMS receives the verification result, if the verification result indicates that sig1 is correct, verifying hash1 in the quote according to a correct hash value of an EVM code acquired in advance, and if the verification result is consistent, verifying through remote certification, namely the KMS confirms that the correct EVM runs in the TEE of the node 1, wherein the KMS can download the correct EVM code from an official developer of the EVM and calculate the correct hash value of the EVM code based on the correct EVM code;

and 6: the KMS generates a private key sk2 corresponding to the public key pk2, symmetrically encrypts the private key sk2 by using the public key pk2, and sends a ciphertext private key to the TEE of the node 1;

and 7: after receiving the ciphertext private key, the TEE of the node 1 may decrypt the ciphertext private key by using the public key pk2, thereby obtaining the private key sk2, and store the private key sk2 and the public key pk2 into the TEE.

After the KMS sends the private key sk2 to the TEE of the node 1, the client for sending the transaction to the blockchain may obtain the public key pk2 from the KMS, for example, the KMS may send the public key pk2 and the signature of the public key pk2 by the KMS to the client together, so that the client may verify the public key pk2 based on the signature of the KMS to ensure that the correct public key pk2 is received. After receiving the public key pk2, the client may encrypt data (e.g., transaction) of the TEE to be sent to the node 1 based on the public key pk2, and send the obtained ciphertext to the TEE of the node 1, so that the TEE of the node 1 may decrypt the ciphertext based on the private key to obtain the corresponding plaintext.

The TEEs of other nodes (e.g., node 2) in the block chain may similarly pass through steps 1 and 2 described above, send a quote report to the KMS, and negotiate a symmetric encryption key k1 with the KMS, and after the remote authentication of the TEE of node 2 is passed, the KMS may use key k1 to symmetrically encrypt the public key pk2 and the private key sk2, and send the ciphertext of the public key pk2 and the private key sk2 to the TEE of node 2, so that the TEE of node 2 may obtain the same public key pk2 and private key sk2 as the TEE in node 1. In this way, the node 1 may broadcast the ciphertext transaction received from the client to each node (including the node 2) in the blockchain, and the TEE in other nodes in the blockchain may all securely obtain the public key pk2 and the private key sk2 by the same method as that of the node 2, so that the TEE in other nodes in the blockchain may also decrypt the ciphertext transaction, and may encrypt data of the output TEE using the public key pk2. It is to be understood that the TEE in the blockchain node is not limited to acquiring the public-private key pair for asymmetric encryption in the above manner, but may acquire the public-private key pair for asymmetric encryption in any known secure manner.

Fig. 2 is a schematic diagram of a process of performing a transaction in a blockchain in an embodiment of the present specification. As shown in fig. 2, in the blockchain shown in fig. 2, a gray sector in a circle representing a blockchain node indicates a TEE included in a blockchain link point, in which a virtual machine (EVM) is operated, and thus can be used to perform a contract transaction. In addition, as described above, the same public key pk2 and private key sk2 for encryption and decryption are preset in the TEE in each node in the block chain.

The transactions sent by the client into the blockchain may include private transactions such as transaction Tx1 (shown as a light gray rectangular block in the figure) and transaction Tx2 (shown as a dark gray rectangular block in the figure), or may include non-private transactions Tx3 (shown as a white rectangular block in the figure).

The privacy transaction refers to a transaction for protecting the privacy of the user. Privacy transactions may include, for example, several types of privacy transactions:

type 1 privacy transaction (e.g., transaction Tx1 in fig. 2) includes a plaintext type field and ciphertext content. This type of privacy transaction may be a normal transfer transaction, or may invoke a clear text contract, or may invoke a privacy contract. The type field in the private transaction is used for indicating that the transaction type is a ciphertext type, and the ciphertext content is a ciphertext obtained by encrypting other plaintext contents (including from, to and data field values) of the transaction together.

The contract state of the privacy contract is stored in the form of ciphertext (the contract state of the privacy contract is shown in grey squares in the "state" of "store" in fig. 2). Specifically, the states of the variables in the contract state of the privacy contract are stored in the form of ciphertext, including ciphertext contract codes of the privacy contract. The ciphertext state of the privacy contract may be a ciphertext obtained by the TEE asymmetrically encrypting the plaintext state of the contract variable using the TEE's public key pk2, or may be a digital envelope obtained by the TEE envelope encrypting the plaintext state based on the TEE's public key pk2. It is to be appreciated that the ciphertext state of the privacy contract is not limited to being obtained by encryption based on public key pk2. For example, a plurality of pairs of public-private key pairs may be generated in the TEE based on the public key pk2 and the private key sk2, and the ciphertext state of the privacy contract may be obtained by encrypting based on a child public key of the public key pk2, where the child private key corresponding to the child public key is also stored within the TEE.

In the case that the privacy transaction includes the call to the privacy contract, since the call information to the privacy contract in the transaction is also encrypted as the ciphertext, the privacy transaction does not reveal the call to the function in the privacy contract and the parameter value transmitted to the function in the transaction, and the privacy of the user is further protected.

Wherein, in the case that the privacy deal directly calls the privacy contract, the deal also comprises a contract type field used for indicating that the called contract is the privacy contract. In the case where the private transaction invokes a plaintext contract and the plaintext contract invokes a privacy contract, the plaintext contract also includes a contract type field that indicates that the invoked contract is a privacy contract.

A 2 nd type of privacy transaction (not shown in fig. 2) that includes a plaintext type field corresponding to each of the from, to, and data fields, indicating whether each of the from, to, and data fields is ciphertext, i.e., at least one of the from, to, and data fields in the transaction is ciphertext. Such private transactions may be ordinary transfer transactions, or the invokable plaintext contracts, or the invokable private contracts.

A privacy transaction of type 3 (e.g., transaction Tx2 in fig. 2), which is a clear text transaction in which a privacy contract is invoked. A type field may be included in such a private transaction to indicate that the transaction type is a clear text type. Where the privacy contract may be invoked directly in such a privacy transaction, in which case the contract type field is included in the transaction to indicate that the invoked contract is a privacy contract. Or such a private transaction may invoke a clear text contract and invoke a private contract in the clear text contract, in which case the clear text contract includes a contract type field indicating that the contract it invokes is a private contract.

For the above-mentioned 1 st and 2 nd privacy transactions, the ciphertext in the privacy transaction may be a ciphertext obtained by the client performing asymmetric encryption on the plaintext by using the public key pk2 of the TEE, or may be a digital envelope obtained by the client performing envelope encryption on plaintext data by using the public key pk2 based on the TEE. The envelope encryption is that the client generates a symmetric encryption key k2, plaintext data is encrypted by using the symmetric encryption key k2 to obtain ciphertext data, the key k2 is asymmetrically encrypted by using a public key pk2 to obtain ciphertext of the key k2, and the digital envelope comprises the ciphertext data and the ciphertext of the key k2. After receiving the digital envelope, the TEE may first decrypt the ciphertext of the key k2 using the private key sk2 to obtain the key k2, and then decrypt the ciphertext data using the key k2 to obtain plaintext data. Through envelope encryption, when plaintext data is long, the TEE can obtain the plaintext data based on a digital envelope in a shorter time compared with a ciphertext obtained through asymmetric encryption, and the processing efficiency of the TEE is improved.

It is to be understood that the ciphertext data transmitted by the client is not limited to be obtained by encryption based on the public key pk2. For example, a plurality of pairs of public and private key pairs may be generated in the TEE based on the public key pk2 and the private key sk2, and the TEE may securely send the sub public key to the client, so that the client may encrypt data based on the sub public key of the public key pk2 to obtain ciphertext data, where the sub private key corresponding to the sub public key is also stored in the TEE.

No matter the above-mentioned type 1, type 2, and type 3 privacy transactions involve ciphertext associated with a private key stored within the TEE, and therefore, each privacy transaction needs to be processed in a respective blockchain node.

As shown in the lower part of fig. 2, each node in the block chain operates as follows. First, a transaction consensus is performed on the received transaction, and specifically a consensus proposal indicating, for example, a plurality of sequentially arranged transactions included in the block B to be executed may be issued by a certain node (e.g., a master node) in the block chain. As shown in fig. 2, in the "transaction consensus" block, the plurality of transactions connected by arrows represent a plurality of transactions sequentially arranged in a consensus proposal, which may include non-private transactions and private transactions. The plurality of nodes in the blockchain can agree on the agreement proposal through a preset agreement algorithm. The current mainstream consensus mechanisms include: proof of Work (POW), proof of stock (POS), proof of commission rights (DPOS), practical Byzantine Fault Tolerance (PBFT) algorithm, etc. In various consensus algorithms, after a predetermined number of nodes agree on data to be agreed (i.e., a consensus proposal), it is determined that the consensus proposal is successful. Specifically, in the PBFT algorithm, f malicious nodes can be tolerated for N ≧ 3f +1 consensus nodes, that is, when 2f +1 nodes in the N consensus nodes agree, success of consensus can be determined.

After the consensus is successful, the nodes may begin transaction processing. Specifically, taking node 5 as an example, node 5 may distribute the transaction first. In the case where the privacy transaction of the plurality of transactions is the above-mentioned type 1 or type 2 privacy transaction, the type field in the privacy transaction indicates that ciphertext content is included in the transaction, and thus, the node 5 transmits the transaction to the TEE to execute the transaction in the TEE. In the case where the privacy transaction of the plurality of transactions is the above-mentioned type 3 privacy transaction, the node 5 transmits the transaction to the TEE in the case where the contract type field included in the privacy transaction indicates that the privacy contract is invoked in the transaction, or the node 5 transmits the transaction to the TEE in the case where the transaction invokes a plaintext contract and the code of the plaintext contract includes a contract type field for indicating that the plaintext contract invokes the privacy contract. Node 5 executes the transaction outside the TEE in the event that it is determined that the transaction does not involve ciphertext content and ciphertext contract code.

Specifically, within the TEE of node 5, if the privacy transaction is the above-mentioned type 1 or type 2 privacy transaction, and the privacy parameters (i.e., parameters that store state in the form of ciphertext in the blockchain, such as parameters defined in a privacy contract) are not accessed in the privacy transaction, the TEE first decrypts the ciphertext content using private key sk2. And when the ciphertext content is decrypted in the TEE, the signature of the transaction can be verified by using a pre-acquired public key of the client, wherein the signature is a digital signature of the client on the transaction data comprising the ciphertext. After the transaction verification is passed, if the transaction is a normal transfer transaction, the transaction is executed directly, and if the transaction is a contract invoking transaction, the contract transaction is executed in the EVM. During the transaction process in the TEE, the plaintext state of the parameter can be read from the cache outside the TEE according to the reading operation included in the transaction, and if the plaintext state of the parameter is not stored in the cache outside the TEE, the state is read from the storage through the data interaction operation. After completion of execution of the transaction, the cache state outside the TEE may be updated based on the write set of the transaction. After the node has performed all transactions for the block, the state in storage, i.e., the "state" in "storage" in FIG. 2, may be updated based on the cached state.

If the privacy transaction is the above-mentioned type 3 privacy transaction, the TEE performs data interaction with the storage in the node after the transaction verification is passed, that is, reads the ciphertext code of the privacy contract from the storage, decrypts the ciphertext code by using the private key sk2 to obtain a plaintext code, and then executes the plaintext contract code in the EVM. In the TEE, during the execution of the plaintext contract code, the ciphertext state of the privacy parameter may be read according to a read operation included in the plaintext contract code. After completion of execution of the transaction, a plaintext write set of the transaction is obtained and the parameter states in the write set may be stored in a cache within the TEE. After the node has performed all transactions for the block, the state in storage may be updated based on the state of the parameters stored in the cache in the TEE.

Outside the TEE of the node 5, after signature verification of the non-private transaction is passed, the normal transaction is executed directly if the transaction is a normal transfer transaction, the contract transaction is executed in the EVM if the transaction is a contract transaction, the state may be read from the cache during execution of the transaction, or from "store" by data interaction if the state is not present in the cache.

After transaction processing is complete, e.g., after processing of all transactions for a block is complete, the blockchain node may update the state in storage as described above and generate and store a block including transaction bodies for multiple transactions. The storage includes, for example, a non-volatile storage medium such as a magnetic disk, a hard disk, or the like. The transactions in the store comprise, for example, privacy transactions (schematically shown in light grey or dark grey rectangles), which states comprise contract states of privacy contracts (schematically shown in grey squares).

In the transaction processing shown in fig. 2, the block nodes may serially execute a plurality of transactions in the block, for which the transactions are distributed in order in the order of the transactions in the consensus proposal, thereby sequentially executing the plurality of transactions.

In one embodiment, to improve the efficiency of transaction execution, the chunk node may analyze the read and write sets of each transaction, where the read set of a transaction includes the key of the parameter requested to be read in the transaction, and the write set of a transaction includes the key of the parameter requested to be written in the transaction. For ordinary transfer transactions, the block chain nodes can directly perform static analysis on the transactions, so that a read-write set of the transactions is obtained. For contract transactions, the block nodes can perform static analysis on the transaction and the contract code called by the transaction, so as to obtain a read-write set of the transaction. The block link points may also obtain the read-write sets of the transactions in other manners, for example, the read-write sets of the transactions may be obtained by pre-executing the transactions.

After obtaining the read-write sets of each transaction, the blockchain node can group the transactions according to the read-write sets of the transactions, so that the transactions in each two groups do not access the same parameters, namely, the transactions in each two groups do not have dependency relationship, and the transactions can be executed in parallel according to the grouping results of the transactions.

In order to perform multiple transactions in a block in parallel when non-private transactions and private transactions are processed simultaneously in a block chain, when read-write set analysis is performed on multiple transactions in the block for grouping the multiple transactions, the read-write set analysis cannot be performed on private transactions outside a TEE in a block chain node, but there may be a dependency relationship between private transactions and non-private transactions, for example, the private transactions and the non-private transactions may call the same plaintext contract, and therefore, a transaction grouping scheme in a block chain node needs to be designed for this case.

Fig. 3 is a schematic diagram of a transaction processing process in an embodiment of the present specification. As shown in fig. 3, the blockchain node determines, outside the TEE, whether the transaction type of the respective transaction is a non-private transaction type or a private transaction type after consensus on the plurality of transactions has been reached and processing of the plurality of transactions in the block has begun. And when the transaction is determined to be a non-private transaction type, performing read-write set analysis on the transaction outside the TEE to obtain a read-write set of the transaction. And when the transaction is determined to be the privacy transaction type, skipping the transaction and continuing to determine the transaction type for the next transaction. After all of the multiple transactions are processed outside the TEE, respective read-write sets of all non-private transactions in the multiple transactions are obtained. The read-write set of individual non-private transactions and all private transactions are then provided outside the TEE into the TEE. After receiving the read-write sets of the non-privacy transactions and all privacy transactions, the TEE decrypts the ciphertexts (cipher text transaction contents or cipher text contract codes) corresponding to the privacy transactions, and performs read-write set analysis on the privacy transactions according to decrypted plaintext data to obtain the read-write sets of the privacy transactions. The transactions may then be grouped within the TEE based on their respective read-write sets.

It is to be understood that, although the read-write set analysis is described in the embodiments of this specification for non-private transactions and private transactions respectively after a plurality of transactions are agreed upon, the embodiments of this specification are not limited thereto. For example, a block link point may generate a read-write set of a transaction outside or inside the TEE upon receipt of the transaction. After the consensus among the blockchain nodes is achieved, pre-generated read-write sets of the multiple transactions can be obtained in the TEE according to the transactions in the consensus proposal, so as to group the multiple transactions according to the read-write sets of the multiple transactions.

In addition, it is further understood that the embodiments of the present description are not limited to processing transactions as shown in fig. 3. For example, after processing a plurality of transactions in a node is started, a non-private transaction may be distributed to the outside of the TEE for read-write set analysis, and a private transaction may be distributed to the inside of the TEE for read-write set analysis, similarly to fig. 2. After completing read-write set analysis on all non-private transactions outside the TEE, providing respective read-write sets of all non-private transactions into the TEE, thereby grouping the transactions within the TEE based on the respective read-write sets of the transactions.

After completing the grouping, the TEE may provide grouping information, including, for example, information for multiple transaction groups, outside the TEE. Thus, individual transaction groups may be executed in parallel in the node according to the grouping information, wherein for each transaction group a plurality of transactions in the transaction group may be executed in series. When executing a transaction group, transaction distribution may occur serially for multiple transactions in the transaction group outside the TEE, i.e. non-private transactions are distributed to outside the TEE for execution and private transactions are distributed to inside the TEE for execution, similar to that shown in fig. 2.

Through the transaction grouping scheme in the embodiments of the present specification, multiple transactions including private transactions can be grouped in a blockchain, so that multiple transactions can be executed in parallel according to a grouping result, and the transaction execution efficiency in the blockchain is improved.

Fig. 4 is a flowchart of a transaction grouping method in an embodiment of the present specification. The method may be executed by any node in the blockchain, as shown in fig. 2, each blockchain node includes a TEE, and the TEE of each node stores the same public key pk2 and private key sk2. Thus, the TEEs of the various nodes may perform a consistent process. The flow shown in fig. 4 is described below by taking node 1 as an example.

As shown in fig. 4, first, at step S401, the node 1 receives a plurality of transactions.

As shown in fig. 2, the respective nodes may receive transactions from clients, respectively, e.g. node 8 receives privacy transaction Tx1, privacy transaction Tx2 from a client, and node 7 receives non-privacy transaction Tx3 from a client. Each node, upon receiving a transaction from a client, broadcasts the transaction into the blockchain so that multiple nodes in the blockchain can all receive the multiple transactions. For example, a plurality of transactions are received in node 1 from other nodes or clients in the blockchain, such as a plurality of transactions in the consensus proposal for the block B, the plurality of transactions including a private transaction Tx1, a private transaction Tx2, and a non-private transaction Tx3, it being understood that other private and non-private transactions may also be included in the plurality of transactions.

In one embodiment, node 1 may receive a consensus proposal from the master node in the blockchain, which may include the plurality of transactions. That is, node 1 receives the plurality of transactions by receiving a consensus proposal. The consensus proposal includes a plurality of transactions arranged in a sequence.

At step S403, node 1 generates a read-write set of non-private transactions outside the TEE.

Referring to fig. 3, the node 1 may perform a readwrite set analysis on the transactions after the consensus on multiple transactions is reached, or after a proposal for consensus is received, or after each transaction is received.

Specifically, node 1 first determines the type of transaction (private transaction or non-private transaction) outside the TEE.

Taking the block chain including the above-mentioned 1 st privacy transaction and 3 rd privacy transaction as an example, fig. 5 is a flowchart of a method for determining whether a transaction is a privacy transaction in this embodiment of the present disclosure. As shown in fig. 5, the node 1 first reads the plaintext type field in the transaction at step S51, and determines whether the transaction is of the ciphertext type. If so, the transaction is determined to be a private transaction. If not, node 1 determines at step S52 whether the transaction invokes a contract, and if the transaction does not invoke a contract, i.e., is a transfer transaction, then the transaction may be determined to be a non-private transaction. If the transaction invokes the contract C1, the node 1 determines in step S53 whether the contract C1 is a privacy contract based on the contract type field in the transaction, and if so, the transaction is a privacy transaction. If not, the node 1 determines in step S54 whether a privacy contract is invoked in the contract C1, that is, whether the contract invoked by the contract C1 is a privacy contract is determined according to the contract type field included in the contract C1, and if so, the transaction is determined to be a privacy transaction. If not, two conditions exist, namely the first condition that other contracts are not called in the contract C1, the transaction can be determined to be a non-private transaction; in the second case, the plaintext contract C2 is invoked in the contract C1, it is necessary to determine whether the privacy contract is invoked in the plaintext contract C2 to determine whether the transaction is a privacy transaction (this case is not shown in fig. 5).

Node 1 performs a read-write set analysis on transaction Tx3 outside the TEE in the event that the received transaction (e.g., transaction Tx 3) is determined to be a non-private transaction. The transaction Tx3 may be a clear text transfer transaction or a clear text transaction that invokes a non-privacy contract (i.e., does not invoke a privacy contract). Specifically, referring to fig. 3, the signature of transaction Tx3 may be verified outside the TEE in node 1 (not shown in fig. 3), and read-write set analysis may be performed on transaction Tx3 after verification is passed, so as to generate a read-write set of transaction Tx3, and the read-write set of transaction Tx3 may be stored in a cache. As described above, in the read/write set of transaction Tx3, the read set of transaction includes the key of the parameter requested to be read in transaction, and the write set of transaction includes the key of the parameter requested to be written in transaction.

A transaction type may be determined for each of the plurality of transactions outside the TEE of node 1, and if the type of transaction is determined to be a non-private transaction type, then read-write set analysis may be performed on the transaction outside the TEE similar to the processing of transaction Tx3, and if the type of transaction is determined to be a private transaction type, then processing of the transaction may be skipped and processing of the next transaction may continue. Thus, read-write set analysis can be performed on all non-private transactions in the multiple transactions outside the TEE, and read-write sets of all the non-private transactions are obtained.

In step S405, the TEE decrypts the ciphertext corresponding to the privacy transaction, and generates a read-write set of the privacy transaction.

Still referring to fig. 3, after obtaining the read-write sets for each non-privacy transaction outside the TEE, node 1 provides the read-write sets for each non-privacy transaction and all privacy transactions, including, for example, transaction Tx1 and transaction Tx2 described above, into the TEE. The transaction Tx1 is, for example, the above-mentioned 1 st privacy transaction, and includes ciphertext content, and the TEE may decrypt the ciphertext content based on the private key sk2 while verifying the signature of the transaction Tx1 to obtain the plaintext content of the transaction Tx1, and then perform read-write set analysis on the transaction Tx1 according to the plaintext content to obtain the read-write set of the transaction Tx1. In the read-write set of the transaction Tx1, the read set of the transaction Tx1 includes the key of the parameter requested to be read in the transaction Tx1, and the write set of the transaction Tx1 includes the key of the parameter requested to be written in the transaction Tx1.

The transaction Tx2 is a clear text type transaction and invokes a privacy contract. The TEE can read the ciphertext contract code of the privacy contract from the storage while verifying the signature of the transaction Tx2, decrypt the ciphertext contract code based on the private key sk2 to obtain a plaintext contract code, and then perform read-write set analysis on the transaction Tx2 according to the plaintext contract code to obtain a read-write set of the transaction Tx2.

At step S407, node 1 groups multiple transactions within the TEE based on the read-write set of private transactions and the read-write set of non-private transactions.

After all privacy transactions are read-write set analyzed in the TEE in the node 1, a plurality of transactions can be grouped in the TEE based on all non-privacy transaction read-write sets and all privacy transaction read-write sets. For example, the transactions may be grouped according to DAG analysis results by performing Directed Acyclic Graph (DAG) analysis on the transactions based on their read-write sets. Specifically, the transactions may be divided into transaction groups, and each two transaction groups do not access the same parameters, i.e., there is no access conflict between transaction groups, so that the transaction groups may be executed in parallel.

After completing the grouping of the multiple transaction groups and after consensus among the blockchain for the multiple transactions is reached, the TEE in node 1 may provide grouping information outside the TEE to execute the multiple transaction groups resulting from the grouping in parallel.

Specifically, for one transaction group (e.g., transaction group G1) of the transaction groups, node 1 distributes n transactions in transaction group G1 sequentially outside the TEE or within the TEE for execution.

Meanwhile, the TEE can also provide read-write set information of each transaction group to the outside of the TEE for use in the transaction execution process. In one embodiment, for a transaction group, a union of the read-write sets of multiple privacy transactions in the transaction group may be provided outside the TEE. Wherein the reading set in the union set is a union set of the reading sets of the plurality of privacy transactions, and the writing set in the union set is a union set of the writing sets of the plurality of privacy transactions. The union may be provided to the TEE external as a read-write set for each private transaction in the transaction group.

Therefore, when the transaction group is executed outside the TEE subsequently, parameter value reading can be carried out based on the read set in the read-write set of each non-private transaction in the transaction group and the read set in the union of the read-write sets of the multiple private transactions, correctness verification can be carried out on the write set generated by executing the transactions based on the write set in the read-write set of each non-private transaction and the write set in the union of the read-write sets of the multiple private transactions, namely whether the key written in the execution process is included in the write set in the read-write set of each non-private transaction and the write set in the union of the read-write sets of the multiple private transactions is verified, if yes, the execution process is determined to be correct, and if not, the read-write set process or one of the execution processes is verified to have errors.

For example, assume that transaction group G1 includes sequentially arranged transaction Tx1, transaction Tx3, and transaction Tx2. For transaction Tx1 included in transaction group G1, in node 1, outside the TEE, transaction Tx1 may be determined to be a private transaction according to the transaction type identification in the transaction and the circumstances of the invoked contract, or in the case where node 1 previously determined transaction Tx1 to be a private transaction, transaction Tx1 may be recorded as a private transaction, so that node 1 may determine transaction Tx1 to be a private transaction according to the already recorded information when performing transaction distribution. After determining transaction Tx1 is a privacy transaction, transaction Tx1 is provided within the TEE.

The TEE may store plaintext transaction content obtained by decrypting the ciphertext content of transaction Tx1 before, and determine whether transaction Tx1 is a normal transfer transaction or a contract transaction according to the plaintext content. If the transaction is a normal transaction, the transaction is directly executed in the TEE, and if the transaction is a contract transaction, the transaction is executed in a virtual machine in the TEE.

When the parameter value needs to be read during the execution of the transaction Tx1 by the TEE, it is assumed that the privacy contract is not invoked in the transaction Tx1, that is, the transaction Tx1 may only read or write the parameter of the external account or the plaintext contract, and therefore, the transaction Tx1 may have access conflict with the non-privacy transaction. In this case, for example, the transaction Tx1 requests a read of the value (i.e., state) of parameter a, the TEE first determines from a cache external to the TEE whether the value of parameter a is stored. The external cache may include a read cache RB1 and a write cache WB1 (not shown in fig. 3), where the read cache RB1 is used to store the state of the non-privacy parameter read from the storage during the transaction execution, and the write cache WB1 is used to store the state of the non-privacy parameter updated according to the transaction, that is, the state of the parameter stored in the cache is the latest state of the parameter. Wherein the non-privacy parameter refers to a parameter for which the parameter value is stored in plaintext in the block chain.

The TEE may first determine whether there is a value for parameter a in the write cache WB1, and in the absence of the write cache WB1, determine whether there is a value for parameter a in the read cache RB 1. If it is determined that the value of the parameter a is stored in the read buffer RB1 or the write buffer WB1, the value of the parameter a is directly read from the read buffer RB1 or the write buffer WB1, and the transaction Tx1 is executed according to the read value of the parameter a. If the value of the parameter a is not stored in the cache outside the TEE, the TEE may read the value of the parameter a from the storage through the storage interface, and after reading the value of the parameter a from the storage, the TEE may store the value of the parameter a in the read cache RB 1.

After executing the completion transaction Tx1 in the TEE, assuming that the write set of transaction Tx1 includes the updated value of parameter b, the TEE writes the key-value pair of parameter b into the write cache WB1 outside the TEE, so that the state maintained in the cache is the parameter latest state.

Transaction Tx3 is executed in node 1 after transaction Tx1 has been executed. After node 1 determines that transaction Tx3 is a non-private transaction, transaction Tx3 is executed outside the TEE in node 1. Node 1, in performing transaction Tx3, if a parameter needs to be read, first determines in a cache external to the TEE whether the value of the parameter is stored, similar to performing transaction Tx1 above, and if so, reads the value of the parameter directly from the cache, and if not, reads the value of the parameter from storage. When node 1 completes transaction Tx3, the state of the parameters in the cache (i.e., write cache WB 1) may be updated according to the write set of transaction Tx3.

Node 1 executes transaction Tx2 after transaction Tx3 execution is complete. After node 1 determines that transaction Tx2 is a private transaction outside the TEE, transaction Tx2 is provided within the TEE for processing.

In a case where it is assumed that only the privacy contract is invoked in transaction Tx2 and the parameters read and written by transaction Tx2 in execution are both parameters defined in the privacy contract (hereinafter referred to as privacy parameters, where the privacy parameters store parameter values in ciphertext in a blockchain), the values of the privacy parameters read and written by transaction Tx2 are both ciphertext parameter values, and thus, there is no possibility of an access conflict with transaction Tx2 for non-private transactions. In this case, a read cache RB2 for storing the plaintext values of the privacy parameters read from storage and a write cache WB2 for storing the plaintext values of the privacy parameters updated according to the transaction write set after the transaction is completed is executed may be maintained within the TEE.

When the value of the privacy parameter needs to be read in executing transaction Tx2 in the TEE, first determining whether a plaintext value of the privacy parameter is stored in a cache (including a read cache RB2 and a write cache WB 2) in the TEE, if so, directly reading the plaintext value from the cache, and executing transaction Tx2 according to the plaintext value; if not, the TEE can read the ciphertext value of the privacy parameter from the storage, decrypt the ciphertext value in the TEE to obtain the plaintext value of the privacy parameter, and meanwhile, the TEE can store the read plaintext value of the privacy parameter into the read buffer RB 2.

The TEE updates the value of the privacy parameter according to the write set after performing the completion transaction Tx2, i.e. the plaintext value of the privacy parameter in the write set is stored in the write cache WB2 within the TEE.

In another case, it is assumed that both privacy and non-privacy contracts are invoked in transaction Tx2, and thus the parameters accessed by transaction Tx2 may include non-privacy and privacy parameters. In this regard, the TEE may update the value of the non-privacy parameter into a cache external to the TEE and the value of the privacy parameter into a cache within the TEE.

After the execution of all transactions in the block B is completed in the node 1, the node 1 may update the state of the non-privacy parameter in the storage according to the state of the non-privacy parameter in the write cache outside the TEE, and may update the state of the privacy parameter in the storage according to the state of the privacy parameter in the write cache inside the TEE. In the updating process, the TEE firstly encrypts the states of the privacy parameters in the write cache in the TEE to obtain the ciphertext states of all the privacy parameters, and then updates the ciphertext states of all the privacy parameters into a state database.

In one embodiment, before starting to execute the transaction, in the node 1, for each transaction group obtained by grouping, keys of a plurality of parameters in a read set in a read-write set of all transactions included in the transaction group may be obtained outside the TEE, values of the plurality of parameters may be read from a storage, and the values of the plurality of parameters may be stored in a read buffer RB1 outside the TEE. In this case, the plurality of parameters may include a plurality of non-privacy parameters and a plurality of privacy parameters, and the plurality of read parameter values include plaintext values of the non-privacy parameters and ciphertext values of the privacy parameters. In this way, when the values of the parameters are read for the first time in the subsequent execution of the transactions included in the transaction group outside or inside the TEE, the values can be directly read from the read cache RB1 without accessing the storage multiple times in the execution process, and particularly in the case where the transaction processing and data storage are performed by two separate computing devices in the node 1, respectively, the transaction processing speed can be greatly increased.

Specifically, when a transaction Tx3 is executed outside the TEE, for example, when a parameter value needs to be read, it is determined whether the parameter value exists in the write cache WB1, if so, the parameter value is directly read from the write cache WB1, if not, the parameter value is read from the read cache RB1, and after the transaction Tx3 is executed, the state of the parameter in the write cache WB1 is updated according to the written parameter value of the transaction Tx3.

When a transaction Tx1 is executed internally in the TEE, for example, when a parameter value needs to be read, it is first determined whether the value of the parameter exists in the write cache WB1, if so, the value of the parameter is directly read from the write cache WB1, if not, the value of the parameter is read from the read cache RB1, and after the transaction Tx1 is executed, the state of the parameter in the write cache WB1 is updated according to the value of the written parameter of the transaction Tx1.

When a transaction Tx2 is executed in the TEE, for example, when a parameter value needs to be read, it is determined whether the value of the parameter exists in the write cache WB2 in the TEE, if so, the value of the parameter is directly read from the write cache WB2, if not, the value of the parameter is read from the read cache RB1, and after the transaction Tx2 is executed, the state of the parameter in the write cache WB2 in the TEE is updated according to the value of the parameter written in the transaction Tx2.

In the embodiment of the description, the private transactions are subjected to read-write set analysis in the TEE, and the non-private transactions are subjected to read-write set analysis outside the TEE, so that the multiple transactions can be grouped based on the read-write sets of all transactions while the private data of the private transactions are protected, the multiple transactions can be executed in parallel, and the transaction execution efficiency in the block chain system is improved.

Fig. 6 is an architecture diagram of a block link point in an embodiment of the present disclosure, where the block link point includes a trusted execution environment TEE, and the block link node further includes:

a receiving unit 61, configured to receive a plurality of transactions, where the plurality of transactions include non-private transactions and private transactions;

a first generating unit 62 to generate a read-write set of the non-private transactions outside of the TEE;

a second generating unit 63, configured to decrypt a ciphertext corresponding to the private transaction in the TEE, and generate a read-write set of the private transaction based on a plaintext obtained through decryption;

a grouping unit 64 configured to group the plurality of transactions within the TEE based on the read-write set of private transactions and the read-write set of non-private transactions.

In one embodiment, the first generating unit 62 is specifically configured to: for each transaction of the plurality of transactions, generating a read-write set of the non-private transaction outside the TEE if the transaction is determined to be a non-private transaction, the node further comprising:

a providing unit to provide a read-write set of all non-private transactions and all private transactions of the plurality of transactions into the TEE for grouping within the TEE.

In one embodiment, the read-write set for each transaction includes the name of the parameter requested to be read in the transaction and the name of the parameter requested to be written in the transaction.

In one embodiment, the ciphertext corresponding to the privacy transaction comprises ciphertext content included in the privacy transaction and/or ciphertext code of a privacy contract invoked by the privacy transaction.

In one embodiment, the TEE has stored therein a corresponding public key and private key, the ciphertext content and the ciphertext code generated by encrypting based on the public key,

the second generating unit is specifically configured to: the TEE decrypts the ciphertext content and/or the ciphertext code based on the private key.

In one embodiment, the node further comprises: and the execution unit is used for executing a plurality of transaction groups obtained by grouping in parallel, wherein when each transaction group is executed, the non-private transaction is executed outside the TEE, and the private transaction is executed in the TEE.

In one embodiment, the providing unit is further configured to: the TEE, after grouping the plurality of transactions, providing the grouping result information to an exterior of the TEE, determining the plurality of transaction groups based on the grouping result information at the exterior of the TEE;

the execution unit is specifically configured to: processing the plurality of transaction groups in parallel outside the TEE as follows: for n transactions in a transaction group, distributing non-private ones of the n transactions outside the TEE and private ones of the n transactions within the TEE.

In one embodiment, the providing unit is specifically configured to: the TEE provides the union of the packet results and the read-write set of all privacy transactions outside the TEE,

the execution unit is specifically configured to: reading values of the plurality of parameters based on keys of the plurality of parameters included in a read set of the read-write sets of the plurality of transactions, and storing the values of the plurality of parameters into a cache outside the TEE for executing the plurality of transactions.

In one embodiment, the privacy transaction includes a first privacy transaction, the first privacy transaction includes ciphertext content, and the execution unit is specifically configured to: the TEE decrypts the ciphertext content in the first privacy transaction to obtain a plaintext transaction, reads the value of a first parameter read by the plaintext transaction request from the exterior of the TEE, executes the plaintext transaction based on the value of the first parameter to obtain the value of a second parameter written by the plaintext transaction request, and provides the value of the second parameter to the exterior of the TEE to be stored in a cache outside the TEE.

In one embodiment, the privacy transaction includes a second privacy transaction, the second privacy transaction calls a privacy contract, and the execution unit is specifically configured to: the TEE reads a ciphertext code of the privacy contract from the exterior of the TEE, decrypts the ciphertext code to obtain a plaintext code, reads a value of a third parameter requested to be read by the plaintext code, executes the plaintext code based on the value of the third parameter to obtain a value of a fourth parameter requested to be written by the plaintext code, and stores the plaintext value of the fourth parameter in a cache in the TEE.

In one embodiment, the node further comprises: and the storage unit is used for acquiring the plaintext values of the parameters stored in the cache in the TEE after the TEE completes the execution of all the privacy transactions in the multiple transactions, respectively encrypting the plaintext values of the parameters to obtain ciphertext values of the parameters, and storing the ciphertext values of the parameters to the outside of the TEE.

In one embodiment, a first transaction of the plurality of transactions includes type information in clear text, the node further comprising: a determining unit, configured to determine whether the first transaction is a private transaction according to type information included in the first transaction.

In one embodiment, a second transaction of the multiple transactions includes plaintext type information, a plaintext first intelligent contract invoked by the second transaction includes type information of an invoked second intelligent contract, and the determining unit is specifically configured to: and determining whether the second transaction is a private transaction according to the type information included in the second transaction and the type information included in the first intelligent contract.

Embodiments of the present specification also provide a computer-readable storage medium on which a computer program is stored, which, when executed in a computer, causes the computer to perform the method shown in fig. 4 or fig. 5.

The embodiment of the present specification further provides a block link point, which includes a memory and a processor, where the memory stores executable code, and the processor executes the executable code to implement the method shown in fig. 4 or fig. 5.

In the 90's of the 20 th century, improvements to a technology could clearly distinguish between improvements in hardware (e.g., improvements to circuit structures such as diodes, transistors, switches, etc.) and improvements in software (improvements to process flow). However, as technology advances, many of today's process flow improvements have been seen as direct improvements in hardware circuit architecture. Designers almost always obtain the corresponding hardware circuit structure by programming an improved method flow into the hardware circuit. Thus, it cannot be said that an improvement in the process flow cannot be realized by hardware physical modules. For example, a Programmable Logic Device (PLD), such as a Field Programmable Gate Array (FPGA), is an integrated circuit whose Logic functions are determined by programming the Device by a user. A digital system is "integrated" on a PLD by the designer's own programming without requiring the chip manufacturer to design and fabricate application-specific integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing an Integrated Circuit chip, such Programming is often implemented by "logic compiler" software, which is similar to a software compiler used in program development and writing, but the original code before compiling is also written by a specific Programming Language, which is called Hardware Description Language (HDL), and HDL is not only one but many, such as ABEL (Advanced Boolean Expression Language), AHDL (alternate Hardware Description Language), traffic, CUPL (core universal Programming Language), HDCal, jhddl (Java Hardware Description Language), lava, lola, HDL, PALASM, rhyd (Hardware Description Language), and vhigh-Language (Hardware Description Language), which is currently used in most popular applications. It will also be apparent to those skilled in the art that hardware circuitry that implements the logical method flows can be readily obtained by merely slightly programming the method flows into an integrated circuit using 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, an Application Specific Integrated Circuit (ASIC), a programmable logic controller, and an embedded microcontroller, 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 for the memory. Those skilled in the art will also appreciate that, in addition to implementing the controller as pure computer readable program code, the same functionality can be implemented by logically programming method steps such that the controller is in the form of logic gates, switches, application specific integrated circuits, programmable logic controllers, embedded microcontrollers and the like. Such a controller may thus be considered a hardware component, and the means included therein for performing the various functions may also be considered as a structure within the hardware component. Or even means for performing the functions may be conceived to be both a software module implementing the method and a structure within a hardware component.

The systems, devices, modules or units illustrated in the above embodiments may be implemented by a computer chip or an entity, or by a product with certain functions. One typical implementation device is a server system. Of course, this application does not exclude that with future developments in computer technology, the computer implementing the functionality of the above described embodiments may be, for example, a personal computer, a laptop computer, a vehicle-mounted human-computer interaction device, a cellular 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 a combination of any of these devices.

Although one or more embodiments of the present description provide method operational steps as described in the embodiments or flowcharts, more or fewer operational steps may be included based on conventional or non-inventive approaches. The order of steps recited in the embodiments is merely one manner of performing the steps in a multitude of sequences, and does not represent a unique order of performance. When an actual apparatus or end product executes, it may execute sequentially or in parallel (e.g., parallel processors or multi-threaded environments, or even distributed data processing environments) according to the method shown in the embodiment or the figures. 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, the presence of additional identical or equivalent elements in processes, methods, articles, or apparatus that include the recited elements is not excluded. For example, if the terms first, second, etc. are used to denote names, they do not denote any particular order.

For convenience of description, the above devices are described as being divided into various modules by functions, and are described separately. Of course, when implementing one or more of the present description, the functions of each module may be implemented in one or more software and/or hardware, or the modules implementing the same functions may be implemented by a combination of a plurality of sub-modules or sub-units, etc. The above-described embodiments of the apparatus are merely illustrative, and for example, the division of the units is only one type of logical functional division, and other divisions may be realized in practice, for example, multiple units or components may be combined or integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, devices or units, and may be in an electrical, mechanical or other form.

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.

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 computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.

The memory may include forms of volatile memory in a computer readable medium, 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 a computer-readable medium.

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 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, compact disc read only memory (CD-ROM), digital Versatile Disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage, graphene storage or other magnetic storage devices, or any other non-transmission medium, which can be used to store information that can be accessed by a computing device. As defined herein, a computer readable medium does not include a transitory computer readable medium such as a modulated data signal and a carrier wave.

As will be appreciated by one skilled in the art, one or more embodiments of the present description may be provided as a method, system, or computer program product. Accordingly, one or more embodiments of the present description may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, one or more embodiments of the present description 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.

One or more embodiments of the specification 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. One or more embodiments of 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.

The embodiments in the present specification are described in a progressive manner, and the same and similar parts among the embodiments are referred to each other, and each embodiment focuses on the differences from the other embodiments. In particular, for the system embodiment, since it is substantially similar to the method embodiment, the description is simple, and for the relevant points, reference may be made to the partial description of the method embodiment. In the description of the specification, reference to the description of the term "one embodiment," "some embodiments," "an example," "a specific example," or "some examples," etc., means that a particular feature, structure, material, or characteristic described in connection with the embodiment or example is included in at least one embodiment or example of the specification. In this specification, the schematic representations of the terms used above are not necessarily intended to refer to the same embodiment or example. Furthermore, the particular features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples. Furthermore, various embodiments or examples and features of different embodiments or examples described in this specification can be combined and combined by one skilled in the art without contradiction.

The above description is merely exemplary of one or more embodiments of the present disclosure and is not intended to limit the scope of one or more embodiments of the present disclosure. Various modifications and alterations to one or more embodiments described herein will be apparent to those skilled in the art. Any modification, equivalent replacement, improvement or the like made within the spirit and principle of the present specification should be included in the scope of the claims.

Claims (16)

1. A transaction grouping method performed by a node in a blockchain system, the node including a trusted execution environment TEE therein, the method comprising:

receiving a plurality of transactions, including non-private transactions and private transactions;

generating a read-write set of the non-private transaction outside of the TEE;

the TEE decrypts the ciphertext corresponding to the private transaction and generates a read-write set of the private transaction based on the plaintext obtained through decryption;

grouping the plurality of transactions within the TEE based on the read-write set of private transactions and the read-write set of non-private transactions.

2. The method of claim 1, the generating the readwrite set of non-private transactions external to the TEE comprising: for each transaction of the plurality of transactions, in the event that the transaction is determined to be a non-private transaction, generating a read-write set of the non-private transaction outside of the TEE, the method further comprising:

providing a read-write set of all non-private transactions and all private transactions of the plurality of transactions into the TEE for grouping within the TEE.

3. The method of claim 1, wherein the read-write set for each transaction includes a name of a parameter requested to be read in the transaction and a name of a parameter requested to be written in the transaction.

4. The method of claim 3, the ciphertext corresponding to the privacy transaction comprising ciphertext content included in the privacy transaction and/or ciphertext code of a privacy contract invoked by the privacy transaction.

5. The method of claim 4, the TEE having stored therein a corresponding public key and private key, the ciphertext content and the ciphertext code generated by encrypting based on the public key,

the TEE decrypting the ciphertext corresponding to the private transaction comprises the following steps: the TEE decrypts the ciphertext content and/or the ciphertext code based on the private key.

6. The method of claim 4, further comprising: executing a plurality of transaction groups obtained by grouping in parallel, wherein the non-private transactions are executed outside the TEE and the private transactions are executed within the TEE while executing each transaction group.

7. The method of claim 6, further comprising: the TEE, after grouping the plurality of transactions, providing the grouping result information outside of the TEE, determining the plurality of transaction groups outside of the TEE based on the grouping result information;

the parallel execution of the plurality of transaction groups by grouping includes: performing the following in parallel for the plurality of transaction groups outside the TEE: for n transactions in a transaction group, distributing non-private ones of the n transactions outside the TEE and private ones of the n transactions within the TEE.

8. The method of claim 7, wherein the first and second light sources are selected from the group consisting of,

the TEE providing the packet result information outside of the TEE includes: the TEE generating a union of the read sets of the plurality of first privacy transactions based on the read sets of the plurality of first privacy transactions included in the first transaction group; the TEE provides the grouping result and the union outside the TEE,

the parallel execution of the plurality of transaction groups by grouping includes: reading values of the plurality of parameters based on the read sets of the respective non-private transactions in the first transaction group and keys of the plurality of parameters included in the union, storing the values of the plurality of parameters in a cache external to the TEE for use in executing transactions in the first transaction group.

9. The method of claim 7 or 8, the privacy transaction comprising a second privacy transaction comprising ciphertext content, the performing the privacy transaction within the TEE comprising: the TEE decrypts the ciphertext content in the second privacy transaction to obtain a plaintext transaction, reads the value of a first parameter read by the plaintext transaction request from the outside of the TEE, executes the plaintext transaction based on the value of the first parameter to obtain the value of a second parameter written by the plaintext transaction request, and provides the value of the second parameter to the outside of the TEE to be stored in a cache outside the TEE.

10. The method of claim 7 or 8, the privacy transaction comprising a third privacy transaction in which a privacy contract is invoked, the performing the privacy transaction within the TEE comprising: the TEE reads a ciphertext code of the privacy contract from the exterior of the TEE, decrypts the ciphertext code to obtain a plaintext code, reads a value of a third parameter requested to be read by the plaintext code, executes the plaintext code based on the value of the third parameter to obtain a value of a fourth parameter requested to be written by the plaintext code, and stores the plaintext value of the fourth parameter in a cache in the TEE.

11. The method of claim 10, further comprising: after the TEE completes execution of all privacy transactions in the multiple transactions, plaintext values of multiple parameters stored in a cache in the TEE are obtained, the plaintext values of the multiple parameters are encrypted respectively to obtain ciphertext values of the multiple parameters, and the ciphertext values of the multiple parameters are stored outside the TEE.

12. The method of claim 2, a first transaction of the plurality of transactions comprising plaintext type information, the method further comprising: determining whether the first transaction is a private transaction according to type information included in the first transaction.

13. The method of claim 12, wherein a second transaction of the plurality of transactions includes type information in clear text, wherein the second transaction invokes a clear text first smart contract that includes type information for an invoked second smart contract, the method further comprising: and determining whether the second transaction is a private transaction according to the type information included in the second transaction and the type information included in the first intelligent contract.

14. A block link point including a trusted execution environment, TEE, therein, the block link node further comprising:

the system comprises a receiving unit, a processing unit and a processing unit, wherein the receiving unit is used for receiving a plurality of transactions, and the plurality of transactions comprise non-privacy transactions and privacy transactions;

a first generating unit, configured to generate a read-write set of the non-private transaction outside the TEE;

the second generation unit is used for decrypting the ciphertext corresponding to the private transaction in the TEE and generating a read-write set of the private transaction based on the plaintext obtained through decryption;

a grouping unit to group the transactions within the TEE based on the read-write set of the private transaction and the read-write set of the non-private transaction.

15. A computer-readable storage medium, on which a computer program is stored which, when executed in a computer, causes the computer to carry out the method of any one of claims 1-12.

16. A block link point comprising a memory having stored therein executable code and a processor which, when executing the executable code, implements the method of any one of claims 1-12.

Images