State channel dynamic trust assurance method and device based on TEE

Abstract

This application proposes a method and device for dynamic trust assurance of a state channel based on TEE, including the following steps: running multiple transaction nodes in a TEE environment, and deploying at least one TEE instance in each transaction node; when any transaction node requests to join the state channel as a node to be joined, the node to be joined sends an authorization request, and after success, the state information of the node to be joined is updated to the state channel smart contract; when any transaction node in the state channel requests to exit the state channel as a node to be exited, an exit request is sent to each transaction node, and after the exit request is passed, the node to be exited is removed from the state channel, and the state channel smart contract is updated. This solution runs multiple transaction nodes and deploys TEE instances in a TEE environment, and updates the transaction node status information in real time by opening the state channel and signing smart contracts, realizing a safe, reliable, flexible and standardized transaction process.

Description

Technical Field

[0001] The present application relates to the field of blockchain technology, and in particular to a data storage method, device, computer program product and computer program. Background Art

[0002] As a decentralized distributed ledger, blockchain technology is characterized by immutability, transparency, and anonymity. At the same time, in order to improve transaction throughput and reduce on-chain transaction costs, state channels are proposed as an off-chain expansion solution, enabling transaction participants to conduct multiple rounds of interactions outside the blockchain and submit them to the chain only after the final state is determined. However, the existing blockchain state channel technology still faces many challenges in terms of fault tolerance and state synchronization. Traditional state channels usually rely on each participating node to store transaction status locally. When the node is offline or fails, it may cause transaction interruption, state data loss, or consensus failure, which in turn affects the integrity and security of the system. Not only is the number of users supported limited, which limits its practicality in large-scale applications. At the same time, it also requires all participants to monitor the transaction status online at the same time and be prepared to deal with possible disputes. If a participant is uncooperative or offline, the channel may not be closed smoothly, thus affecting the final settlement of the transaction. With the increase in participants, the maintenance and management of state channels becomes more complicated. The existing scheme lacks an efficient distributed data storage and recovery mechanism, making it difficult to quickly restore the transaction status after a node failure, reducing the correctness and reliability of the system. In addition, security still depends on the private key management and signature verification process of the participants. If the private key is leaked or the signature verification mechanism is compromised, funds may be stolen or transactions may be tampered with. The state channel requires frequent synchronization of state data between participating nodes, while existing technologies mainly use simple broadcast or point-to-point synchronization mechanisms, which have problems such as high synchronization delay and low efficiency.

[0003] In order to solve the problem of state channel data synchronization, Chinese patent 201811270369.9 uses shared keys between nodes to verify transaction data, reduce reliance on asymmetric encryption calculations, and improve the efficiency of transaction data verification in the state channel. However, the trust issue between nodes is not fully considered, and there may be a risk of malicious nodes tampering with data. In addition, there is a lack of effective response strategies for node failures or data loss. Chinese invention patent 202211365055.3 proposes a blockchain node failure recovery method and blockchain system, which aims to detect node status, discover block lags and actively synchronize to improve the reliability and fault tolerance of the blockchain system. It mainly focuses on the state maintenance and recovery of blockchain nodes.

[0004] Moreover, in the traditional state channel design, participating nodes are usually unable to join or exit at any time, which will lead to a lack of flexibility, low resource utilization and system robustness, and will also affect the security of state data. Chinese invention patent 202410589887.6 provides a chain-based secure and trusted collaborative computing method and device combined with a trusted execution environment (TEE, Trusted Execution Environment), so that the chain data is stored in a confidential state, and when necessary, it is processed through smart contracts and TEE collaboration to avoid unnecessary privacy leakage when sharing blockchain ledgers, while ensuring trusted collaboration of off-chain devices. It can be seen that the collaboration between TEE and blockchain state channels is a method that is more conducive to state synchronization and trusted computing, but it cannot solve the problems of inflexible and delayed state channel fund management. Summary of the invention

[0005] The embodiment of the present application provides a TEE-based state channel dynamic trust assurance method and device, which runs multiple transaction nodes and deploys TEE instances in a TEE environment, updates the transaction node status information in real time by opening a state channel and signing a smart contract, performs TEE trusted verification, authorization request processing, and state information calculation and judgment when the transaction node joins and exits the state channel, and at the same time, different numbers of TEE instances have a reasonable division of labor and parity check to ensure data security, and use remote authentication for identity authentication, thereby achieving a safe, reliable, flexible and standardized transaction process.

[0006] In a first aspect, an embodiment of the present application provides a state channel dynamic trust assurance method based on TEE, the method comprising:

[0007] Run multiple transaction nodes in the TEE environment, and deploy at least one TEE instance in each transaction node. Multiple transaction nodes open state channels and sign state channel smart contracts. The state channel smart contract defines the state information and transaction rules of each transaction node, and updates the state information of each transaction node in real time according to the transaction situation during the transaction process, wherein the state information includes the balance and transaction record of the transaction node;

[0008] When any transaction node requests to join the state channel as a node to be joined, TEE trusted verification is performed on the node to be joined. After the TEE trusted verification is passed, the node to be joined sends an authorization request to each transaction node in the state channel. When the first number of transaction nodes pass the authorization request, the node to be joined is added to the state channel, and the state information of the node to be joined is updated to the state channel smart contract; when any transaction node in the state channel requests to exit the state channel as a node to be exited, the state information of the node to be exited is broadcast to each transaction node in the state channel, and an exit request is sent to each transaction node. Each transaction node in the state channel performs TEE calculation on the state information of the node to be exited, and passes / rejects the exit request based on the TEE calculation result. When the first number of transaction nodes pass the exit request, the node to be exited is removed from the state channel, and the state channel smart contract is updated.

[0009] In a second aspect, an embodiment of the present application provides a state channel dynamic trust assurance device based on TEE, including:

[0010] A deployment module is used to run multiple transaction nodes in a TEE environment and deploy at least one TEE instance in each transaction node. Multiple transaction nodes open a state channel and sign a state channel smart contract. The state channel smart contract defines the state information and transaction rules of each transaction node, and updates the state information of each transaction node in real time according to the transaction situation during the transaction process, wherein the state information includes the balance and transaction record of the transaction node;

[0011] Trust assurance module, when any transaction node requests to join the state channel as a node to be joined, TEE trusted verification is performed on the node to be joined. After the TEE trusted verification is passed, the node to be joined sends an authorization request to each transaction node in the state channel. When the first number of transaction nodes pass the authorization request, the node to be joined is added to the state channel, and the state information of the node to be joined is updated to the state channel smart contract; when any transaction node in the state channel requests to exit the state channel as a node to be exited, the state information of the node to be exited is broadcast to each transaction node in the state channel, and an exit request is sent to each transaction node. Each transaction node in the state channel performs TEE calculation on the state information of the node to be exited, and passes / rejects the exit request based on the TEE calculation result. When the first number of transaction nodes pass the exit request, the node to be exited is removed from the state channel, and the state channel smart contract is updated.

[0012] In a third aspect, an embodiment of the present application provides an electronic device, comprising a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to execute a state channel dynamic trust assurance method based on TEE.

[0013] In a fourth aspect, an embodiment of the present application provides a readable storage medium, in which a computer program is stored. The computer program includes a program code for controlling a process to execute a process, and the process includes a state channel dynamic trust assurance method based on TEE.

[0014] The main contributions and innovations of the present invention are as follows:

[0015] The embodiment of the present application runs multiple transaction nodes and deploys TEE instances in a TEE environment. By opening a status channel and signing a smart contract, the transaction node status information and transaction rules are defined and updated in real time. It can not only perform TEE trustworthy verification on the nodes to be added, but also join the status channel according to the process and update relevant information. It can also properly handle the situation of the nodes to be exited to ensure reasonable changes in the status channel. The TEE instance can be responsible for executing transaction tasks. Different numbers of TEE instances have corresponding reasonable division of labor. When there are multiple main TEE instances, there is also a parity check TEE instance to ensure data security. After the status channel is opened, the remote authentication mechanism is used to verify the credibility of the transaction node TEE environment and allocate relevant keys and identifiers for identity authentication to achieve overall orderly operation. The entire solution ensures the security and reliability of the transaction process and the standardization and flexibility of transaction node management from many aspects.

[0016] Details of one or more embodiments of the present application are set forth in the following drawings and description to make other features, objects, and advantages of the present application more readily apparent. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:

[0018] Figure 1 It is a flow chart of a state channel dynamic trust assurance method based on TEE according to an embodiment of the present application;

[0019] Figure 2 It is a structural block diagram of a state channel dynamic trust assurance device based on TEE according to an embodiment of the present application;

[0020] Figure 3 It is a schematic diagram of the hardware structure of an electronic device according to an embodiment of the present application. DETAILED DESCRIPTION

[0021] Exemplary embodiments will be described in detail herein, examples of which are shown in the accompanying drawings. When the following description refers to the drawings, the same numbers in different drawings represent the same or similar elements unless otherwise indicated. The implementations described in the following exemplary embodiments do not represent all implementations consistent with one or more embodiments of this specification. Instead, they are merely examples of devices and methods consistent with some aspects of one or more embodiments of this specification as detailed in the appended claims.

[0022] It should be noted that: in other embodiments, the steps of the corresponding method are not necessarily performed in the order shown and described in this specification. In some other embodiments, the steps included in the method may be more or less than those described in this specification. In addition, a single step described in this specification may be decomposed into multiple steps for description in other embodiments; and multiple steps described in this specification may be combined into a single step for description in other embodiments.

[0023] Embodiment 1

[0024] The embodiment of the present application provides a dynamic trust assurance method for a state channel based on TEE. In the TEE environment, multiple transaction nodes are run and TEE instances are deployed. The transaction node status information is updated in real time by opening a state channel and signing a smart contract. TEE trusted verification, authorization request processing, and state information calculation and judgment are performed when the transaction node joins and exits the state channel. At the same time, different numbers of TEE instances are reasonably divided into different tasks and have parity checks to ensure data security. Remote authentication is also used for identity authentication, thereby realizing a safe, reliable, flexible and standardized transaction process. Specifically, refer to Figure 1 , the method comprising:

[0025] Run multiple transaction nodes in the TEE environment, and deploy at least one TEE instance in each transaction node. Multiple transaction nodes open state channels and sign state channel smart contracts. The state channel smart contract defines the state information and transaction rules of each transaction node, and updates the state information of each transaction node in real time according to the transaction situation during the transaction process, wherein the state information includes the balance and transaction record of the transaction node;

[0026] When any transaction node requests to join the state channel as a node to be joined, TEE trusted verification is performed on the node to be joined. After the TEE trusted verification is passed, the node to be joined sends an authorization request to each transaction node in the state channel. When the first number of transaction nodes pass the authorization request, the node to be joined is added to the state channel, and the state information of the node to be joined is updated to the state channel smart contract; when any transaction node in the state channel requests to exit the state channel as a node to be exited, the state information of the node to be exited is broadcast to each transaction node in the state channel, and an exit request is sent to each transaction node. Each transaction node in the state channel performs TEE calculation on the state information of the node to be exited, and passes / rejects the exit request based on the TEE calculation result. When the first number of transaction nodes pass the exit request, the node to be exited is removed from the state channel, and the state channel smart contract is updated.

[0027] In some specific embodiments, in the state channel, nodes are usually divided into transaction nodes, proxy nodes, and supervision nodes according to their roles and tasks. In this solution, all nodes are run in a TEE environment to ensure that the logic and data of the state update run in an isolated trusted environment.

[0028] In some embodiments, the TEE instance is responsible for executing transaction tasks of the corresponding transaction node, and the transaction tasks include transaction calculation, signature verification, and smart contract calling.

[0029] Specifically, using TEE instances to execute transaction tasks can ensure that the transaction process is carried out in a relatively isolated and trusted environment, effectively preventing external malicious attacks, data tampering, etc., and ensuring the security and reliability of transactions.

[0030] In some specific embodiments, when the number of TEE instances of a transaction node is one, the TEE instance is responsible for executing all transaction tasks of the corresponding transaction node.

[0031] For example, let's assume that a small online retail company uses a TEE instance for its transaction node. The daily transaction scale of the company is relatively small, processing transaction calculations for hundreds of orders, verifying customer signatures, and calling smart contracts to complete tasks such as inventory deductions and payment docking. This unique TEE instance is responsible for all these transaction tasks, ensuring that each transaction is completed in a secure and reliable environment. The company does not have to worry about transaction data being leaked or transaction processes being maliciously interfered with, and the system management is relatively simple and the cost is low.

[0032] In some specific implementations, when the number of TEE instances of a transaction node is two, the two TEE instances are respectively used as the main TEE instance and the secondary TEE instance, where the main TEE instance is responsible for executing all transaction tasks of the corresponding transaction node, and the secondary TEE instance synchronizes and stores the transaction task information executed by the main TEE.

[0033] For example, a medium-sized financial services company has two TEE instances configured in its transaction node. In daily transfers, financial transactions and other businesses, the main TEE instance is responsible for executing transaction tasks such as calculating transaction amounts, verifying user transfer signatures, and calling related smart contracts such as financial purchases. The secondary TEE instance synchronizes and stores the transaction task information executed by the main TEE, such as recording the detailed calculation process of each transfer, verifying the results of the signature, etc. Once, the server where the main TEE instance is located experienced a brief network fluctuation, which affected the real-time viewing of the execution of some transactions. Through the information stored in the secondary TEE instance, the transaction task execution status at that time can be quickly restored, ensuring the normal operation of the business, and also facilitating subsequent compliance operations such as audits.

[0034] In some specific embodiments, when the number of TEE instances of a transaction node is more than two, any one of the TEE instances is selected as a secondary TEE instance, and the remaining TEE instances are all primary TEE instances. Multiple primary TEE instances execute transaction tasks of the corresponding transaction nodes, and the secondary TEE instances synchronize and store the transaction task information executed by each primary TEE.

[0035] Furthermore, when there are multiple main TEE instances, each main TEE instance exclusively occupies CPU cores and memory resources, and allocates CPU cores and memory resources to the secondary TEE instances based on the number of main TEE instances.

[0036] Take a large digital currency trading platform as an example. Its transactions are frequent and the transaction tasks are complex. The transaction node is configured with multiple (for example, 5) TEE instances. Among them, 4 are main TEE instances, each of which has exclusive CPU cores and memory resources, and performs a large number of digital currency transaction calculations, verifies the signatures of buyers and sellers, and calls smart contracts to complete transaction matching, fund transfers and other transaction tasks. The remaining 1 is a secondary TEE instance, which is reasonably allocated with corresponding CPU cores and memory resources based on the number of main TEE instances, and synchronizes and stores the transaction task information executed by each main TEE instance. When the platform's business volume grows significantly during the bull market, it can easily add a few more main TEE instances to cope with the increasing volume of transaction tasks, ensuring the safe, stable and efficient operation of the entire trading platform, and the secondary TEE instance can provide complete transaction task backup information at any time, which is convenient for regulatory authorities to check and the platform itself to troubleshoot problems. It is worth mentioning that the transactions of "digital currency" and "funds" mentioned in this plan are limited to legal purposes and do not include transactions of virtual currency.

[0037] Specifically, by reasonably allocating hardware resources to multiple main TEE instances, the efficient operation of the main TEE instances is ensured, while supporting dynamic resource allocation to apply different load requirements.

[0038] Furthermore, when there are multiple main TEE instances in a transaction node, a first parity TEE instance and a second parity TEE instance are additionally established in the transaction node, and the status information of the transaction node is split into multiple status information fragments, and one status information fragment is stored in each main TEE instance, wherein the first parity TEE instance is used to detect whether the status information fragment in each main TEE instance has changed, and the second parity TEE instance is used to perform data recovery when the status information fragment has changed.

[0039] Specifically, in the first parity check TEE instance, an XOR operation is performed on the status information fragments in each main TEE instance, and in the second parity check instance, a Galois field generator is used to perform Galois field multiplication with the status information fragments in each main TEE instance to obtain a Galois field value, and then an XOR operation is performed on the Galois field values ​​corresponding to each main TEE instance.

[0040] For example, assume that transaction node N 1 Divide the state S into k parts S→{S 1 , S 2 , S 3 , S 4} (k = 4), stored in 6 TEEs, TEE 1 Storage 1 、TEE2 Storage 2 、TEE 3 Storage 3 、TEE 4 Storage 4 、TEE 5 Store the first parity check Parity → )、TEE 6 For the first parity TEE instance, TEE 7 For the second parity TEE instance Parity → ).

[0041] in, is a generator in the Galois field, and · represents Galois field multiplication.

[0042] Specifically, the following example illustrates the data recovery through the Galois field:

[0043] When a TEE (such as TEE 2 ) is damaged, the node calculates and recovers S 2 : ,TEE 2 After coming back online, restore S from TEE 2 , and synchronize the latest status information.

[0044] When two data blocks S i and S j Lost (i, j ≤ 4), can be recovered by the following steps:

[0045] 1) Read the remaining data blocks and parity blocks.

[0046] 2) Construct a system of equations.

[0047]

[0048]

[0049] 3) Solve the system of equations. Use linear algebra methods (such as matrix inversion) to solve the system of equations and get the missing data block S i and S j . Write the above equations in matrix form:

[0050]

[0051] Simplified to: , where A is the coefficient matrix, X is the unknown variable, and B is the constant variable.

[0052] 4) Find the inverse matrix. Calculate the determinant of the coefficient matrix A:

[0053]

[0054] If det(A) ≠ 0, then A is invertible and the inverse matrix is:

[0055]

[0056] 5) Solve for the unknown variable. Calculate X = A by matrix multiplication -1 B, get S i and S j .

[0057]

[0058] In some specific embodiments, when multiple transaction nodes need to conduct frequent transactions with each other, a state channel is opened through negotiation among the multiple transaction nodes, and a state channel smart contract is created and deployed by the multiple transaction nodes on the blockchain platform, a certain amount of funds are deposited and locked into the state channel smart contract, and the initial state of the state channel is defined in the state channel smart contract, which is the initial balance, transaction record and configuration parameters of the state channel of each transaction node when the state channel smart contract is created. The state channel smart contract is jointly signed and confirmed by all participating transaction nodes and will be stored in the protection area of ​​the TEE environment.

[0059] In some specific embodiments, after the state channel is opened and the state channel smart contract is signed, a remote authentication mechanism is used to verify the credibility of the TEE environment of each transaction node in the state channel. When the credibility verification of all transaction nodes in the state channel is passed, a private key, a public key and a unique identity are assigned to each transaction node. Each transaction node connects its own public key and unique identity to calculate a hash value, and uploads the hash value to the blockchain. Each transaction node authenticates each other through the hash value.

[0060] Specifically, this solution uses a remote authentication mechanism to verify the credibility of the TEE environment of each transaction node, ensuring that transactions are conducted in a secure and isolated computing environment. In other words, only transaction nodes in the state channel that have passed credibility verification can participate in transactions, reducing the risk of malicious nodes mixing into the state channel, disrupting transaction order, or stealing information from the source.

[0061] Specifically, each transaction node is assigned a public-private key pair and a unique identity, and the hash value is calculated by connecting the public key and the identity and uploaded to the blockchain for identity authentication, which increases the complexity and security of identity authentication. The public-private key pair is based on the principle of asymmetric encryption. The private key is kept privately by the node and the public key is made public. The node signs with the private key, and other nodes verify the signature with the public key. This method is difficult to forge. The hash value, as a compact and difficult to reverse derivation information summary, further ensures the secure storage and verification of identity information on the blockchain, and ensures that every transaction node in the state channel is a trusted participant.

[0062] In some embodiments, during the transaction execution phase, each transaction node uses a private key to sign to confirm the transaction. After confirming the transaction, the node updates its own state information and broadcasts it to the transaction nodes in the state channel.

[0063] Furthermore, since the channel state of the state channel records the status information of each transaction node, when a transaction node broadcasts its own status information to other transaction nodes in the state channel, the channel state of the state channel is also updated accordingly.

[0064] Specifically, during a multi-party transaction, a transaction node updates its own status information by using a private key signature and broadcasts it to the transaction nodes in the status channel to ensure that the status of all transaction nodes remains synchronized.

[0065] In some specific embodiments, when any transaction node requests to join the state channel as a node to be joined, the node to be joined generates a remote attestation containing a measurement value of the evidence, and sends the remote attestation to all transaction nodes in the state channel. Each transaction node in the state channel verifies the signature, hash value and security version in the remote attestation through the Intel remote attestation service and returns a verification report, thereby completing the TEE trusted verification of the node to be joined, ensuring that the node to be joined has not been tampered with and the operating environment is trusted.

[0066] Specifically, when the TEE trust verification of the node to be joined fails, the node to be joined is refused to join the state channel.

[0067] When the TEE trusted verification of the node to be added passes, the node to be added needs to obtain the status information of each transaction node in the state channel to conduct transactions. Therefore, the state channel generates a public-private key pair through a threshold key sharing protocol. The public-private key pair stores the status information of each transaction node in the state channel. The public key is shared by all transaction nodes, and the private key is divided into multiple key fragments. The number of key fragments is the same as the transaction node data in the state channel, and each transaction node stores a key fragment. When the transaction node in the state channel receives the authorization request, if the authorization request is signed with the corresponding key fragment and returned to the node to be added, it is deemed to have passed the authorization request. If the authorization request is not signed, it is deemed to have failed the authorization request. When the first number of transaction nodes pass the authorization request, that is, when the nodes to be added collect the first number of key fragments, threshold signature aggregation is performed to generate a complete private key from the first number of key fragments, and the private key is verified by the public key. When the verification passes, the node to be added is added to the state channel.

[0068] Specifically, this solution divides the private key into multiple key fragments, and each transaction node only holds one key fragment. Even if the key fragment of a node is leaked, the attacker cannot obtain the complete private key, and thus cannot forge signatures or perform illegal operations. This significantly reduces the risk of the entire system being attacked due to a single point of private key leakage, and enhances the security of the state channel.

[0069] Specifically, in this solution, as long as a sufficient number (the first number) of transaction nodes work normally and pass the authorization request, the node to be joined can successfully join the state channel. Even if some nodes fail, go offline, or refuse to sign, it will not affect the entire joining process, ensuring that the system can still operate normally in the event of some node abnormalities, thereby improving the reliability and fault tolerance of the system.

[0070] In some specific embodiments, when the node to be exited submits an exit request, a hash calculation is performed using the current state information of the node to be exited and the current channel state of the state channel to obtain an exit hash value, and the exit hash value is signed using the private key of the node to be exited. The exit hash value is then broadcast to each transaction node in the state channel, wherein the current channel state of the state channel is the state information of each transaction node in the current state channel recorded by the node to be exited.

[0071] When the transaction node in the state channel receives the exit request and the exit hash value, it verifies the private key of the exit hash value. After the verification, it approves / rejects the exit request based on the TEE calculation result. That is to say, it determines whether there is any discrepancy between the transaction information recorded by the node to be exited and its own transaction information through TEE calculation. If there is no problem with the records of both parties and the transaction node subjectively allows the node to be exited to exit, the exit request is approved, otherwise the exit request is rejected.

[0072] If a first number of transaction nodes pass the exit request, the status information of the nodes to be exited is removed from the channel status, and the state channel smart contract is updated.

[0073] Specifically, in this solution, the node to be exited uses its current state information and the current channel state of the state channel to perform hash calculation to obtain the exit hash value, and then signs it with the private key. Hash calculation can convert complex state information into a hash value of fixed length. Once the original information changes, the hash value will be completely different. The private key signature ensures that the exit request is indeed issued by the node to be exited and has not been tampered with during the transmission process. After receiving the exit request and the exit hash value, other transaction nodes verify the private key. If the verification is successful, the authenticity and integrity of the information can be confirmed, effectively preventing malicious nodes from forging exit requests or tampering with transaction information.

[0074] Specifically, during the entire exit process of the node to be exited, all information (such as exit request, hash value, signature, verification result, etc.) can be recorded. This makes it easy to audit and trace when problems or disputes arise. By reviewing these records, you can clearly understand every link of the exit process, clarify the responsibility, and ensure the fairness and transparency of the system.

[0075] Embodiment 2

[0076] Based on the same idea, refer to Figure 2 , the present application also proposes a state channel dynamic trust assurance device based on TEE, including:

[0077] A deployment module is used to run multiple transaction nodes in a TEE environment and deploy at least one TEE instance in each transaction node. Multiple transaction nodes open a state channel and sign a state channel smart contract. The state channel smart contract defines the state information and transaction rules of each transaction node, and updates the state information of each transaction node in real time according to the transaction situation during the transaction process, wherein the state information includes the balance and transaction record of the transaction node;

[0078] Trust assurance module, when any transaction node requests to join the state channel as a node to be joined, TEE trusted verification is performed on the node to be joined. After the TEE trusted verification is passed, the node to be joined sends an authorization request to each transaction node in the state channel. When the first number of transaction nodes pass the authorization request, the node to be joined is added to the state channel, and the state information of the node to be joined is updated to the state channel smart contract; when any transaction node in the state channel requests to exit the state channel as a node to be exited, the state information of the node to be exited is broadcast to each transaction node in the state channel, and an exit request is sent to each transaction node. Each transaction node in the state channel performs TEE calculation on the state information of the node to be exited, and passes / rejects the exit request based on the TEE calculation result. When the first number of transaction nodes pass the exit request, the node to be exited is removed from the state channel, and the state channel smart contract is updated.

[0079] Embodiment 3

[0080] This embodiment also provides an electronic device, referring to Figure 3 , comprises a memory 404 and a processor 402, wherein the memory 404 stores a computer program, and the processor 402 is configured to run the computer program to execute the steps in any of the above method embodiments.

[0081] Specifically, the processor 402 may include a central processing unit (CPU), or an application specific integrated circuit (ASIC), or may be configured to implement one or more integrated circuits of the embodiments of the present application.

[0082] Among them, the memory 404 may include a large capacity memory 404 for data or instructions. For example, but not limitation, the memory 404 may include a hard disk drive (HDD), a floppy disk drive, a solid state drive (SSD), a flash memory, an optical disk, a magneto-optical disk, a tape, or a universal serial bus (USB) drive, or a combination of two or more of these. In appropriate cases, the memory 404 may include a removable or non-removable (or fixed) medium. In appropriate cases, the memory 404 may be inside or outside the data processing device. In a specific embodiment, the memory 404 is a non-volatile memory. In a specific embodiment, the memory 404 includes a read-only memory (ROM) and a random access memory (RAM). Where appropriate, the ROM may be a mask-programmed ROM, a programmable ROM (Programmable Read-Only Memory, PROM for short), an erasable PROM (Erasable Programmable Read-Only Memory, EPROM for short), an electrically erasable PROM (Electrically Erasable Programmable Read-Only Memory, EEPROM for short), an electrically alterable ROM (Electrically Alterable Read-Only Memory, EAROM for short) or a flash memory (FLASH) or a combination of two or more of these. In appropriate circumstances, the RAM may be a static random access memory (SRAM) or a dynamic random access memory (DRAM), wherein the DRAM may be a fast page mode dynamic random access memory 404 (FPMDRAM), an extended data output dynamic random access memory (EDODRAM), a synchronous dynamic random access memory (SDRAM), etc.

[0083] The memory 404 may be used to store or cache various data files required for processing and / or communication, as well as possible computer program instructions executed by the processor 402 .

[0084] The processor 402 implements any one of the TEE-based state channel dynamic trust assurance methods in the above embodiments by reading and executing computer program instructions stored in the memory 404.

[0085] Optionally, the electronic device may further include a transmission device 406 and an input / output device 408 , wherein the transmission device 406 is connected to the processor 402 , and the input / output device 408 is connected to the processor 402 .

[0086] The transmission device 406 can be used to receive or send data via a network. Specific examples of the above-mentioned network may include a wired or wireless network provided by a communication provider of the electronic device. In one example, the transmission device includes a network adapter (Network Interface Controller, referred to as NIC), which can be connected to other network devices through a base station so as to communicate with the Internet. In one example, the transmission device 406 can be a radio frequency (Radio Frequency, referred to as RF) module, which is used to communicate with the Internet wirelessly.

[0087] The input and output device 408 is used to input or output information. In this embodiment, the input information may be the status information of the transaction node, the channel smart contract, etc., and the output information may be the updated channel smart contract.

[0088] Optionally, in this embodiment, the processor 402 may be configured to perform the following steps through a computer program:

[0089] Run multiple transaction nodes in the TEE environment, and deploy at least one TEE instance in each transaction node. Multiple transaction nodes open state channels and sign state channel smart contracts. The state channel smart contract defines the state information and transaction rules of each transaction node, and updates the state information of each transaction node in real time according to the transaction situation during the transaction process, wherein the state information includes the balance and transaction record of the transaction node;

[0090] When any transaction node requests to join the state channel as a node to be joined, TEE trusted verification is performed on the node to be joined. After the TEE trusted verification is passed, the node to be joined sends an authorization request to each transaction node in the state channel. When the first number of transaction nodes pass the authorization request, the node to be joined is added to the state channel, and the state information of the node to be joined is updated to the state channel smart contract; when any transaction node in the state channel requests to exit the state channel as a node to be exited, the state information of the node to be exited is broadcast to each transaction node in the state channel, and an exit request is sent to each transaction node. Each transaction node in the state channel performs TEE calculation on the state information of the node to be exited, and passes / rejects the exit request based on the TEE calculation result. When the first number of transaction nodes pass the exit request, the node to be exited is removed from the state channel, and the state channel smart contract is updated.

[0091] It should be noted that the specific examples in this embodiment can refer to the examples described in the above embodiments and optional implementation modes, and this embodiment will not be described in detail here.

[0092] In general, various embodiments may be implemented in hardware or dedicated circuits, software, logic, or any combination thereof. Some aspects of the invention may be implemented in hardware, while other aspects may be implemented in firmware or software that may be executed by a controller, microprocessor, or other computing device, but the invention is not limited thereto. Although various aspects of the invention may be shown and described as block diagrams, flow charts, or using some other graphical representation, it should be understood that, as non-limiting examples, the boxes, devices, systems, techniques, or methods described herein may be implemented in hardware, software, firmware, dedicated circuits or logic, general-purpose hardware or controllers or other computing devices, or some combination thereof.

[0093] Embodiments of the present invention may be implemented by computer software that is executable by a data processor of a mobile device, such as in a processor entity, or by hardware, or by a combination of software and hardware. Computer software or programs (also referred to as program products) including software routines, applets and / or macros may be stored in any device-readable data storage medium, and they include program instructions for performing specific tasks. A computer program product may include one or more computer executable components configured to perform an embodiment when the program is run. One or more computer executable components may be at least one software code or a portion thereof. In addition, at this point, it should be noted that, for example, Figure 3Any block of the logic flow in the program may represent program steps, or interconnected logic circuits, blocks and functions, or a combination of program steps and logic circuits, blocks and functions. The software may be stored on physical media such as memory chips or storage blocks implemented within a processor, magnetic media such as hard disks or floppy disks, and optical media such as, for example, DVDs and their data variants, CDs, etc. Physical media are non-transitory media.

[0094] Those skilled in the art should understand that the technical features of the above embodiments may be arbitrarily combined. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0095] The above embodiments only express several implementation methods of the present application, and the descriptions thereof are relatively specific and detailed, but they cannot be understood as limiting the scope of the present application. It should be pointed out that, for a person of ordinary skill in the art, several variations and improvements can be made without departing from the concept of the present application, and these all belong to the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the attached claims.

Claims

1. A state channel dynamic trust assurance method based on TEE, characterized in that: The following steps are involved: Run multiple transaction nodes in the TEE environment, and deploy at least one TEE instance in each transaction node. Multiple transaction nodes open state channels and sign state channel smart contracts. The state channel smart contract defines the state information and transaction rules of each transaction node, and updates the state information of each transaction node in real time according to the transaction situation during the transaction process, wherein the state information includes the balance and transaction record of the transaction node; When any transaction node requests to join the state channel as a node to be joined, TEE trusted verification is performed on the node to be joined. After the TEE trusted verification is passed, the node to be joined sends an authorization request to each transaction node in the state channel. When the first number of transaction nodes pass the authorization request, the node to be joined is added to the state channel, and the state information of the node to be joined is updated to the state channel smart contract; when any transaction node in the state channel requests to exit the state channel as a node to be exited, the state information of the node to be exited is broadcast to each transaction node in the state channel, and an exit request is sent to each transaction node. Each transaction node in the state channel performs TEE calculation on the state information of the node to be exited, and passes / rejects the exit request based on the TEE calculation result. When the first number of transaction nodes pass the exit request, the node to be exited is removed from the state channel, and the state channel smart contract is updated.

2. According to a TEE-based state channel dynamic trust assurance method according to claim 1, it is characterized in that: The TEE instance is responsible for executing the transaction tasks of the corresponding transaction node, which include transaction calculation, signature verification and smart contract calling.

3. According to a TEE-based state channel dynamic trust assurance method according to claim 1, it is characterized in that: When the number of TEE instances of a transaction node is one, the TEE instance is responsible for executing all transaction tasks of the corresponding transaction node.

4. According to a TEE-based state channel dynamic trust assurance method according to claim 1, it is characterized in that: When the number of TEE instances of a transaction node is two, the two TEE instances are used as the main TEE instance and the secondary TEE instance respectively. The main TEE instance is responsible for executing all transaction tasks of the corresponding transaction node, and the secondary TEE instance synchronizes and stores the transaction task information executed by the main TEE.

5. According to a TEE-based state channel dynamic trust assurance method according to claim 1, it is characterized in that: When there are more than two TEE instances in a transaction node, any one TEE instance is selected as the secondary TEE instance, and the remaining TEE instances are all primary TEE instances. Multiple primary TEE instances execute transaction tasks of the corresponding transaction nodes, and the secondary TEE instances synchronize and store the transaction task information executed by each primary TEE.

6. A TEE-based state channel dynamic trust assurance method according to claim 5, characterized in that: When there are multiple main TEE instances in a transaction node, a first parity TEE instance and a second parity TEE instance are additionally established in the transaction node, and the status information of the transaction node is split into multiple status information fragments, and one status information fragment is stored in each main TEE instance, wherein the first parity TEE instance is used to detect whether the status information fragment in each main TEE instance has changed, and the second parity TEE instance is used to perform data recovery when the status information fragment has changed.

7. A TEE-based state channel dynamic trust assurance method according to claim 1, characterized in that: After the state channel is opened and the state channel smart contract is signed, the remote authentication mechanism is used to verify the credibility of the TEE environment of each transaction node in the state channel. When the credibility verification of all transaction nodes in the state channel is passed, a private key, public key and unique identity are assigned to each transaction node. Each transaction node connects its own public key and unique identity to calculate the hash value, and uploads the hash value to the blockchain. Each transaction node authenticates each other through the hash value.

8. A state channel dynamic trust assurance device based on TEE, characterized in that: include: A deployment module is used to run multiple transaction nodes in a TEE environment and deploy at least one TEE instance in each transaction node. Multiple transaction nodes open a state channel and sign a state channel smart contract. The state channel smart contract defines the state information and transaction rules of each transaction node, and updates the state information of each transaction node in real time according to the transaction situation during the transaction process, wherein the state information includes the balance and transaction record of the transaction node; Trust assurance module, when any transaction node requests to join the state channel as a node to be joined, TEE trusted verification is performed on the node to be joined. After the TEE trusted verification is passed, the node to be joined sends an authorization request to each transaction node in the state channel. When the first number of transaction nodes pass the authorization request, the node to be joined is added to the state channel, and the state information of the node to be joined is updated to the state channel smart contract; when any transaction node in the state channel requests to exit the state channel as a node to be exited, the state information of the node to be exited is broadcast to each transaction node in the state channel, and an exit request is sent to each transaction node. Each transaction node in the state channel performs TEE calculation on the state information of the node to be exited, and passes / rejects the exit request based on the TEE calculation result. When the first number of transaction nodes pass the exit request, the node to be exited is removed from the state channel, and the state channel smart contract is updated.

9. An electronic device comprising a memory and a processor, characterized in that: A computer program is stored in the memory, and the processor is configured to run the computer program to execute a state channel dynamic trust assurance method based on TEE as described in any one of claims 1-7.

10. A readable storage medium, characterized in that: The readable storage medium stores a computer program, which includes a program code for controlling a process so that the process is executed by a processor, and the process includes a state channel dynamic trust assurance method based on TEE as described in any one of claims 1-7.

Images