Method and related device for constructing distributed trusted sandbox in on-chain and off-chain cooperation

Abstract

The application provides a chain-on-chain-off cooperative distributed trusted sandbox construction method and related device, which is applied to a target node in a distributed system. The target node and other nodes in the distributed system form a state channel network to cooperatively execute a distributed task. An electronic device obtains budget information pre-allocated for a to-be-executed task; the budget information includes a preset state recording number and a budget cost; in the execution process of the to-be-executed task, task state information of each task stage is collected according to the state recording number; wherein the task state information includes an actual cost generated in the corresponding stage; a transaction record is generated based on the task state information, and the transaction record is submitted to the state channel network as an off-chain transaction, so that after the to-be-executed task is completed, other nodes compare the final accounts of all transaction records with the budget cost to verify whether the task execution process of the target node is trustworthy.

Description

Technical Field

[0001] This application relates to distributed computing security technology, specifically to a method and apparatus for constructing a distributed trusted sandbox with on-chain and off-chain collaboration. Background Technology

[0002] In the current development of artificial intelligence technology, a single node can no longer independently complete the training and inference tasks of large-scale models. Collaboration among multiple participants is necessary, thus leading to the development of distributed intelligent computing. Taking a typical model training process as an example, suppose there are three participants, A, B, and C, each with different responsibilities. Participant A is responsible for preprocessing the raw data, such as cleaning and normalizing, to provide high-quality input for subsequent modeling. Participant B uses the preprocessed data to execute the model training process, continuously adjusting model parameters through iterative optimization algorithms. Participant C is responsible for validating the trained model, evaluating its accuracy, generalization ability, and other key performance indicators to ensure the model meets quality standards. This collaborative approach fully utilizes the computing resources and expertise of each party, significantly improving overall efficiency.

[0003] However, in such a distributed environment, ensuring the reliability of the entire model lifecycle faces numerous challenges. The high heterogeneity caused by differences in hardware, software environments, and data formats used by various participants makes it difficult to align collaborative goals. More seriously, malicious participants may inject forged or contaminated data samples during data preprocessing, upload tampered model parameters during model training, or submit false evaluation results during model validation; all of these actions undermine the consistency and reliability of the global model. Furthermore, due to the frequent exchange and transmission of model parameters throughout the network, ownership is difficult to trace. If a model is stolen or illegally copied, current technologies struggle to effectively prove and hold perpetrators accountable. Simultaneously, during model inference, the state authentication mechanisms of different nodes are inadequate, and mismatches may exist between data distribution and model versions, leading to biased or even completely invalid inference results.

[0004] To address these issues, related technologies have introduced federated learning frameworks to achieve multi-party collaborative modeling, hoping to protect privacy by restricting raw data from leaving the local machine. However, these methods typically only focus on data-level security, lacking fine-grained verification mechanisms for the actions of participating parties. They cannot determine whether a party has truly completed the designated tasks as required by the agreement, nor can they identify covert attacks. Some solutions use digital watermarking technology to mark models for ownership verification, but because watermarks are susceptible to adversarial perturbations and have poor robustness, slight modifications to the model can lead to watermark loss or invalidation, thus losing their protective function. Other methods attempt to use blockchain to record critical operation logs, but most remain at the high-level log storage level, failing to delve into the integrity verification of the underlying execution process, and still cannot guarantee the trustworthiness of the computation process itself.

[0005] Therefore, large-scale artificial intelligence networks lacking centralized oversight, such as collaboration between multiple terminal devices in edge computing scenarios or joint learning projects across institutions, face core challenges including difficulty in verifying node behavior, susceptibility to model parameter tampering, and a lack of trust foundation for cross-domain collaboration. Against this backdrop, a technical solution capable of establishing a decentralized and trustworthy collaboration mechanism is needed. Summary of the Invention

[0006] To overcome at least one deficiency in the prior art, this application provides a method and related apparatus for constructing a distributed trusted sandbox for on-chain and off-chain collaboration, which can realize trusted verification of node behavior without relying on a centralized institution, and provides a decentralized trust verification mechanism for specific cross-domain collaborative behaviors.

[0007] Firstly, this application provides a method for constructing a distributed trusted sandbox with on-chain and off-chain collaboration, applied to a target node in a distributed system. The target node and other nodes in the distributed system collaborate to execute distributed tasks by establishing a state channel network. The method includes:

[0008] Obtain the budget information pre-allocated for the task to be executed, wherein the task to be executed is a subtask of the distributed task, and the budget information includes a preset number of state records and budget costs;

[0009] During the execution of the task to be executed, task status information for each task stage is collected based on the number of status records, wherein the task status information includes the actual costs incurred in the corresponding stage;

[0010] The transaction records generated based on the task status information are submitted to the state channel network as off-chain transactions. After the task to be executed is completed, the other nodes compare the final settlement results of all the transaction records with the budgeted fees to verify whether the task execution process of the target node is reliable.

[0011] Secondly, this application provides a distributed trusted sandbox construction device for on-chain and off-chain collaboration, applied to a target node in a distributed system. This target node collaborates with other nodes in the distributed system to execute distributed tasks by establishing a state channel network. The device includes:

[0012] The budget information module is used to obtain the budget information pre-allocated for the task to be executed, wherein the task to be executed is a subtask of the distributed task, and the budget information includes a preset number of status records and budget costs;

[0013] The task monitoring module is used to collect task status information for each task stage during the execution of the task to be executed, based on the number of status records, wherein the task status information includes the actual costs incurred in the corresponding stage.

[0014] The transaction record module is used to generate transaction records based on the task status information and submit the transaction records as off-chain transactions to the state channel network so that after the task to be executed is completed, the other nodes will compare the final settlement results of all the transaction records with the budgeted fees to verify whether the task execution process of the target node is reliable.

[0015] Thirdly, this application provides a storage medium storing a computer program, which, when executed by a processor, implements the on-chain and off-chain collaborative distributed trusted sandbox construction method.

[0016] Fourthly, this application provides an electronic device, which includes a processor and a memory, wherein the memory stores a computer program, and the computer program, when executed by the processor, implements the method for constructing a distributed trusted sandbox with on-chain and off-chain collaboration.

[0017] Compared with the prior art, this application has the following beneficial effects:

[0018] This application provides a method and related apparatus for constructing a distributed trusted sandbox for on-chain and off-chain collaboration, applied to a target node in a distributed system. This target node collaborates with other nodes in the distributed system to execute distributed tasks by establishing a state channel network. An electronic device acquires pre-allocated budget information for the task to be executed; wherein the task to be executed is a sub-task of a distributed task, and the budget information includes a preset number of state records and a budgeted cost. During the execution of the task to be executed, task status information for each task stage is collected based on the number of state records; wherein the task status information includes the actual cost incurred in the corresponding stage. Transaction records are generated based on the task status information and submitted to the state channel network as off-chain transactions. After the task to be executed is completed, other nodes compare the final settlement results of all transaction records with the budgeted cost to verify the trustworthiness of the target node's task execution process. Attached Figure Description

[0019] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 This is one of the flowcharts illustrating the distributed trusted sandbox construction method for on-chain and off-chain collaboration provided in this application embodiment;

[0021] Figure 2 This is a schematic diagram illustrating the implementation principle of the method provided in the embodiments of this application in the target node;

[0022] Figure 3 A schematic diagram illustrating the creation principle of the channel network provided in this application embodiment;

[0023] Figure 4 The recording principle of the off-chain ledger provided in the embodiments of this application;

[0024] Figure 5 The second flowchart illustrates the method for constructing a distributed trusted sandbox with on-chain and off-chain collaboration provided in this application embodiment.

[0025] Figure 6 A schematic diagram of the structure of the distributed trusted sandbox builder device for on-chain and off-chain collaboration provided in the embodiments of this application;

[0026] Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0027] To make the objectives, technical solutions, and advantages of the embodiments of this application (hereinafter referred to as "the embodiments") clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. The components of the embodiments of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations.

[0028] Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0029] It should be noted that similar labels and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures.

[0030] In the description of this application, it should be noted that the terms "first," "second," "third," etc., are used only for distinguishing descriptions and should not be construed as indicating or implying relative importance. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0031] Based on the above statement, as introduced in the background technology, large-scale artificial intelligence networks lacking centralized supervision face core challenges such as difficulty in verifying node behavior, easy tampering of model parameters, and lack of trust foundation for cross-domain collaboration.

[0032] It should be noted that the defects in the solutions in the prior art are the result of practice and careful research. Therefore, the discovery process of the above problems and the solutions proposed by the embodiments of this application in the following text should be regarded as contributions to this application in the process of invention and creation, and should not be understood as technical content known to those skilled in the art.

[0033] Based on the aforementioned technical problems, this embodiment provides a method for constructing a distributed trusted sandbox with on-chain and off-chain collaboration. This method is applied to a target node in a distributed system, which collaborates with other nodes in the system to execute distributed tasks by establishing a state channel network. Figure 1 The method includes:

[0034] S1, obtain the budget information pre-allocated for the tasks to be executed.

[0035] Among them, the task to be executed is a subtask of the distributed task, and the budget information includes the preset number of state records and the budget cost.

[0036] S2, during the execution of the task to be executed, collect the task status information of each task stage based on the number of status records.

[0037] The task status information includes the actual costs incurred at the corresponding stage.

[0038] S3 generates transaction records based on task status information and submits these records as off-chain transactions to the state channel network. This allows other nodes to compare the final settlement results of all transaction records with the budgeted costs after the task is completed, in order to verify the reliability of the target node's task execution process.

[0039] Thus, if the final settlement results are consistent with the budgeted expenses and the status records for each stage are complete, it indicates that the target node's behavior is in line with expectations; otherwise, there may be abnormal operations. Therefore, this method can achieve reliable verification of node behavior without relying on a centralized institution, providing a decentralized trust verification mechanism for specific cross-domain collaborative activities.

[0040] To make the solution provided in this embodiment clearer, the following is combined with... Figure 1 Each step of the method is described in detail. However, it should be understood that the operations in the flowchart may not be implemented in sequence, and steps without logical contextual relationships may be reversed in order or implemented simultaneously. Furthermore, those skilled in the art, guided by the content of this application, may add one or more other operations to the flowchart, or remove one or more operations from the flowchart.

[0041] In the Figure 1 Before introducing the ongoing steps, it should be noted that, as an optional implementation, the target node is deployed with a task container and a service container. The task container is used to run tasks to be executed, and the service container is used to run tasks for trusted verification with other nodes.

[0042] This embodiment can be understood as achieving secure and reliable distributed collaboration by constructing container group instances with strong isolation capabilities on the target node. Specifically, as follows... Figure 2As shown, in the on-chain / off-chain collaborative architecture provided in this embodiment, the target node and other nodes in the distributed system can communicate with the main blockchain to synchronize the ledger generated during off-chain execution to the main blockchain when specific state update conditions are met, thereby achieving final confirmation and immutability of the distributed task execution process. Alternatively, smart contracts deployed on the main blockchain can be invoked to create an off-chain state channel network.

[0043] See also Figure 2 In a distributed system, the target node and other nodes provide container sandboxes. Each container group within this sandbox acts like an independently running, secure workspace, containing task containers and service containers. Task containers actually execute tasks, such as processing data or performing part of model training, while service containers, through their running state channel instances, handle consensus logic—the task of trusted verification with other nodes. In this process, the entire container group achieves underlying computational isolation through container sandbox technology, ensuring that operations within task containers are not interfered with externally and that sensitive information is not leaked.

[0044] In practical applications, such as Figure 3 As shown, when a target node wants to participate in a collaborative task, it initiates a request to create a state channel by calling a smart contract deployed on the blockchain main chain. Here, a smart contract refers to a pre-written and deployed automated program on the blockchain, whose function is to automatically execute specific operations according to preset rules without human intervention. When initiating the request, the target node needs to inject a certain amount of funds into the smart contract as a performance guarantee; this fund is locked to ensure the traceability of subsequent actions. Upon receiving the request, the blockchain engine located at the sandbox base initiates the channel creation process and generates a temporary channel to temporarily store the current collaborative state.

[0045] See also Figure 3 This temporary channel maintains a participant list, initially containing only the target node that initiated the creation request. Other nodes wishing to join must first register and inject funds by calling the same smart contract before becoming members of the temporary channel. The participant list is dynamically updated as more nodes join. It's important to note that the channel will only proceed to the next stage once the number of joining nodes reaches the preset minimum participant requirement and all expected participants have successfully joined.

[0046] See also Figure 3The blockchain engine elects a leader node from among all participating nodes, a process that can be based on quantifiable metrics such as each node's historical reputation score. Once the leader node is elected, the temporary channel is upgraded to a formal state channel, marking the formal establishment of the distributed collaborative relationship between the nodes. The formal state channel fully records key information such as the financial status of all participating nodes and the total funds within the channel, and submits this information to the main blockchain for notarization, forming the channel's version 0 state. This essentially establishes a public, transparent, and tamper-proof initial benchmark for the entire collaborative process.

[0047] In this way, by leveraging the automated execution capabilities of smart contracts and the trusted evidence storage characteristics of blockchain, a reliable state channel network is built in a decentralized environment through the above methods.

[0048] Research has found that in distributed collaborative environments, the computing environment of each node can be maliciously attacked or experience operational anomalies, rendering its internal execution state unreliable. Specifically, when the task container or service container of a target node undergoes state changes, the lack of a reliable mechanism to verify the authenticity of the change can introduce errors or even be used to forge execution results. Furthermore, if the Trusted Execution Environment (TEE) running a monitor replica on a node restarts due to a failure, the state data it maintains may be lost or inconsistent, thereby undermining the original consensus foundation. Therefore, it is necessary to ensure that each node maintains observable behavior and verifiable state during dynamic operation, and remains consistent with other nodes after fault recovery.

[0049] Therefore, please continue to see Figure 2 The target node and other nodes are configured with a trusted execution environment that runs a monitor replica. The monitor replica of the target node is used to monitor the behavior of task containers and service containers. Furthermore, the monitor replica of the target node shares immutable static code with the monitor replicas of other nodes, and independently maintains its own dynamic data state.

[0050] As one alternative implementation, if a status update notification from a task container is received through a monitor replica, the target node performs cross-replica collaborative verification with other nodes, and the update is only executed after more than half of the monitor replicas of the nodes reach a consensus.

[0051] As another optional implementation, if the trusted execution environment of the target node restarts due to a failure, the target node obtains the latest snapshot of the monitor replica from other nodes and restores the operation of the monitor replica based on the latest snapshot.

[0052] This embodiment can be understood as ensuring the reliability of the entire distributed collaboration process by deploying and running a trusted execution environment with monitor replicas on both the target node and other participating nodes.

[0053] Specifically, each node has a highly secure, isolated area, known as a trusted execution environment, which prevents external programs from interfering with or stealing critical tasks running within it. Within this secure area, a component called a monitor replica is activated to monitor the behavior of the task containers and service containers within that node in real time to ensure they are behaving as expected.

[0054] In practical applications, all participating nodes create their own trusted execution environments (TEXs) based on hardware support during the initialization phase and initialize them using a unified protocol. This process requires each TEX instance to obtain initial monitor information from the same trusted source (e.g., the master node or records on the blockchain), including the hash value of static code and the initial state of dynamic data, thus ensuring that all monitor replicas are consistent from the outset. Here, static code refers to the fixed core logic within the monitor, such as startup, initialization, and integrity verification functions, which cannot be modified throughout the entire runtime. Each TEX instance independently maintains its own dynamic data state, including runtime snapshots, hash values, signatures, and other variable information, which can be updated based on actual operations.

[0055] In this process, when a node's monitor replica receives a state update notification from the task container, it does not immediately accept the change. Instead, it first broadcasts the update request and its accompanying trusted verification credentials to other nodes that are still running normally. Only after receiving confirmation responses from more than half of the other nodes will the state update be formally executed. This mechanism, through multi-party verification, avoids the risks of errors or manipulation that might arise from single-point judgments.

[0056] Furthermore, before the state channel submits the latest state to the main blockchain, each monitor replica independently verifies the data to be agreed upon again, allowing upload only if its integrity is confirmed to be intact. This is equivalent to a final collective review before the data is finally uploaded to the chain, further enhancing the system's security.

[0057] It's important to note that if a node experiences a hardware or software failure that causes the trusted execution environment to interrupt and restart, it cannot directly resume operation using local residual data. Instead, it must actively broadcast a rejoin request to other healthy nodes, obtain the latest dynamic execution state snapshot from them, and then rebuild its own operational state based on this latest snapshot. This ensures that even if individual nodes malfunction, the overall system's state consistency remains unaffected.

[0058] In this way, by collaboratively running monitor replicas through multiple trusted execution environment instances, and combining a design of shared static code with independent maintenance of dynamic data, the runtime integrity of the state channel is protected. Even if some instances fail, normal operation can still be maintained through the remaining nodes, solving the problem of the overall trust chain breaking due to unreliable nodes in open networks.

[0059] Based on the above embodiments regarding the architecture of the target node and other nodes, as an optional implementation, the target node and other nodes are electronic devices, computing devices with data processing and network communication capabilities, specifically including but not limited to servers, edge computing devices, cloud computing nodes, industrial control computers, computing nodes in high-performance computing clusters, or smart terminal devices. In practical applications, these electronic devices need to be equipped with an operating system that supports containerized runtime environments and have hardware-level security extension functions to support the creation and management of trusted execution environments. In other words, as long as the electronic device has the basic capabilities to run container sandboxes, blockchain clients, and trusted execution environments, it can serve as a target node to access the state channel network and implement the above methods.

[0060] Based on the above description of the electronic device, please refer to... Figure 1 The method includes:

[0061] S1, obtain the budget information pre-allocated for the tasks to be executed.

[0062] Among them, the task to be executed is a subtask of the distributed task, and the budget information includes the preset number of state records and the budget cost.

[0063] This embodiment can be understood as follows: by pre-setting a clear expected execution standard before the task officially begins execution, it provides a quantifiable basis for subsequent judgment on whether the task has been completed correctly and compliantly.

[0064] In practical applications, in a distributed computing environment, multiple participating nodes need to collaborate to complete a large distributed task, while each node actually undertakes only a portion of the subtasks. To ensure that each node does not arbitrarily execute or maliciously deviate from the established process, a budget information containing key control parameters is configured for each subtask at the beginning of its execution.

[0065] It should be understood that this budget information does not simply refer to an estimated expenditure, but rather includes the preset number of status records and the budgeted cost. The preset number of status records refers to the number of staged status reports that should be generated throughout the entire execution process, based on the clearly defined workload of the subtask during the offline phase. For example, if the subtask involves five key operations, the number of status records can be set to five, meaning that a progress report must be submitted after each step is completed. The budgeted cost refers to the virtual assets allowed to be consumed in completing the entire subtask.

[0066] During this process, when a target node is ready to start the task it is responsible for, the container orchestration and scheduling layer (e.g., Kubernetes) first identifies whether the task belongs to a known standard subprocess. If so, it triggers a call to the task startup contract designed for the state channel, which assists in registering and locking the budget information. In other words, only after the budget information is successfully written to the state channel will control be truly handed over to the task container and it will be allowed to start running.

[0067] Thus, by acquiring and binding budget information during the task initialization phase, it becomes possible to compare it with the actual cost of intermediate states during the subsequent execution process.

[0068] Based on the above description of the tasks to be executed and budget information in the embodiments, the following will continue to discuss... Figure 1 Step S2 will be explained below:

[0069] S2, during the execution of the task to be executed, collect the task status information of each task stage based on the number of status records.

[0070] The task status information includes the actual costs incurred at the corresponding stage.

[0071] It should be understood that the lack of a unified observation standard among different nodes makes it difficult to verify whether a task is executed correctly as required in a distributed environment. Therefore, this embodiment provides the following optional implementation methods for step S2:

[0072] S2-1 loads the preset execution monitoring configuration when the task to be executed starts.

[0073] The execution monitoring configuration defines multiple status acquisition events corresponding to the number of status records.

[0074] S2-2, If the execution progress of the task to be executed triggers any status acquisition event, then obtain the execution context information of the current task stage.

[0075] S2-3 uses the execution context information as task status information.

[0076] This can be understood as follows: in a distributed environment, to determine whether a task is executed as expected, one cannot rely solely on the final result; it is also necessary to observe whether the process is compliant. Therefore, this embodiment solves the problem of untraceable execution process by setting multiple status acquisition events during task execution.

[0077] Specifically, when a task to be executed starts, the target node first loads a preset execution monitoring configuration. This configuration defines multiple status collection events corresponding to a preset number of status records. These status collection events are essentially pre-set monitoring times, used to indicate which key nodes the task execution reaches when status collection is required. During this process, when the actual execution progress of the task triggers any of these status collection events, the target node immediately obtains the execution context information of the current task stage and records this execution context information as the task status information for the corresponding task stage.

[0078] In this embodiment, the execution context information includes not only the actual costs incurred in the corresponding stage, but also a formal language summary of the executed code. Therefore, the target node can also obtain the code execution record of the task to be executed in the current task stage; extract the summary information of the code execution record to obtain the formal language summary of the executed code.

[0079] In practice, the target node obtains the execution context information of the current task stage, including the code execution records generated by the task in this stage, and extracts the summary information that can represent the behavioral characteristics of the code segment, namely the formal language summary of the executed code. This summary can describe the actual behavior of the code in a concise and standardized way, such as which functions were called and which data were accessed, so that the subsequent verification party can judge its correctness without replaying the entire execution process.

[0080] Based on the task status information obtained from the above embodiments, the following steps will continue... Figure 1 Step S3 will be explained below:

[0081] S3 generates transaction records based on task status information and submits these records as off-chain transactions to the state channel network. This allows other nodes to compare the final settlement results of all transaction records with the budgeted costs after the task is completed, in order to verify the reliability of the target node's task execution process.

[0082] It should be understood that in a distributed system, it is necessary to avoid the inefficiency of recording every operation directly on the blockchain. Therefore, an efficient intermediate recording mechanism is required. In this embodiment, a dedicated off-chain transaction channel is established between nodes to enable rapid recording and interaction of high-frequency states.

[0083] In practical applications, when it is necessary to generate transaction records based on task status information, the target node will construct it into an off-chain transaction in a specific format and submit it to the state channel network for processing. This state channel network is a dedicated communication channel established between multiple participating nodes to complete efficient interaction without frequently relying on the main blockchain.

[0084] like Figure 4 As shown, in this process, the target node, acting as the transaction initiator, first creates a transaction request (transfer) and sends it to the relevant participants. This transaction request includes a formal language digest of the operation, describing the code behavior characteristics of the current task phase, as well as necessary information such as the initiator's public key, the recipient's public key, the resource consumption or cost involved, the transaction nonce, and the sending time. The target node uses the initiator's private key to digitally sign the hash value of the transaction content to prove that the request indeed comes from a legitimate entity and has not been tampered with. Upon receiving the transaction request, the state channel instance located in the service container immediately verifies key attributes such as the validity of the signature and the continuity of the transaction nonce. Only transactions that pass verification are accepted and temporarily stored in the channel's internal processing queue as the basis for subsequent consensus and ledger recording.

[0085] It should be understood that in traditional off-chain transaction systems, multiple transaction records often lack inherent connections. When multiple nodes record transactions independently in a distributed environment, without a unified organization method, data inconsistency or isolated transactions can easily occur, making it impossible to determine whether a transaction has been recognized by other nodes.

[0086] In view of this, such as Figure 5 The distributed trusted sandbox construction method for on-chain and off-chain collaboration provided in this embodiment also includes:

[0087] S4. If a valid response to the transaction record is received from another node, the transaction record is written as a new node into the off-chain ledger based on the directed acyclic graph.

[0088] This embodiment can be understood as addressing the issue of untrustworthy off-chain behavior by requiring transactions to be confirmed by both parties before being formally recorded in the ledger. Specifically, when a target node initiates a transaction record, it is not immediately treated as valid data; instead, it waits for feedback from other relevant nodes. (Continue to see...) Figure 4During this process, a valid response is only considered received when the recipient of the transaction (i.e., other nodes) explicitly agrees and returns a signed confirmation transaction reply, `tx_confirm`. Upon receiving this confirmation, the target node constructs a new commit transaction, `submit_tx`, to formally record this interaction in the ledger. This commit transaction contains the transaction hash of the original transaction request `transfer` and the transaction hash of the recipient's confirmation transaction, `tx_confirm`. When the state channel instance in the service container receives this `submit_tx` request, it first checks whether these two hashes exist, match, and are both validly signed. Only after all verifications pass will the transaction be allowed to be written as a new node into the off-chain ledger based on a directed acyclic graph.

[0089] In this way, it is ensured that every record entering the ledger is a credible result that has been recognized by consensus.

[0090] The study also found that if multiple transaction records lack an effective linkage mechanism, it can easily lead to a loose ledger structure that fails to reflect the true dependencies between transactions, and a simple list of transactions cannot express the mutual trust relationships between them. Therefore, this embodiment also provides the following optional implementation methods for step S4:

[0091] S4-1: Select at least two legitimate transactions from the off-chain ledger as parent transaction nodes.

[0092] S4-2 If the parent transaction node passes the validity verification, the transaction record is treated as a child node of the parent transaction node, and a directed reference relationship is constructed for each parent transaction to obtain a new off-chain ledger.

[0093] In practical applications, the target node randomly selects two legitimate transactions from the existing off-chain ledger based on a directed acyclic graph (DAG) that have not yet reached the consensus weight threshold as parent transaction nodes. For example, it prioritizes transactions with lower weights. Then, the target node verifies the legitimacy and validity of these two parent transaction nodes again. If either parent transaction node is illegitimate, new parent transaction nodes are selected until two legitimate targets are found. Once verification is successful, the transaction record becomes a new node, establishing a directed reference relationship to the two parent transaction nodes, thus pointing itself to them, forming a data dependency, and recording its child transaction information in the DAG.

[0094] Furthermore, the addition of a new transaction increases the consensus among each referenced parent transaction node, specifically by incrementing the transaction weight by 1. It's important to note that this random selection and referencing process is repeated whenever a new transaction is added, continuously providing verification support for historical transactions. When a new transaction is recorded, its initial weight is set to 1, and the information of its referenced parent transactions is saved, completing the attachment of a trusted transaction record. Transactions that are temporarily isolated because no legitimate parent transaction can be found automatically become the top node of the directed acyclic graph, awaiting retrospective verification by subsequent transactions.

[0095] Thus, when a transaction receives enough references from subsequent transactions to make its transaction weight reach a preset consensus threshold (e.g., greater than or equal to 4), it can be considered to have reached consensus within the state channel. When the state update conditions are met, the transaction is submitted to the chain in batches by the leader node elected in the distributed system, thereby realizing the authentication relationship between transactions.

[0096] Based on the above embodiments regarding the writing of transaction records to the off-chain ledger, this embodiment also provides an arbitration mechanism for abnormal transaction records.

[0097] In practical applications, the target node, as one of the distributed nodes participating in the state channel network, can initiate a dispute arbitration process for suspicious transactions based on its local observations. When the target node, while performing tasks or synchronizing its state, identifies a transaction that has entered the consensus process but has not yet been finalized on the blockchain as having legal issues, it can proactively invoke the dispute arbitration contract to initiate the dispute resolution mechanism. This dispute can involve the following three scenarios:

[0098] (1) A transaction for which consensus has been reached is disputed;

[0099] (2) Transactions for which no consensus has been reached are disputed;

[0100] (3) There is a dispute over the version of the off-chain ledger within the state channel.

[0101] When a target node initiates a dispute, it must clearly identify the object of the dispute in the disputed transaction, and provide details of the dispute, how it believes the correct state should be corrected, and the technical or logical basis for raising the dispute, so that other participating nodes can understand the reason for the dispute.

[0102] Following this, other participating nodes within the state channel become aware of the dispute through on-chain event monitoring and make independent judgments based on their respective local ledger data and verification results. Each node can submit a positional voting response to the dispute arbitration contract, expressing its support for or opposition to the modification. After receiving the votes from all parties, the dispute arbitration contract will quantify the voting results according to a preset weighting rule. The leading node, due to its coordinating role, is given a higher voting weight to enhance decision-making stability; while entities directly related to the disputed transaction, including the sender and receiver of the disputed transaction, as well as the sender and receiver of child transactions that previously used the transaction as a parent node, have their voting weight reduced to suppress potential conflicts of interest and collusion risks.

[0103] In this way, the arbitration contract makes a ruling based on the weighted sum of votes, deciding whether to accept the state modification claimed by the party raising the dispute, thus providing a decentralized and manipulation-resistant dispute resolution mechanism for the entire state channel network.

[0104] It should also be understood that, because this embodiment constructs a trust environment for distributed task execution by cooperating with the off-chain state channel and the main blockchain, when the state channel meets preset state update conditions during operation—for example, when the number of off-chain transactions reaches a set threshold or the time interval since the last update has expired—the leader node within the channel will trigger a state update contract call, submitting the latest consensus state of the current channel to the main blockchain. This latest consensus state is jointly determined by transactions in the directed acyclic graph that have been referenced by a sufficient number of subsequent transactions and have reached a consensus weight threshold, reflecting changes in the resource balances among participating nodes. During state updates, the leader node aggregates these consensus-reaching transactions and constructs a Merkle tree structure, generating the Merkle root corresponding to this update, and uploads it along with the Merkle root from the previous update to the chain to prove the continuity and integrity of state evolution. Simultaneously, the leader node also generates zero-knowledge proofs for this state change to verify its legality and consistency without revealing specific transaction details. After each successful state update, the version number of the state channel automatically increments, forming a traceable state evolution sequence.

[0105] Furthermore, when a participating node requests to close the channel, the channel closure contract is immediately invoked. At this point, the leader node first checks whether all transfer transactions within the channel have been fully recorded in the directed acyclic graph, including whether each transaction request (transfer) and its corresponding confirmation response (tx_confirm) have been processed. If all transaction processes are complete, it further checks for any unresolved disputes and clears them by invoking the dispute arbitration contract. For transactions that have reached consensus, the leader node directly uses the aforementioned state update mechanism to solidify the results on the blockchain. For legacy transactions that are still in a state of unresolved consensus, a dual verification mechanism is initiated: nodes in the state channel network automatically perform logical verification, combined with the leader node's auxiliary judgment for comprehensive determination. If abnormal or invalid transactions are found, they are submitted to the arbitration process. After confirming the validity of all transaction states, the channel closure contract calculates and updates the final fund allocation scheme for each node, generates the Merkle root of the final state snapshot and the corresponding zero-knowledge proof, and collects digital signatures of the final result from all participants.

[0106] Therefore, any node must explicitly confirm the result and sign the response before exiting to ensure that all parties agree. Subsequently, the leader node generates an aggregate signature based on all signatures and submits the final state data, cryptographic credentials, and aggregate signature to the blockchain, completing the formal closure of the channel.

[0107] Following this, the reputation score of each node on the blockchain needs to be adjusted based on its behavior throughout the entire lifecycle, serving as a reference for future collaborative decisions.

[0108] Based on the same inventive concept as the on-chain / off-chain collaborative distributed trusted sandbox construction method provided in this embodiment, this embodiment also provides an on-chain / off-chain collaborative distributed trusted sandbox construction device, applied to a target node in a distributed system. This target node and other nodes in the distributed system collaborate to execute distributed tasks by forming a state channel network. The device includes at least one software functional module that can be stored in memory or embedded in an electronic device. A processor in the electronic device executes the executable module stored in memory. Examples include the software functional modules and computer programs included in the device. Please refer to... Figure 6 Functionally, the device may include:

[0109] Budget information module 11 is used to obtain budget information pre-allocated for tasks to be executed, wherein the tasks to be executed are subtasks of distributed tasks, and the budget information includes the preset number of status records and budget costs;

[0110] The task monitoring module 12 is used to collect task status information for each task stage based on the number of status records during the execution of the task to be executed. The task status information includes the actual cost incurred in the corresponding stage.

[0111] The transaction record module 13 is used to generate transaction records based on task status information and submit the transaction records as off-chain transactions to the state channel network so that after the task to be executed is completed, other nodes will compare the final settlement results of all transaction records with the budgeted fees to verify whether the task execution process of the target node is trustworthy.

[0112] In this embodiment, the budget information module 11 is used to implement Figure 1 In step S1, the task monitoring module 12 is used to implement... Figure 1 In step S2, the transaction record module 13 is used to implement Figure 1 Therefore, for a detailed description of each of the above modules, please refer to the specific implementation method of the corresponding step.

[0113] Optionally, the task monitoring module 12 is also specifically used for:

[0114] When a task to be executed is started, a preset execution monitoring configuration is loaded, which defines multiple status acquisition events corresponding to the number of status records.

[0115] If the execution progress of the task to be executed triggers any status acquisition event, the execution context information of the current task stage is obtained;

[0116] Use execution context information as task status information.

[0117] Optionally, the execution context information includes a formal language summary of the executed code, and the task monitoring module 12 is also specifically used for:

[0118] Retrieve the code execution records of the task to be executed at the current task stage;

[0119] Extract the summary information from the code execution record to obtain a formal language summary of the executed code.

[0120] Optionally, the transaction record module 13 is also used for:

[0121] If a valid response to a transaction record is received from another node, the transaction record is written as a new node into the off-chain ledger based on a directed acyclic graph.

[0122] Optionally, the transaction record module 13 is also specifically used for:

[0123] Select at least two legitimate transactions from the off-chain ledger as parent transaction nodes;

[0124] If the parent transaction node passes the validity verification, the transaction record becomes a child node of the parent transaction node, and a directed reference relationship is constructed for each parent transaction to obtain a new off-chain ledger.

[0125] Optionally, the transaction record module 13 is also used for:

[0126] The new off-chain ledger is broadcast to other participating nodes within the state channel, and the reference weight of each parent transaction node is increased, where the reference weight of each parent transaction node represents its own credibility.

[0127] Optionally, the target node is deployed with task containers and service containers. The task containers are used to run tasks to be executed, and the service containers are used to run tasks that perform trusted verification with other nodes.

[0128] The target node and other nodes are configured with a trusted execution environment that runs a monitor replica. The monitor replica of the target node is used to monitor the behavior of task containers and service containers. The monitor replica of the target node shares immutable static code with the monitor replicas of other nodes, and independently maintains its own dynamic data state.

[0129] Task monitoring module 12 is also used for:

[0130] If a status update notification from a task container is received through a monitor replica, cross-replica collaborative verification is performed with other nodes, and the update is only executed after more than half of the monitor replicas of the nodes reach a consensus.

[0131] If the trusted execution environment of the target node restarts due to a failure, the latest snapshot of the monitor replica is obtained from other nodes, and the operation of the monitor replica is restored based on the latest snapshot.

[0132] In addition, the functional modules in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0133] It should also be understood that if the above embodiments are implemented as software functional modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application.

[0134] Therefore, this embodiment also provides a storage medium, which is a computer-readable storage medium. This storage medium stores a computer program, which, when executed by a processor, implements the distributed trusted sandbox construction method for on-chain and off-chain collaboration provided in this embodiment. The storage medium can be any medium capable of storing program code, such as a USB flash drive, external hard drive, read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk.

[0135] This embodiment provides an electronic device for implementing a distributed trusted sandbox construction method for on-chain and off-chain collaboration. For example... Figure 7 As shown, the electronic device may include a processor 22 and a memory 21. The memory 21 stores a computer program, and the processor reads and executes the computer program in the memory 21 corresponding to the above-described embodiments to implement the distributed trusted sandbox construction method for on-chain and off-chain collaboration provided in this embodiment.

[0136] See also Figure 7 The electronic device also includes a communication unit 23. The memory 21, processor 22 and communication unit 23 are electrically connected to each other directly or indirectly through system bus 24 to realize data transmission or interaction.

[0137] The memory 21 can be an information recording device based on any electronic, magnetic, optical, or other physical principles, used to record execution instructions, data, etc. In some embodiments, the memory 21 can be, but is not limited to, volatile memory, non-volatile memory, memory drive, etc.

[0138] In some embodiments, the volatile memory may be random access memory (RAM); in some embodiments, the non-volatile memory may be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory, etc.; in some embodiments, the storage drive may be a disk drive, solid-state drive, any type of storage disk (such as optical disc, DVD, etc.), or similar storage media, or a combination thereof.

[0139] The communication unit 23 is used to send and receive data over a network. In some embodiments, the network may include a wired network, a wireless network, a fiber optic network, a telecommunications network, an intranet, the Internet, a local area network (LAN), a wide area network (WAN), a wireless local area network (WLAN), a metropolitan area network (MAN), a public switched telephone network (PSTN), a Bluetooth network, a ZigBee network, or a near field communication (NFC) network, or any combination thereof. In some embodiments, the network may include one or more network access points. For example, the network may include wired or wireless network access points, such as base stations and / or network switching nodes, through which one or more components of the service request processing system can connect to the network to exchange data and / or information.

[0140] The processor 22 may be an integrated circuit chip with signal processing capabilities, and may include one or more processing cores (e.g., a single-core processor or a multi-core processor). By way of example only, the processor described above may include a Central Processing Unit (CPU), an Application Specific Integrated Circuit (ASIC), an Application Specific Instruction-set Processor (ASIP), a Graphics Processing Unit (GPU), a Physics Processing Unit (PPU), a Digital Signal Processor (DSP), a Field Programmable Gate Array (FPGA), a Programmable Logic Device (PLD), a controller, a microcontroller unit, a Reduced Instruction Set Computing (RISC) computer, or a microprocessor, or any combination thereof.

[0141] Understandable. Figure 7The structure shown is for illustrative purposes only. Electronic devices may also have more advanced features. Figure 7 Showing more or fewer components, or having with Figure 7 The different configurations shown. Figure 7 The components shown can be implemented using hardware, software, or a combination thereof.

[0142] It should be understood that the apparatus and methods disclosed in the above embodiments can also be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the flowcharts and block diagrams in the accompanying drawings show the architecture, functionality, and operation of possible implementations of apparatus, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram and / or flowchart, and combinations of blocks in block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0143] The above descriptions are merely various embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for constructing a distributed trusted sandbox with on-chain and off-chain collaboration, characterized in that, A method applied to a target node in a distributed system, wherein the target node and other nodes in the distributed system collaborate to execute distributed tasks by establishing a state channel network, the method comprising: Obtain the budget information pre-allocated for the task to be executed, wherein the task to be executed is a subtask of the distributed task, and the budget information includes a preset number of state records and budget costs; During the execution of the task to be executed, task status information for each task stage is collected based on the number of status records, wherein the task status information includes the actual costs incurred in the corresponding stage; The transaction records generated based on the task status information are submitted to the state channel network as off-chain transactions. After the task to be executed is completed, the other nodes compare the final settlement results of all the transaction records with the budgeted fees to verify whether the task execution process of the target node is reliable.

2. The method for constructing a distributed trusted sandbox with on-chain and off-chain collaboration according to claim 1, characterized in that, Based on the number of status records, collect task status information for each task stage, including: When the task to be executed is started, a preset execution monitoring configuration is loaded, wherein the execution monitoring configuration defines multiple status acquisition events corresponding to the number of status records; If the execution progress of the task to be executed triggers any status acquisition event, the execution context information of the current task stage is obtained; The execution context information is used as the task status information.

3. The method for constructing a distributed trusted sandbox with on-chain and off-chain collaboration according to claim 2, characterized in that, The execution context information includes a formal language summary of the executable code. Obtaining the execution context information for the current task stage includes: Obtain the code execution record of the task to be executed in the current task stage; Extract the summary information of the code execution record to obtain a formal language summary of the executed code.

4. The method for constructing a distributed trusted sandbox with on-chain and off-chain collaboration according to claim 1, characterized in that, The method further includes: If a valid response to the transaction record is received from the other nodes, the transaction record is written as a new node into the off-chain ledger based on the directed acyclic graph.

5. The method for constructing a distributed trusted sandbox with on-chain and off-chain collaboration according to claim 4, characterized in that, Writing the transaction record as a new node into the off-chain ledger based on a directed acyclic graph includes: Select at least two legitimate transactions from the off-chain ledger as parent transaction nodes; If the parent transaction node passes the validity verification, the transaction record becomes a child node of the parent transaction node, and a directed reference relationship is constructed for each parent transaction to obtain a new off-chain ledger.

6. The method for constructing a distributed trusted sandbox with on-chain and off-chain collaboration according to claim 5, characterized in that, The method further includes: Broadcast the new off-chain ledger to other participating nodes within the state channel; Increase the reference weight of each parent transaction node, where the reference weight of each parent transaction node represents its own credibility.

7. The method for constructing a distributed trusted sandbox with on-chain and off-chain collaboration according to claim 1, characterized in that, The target node is deployed with a task container and a service container. The task container is used to run the task to be executed, and the service container is used to run the task to perform trusted verification with other nodes. The target node and the other nodes are all configured with a trusted execution environment that runs a monitor copy. The monitor copy of the target node is used to monitor the behavior of the task container and the service container. The monitor copy of the target node and the monitor copies of the other nodes share immutable static code and independently maintain their respective dynamic data states. The method further includes: If a status update notification from a task container is received through the monitor replica, cross-replica collaborative verification is performed with the other nodes, and the update is only executed after more than half of the monitor replicas of the nodes reach a consensus. If the trusted execution environment of the target node restarts due to a failure, the latest snapshot of the monitor replica is obtained from other nodes, and the operation of the monitor replica is restored based on the latest snapshot.

8. A distributed trusted sandbox construction device for on-chain and off-chain collaboration, characterized in that, An apparatus for use with a target node in a distributed system, which collaborates with other nodes in the distributed system to execute distributed tasks by establishing a state channel network, the apparatus comprising: The budget information module is used to obtain the budget information pre-allocated for the task to be executed, wherein the task to be executed is a subtask of the distributed task, and the budget information includes a preset number of status records and budget costs; The task monitoring module is used to collect task status information for each task stage during the execution of the task to be executed, based on the number of status records, wherein the task status information includes the actual costs incurred in the corresponding stage. The transaction record module is used to generate transaction records based on the task status information and submit the transaction records as off-chain transactions to the state channel network so that after the task to be executed is completed, the other nodes will compare the final settlement results of all the transaction records with the budgeted fees to verify whether the task execution process of the target node is reliable.

9. A storage medium, characterized in that, The storage medium stores a computer program, which, when executed by a processor, implements the on-chain and off-chain collaborative distributed trusted sandbox construction method as described in any one of claims 1-7.

10. An electronic device, characterized in that, The electronic device includes a processor and a memory, the memory storing a computer program, which, when executed by the processor, implements the on-chain and off-chain collaborative distributed trusted sandbox construction method according to any one of claims 1-7.

Images