Off-chain transaction protocol and transaction authentication method based on trusted execution environment

Abstract

The present invention belongs to the field of blockchain technology, specifically, an off-chain transaction protocol and transaction authentication method based on a trusted execution environment; the present invention designs a point-to-point off-chain transaction method to execute transactions off-chain; designs a transaction authentication method based on zk-SNARK; designs a management mechanism for off-chain digital assets based on a trusted execution environment. The present invention transfers on-chain transactions to off-chain execution, accumulates off-chain transactions and only writes the final results to the blockchain, thereby reducing transaction costs and transaction confirmation time.

Description

Technical Field

[0001] The present invention belongs to the technical field of blockchain, and specifically relates to an off-chain transaction protocol and a transaction authentication method based on a trusted execution environment. Background Art

[0002] The blockchain is composed of blocks, which record transaction information and the hash value of the previous block. In this way, each block is connected together to ensure that the information in the block cannot be tampered with. As a decentralized distributed ledger, everyone can maintain the ledger, so the blockchain needs a consensus mechanism to ensure the consistency of the ledger data. The consensus mechanisms currently widely used include POW, POS, DPOS, etc., which also means that users no longer need to trust additional third parties.

[0003] With the continuous development of blockchain technology, the technology has been widely used in various scenarios: for example, JD Zhizhen Chain provides users with the function of product traceability. All information of the entire process from production to sales of a product will be recorded on the blockchain. Users can view all information of the products they purchased to identify the quality, authenticity, etc. In addition, blockchain is also widely used in finance, medical and other scenarios.

[0004] Currently, blockchain platforms include Ethereum, Hyperledger Fabric, Polkadot, etc. Among them, Ethereum is the most popular as a representative of blockchain 2.0 because it supports Turing-complete smart contracts. Currently, there are about 2,900 applications based on Ethereum, and more than one million transactions need to be processed every day. However, with such a high transaction volume, the system throughput TPS of Ethereum is only 15.4, which cannot meet the needs of most users.

[0005] Improving transaction throughput can greatly reduce the time users have to wait for transaction confirmation and improve user experience, which is crucial to the development of blockchain. Therefore, how to improve blockchain transaction throughput is a very worthy issue to explore. Summary of the invention

[0006] In view of the deficiencies of the above-mentioned prior art, the present invention provides a peer-to-peer off-chain transaction method based on a trusted execution environment, which can solve the problem of slow on-chain transactions and long transaction times. At the same time, the trusted execution environment (TEE) divides the CPU into a trusted area through hardware isolation technology. The code in the trusted area can be executed correctly and can effectively prevent external attacks, providing security for off-chain digital asset transactions. Secondly, for light node users who entrust digital assets to trusted nodes for hosting, the present invention adopts a zk-SNARK (zero-knowledge proof) transaction authentication mechanism based on a trusted execution environment, which enables it to verify the node execution transaction situation, and improves the security of the zk-SNARK algorithm through a trusted execution environment.

[0007] The technical solution adopted by the present invention is specifically as follows.

[0008] The present invention provides an off-chain transaction protocol and transaction authentication method based on a trusted execution environment. The trusted execution environment (TEE) divides the CPU into a trusted area through hardware isolation technology. The code in the trusted area can be executed correctly and can effectively prevent external attacks. The specific steps are as follows:

[0009] 1. Generate a deposit agreement

[0010] When users use the off-chain transaction network, they need to transfer certain digital assets to the off-chain. The specific process of transferring assets is as follows: users need to execute a transaction on the blockchain and send the digital assets that need to be transferred to the off-chain to the specified address. After the transaction is successful, the user sends the transaction information to the trusted node, and the node will authenticate the transaction information. After the authentication is successful, a deposit ID will be generated in the trusted execution environment as the unique identifier of the off-chain deposit. Each deposit contains the following attributes:

[0011]

[0012] The signature sig generated by the deposit is used to verify the ownership of the deposit; the default initial value of the deposit state is True, which is used to confirm the current deposit status to prevent multiple transactions from being executed at the same time; the initial value of nonce is 0, and the nonce value increases by 1 for each transaction. The nonce value will be compared before the transaction to prevent double spending.

[0013] 2. Off-chain Transaction Protocol

[0014] When executing a transaction, the node first checks the current deposit state value to confirm that the deposit has not been modified to False after executing other transactions, ensuring that no other transactions will be executed concurrently with it during the transaction. At the same time, the current nonce value of the deposit is retained in the trusted execution environment. When executing a transaction and needing to modify the deposit balance, first determine whether the nonce value of the current deposit information is equal to the nonce value saved in the trusted execution environment. If they are equal, modify the balance and add 1 to the nonce value. When the transaction is completed, modify the deposit state to True again. The specific process of this method is shown in Algorithm 1.

[0015]

[0016] 3. Exit Mechanism

[0017] When a user exits the off-chain transaction network, the trusted execution environment will first verify the user's identity. After successful verification, the trusted execution environment will check whether the current deposit contains unfinished transactions. If there are no unfinished transactions, the trusted execution environment will obtain the current deposit balance and initiate a transaction to transfer the deposit to the blockchain account specified by the user. Since the process of closing a transaction is completely completed by the code logic in the trusted execution environment, users do not need to worry about the correctness of the transactions written into the blockchain.

[0018] The present invention further provides a transaction authentication method based on the above-mentioned off-chain transaction method, which is based on zk-SNARK transaction authentication, and the specific method is as follows:

[0019] After the user transfers the digital assets to the off-chain transaction network based on the trusted execution environment, a commitment will be generated for each deposit balance and the generated transaction, which is mainly used to authenticate the off-chain transaction. When the light node user sends a transaction authentication request, the node will generate authentication information through zk-SNARK and hand it over to the light node, which will verify the authentication information.

[0020] zk-SNARK is widely used in the blockchain field due to its zero-knowledge, non-interactive, and concise characteristics. This method can verify the authenticity of a transaction without revealing any useful information. The zk-SNARK algorithm is implemented in the off-chain transaction network based on the trusted execution environment, and some functions are protected by the trusted execution environment, which effectively improves the security of transaction authentication. The zk-SNARK algorithm based on the trusted execution environment TZ= (Gen, Setup, Prove, Verify) includes the following functions:

[0021] 1. Gen (1 λ)->pp: The preprocessing algorithm needs to input a randomly generated security parameter λ and return a public parameter list pp;

[0022] 2. Setup (C) -> (sp, sv): Generate an algorithm to process the digital operation circuit C and generate two sets of parameters SP and SV through the public parameter list pp. SP is sent to the prover for generating the proof, and SV is sent to the verifier for verifying the proof.

[0023] 3.Prove(sp,x,w)-> : Proof algorithm generates a short zero-knowledge proof , and sent to the verifier. The process of generating the proof requires the use of the SP generated in the generation algorithm, the public input x, and the private input w;

[0024] 4.Verify(sv,x,)->{0,1}: The verification algorithm verifies the received proof through the public input x and SV, and returns the verification result information.

[0025] In the zk-SNARK algorithm, if the pp public parameter list is leaked, the proof can be forged. This process needs to ensure the randomness of the security parameter λ, as well as the security of the public parameter list to prevent the leakage of verification information. Therefore, the Gen, Setup part will be implemented in a trusted execution environment. In addition, a private input w is required in the Prove process. In the transaction authentication process, w is the plaintext information of the user's transaction. Therefore, when generating the proof, the encryption processing process related to w is implemented in the trusted execution environment, and the Verify process only needs to verify the received proof, so there is no need to interact with the trusted execution environment.

[0026] The authentication of off-chain transactions by light nodes mainly includes the following three types:

[0027] Deposit generation authentication: After the user transfers the digital asset to the off-chain, a corresponding deposit will be generated. The user can send a request to verify whether the corresponding amount of off-chain digital assets has been generated. During the authentication process, the on-chain transaction TX will be used as a public input, and the deposit amount value, deposit nonce value, deposit status, and deposit signature will be used as private inputs. The circuit will compare the generated deposit amount and the transaction amount of the transferred asset to ensure the correctness of the off-chain deposit generation.

[0028] Transaction execution authentication: After the transaction is executed, the user can verify whether the transaction is executed successfully and whether the sent digital assets have arrived in the corresponding account. During the verification process, the light node must confirm the execution of the transaction and ensure that the transaction object is the payee in the sent transaction request. Secondly, it is also necessary to confirm whether the newly generated deposit balance is the current balance minus the transaction balance. Therefore, the public input generated by the transaction is the deposit ID, transaction execution information, current deposit information, and newly generated deposit information. The private input is the deposit plaintext balance, transaction amount, and payee.

[0029] Deposit release authentication: The user verifies whether a digital asset has been successfully transferred to the on-chain account specified by the user. When the user initiates a deposit release request, the node will obtain the deposit information data, and after verifying the deposit status in the trusted execution environment, write the plaintext balance and blockchain account public key into the contract and return the transaction information. Therefore, the public input required for the verification process is the deposit ID, the public key of the account that transfers the off-chain asset, the deposit information, and the on-chain transaction hash. The private input is the final balance of the off-chain deposit.

[0030] Compared with the prior art, the present invention has the following beneficial effects:

[0031] 1. The present invention transfers on-chain transactions to off-chain execution, accumulates multiple off-chain transactions, and writes the accumulated results to the blockchain, thereby reducing on-chain transaction fees and transaction confirmation time.

[0032] 2. The present invention entrusts digital assets to off-chain nodes for management, and completes transactions through secure communication between nodes. The digital assets managed by the nodes are provided with security protection by the trusted execution environment. The execution of transactions is completed in the trusted execution environment to ensure the security of transactions.

[0033] 3. The present invention hides off-chain transaction information to ensure user privacy and security. All transaction information is encrypted in a trusted execution environment to prevent malicious modification of transaction information and leakage of user data.

[0034] 4. The present invention provides a safe and reliable transaction authentication method. Any user can verify whether the transaction is correctly executed through the transaction authentication process. BRIEF DESCRIPTION OF THE DRAWINGS

[0035] Figure 1 It is a diagram of the off-chain transaction protocol architecture of the present invention.

[0036] Figure 2 FIG. 2 is a diagram illustrating the transaction authentication architecture of the present invention.

[0037] Figure 3 This is a diagram of embodiment 1 of the present invention.

[0038] Figure 4This is a diagram of Embodiment 2 of the present invention. DETAILED DESCRIPTION

[0039] The technical solution of the present invention is described in detail below in conjunction with the accompanying drawings and embodiments.

[0040] Figure 1 The diagram is a diagram of the off-chain transaction protocol architecture of the present invention. The off-chain transaction protocol contains three types of transactions: deposit generation, transaction execution, and deposit release. The deposit generation and deposit release processes interact with the blockchain through the on-chain contract, and the transaction execution process ensures the security of off-chain transactions through a trusted execution environment.

[0041] Figure 2 The transaction authentication architecture of the present invention is illustrated. During the transaction execution process, a certificate will be generated for the transaction at the same time. The user can send an authentication request to the node to obtain the transaction certificate for verification. In the off-chain transaction network, transaction authentication can be divided into three types: deposit generation authentication will verify the process of off-chain asset generation, transaction execution authentication can verify the transfer of off-chain digital assets, and deposit release authentication can verify the correctness of the released deposit amount.

[0042] Based on the off-chain transaction protocol and transaction authentication method introduced in this invention and the Ethereum platform, an off-chain trusted transaction platform is realized, providing users with a safe, free and decentralized off-chain transaction channel. The system is implemented using Python language and Django framework programming, and Solidity is used to write smart contracts to complete the interaction with Ethereum.

[0043] Example 1

[0044] like Figure 3 As shown in the figure, users can perform off-chain transactions in the off-chain trusted trading platform. The user enters the deposit ID for executing the transaction, the recipient's deposit ID, and the transaction amount. The node receives the transaction request and executes the transaction, modifying the deposit amounts of both parties. After the node successfully executes the transaction, it returns the detailed information of the user's transaction.

[0045] Example 2

[0046] like Figure 4 As shown, a light node user can send a request for authentication of a transaction to the node, and the node will return a proof of the transaction, which the user can verify through the proof.

Claims

1. An off-chain transaction method based on a trusted execution environment, characterized in that: The steps include: (1) Generate deposit Users use the off-chain transaction network to transfer certain digital assets to the off-chain and generate a deposit agreement. The specific process is as follows: The user executes a transaction on the blockchain and sends the digital assets that need to be transferred off-chain to the specified address. After the transaction is successful, the user sends the transaction information to the trusted node, and the node authenticates the transaction information. After the authentication is successful, a deposit ID is generated in the trusted execution environment as the unique identifier of the off-chain deposit. The attributes of each deposit include: value, depID, pubID, sig, state, nonce; among them: value represents the deposit balance, depID represents the deposit ID, and pubID represents the node convention; the signature sig generated by the deposit is used to verify the ownership of the deposit; the default initial value of the deposit state is True, which is used to confirm the current deposit status to prevent multiple transactions from being executed at the same time; nonce represents the number of transactions, and its initial value is 0. The nonce value increases by 1 for each transaction. The nonce value will be compared before the transaction to prevent double spending; (2) Execution of transactions When executing a transaction, the node first checks the current deposit state value to confirm that the deposit has not been modified to False after executing other transactions, ensuring that no other transactions will be executed concurrently with the transaction, and retaining the current nonce value of the deposit in the trusted execution environment; when executing a transaction and needing to modify the deposit balance, first determine whether the nonce value of the current deposit information is equal to the nonce value saved in the trusted execution environment. If they are equal, modify the balance and add 1 to the nonce value. When the transaction is completed, modify the deposit state to True again; (3) Exit off-chain transactions When a user exits the off-chain transaction network, the trusted execution environment first verifies the user's identity. After successful verification, the trusted execution environment checks whether the current deposit contains any unfinished transactions. If there are no unfinished transactions, the trusted execution environment will obtain the current deposit balance and initiate a transaction to transfer the deposit to the blockchain account specified by the user; the process of closing the transaction is completed by the code logic in the trusted execution environment.

2. A transaction authentication method based on the off-chain transaction method of claim 1, characterized in that: It uses a zk-SNARK-based transaction authentication method to authenticate off-chain transactions, as follows: After the user transfers the digital assets to the off-chain transaction network based on the trusted execution environment, a commitment is generated for each deposit balance and the generated transaction. The commitment is mainly used to authenticate the off-chain transaction. When the light node user sends a transaction authentication request, the node generates authentication information through zk-SNARK and gives it to the light node, which verifies the authentication information. Among them: The zk-SNARK algorithm TZ=(Gen, Setup, Prove, Verify) based on the trusted execution environment includes the following functions: 1) Gen(1 λ )->pp: The preprocessing algorithm returns a public parameter list pp by inputting a randomly generated security parameter λ; 2) Setup(C)->(SP,SV): The generation algorithm processes the digital operation circuit C and generates two sets of parameters SP and SV through the public parameter list pp. SP is sent to the prover for generating the proof, and SV is sent to the verifier for verifying the proof. 3) Prove(SP,x,w)->π: The proof algorithm generates a short zero-knowledge proof π and sends it to the verifier. The SP generated in the generation algorithm, the public input x, and the private input w are used in the process of generating the proof. 4) Verify(SV,x,π)->{0,1}: The verification algorithm verifies the received proof through the public input x and SV, and returns the verification result information; In the zk-SNARK algorithm, the randomness of the security parameter λ needs to be ensured to prevent the leakage of the pp public parameter list. Therefore, the contents of the Gen, Setup part will be implemented in a trusted execution environment. In addition, a private input w is required in the Prove process. In the transaction authentication process, w is the plaintext information of the user's transaction. Therefore, the encryption processing process related to w when generating the proof is implemented in a trusted execution environment. The authentication of off-chain transactions by light nodes mainly includes the following three types: Deposit generation authentication: After the user transfers the digital asset to the off-chain, a corresponding deposit will be generated. The user sends a request to verify whether the corresponding amount of off-chain digital assets has been generated. During the authentication process, the on-chain transaction TX will be used as the public input x, and the deposit amount value, deposit nonce value, deposit status, and deposit signature will be used as private input w. The digital operation circuit C compares the generated deposit amount and the transaction amount of the transferred asset to ensure the correctness of the off-chain deposit generation; Transaction execution authentication: After the transaction is executed, the user verifies whether the transaction is executed successfully and whether the sent digital assets have arrived in the corresponding account. During the verification process, the light node must confirm the execution of the transaction to ensure that the transaction object is the payee in the sent transaction request. Secondly, it is also necessary to confirm whether the newly generated deposit balance is the current balance minus the transaction balance. Therefore, the public input x generated by the transaction is the deposit ID, transaction execution information, current deposit information, and newly generated deposit information. The private input w is the plaintext balance of the deposit, transaction amount, and payee. Deposit release authentication: The user verifies whether a digital asset has been successfully transferred to the on-chain blockchain account specified by the user; when the user initiates a deposit release request, the node obtains the deposit information data, verifies the deposit status in the trusted execution environment, writes the plaintext balance and blockchain account public key into the contract, and returns the transaction information; therefore, the public input x required to verify the process is the deposit ID, the public key of the account that transfers the off-chain assets, the deposit information and the on-chain transaction hash, and the private input w is the final balance of the off-chain deposit.

Images