Blockchain off-chain transaction method, device and equipment and storage medium

Abstract

This invention discloses a method, apparatus, device, and storage medium for off-chain blockchain transactions, belonging to the field of blockchain technology. The method includes: after receiving a transaction request from a user node, broadcasting the transaction request to the consensus node group, so that the first secure enclave of the current consensus node leader receives the transaction request, generates a new block according to the transaction request, and synchronizes the new block to all the consensus nodes; updating the account information corresponding to the user node, and feeding back the transaction result to the user node, thus completing the off-chain transaction. This invention performs off-chain blockchain transactions within the consensus nodes, utilizing the trusted execution environment provided by the secure enclaves within the consensus nodes to isolate the running programs within the consensus nodes from the external environment, processing and sending / receiving transaction information within the secure enclaves, thereby ensuring the security of off-chain transactions.

Description

Technical Field

[0001] This invention relates to the field of blockchain technology, and in particular to a blockchain off-chain transaction method, apparatus, device, and storage medium. Background Technology

[0002] The relevant technologies require both parties to the transaction to continuously monitor the blockchain and promptly detect abnormal information such as expired transactions to ensure the security of the transaction.

[0003] However, due to the low storage and connectivity of most IoT devices, it is difficult for them to detect abnormal information in a timely manner and to take timely countermeasures, thus making it difficult to guarantee the security of off-chain transactions. Summary of the Invention

[0004] The main objective of this invention is to provide a blockchain off-chain transaction method, apparatus, device, and storage medium, aiming to solve the technical problem that it is difficult to guarantee the security of blockchain off-chain transactions in the prior art.

[0005] According to a first aspect of the present invention, a blockchain off-chain transaction method is provided for a secure enclave of any consensus node in a consensus node group within an off-chain service blockchain, wherein the secure enclave has account information for each user node in an external blockchain; the method includes:

[0006] After receiving a transaction request from a user node, the transaction request is broadcast to the consensus node group so that the first secure enclave of the current consensus node leader receives the transaction request, generates a new block according to the transaction request, and synchronizes the new block to all the consensus nodes.

[0007] Update the account information corresponding to the user node and send the transaction result back to the user node to complete the off-chain transaction.

[0008] Optionally, before broadcasting the transaction request to the consensus node group, the method further includes:

[0009] Verify the transaction request;

[0010] If the transaction request passes verification, the smart contract contained in the transaction request is invoked, the transaction data processing logic declared by the smart contract is executed, and the data information of the transaction request is obtained.

[0011] The broadcasting of the transaction request to the consensus node group includes:

[0012] The transaction request and the data information are broadcast to the consensus node group.

[0013] Optionally, after receiving a transaction request from a user node and before broadcasting the transaction request to the consensus node group, the method further includes:

[0014] After receiving the deposit request sent by the user node, an external blockchain address corresponding to the user node is generated;

[0015] The external blockchain address is sent to the user node so that the user can use the external blockchain address as the account address to make a deposit and generate a corresponding deposit record.

[0016] The betting record is broadcast to the consensus node group so that the current consensus node leader adds the betting record as a new block to the off-chain service blockchain.

[0017] Optionally, after receiving the deposit request sent by the user node and before generating an external blockchain address, the method further includes:

[0018] After receiving the registration request sent by the user node, the corresponding registration information is obtained according to the registration request; the registration information includes the public and private key pair of the corresponding user node account information and the secure enclave signature;

[0019] The registration information is verified. If the public-private key pair does not duplicate the public-private key pair of the account information of other user nodes, and the secure enclave signature is correct, then the corresponding registration record is generated.

[0020] The registration record is broadcast to the consensus node group so that the current consensus node leader adds the registration record as a new block to the off-chain service blockchain.

[0021] Optionally, after broadcasting the deposit record to the consensus node group so that the current consensus node leader adds the deposit record as a new block to the off-chain service blockchain, the method further includes:

[0022] Read the deposit records from the off-chain service blockchain;

[0023] Update the account balance of the corresponding account based on the deposit record;

[0024] If the account balance reaches a preset balance threshold, the corresponding account will be registered to the emergency settlement platform;

[0025] If an emergency settlement request is received from the corresponding user node, the emergency settlement platform is activated so that the user can transfer funds out through the emergency settlement platform.

[0026] Optionally, broadcasting the transaction request to the consensus node group after receiving the transaction request from the user node includes:

[0027] The transaction request is encrypted using a symmetric key to obtain encrypted transaction information; the symmetric key is generated by the current consensus node leader.

[0028] The encrypted transaction information is broadcast to the consensus node group.

[0029] Optionally, the consensus node serves the corresponding transaction channel. After updating the account information corresponding to the user node using the secure enclave and feeding back the transaction result to the user node to complete the off-chain transaction, the method further includes:

[0030] After receiving a settlement request from the payer's user node, the corresponding transaction information, the payee's user node, and at least one transaction channel are determined based on the settlement request.

[0031] The funds are sent to the payee user node through at least one of the transaction channels, so that the payee user node updates the account balance of the payee account according to the transaction information and sends back transaction confirmation information.

[0032] The transaction confirmation information is sent to the payer user node through at least one of the transaction channels, so that the payer user node updates the account balance of the payer's account based on the transaction confirmation information and the transaction information.

[0033] According to a second aspect of the present invention, a blockchain off-chain transaction device is provided, the device comprising:

[0034] The request receiving module is used to broadcast the transaction request to the consensus node group after receiving the transaction request sent by the user node, so that the first secure enclave of the current consensus node leader can receive the transaction request, generate a new block according to the transaction request, and synchronize the new block to all the consensus nodes.

[0035] The transaction completion module is used to update the account information corresponding to the user node using the secure enclave, and to feed back the transaction result to the user node to complete the off-chain transaction.

[0036] According to a third aspect of the present invention, a blockchain off-chain transaction device is provided, comprising: a memory, a processor, and a blockchain off-chain transaction program stored in the memory and executable on the processor, wherein the blockchain off-chain transaction program, when executed by the processor, implements the steps described in any possible implementation of the first aspect.

[0037] According to a fourth aspect of the present invention, a computer-readable storage medium is provided having a blockchain off-chain transaction program stored thereon, wherein the blockchain off-chain transaction program, when executed by a processor, implements the steps described in any possible implementation of the first aspect.

[0038] This invention proposes a blockchain off-chain transaction method, apparatus, device, and storage medium. After receiving a transaction request from a user node, the blockchain off-chain transaction device broadcasts the transaction request to the consensus node group. Upon receiving the transaction request, the first secure enclave of the current consensus node leader generates a new block based on the transaction request and synchronizes the new block to all consensus nodes. The device also updates the account information corresponding to the user node and feeds back the transaction result to the user node, thus completing the off-chain transaction.

[0039] This invention addresses the need for transactions outside the blockchain by using an external consensus node to execute them. This consensus node utilizes trusted hardware technology to provide a trusted execution environment—a secure enclave—based on processor hardware. Transactions are conducted within this secure enclave. This invention differs from existing technologies that struggle to guarantee the security of off-chain blockchain transactions. By conducting off-chain transactions within a consensus node and utilizing the trusted execution environment provided by the secure enclave, the invention isolates the running program within the consensus node from the external environment. Transaction information processing and transmission are performed within the secure enclave, thus ensuring the security of off-chain transactions. Attached Figure Description

[0040] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0041] Figure 1 This is a schematic diagram of the structure of the off-chain blockchain transaction device in the hardware operating environment involved in the embodiments of the present invention;

[0042] Figure 2 This is a flowchart illustrating the first embodiment of the blockchain off-chain transaction method of the present invention;

[0043] Figure 3 For the present invention Figure 2 A flowchart illustrating the steps preceding S201;

[0044] Figure 4 For the present invention Figure 2 A flowchart illustrating the steps preceding S201;

[0045] Figure 5 For the present invention Figure 4 A flowchart illustrating the steps preceding those in S401;

[0046] Figure 6 For the present invention Figure 4 A flowchart illustrating the steps following S403;

[0047] Figure 7 For the present invention Figure 2 A detailed flowchart illustrating the steps in S201;

[0048] Figure 8 For the present invention Figure 2 A flowchart illustrating the steps following S202;

[0049] Figure 9 This is a schematic diagram of the functional modules of the blockchain off-chain transaction device involved in an embodiment of the present invention.

[0050] The realization of the objective, functional features and advantages of the present invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0051] It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.

[0052] The main solution of this invention is as follows: after receiving a transaction request sent by a user node, the transaction request is broadcast to the consensus node group so that the first secure enclave of the current consensus node leader receives the transaction request, generates a new block according to the transaction request, and synchronizes the new block to all the consensus nodes; the account information corresponding to the user node is updated, and the transaction result is fed back to the user node to complete the off-chain transaction.

[0053] Related technologies require both parties to a transaction to continuously monitor the blockchain and promptly detect abnormal information such as expired transactions to ensure transaction security. However, due to the low storage and connectivity of most IoT devices, it is difficult for them to detect abnormal information in a timely manner and take timely countermeasures, thus making it difficult to guarantee the security of off-chain transactions.

[0054] This invention provides a solution for off-chain blockchain transaction devices. When transactions need to be conducted outside the blockchain, they are executed through an external consensus node. This consensus node utilizes trusted hardware technology to provide a trusted execution environment based on processor hardware, i.e., a secure enclave, for transactions. This invention differs from existing technologies that struggle to guarantee the security of off-chain blockchain transactions. By conducting off-chain transactions within the consensus node and utilizing the trusted execution environment provided by the secure enclave, the running program within the consensus node is isolated from the external environment. Transaction information processing and transmission are performed within the secure enclave, thus ensuring the security of off-chain transactions.

[0055] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0056] The terms "first" and "second" in the specification and claims of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such terms can be interchanged where appropriate so that the embodiments described herein can be implemented in orders other than those illustrated or described herein.

[0057] Reference Figure 1 , Figure 1 This is a schematic diagram of the structure of the off-chain blockchain transaction device in the hardware operating environment involved in the embodiments of the present invention.

[0058] like Figure 1As shown, the off-chain transaction device of the blockchain may include: a processor 1001, such as a central processing unit (CPU), a communication bus 1002, a user interface 1003, a network interface 1004, and a memory 1005. The communication bus 1002 is used to enable communication between these components. The user interface 1003 may include a display screen or an input unit such as a keyboard; optionally, the user interface 1003 may also include a standard wired interface or a wireless interface. The network interface 1004 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface). The memory 1005 may be high-speed random access memory (RAM) or stable non-volatile memory (NVM), such as a disk storage device. Optionally, the memory 1005 may also be a storage device independent of the aforementioned processor 1001.

[0059] Those skilled in the art will understand that Figure 1 The structure shown does not constitute a limitation on off-chain transaction devices for blockchains and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0060] like Figure 1 As shown, the memory 1005, which serves as a storage medium, may include an operating system, a request receiving module, a transaction completion module, and a blockchain off-chain transaction program.

[0061] exist Figure 1 In the blockchain off-chain transaction device shown, the network interface 1004 is mainly used for data communication with the network server; the user interface 1003 is mainly used for data interaction with the user; the processor 1001 and the memory 1005 in the blockchain off-chain transaction device of the present invention can be set in the blockchain off-chain transaction device. The blockchain off-chain transaction device calls the blockchain off-chain transaction program stored in the memory 1005 through the processor 1001 and executes the blockchain off-chain transaction method provided in the embodiment of the present invention.

[0062] Based on, but not limited to, the above hardware structure, this invention provides a first embodiment of a blockchain off-chain transaction method. (Refer to...) Figure 2 , Figure 2 This is a flowchart illustrating the first embodiment of the blockchain off-chain transaction method of the present invention.

[0063] In this embodiment, the method includes:

[0064] Step S201: After receiving a transaction request sent by a user node, broadcast the transaction request to the consensus node group so that the first secure enclave of the current consensus node leader receives the transaction request, generates a new block according to the transaction request, and synchronizes the new block to all the consensus nodes.

[0065] In this embodiment, the execution entity is a secure enclave of any consensus node in the consensus node group of the off-chain service blockchain. When a user needs to conduct a transaction, the user can generate a transaction request through their corresponding user node and send the transaction request to any one or more consensus node secure enclaves via a secure channel. The transaction request includes at least the sender ID (sender Pk_c), the receiver ID (receiver Pk_c), the transaction sequence number (sender nonce), and the sender signature Sk_c(sender Pk_c, receiver Pk_c, nonce). The transaction sequence number identifies which off-chain transaction the sender has initiated, and its purpose is to prevent malicious consensus nodes from replaying user transactions and causing losses to the user. It should be noted that if the transaction request invokes a smart contract, it also includes the corresponding smart contract information.

[0066] When any consensus node receives the transaction request, it broadcasts the transaction request to all consensus node enclaves. When the first enclave of the current consensus node leader receives the transaction request, it generates a new block in the user operation log based on the transaction request, and uses the improved RAFT algorithm to synchronize the new block to all consensus nodes, while updating the user operation log.

[0067] To address the weak fault tolerance of the RAFT algorithm, this embodiment uses a trusted incrementing counter provided by the Intel service platform (SGX) to prevent malicious consensus nodes from performing Byzantine behavior (i.e., nodes can only stop responding, not make erroneous responses). Whenever the leader node in the RAFT algorithm generates a new block in its safe enclave, it first selects a predetermined number of transactions from the transaction pool and arranges them in order. Then, it increments the non-rollback incrementing counter by 1, and finally reads the incremented counter and embeds the result into the block header. The user operation log block header between the consensus node safe enclaves contains the block height, the block transaction hash, and the aforementioned trusted monotonic counter. Since all consensus nodes use SGX to run the consensus algorithm, the only way for a malicious consensus node to perform Byzantine behavior is to create two blocks with the same height but containing different transactions by rolling back the SGX. However, due to the existence of the trusted counter, assuming a malicious leader node embeds a separate counter when assembling the first block in its safe enclave, when it rolls back the SGX and assembles the second block of the same height, it can only embed the counter + 1 into the second block. After receiving a block, other consensus node enclaves can detect whether the leader node has maliciously rolled back by checking if the monotonic count is continuous. When a consensus node enclave loses its leader position, it resets its counter to zero, and the new leader generates a new monotonic counter and restarts the process. Furthermore, based on this mechanism, the current upper limit of the SGX monotonic counter can support the leader node's incrementing operation in this invention for approximately 1-2 days. Changing the leader every 1-2 days is easily implemented, therefore this invention does not suffer from the count exhaustion problem seen in some other schemes using SGX monotonic counters.

[0068] Finally, it should be noted that the consensus node group in this embodiment is composed of third-party components based on SGX technology. SGX provides a trusted execution environment based on processor hardware, isolating the application execution environment in the trusted hardware from the external environment, thus forming a secure enclave and ensuring the security of subsequent operations. User nodes can be user terminal devices such as IoT devices. Smart contracts can be understood as a set of contract terms that automatically execute corresponding operations when a preset condition is triggered. Raft is a consensus algorithm that ensures that each node in the cluster agrees on a series of identical state transitions. SGX is a trusted hardware technology that provides a trusted execution environment. In addition, the consensus node leader, i.e., the leader node, is randomly selected from all consensus nodes using a random number generation algorithm.

[0069] In one specific implementation, refer to Figure 7 , Figure 7 For the present invention Figure 2A detailed flowchart of steps S201 is provided, showing that after receiving a transaction request from a user node, broadcasting the transaction request to the consensus node group includes:

[0070] Step A10: Encrypt the transaction request using a symmetric key to obtain encrypted transaction information;

[0071] Upon receiving a transaction request, the corresponding consensus node's secure enclave will encrypt the request using a symmetric key to obtain encrypted transaction information. This symmetric key is randomly generated within the current consensus node leader's secure enclave and then encrypted and transmitted to all other consensus node secure enclaves via a secure channel.

[0072] Step A20: Broadcast the encrypted transaction information to the consensus node group.

[0073] After receiving the aforementioned encrypted transaction information, the consensus node broadcasts this encrypted transaction information to other consensus nodes, thereby ensuring the security of information transmission. Specifically, upon receiving a new transaction, a consensus node first checks whether the transaction is already in the transaction pool, then checks whether the transaction has been included in the user operation log by comparing the transaction count sequence number, and finally writes the new transaction that has not yet been recorded in the user operation log and does not duplicate transactions in the transaction pool into the transaction pool. The transaction pool stores all prior transactions and can be used to store new transactions.

[0074] Step S202: Update the account information corresponding to the user node and send the transaction result back to the user node to complete the off-chain transaction.

[0075] When a consensus node secure enclave receives a new block from the leader node, it first decrypts the block using a symmetric key, then verifies (1) the correctness of the hash in the block header and (2) the continuity of the monotonically increasing count. If the new block passes verification, it sends the block height to each light node through a secure channel with the user node, synchronizes the complete encrypted block to the storage node, and begins to sequentially verify the legality of transactions, and sequentially updates the user account balance and user transaction sequence number, thereby completing the off-chain transaction update. A transaction is considered legal if and only if (1) the user's account balance is sufficient to support the transaction and (2) the contract called by the transaction, the read / write set, and the records in the consensus node's local database do not conflict. After verifying the transaction, the consensus node secure enclave signs the transaction execution result with the secure enclave's private key and sends it to the user associated with the transaction. The transaction execution result includes the complete transaction content and identification information used to identify whether the transaction is valid. Storage nodes are user nodes that maintain the current balance of all participants in the channel, while light nodes are user nodes that only store the height of off-chain transaction blocks. Users can choose according to their own needs.

[0076] In this embodiment, off-chain transactions are conducted within the consensus nodes of the blockchain. By utilizing the trusted execution environment provided by the secure enclave within the consensus nodes, the running programs within the consensus nodes are isolated from the external environment. Transaction information processing and transmission are carried out within the secure enclave, ensuring the security of off-chain transactions. Furthermore, the improved RAFT algorithm is used to prevent the influence of malicious nodes, symmetric keys are used to prevent information encryption, and verification is used to ensure the accuracy and legality of all information, further guaranteeing the security of off-chain transactions.

[0077] Furthermore, refer to Figure 3 , Figure 3 For the present invention Figure 2 The flowchart before step S201 shows that, before broadcasting the transaction request to the consensus node group, the method further includes:

[0078] Step S301: Verify the transaction request;

[0079] Upon receiving the aforementioned transaction request, the corresponding consensus node security enclave will first verify (1) the correctness of the signature in the transaction request and (2) the validity of the transaction sequence number in the transaction request. For a transaction request that passes verification, the consensus node security enclave will remove the signature from the transaction request and transform it into a designed off-chain transaction. The reason for removing the signature is that subsequent operations no longer need to verify the correctness of the signature, thereby significantly accelerating the transaction verification speed.

[0080] Step S302: If the transaction request passes verification, the smart contract contained in the transaction request is invoked to execute the transaction data processing logic declared by the smart contract and obtain the data information of the transaction request.

[0081] If a transaction request includes a smart contract, the consensus node's secure enclave will simulate the contract call process based on the contract parameters in its local database, obtain the contract call result, generate a corresponding read-write set, and write the read-write set and the simulated execution result into the transaction. Since the pre-execution of the contract call is completed by the secure enclave in this embodiment, any consensus node's secure enclave is sufficient to endorse the validity of the contract execution result. Furthermore, by adopting a "execute first, then sort" contract call method, a single smart contract state transition only requires execution by one consensus node's secure enclave, thereby significantly improving the efficiency of contract execution.

[0082] Finally, the transaction request, contract execution result, and read / write set are broadcast together. The read / write set includes data related to the transaction request.

[0083] In this embodiment, on the one hand, the correctness and legality of the transaction request are ensured by verifying the transaction request; on the other hand, the subsequent verification speed is accelerated by removing the signature from the transaction request to avoid subsequent repeated verification; in addition, the smart contract contained in the transaction request can be executed efficiently, thereby ensuring the smooth execution of the transaction.

[0084] Furthermore, refer to Figure 4 , Figure 4 For the present invention Figure 2 The flowchart preceding step S201 shows that, after receiving a transaction request from a user node and before broadcasting the transaction request to the consensus node group, the method further includes:

[0085] Step S401: After receiving the deposit request sent by the user node, generate the external blockchain address corresponding to the user node;

[0086] It's easy to understand that each user node's account needs sufficient funds to complete a transaction smoothly. Therefore, users must deposit funds into their accounts before conducting a transaction.

[0087] When a user needs to inject funds, they first send a deposit request to the consensus node's secure enclave through the corresponding user node. Upon receiving the deposit request, the consensus node's secure enclave generates an external blockchain address and its corresponding private key, and then encrypts the external blockchain address, the corresponding private key, and the user's identity information using a symmetric key.

[0088] Step S402: Send the external blockchain address to the user node so that the user can use the external blockchain address as the account address to make a deposit and generate a corresponding deposit record;

[0089] The external blockchain address obtained above is sent to the corresponding user node, and the user can use this address to make a deposit. At the same time, a deposit record is generated based on the encrypted external blockchain address, the corresponding private key, and the user's identity information.

[0090] Step S403: Broadcast the deposit record to the consensus node group so that the current consensus node leader adds the deposit record as a new block to the off-chain service blockchain.

[0091] The aforementioned deposit record is broadcast to all consensus nodes. Upon receiving the deposit record, the current consensus node leader will generate a new block based on it and record it in the user's operation log. All consensus nodes can independently verify the record and update the corresponding user's account balance accordingly.

[0092] In this embodiment, the deposit address and other information are generated through the secure enclave of the consensus node, and the deposit record is generated and sent and received. Finally, the account is updated to complete the deposit. The trusted execution environment of the secure enclave ensures the security of the deposit.

[0093] Furthermore, refer to Figure 5 , Figure 5 For the present invention Figure 4 A flowchart illustrating steps prior to S401, where, after receiving the deposit request from the user node and before generating an external blockchain address, the method further includes:

[0094] Step S501: After receiving the registration request sent by the user node, obtain the corresponding registration information according to the registration request;

[0095] It's easy to understand that whether you're making a deposit or a transaction, you first need an account. Therefore, users need to register before making a deposit.

[0096] Specifically, when a user needs to register, the user node first creates a public-private key pair (Pk_c, Sk_c) for identifying the user and establishing a secure channel, and a public-private key pair (Pk_e, Sk_e) for emergency settlement. Then, Pk_c, Pk_e, the emergency settlement address, and voting platform metadata signed with Sk_e in a secure enclave are sent to any consensus node's secure enclave as a registration request. Upon receiving the registration request, the consensus node obtains this registration information.

[0097] Step S502: Verify the registration information. If the public-private key pair does not duplicate the public-private key pair of the account information of other user nodes, and the secure enclave signature is correct, then generate the corresponding registration record.

[0098] After obtaining the above registration information, the corresponding consensus node security enclave verifies (1) whether Pk_c and Pk_e are duplicates of other registered accounts, and (2) whether the voting platform metadata and the signature of the user's emergency settlement security enclave are correct. If the user's registration application passes the security enclave verification, the security enclave generates a registration record that will be written to the user's operation log, containing Pk_c and Pk_e. Pk_c will be used as the user's account identifier by all consensus node security enclaves, while Pk_e will be read by the user's emergency settlement security enclave during the user's emergency settlement to verify whether the corresponding account has the qualification for emergency settlement. The emergency settlement address records the output address of the emergency settlement transaction.

[0099] Step S503: Broadcast the registration record to the consensus node group so that the current consensus node leader adds the registration record as a new block to the off-chain service blockchain.

[0100] Subsequently, this consensus node's secure enclave will broadcast this registration record to other consensus node secure enclaves via a secure channel. Upon receiving this record, the current consensus node leader will generate a new block and write it to the user operation log. This new block will then be broadcast to all consensus nodes. All consensus nodes that read the new block will add Pk_c and Pk_e to the user account set maintained within their secure enclave and set the account balance to 0.

[0101] Ultimately, the consensus node security enclave that receives the user's registration request will be responsible for sending a registration success message to the user. However, at this point, the user's account balance is still 0, so they have no need for emergency settlement and therefore do not need to use the emergency settlement security enclave to perform any operations, and do not need to register on the emergency settlement platform for the time being.

[0102] In this embodiment, after a user registers, the corresponding consensus node verifies the relevant registration information. After verification, the registration record is sent and received, a new block is generated, and the user's operation log is updated. This ensures the correctness of the newly registered information and prevents it from duplicating with other account information, ensuring the smooth operation of subsequent operations. Furthermore, the trusted execution environment of the secure enclave ensures that the registration information is not leaked, thus guaranteeing security.

[0103] Furthermore, refer to Figure 6 , Figure 6 For the present invention Figure 4 The flowchart following step S403 illustrates that, after broadcasting the deposit record to the consensus node group so that the current consensus node leader adds the deposit record as a new block to the off-chain service blockchain, the method further includes:

[0104] Step S601: Read the deposit records in the off-chain service blockchain;

[0105] Step S602: Update the account balance of the corresponding account according to the deposit record;

[0106] The deposit record contains the corresponding user and the amount of funds injected. The corresponding account can be identified based on the account information, and then the account balance can be updated based on the amount of funds injected.

[0107] Step S603: If the account balance reaches a preset balance threshold, the corresponding account will be registered to the emergency settlement platform.

[0108] When an account's balance first reaches a predefined threshold (through a funding transaction or transfers from other participants), the user can interact with the consensus node's security enclave using their own emergency settlement security enclave. This allows them to obtain and store a symmetric key used to encrypt user activity logs via a secure channel. The threshold is set to prevent attackers from launching Sybil attacks on the voting platform by creating a large number of low-balance accounts. Simultaneously, the leader node in the consensus network is responsible for registering the user's emergency settlement security enclave's public key Pk_e to the emergency settlement voting platform when the user's balance exceeds the threshold, and for deleting the user's public key from the emergency settlement platform when the user's balance is below the threshold.

[0109] Step S604: If an emergency settlement request is received from the corresponding user node, the emergency settlement platform is activated so that the user can transfer funds out through the emergency settlement platform.

[0110] If a user fails to receive updates to their user operation logs from any consensus node's secure enclave for an extended period, they have reason to suspect that the consensus node is no longer providing reliable service and therefore need to initiate an emergency settlement operation. First, the user initiates their own emergency settlement secure enclave through their corresponding user node, synchronizing all user operation logs, restoring the latest account state set for the channel, and the private keys corresponding to all external blockchain addresses controlled by the consensus node. If the user node is a storage node, it can directly instruct the emergency settlement secure enclave to read the encrypted blocks; if the user node is a light node, it needs to obtain the complete user operation logs from the storage node.

[0111] After restoring the latest set of user accounts using the emergency settlement enclave, users can use the emergency settlement enclave to vote on the final state of the channel on the voting platform based on the final block height it reads. The voting information is signed using the user's emergency settlement enclave's private key Pk_e and includes the final height of the channel user operation log read by the enclave. If more than half of the users vote on the same block height using their respective enclaves, anyone can call the contract function to change the voting platform's state from invalid to disputed, modify the channel's final block height parameter, and initiate a predefined dispute period. Since the failure of more than half of the consensus nodes is a low-probability event, the dispute period can be set to a relatively long time interval (e.g., 2 weeks) to reduce user monitoring overhead without affecting normal user operation. It is important to note that before the dispute period begins (i.e., when the channel state is invalid), users must sign their votes using their own emergency settlement enclaves for the vote to be considered valid.

[0112] If no user challenges the final state of the channel during the dispute period, any user can call the contract function to change the voting platform state to valid. If a user submits a higher block height to challenge the final state of the channel, the voting platform state reverts to invalid, and the final channel height is changed accordingly. Only when the voting platform state is valid can the user input evidence of the valid state, along with the final block height parameter of the channel, into the emergency settlement voting platform to generate an emergency settlement transaction. After confirming that the voting platform state is valid, the user's emergency settlement security enclave immediately generates an emergency settlement transaction, transferring the funds due to the user from the address controlled by the consensus node's security enclave to the user's own address, and returning the balance to the secure address controlled by the consensus node's security enclave, where the user's emergency settlement enclave holds the user's private key.

[0113] Compared with existing off-chain payment solutions (such as Plasma), this invention provides users with ultimate security in the emergency settlement process after a consensus node fails. That is, users do not need to go on-chain for an emergency settlement transaction within a specified time to retrieve their funds; the emergency settlement transaction can be generated at any time.

[0114] It is worth noting that the selection of emergency settlement transaction inputs is determined by deterministic calculations based on the channel's final state and the user's emergency settlement address. This prevents users from creating multiple emergency settlement transactions by rolling back their own emergency settlement security enclave. Based on the deterministic algorithm, even if a user rolls back their own emergency settlement security enclave, they will only receive a completely identical emergency settlement transaction. If this transaction conflicts with another user's emergency settlement transaction, the user can input evidence that the conflicting transaction has already been confirmed on an external blockchain into the emergency settlement security enclave. After verification, the emergency settlement security enclave regenerates the emergency settlement transaction. The new emergency settlement transaction is also generated by the deterministic algorithm, preventing malicious users from compromising the security of the emergency settlement process through replay.

[0115] However, this design still has a security vulnerability: when a majority of users collude to reach a consensus on a non-updated state, the remaining minority of users may suffer losses. To circumvent this vulnerability, when the voting platform is in a dispute period, users can directly send the block height containing the consensus node's secure enclave signature to the voting platform without reading all user operation logs, as a way to verify the voting platform's state. For example, suppose most participants use secure enclaves to vote on a channel with a final block height of n. However, if a user has received a channel update message from the consensus node's secure enclave showing a block height of n' (n'>n), they can directly submit the block height n' containing the consensus node's secure enclave private key signature (this signature is included in any secure channel built by a secure enclave) to the voting platform via the contract function `dispute()`. Since n'>n, the voting platform will change the state parameter back to invalid and modify the final channel height to n'. Based on this mechanism, rational storage nodes, in order to reclaim their rightful channel share, will only broadcast complete user operation logs, thus effectively resolving the aforementioned security vulnerabilities.

[0116] It's important to note that for normal settlements, when a user clears their account, they can send a settlement address to the consensus node's secure enclave via a secure channel. The consensus node's secure enclave then generates a settlement transaction and submits it to the external blockchain. To ensure no conflicts occur when multiple users simultaneously submit settlement requests, the leader node's secure enclave handles these requests. Therefore, when a non-leader consensus node receives a user's settlement request, it forwards the message to the current consensus node leader. All consensus nodes, upon verifying the settlement transaction record in the new block, check if the user's balance is sufficient to cover the transaction. If it is, the corresponding balance is deducted, and the settlement transaction is broadcast to the external blockchain. If a user wishes to clear their account or reduce their balance below a specified threshold, the leader node, upon verifying this message in the new block of the user's operation log, is also responsible for deleting the corresponding user's public key on the emergency settlement voting platform, signifying that this user will no longer participate in emergency settlement voting.

[0117] In this embodiment, even if the consensus node group fails to function properly, users can still conduct emergency settlements at any time through the emergency settlement platform, thereby further ensuring the safety of user funds. Furthermore, by designing the voting platform accordingly, the security and fairness of the voting platform are guaranteed, preventing collusion among a majority of users from causing losses to a small number of users.

[0118] Furthermore, refer to Figure 8 , Figure 8 For the present invention Figure 2The flowchart following step S202 shows that the consensus node serves the corresponding transaction channel. After updating the account information corresponding to the user node using the secure enclave and feeding back the transaction result to the user node to complete the off-chain transaction, the method further includes:

[0119] Step S801: After receiving the settlement request sent by the payer user node, determine the corresponding transaction information, the payee user node and at least one transaction channel according to the settlement request;

[0120] To further increase transaction throughput and reduce the workload of secure enclaves of consensus nodes within a channel, this embodiment divides the channel into multiple relatively independent sub-channels. Each channel is served by an independent set of consensus nodes and maintains an independent user operation log. Furthermore, this embodiment proposes two cross-channel transaction settlement strategies: cross-channel cooperative settlement and single-channel independent settlement. When all channels are operating normally, each consensus node's secure enclave can periodically settle all cross-channel transactions at once through net settlement via cross-channel cooperative settlement. All channels retain the right to use single-channel independent settlement, ensuring that even if all channels except its own cease cooperation, the channel can still settle all cross-channel transactions on an external blockchain.

[0121] That is, (1) when all channels are running normally, all cross-channel transaction-related channels will conduct cross-channel cooperative settlement at fixed intervals or when a channel is about to run out of its channel balance, and (2) each channel retains the ability to settle all cross-channel transactions related to this channel separately, although single-channel independent settlement will consume more time and transaction fees.

[0122] Step S802: Send the fund amount to the payee user node through at least one of the transaction channels, so that the payee user node updates the account balance of the payee account according to the transaction information and sends back transaction confirmation information;

[0123] The secure enclave of the consensus node in the payer's channel broadcasts evidence that the cross-channel transaction has been uploaded to the blockchain to the consensus node in the payee's channel. Since the consensus node uses a secure enclave to provide services in this invention, the blockchain evidence can be the complete transaction content sent by the payer's consensus node's secure enclave through a secure channel. Upon receiving the blockchain evidence from the payer's consensus node's secure enclave, the payee's consensus node's secure enclave also synchronizes this transaction in its own user operation log. After the transaction is uploaded to the blockchain, it replies to the payer's consensus node that the transaction has been synchronized in the payee's user operation log and increases the payee's balance by the corresponding amount.

[0124] Step S803: Send the transaction confirmation information to the payer user node through at least one of the transaction channels, so that the payer user node updates the account balance of the payer's account based on the transaction confirmation information and the transaction information.

[0125] Once the transaction is confirmed to have been synchronized in the recipient's user operation log, the payer's consensus node security enclave records the transaction confirmation message in the user operation log and removes the corresponding funds from the payer's account balance. Furthermore, all consensus node security enclaves that read this message also remove the corresponding funds from the payer's account balance.

[0126] It is important to emphasize that in practical applications, the following situation may occur: consensus nodes within a channel can collude to publish only a portion of the valid transaction chain, and then quickly spend the output at the end of the valid transaction chain, thereby invalidating the valid transaction chains held by consensus nodes in other channels.

[0127] To address this issue, this embodiment requires that if a channel performs independent settlement, funds sent back to the channel from the end of its valid transaction chain can only be spent after a predefined period (e.g., 1-2 days). This time constraint can be implemented by hard-coding it into the consensus node's secure enclave code. Since secure enclaves can only be rolled back, not forward, this time interval is safe. Furthermore, to minimize the need for user monitoring of the blockchain, this embodiment adds an additional state, netting, to the emergency settlement voting platform's state parameters. The netting state requires more than half of the consensus node secure enclaves within the channel to vote on the same block height, and then calls the contract function start_netting() to initiate it. Similar to the emergency settlement mechanism, the consensus node secure enclave will only publish the locked valid transaction chain after receiving evidence that the voting platform is in the netting state. This way, users only need to monitor a fixed voting platform to know if a channel is preparing for independent settlement, thereby reducing the need for blockchain monitoring.

[0128] In this embodiment, by dividing the transaction channel into multiple relatively independent sub-channels, the transaction throughput is increased, the task load of consensus nodes within the channel is reduced, and single-channel settlement or cross-channel settlement can be flexibly selected. Furthermore, by implementing corresponding implementations for the emergency settlement voting platform, the user's monitoring needs are reduced while ensuring transaction security.

[0129] Based on the same inventive concept, embodiments of the present invention also provide a blockchain off-chain transaction device, referring to... Figure 9 As shown, it includes:

[0130] The request receiving module is used to broadcast the transaction request to the consensus node group after receiving the transaction request sent by the user node, so that the first secure enclave of the current consensus node leader can receive the transaction request, generate a new block according to the transaction request, and synchronize the new block to all the consensus nodes.

[0131] The transaction completion module is used to update the account information corresponding to the user node using the secure enclave, and to feed back the transaction result to the user node to complete the off-chain transaction.

[0132] As an optional embodiment, the blockchain off-chain transaction device may further include:

[0133] The deposit record module is used to broadcast the deposit record to the consensus node group so that the current consensus node leader can add the deposit record as a new block to the off-chain service blockchain.

[0134] As an optional embodiment, the blockchain off-chain transaction device may further include:

[0135] The registration record module is used to broadcast the registration record to the consensus node group so that the current consensus node leader adds the registration record as a new block to the off-chain service blockchain.

[0136] It should be noted that since the steps performed by the device in this embodiment are the same as those in the aforementioned method embodiments, the specific implementation methods and the technical effects that can be achieved can be referred to the aforementioned embodiments, and will not be repeated here.

[0137] In addition, in one embodiment, this application also provides a computer storage medium storing a computer program, which is executed by a processor to implement the steps of the method in the foregoing method embodiment.

[0138] In some embodiments, the computer-readable storage medium may be a memory such as FRAM, ROM, PROM, EPROM, EEPROM, flash memory, magnetic surface memory, optical disk, or CD-ROM; or it may be a device including one or any combination of the above-mentioned memories. The computer may be a variety of computing devices, including smart terminals and servers.

[0139] In some embodiments, executable instructions may take the form of a program, software, software module, script, or code, written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and may be deployed in any form, including as a standalone program or as a module, component, subroutine, or other unit suitable for use in a computing environment.

[0140] As an example, executable instructions may, but do not necessarily, correspond to files in the file system. They may be stored as part of a file that holds other programs or data, for example, in one or more scripts in a Hyper Text Markup Language (HTML) document, in a single file dedicated to the program in question, or in multiple collaborative files (e.g., a file that stores one or more modules, subroutines, or code sections).

[0141] As an example, executable instructions can be deployed to execute on a single computing device, or on multiple computing devices located in one location, or on multiple computing devices distributed across multiple locations and interconnected via a communication network.

[0142] The above are merely preferred embodiments of the present invention and do not limit the scope of the patent. Any equivalent structural or procedural transformations made based on the description and drawings of the present invention, or direct or indirect applications in other related technical fields, are similarly included within the scope of patent protection of the present invention.

Claims

1. A blockchain off-chain transaction method, characterized in that, A secure enclave for any consensus node in a consensus node group in an off-chain service blockchain, wherein the secure enclave has account information for each user node in an external blockchain; The method includes: After receiving a transaction request from a user node, the transaction request is broadcast to the consensus node group so that the first secure enclave of the current consensus node leader receives the transaction request, generates a new block according to the transaction request, and synchronizes the new block to all the consensus nodes. Update the account information corresponding to the user node and send the transaction result back to the user node to complete the off-chain transaction; Before broadcasting the transaction request to the consensus node group after receiving the transaction request from the user node, the method further includes: After receiving the deposit request sent by the user node, an external blockchain address corresponding to the user node is generated; The external blockchain address is sent to the user node so that the user can use the external blockchain address as the account address to make a deposit and generate a corresponding deposit record. The deposit record is broadcast to the consensus node group so that the current consensus node leader adds the deposit record as a new block to the off-chain service blockchain; Read the deposit records from the off-chain service blockchain; Update the account balance of the corresponding account based on the deposit record; If the account balance reaches a preset balance threshold, the corresponding account will be registered to the emergency settlement platform; If an emergency settlement request is received from the corresponding user node, the emergency settlement platform is activated so that the user can transfer funds out through the emergency settlement platform.

2. The method according to claim 1, characterized in that, Before broadcasting the transaction request to the consensus node group, the method further includes: Verify the transaction request; If the transaction request passes verification, the smart contract contained in the transaction request is invoked, the transaction data processing logic declared by the smart contract is executed, and the data information of the transaction request is obtained. The broadcasting of the transaction request to the consensus node group includes: The transaction request and the data information are broadcast to the consensus node group.

3. The method according to claim 1, characterized in that, Before generating an external blockchain address after receiving a deposit request from the user node, the method further includes: After receiving the registration request sent by the user node, the corresponding registration information is obtained according to the registration request; the registration information includes the public and private key pair of the corresponding user node account information and the secure enclave signature; The registration information is verified. If the public-private key pair does not duplicate the public-private key pair of the account information of other user nodes, and the secure enclave signature is correct, then the corresponding registration record is generated. The registration record is broadcast to the consensus node group so that the current consensus node leader adds the registration record as a new block to the off-chain service blockchain.

4. The method according to claim 1, characterized in that, The step of broadcasting the transaction request to the consensus node group after receiving the transaction request from the user node includes: The transaction request is encrypted using a symmetric key to obtain encrypted transaction information; the symmetric key is generated by the current consensus node leader. The encrypted transaction information is broadcast to the consensus node group.

5. The method according to claim 1, characterized in that, The consensus node serves the corresponding transaction channel. After updating the account information corresponding to the user node and feeding back the transaction result to the user node, and completing the off-chain transaction, the method further includes: After receiving a settlement request from the payer's user node, the corresponding transaction information, the payee's user node, and at least one transaction channel are determined based on the settlement request. The transaction information is sent to the payee user node through at least one of the transaction channels, so that the payee user node updates the account balance of the payee account according to the transaction information and provides transaction confirmation information. The transaction confirmation information is sent to the payer user node through at least one of the transaction channels, so that the payer user node updates the account balance of the payer's account based on the transaction confirmation information and the transaction information.

6. A blockchain off-chain transaction device, characterized in that, The device includes: The request receiving module is used to broadcast the transaction request to the consensus node group after receiving the transaction request sent by the user node, so that the first secure enclave of the current consensus node leader can receive the transaction request, generate a new block according to the transaction request, and synchronize the new block to all the consensus nodes. The transaction completion module is used to update the account information corresponding to the user node using the secure enclave, and to feed back the transaction result to the user node to complete the off-chain transaction. The off-chain transaction device is further configured to, upon receiving a deposit request from the user node, generate an external blockchain address corresponding to the user node; send the external blockchain address to the user node so that the user can use the external blockchain address as an account address for depositing funds, and generate a corresponding deposit record; broadcast the deposit record to the consensus node group so that the current consensus node leader can add the deposit record as a new block to the off-chain service blockchain; read the deposit record in the off-chain service blockchain; update the account balance of the corresponding account according to the deposit record; if the account balance reaches a preset balance threshold, register the corresponding account to the emergency settlement platform; and if an emergency settlement request is received from the corresponding user node, activate the emergency settlement platform so that the user can transfer funds out through the emergency settlement platform.

7. A blockchain off-chain transaction device, characterized in that, The method includes a memory, a processor, and a blockchain off-chain transaction program stored on the memory and executable on the processor. When executed by the processor, the blockchain off-chain transaction program implements the steps of the blockchain off-chain transaction method as described in any one of claims 1 to 5.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a blockchain off-chain transaction program, which, when executed by a processor, implements the steps of the blockchain off-chain transaction method as described in any one of claims 1 to 5.

Images