A cross-chain execution control method and system based on identity binding trusted execution environment relay

Abstract

The application discloses a cross-chain execution control method and system based on identity binding trusted execution environment relay, generates a relay node long-term identity key pair in a trusted execution environment, and submits a registration request to an identity registration module in combination with organization endorsement; the identity registration module completes relay identity registration after verification; the user capability certificate is subjected to permission verification in the trusted execution environment, a short-time session key pair is derived after verification, and is registered to a session registration table; a source chain gateway inquires the session registration table according to a session handle, executes locking on a to-be-transferred object and generates a source chain locking snapshot record after the session is valid and signature verification is passed; the relay node listens to the locking event, submits a relay message, a session signature and the source chain locking snapshot record to a target chain; the target chain performs proof gating verification, executes a target chain state updating operation after verification, and writes a cross-chain execution identifier into a processed set in an atomic manner.

Description

Technical Field

[0001] This invention relates to the field of blockchain technology, and in particular to a cross-chain execution control method and system based on identity-bound trusted execution environment relay. Background Technology

[0002] With the rapid development of consortium blockchains, industry blockchains, and heterogeneous blockchain networks, the demand for data collaboration, asset migration, business linkage, and state sharing between different chains is increasing. To achieve inter-chain interoperability, the industry has proposed various cross-chain communication, cross-chain verification, and cross-chain execution solutions, such as mechanisms based on relays, gateways, light client verification, proof submission, hash time locking, or multi-signature confirmation. However, in consortium blockchain cross-chain execution scenarios, existing technologies still face a series of unavoidable problems.

[0003] First, relay nodes or execution proxies in existing solutions often rely on long-term valid node certificates, long-term private keys, or fixed identity identifiers to undertake the responsibilities of cross-chain message signing and execution forwarding. Since cross-chain execution usually runs on a continuously online hot path, if long-term credentials are exposed, copied, or unauthorizedly invoked during operation, it may lead to continuous unauthorized forwarding, signature misuse, or abuse of permissions.

[0004] Secondly, many cross-chain solutions use public trace identifiers, transaction serial numbers, or context numbers to track cross-chain requests. However, without strict one-time consumption control, the same cross-chain request may be submitted, replayed, or interpreted repeatedly, leading to abnormal results such as repeated asset mints, repeated state unlocks, and repeated message confirmations.

[0005] Furthermore, existing cross-chain execution mechanisms often require the target chain to bear a heavy verification burden, such as re-verifying the source chain's consensus results, verifying complete inclusion proofs, performing complex proof calculations, or synchronizing a large number of historical states. While this approach theoretically enhances cross-chain security, it significantly increases the execution overhead, access complexity, and maintenance costs of the target chain in engineering deployment.

[0006] Furthermore, traditional cross-chain solutions suffer from the problem of overly tight coupling between execution permissions and long-term identities. If a long-term identity is directly used as the cross-chain execution identity, the exposure of the long-term identity will amplify security risks; if an anonymous relay or weak identity mechanism is adopted, there will be significant deficiencies in auditing, governance, accountability, and permission attribution.

[0007] Therefore, there is an urgent need for a new cross-chain execution control mechanism that can still achieve trusted relay, short-term authorization, single-consumption control, and lightweight gating verification on the target side without relying on the continuous exposure of long-lifecycle credentials, thereby improving the security, efficiency, and deployability of cross-chain execution in consortium blockchains. Summary of the Invention

[0008] To address the shortcomings of existing technologies, the present invention aims to provide a cross-chain execution control method and system based on identity-bound trusted execution environment relay, thereby overcoming the aforementioned deficiencies in existing technologies.

[0009] To achieve the above objectives, the present invention provides the following technical solution:

[0010] A cross-chain execution control method based on identity-bound trusted execution environment relay includes:

[0011] The identity access process involves generating a long-term identity key pair for the relay node within a trusted execution environment, generating a hardware certificate based on the long-term identity public key, and submitting a registration request to the identity registration module in conjunction with organizational endorsement. The identity registration module then verifies the certificate signature, hardware certificate, public key binding relationship, and organizational identifier to complete the relay identity registration.

[0012] The session authorization step involves verifying the user's capability credentials within a trusted execution environment. Once the verification is successful, a short-term session key pair is derived, a session handle is generated, and the session handle is registered in the session registry.

[0013] In the source chain locking step, the source chain gateway queries the session registry based on the session handle. After the session is valid and the signature verification is successful, it locks the object to be transferred and generates a source chain locking snapshot record.

[0014] The relay submission step involves the relay node listening for the lock event and then submitting the relay message, session signature, and source chain lock snapshot record to the target chain.

[0015] The target chain executes the following steps: it sequentially performs proof gating verification on session validity, session signature, authorization signature for locking snapshot, field consistency, freshness, and uniqueness of cross-chain execution identifier. If the verification passes, it performs a target chain state update operation and atomically writes the cross-chain execution identifier into the processed set. If the verification fails, the execution is terminated and the target chain state is not changed.

[0016] Preferably, the hardware proof is generated by the trusted execution environment based on the long-term identity public key, used to prove that the long-term identity key pair was generated by the trusted execution environment and that the private key does not leave the trusted execution environment; the identity registration module performs the following verifications on the registration request: verifying that the certificate signature is legal and valid, verifying that the hardware proof binding public key is consistent with the long-term identity public key, verifying that the organization identifier is consistent with the hardware execution environment, and verifying that the long-term identity public key has not been revoked; if any verification fails, the relay identity is not accepted.

[0017] Preferably, the session handle is generated by the trusted execution environment through a hash operation on the relay identity, session public key, session validity period, and random number; the session registry records the session handle, session public key, relay identity, session validity period, session status, and revocation reason; the session status includes at least active, expired, revoked, and consumed; the session enters the active state after registration, enters the expired or revoked state after reaching its validity period or being revoked, and enters the consumed state after the target chain is successfully executed once; and when the trusted execution environment restarts, if it fails to restore the corresponding session status from sealed storage or external registry, the session is marked as invalid and a new session is required to be derived, and sessions in an inactive state are determined to be invalid in both the source chain locking step and the target chain execution step.

[0018] Preferably, the source chain lock snapshot record includes at least a cross-chain execution identifier, a locked business tag, a session handle, a source chain identifier, a locked state, a source chain transaction hash, a locked event hash, a snapshot timestamp, an authorized signature, and a locked object. The source chain lock snapshot record is generated by a single authorized signer or by multiple authorized signers jointly generating it according to a threshold signing method. The target chain verifies the authorized signature based on the public key of the signers in the authorized list. If the verification fails, the execution is terminated. The authorized list is maintained by the governance contract, the registration module, or the alliance management node, and supports the addition, revocation, and rotation of authorized signers. The current valid list version is identified by the version number or the height of the effective block.

[0019] Preferably, the proof gating verification in the target chain execution step includes: querying the session registry based on the session handle and verifying the session status; verifying that the relay message is signed by the session private key and that the signature content covers the key fields of the cross-chain request; verifying the authorization signature in the source chain lock snapshot record, wherein the authorization signature includes snapshot signature verification and authorization list verification; verifying that the relay message is consistent with the cross-chain execution identifier, session handle, and source chain identifier in the source chain lock snapshot record; verifying that the lock status is locked and the snapshot timestamp is within a preset freshness window; checking that the cross-chain execution identifier does not exist in the processed set; if any step fails to verify, the target chain execution is immediately terminated.

[0020] Preferably, the cross-chain execution identifier is written to the processed set in an atomic manner only after the target chain state update operation is successfully executed; if the state update fails, it is not written to the processed set; when the same cross-chain execution identifier is received subsequently, the target chain refuses to execute it again by querying the processed set; after the refund is restored, the source chain marks the corresponding cross-chain execution identifier as a refunded state and unlocks the state.

[0021] Preferably, the target chain state update operation includes at least one of asset minting, asset unlocking, state synchronization, certificate issuance, permission activation, or order confirmation; after the target chain completes the state update, it sends an execution confirmation notification to the source chain or governance module, and the source chain marks the corresponding cross-chain execution identifier as completed based on the execution confirmation notification.

[0022] A cross-chain execution control system based on identity-bound trusted execution environment relay includes an identity access module, a session authorization module, a source chain locking module, a target chain proof gating module, a processed record module, and a timeout recovery module;

[0023] The identity access module is used to generate long-term identity key pairs and complete hardware proof binding;

[0024] The session authorization module is used to derive session key pairs, generate session handles, and maintain the session registry.

[0025] The source chain locking module is used to perform locking operations and generate source chain locking snapshot records;

[0026] The target chain proof gating module is used to sequentially verify session validity, session signature, authorization signature for locking snapshot, field consistency, freshness, and uniqueness of cross-chain execution identifier, and to perform target chain state update after the verification is passed;

[0027] The processed record module is used to write the cross-chain execution identifier after the state update is successful;

[0028] The timeout recovery module is used to unlock and return the object to be transferred when a timeout occurs or execution fails.

[0029] The beneficial effects of this invention are as follows: It separates long-term identity from short-term execution permissions, reducing the exposure of long-term credentials in hot paths; it generates short-term session keys and session handles within a trusted execution environment, making execution authorization time-sensitive, revocable, and auditable; it compresses the heavy source chain verification process into lightweight structure verification and authorization verification by locking snapshot records on the source chain and gating the target-side proof; it suppresses replay attacks and repeated execution by implementing single-consumption control on public trace identifiers; it forms a compact, secure, and auditable path suitable for cross-chain execution in consortium blockchains through a combination of identity binding, state gating, time gating, and single-consumption gating; it eliminates the burden of full source chain re-verification on the target chain, thereby reducing deployment complexity and execution costs; and it exhibits good engineering adaptability and scalability under multi-organization, multi-chain, and multi-role governance structures. Attached Figure Description

[0030] Figure 1 This is a flowchart of the method of the present invention;

[0031] Figure 2This is a schematic diagram of the system structure of the present invention;

[0032] Figure 3 This is a flowchart illustrating the gate control judgment process for the target side of the present invention.

[0033] Figure 4 This is a schematic diagram illustrating session registration and lifecycle management according to the present invention;

[0034] Figure 5 This is a flowchart illustrating the linkage between source chain locking and target chain execution in this invention. Detailed Implementation

[0035] like Figures 1-5 As shown, the specific implementation of the cross-chain execution control method based on identity-bound trusted execution environment relay provided by the present invention will be further described in detail. Those skilled in the art can make various modifications, equivalent substitutions, or variations to the following embodiments without departing from the spirit and substance of the present invention, and all such modifications, equivalent substitutions, or variations should fall within the protection scope of the present invention.

[0036] The cross-chain execution control system described in this embodiment operates in a multi-chain network environment consisting of at least two heterogeneous consortium chains. The source chain is responsible for performing locking operations on the object to be transferred, relay nodes act as inter-chain transmission media, and the target chain completes the final state update according to gating rules. To enable the target chain to implement effective permission control without re-verifying the source chain's consensus, this embodiment employs a combination of a trusted execution environment and an identity binding mechanism. The exposure of long-term identity credentials is limited to the admission phase, and a short-term session authorization mechanism serves as the basis for daily cross-chain execution permissions.

[0037] Before participating in cross-chain execution, relay nodes must complete an identity access process. This process takes place within a trusted execution environment (TEA) and is verified using hardware proofs. A TEA is a secure execution domain with hardware-level isolation capabilities. Typical implementations include TEAs provided by processor security extension technologies such as Intel SGX and ARM TrustZone. Code and data running within this environment are protected by hardware-level isolation, preventing external host operating systems or superusers from directly reading or modifying its internal state. Within this secure region, relay nodes generate long-term identity key pairs, ensuring that the private key remains within the TEA from its generation and is never exposed to the outside world in plaintext.

[0038] In its implementation, the long-term identity key pair of the relay node is generated by the key generation module within the trusted execution environment, and the generated long-term identity public key is denoted as... The corresponding private key is denoted as , Persistently stored in the trusted storage area of ​​a trusted execution environment. It can be made public.

[0039] After key generation is complete, the Trusted Execution Environment (TEE) is based on... Generate hardware proof. Hardware proof is a structured proof data provided by the Trusted Execution Environment (TEE) to external verifiers. Its content is generated by the trusted root of trust of the hardware platform and includes a code digest of the security domain, runtime configuration information, and a signature of a specific data binding value. The core function of hardware proof is to demonstrate to external verifiers that the specified public key was indeed generated internally by the TEE and that the corresponding private key has not left the TEE domain.

[0040] Simultaneously with the generation of hardware proof, the organization or consortium governance body to which the relay node belongs endorses the ownership of the public key, forming a node certificate. The node certificate can be formally represented as follows:

[0041]

[0042] in, For node certificates, This is the node's public key, i.e., the long-term identity public key of the relay node; The organization identifier identifies the alliance member organization or institution to which the relay node belongs; For the organization's A signature or endorsement certificate used to confirm It does indeed belong to the organization stated in the declaration. Furthermore, it can be based on... The hash value generates a decentralized identifier for the node, in the form of... , where H represents the hash function, and this decentralized identifier is used as a unique identity index for relay nodes in subsequent session management and cross-chain auditing.

[0043] The relay node then submits its node certificate, hardware verification, and organizational endorsement information to the identity registration module, initiating a registration request. The identity registration module, as the trusted identity management entity within the consortium, sequentially verifies each element in the registration request: verifying the organizational signature on the node certificate. The legality and validity of the hardware proof; verifying the public key bound to the node certificate. Pointing to the same public key ensures consistency between the proof data and the identity claim; verifying the information recorded in the certificate. Consistent with the actual attribution to the hardware execution environment; verification. The relay identity is not currently in a revoked state. If any of the above four verifications fails, the identity registration module will refuse to accept the registration request, and the corresponding relay identity will not be registered, thus preventing participation in subsequent session authorization and cross-chain execution processes. Once all verifications are passed, the identity registration module will write the relay node's public key, organization identifier, and node decentralized identifier into the identity registry, completing the relay identity registration.

[0044] Throughout the entire identity access process, the long-term private key It always remains within the trusted execution environment; external systems can only perceive the corresponding public key. And related supporting materials, thereby strictly limiting the exposure of long-term identity keys to within the trusted execution boundary.

[0045] Once identity access is granted, relay nodes possess the basic identity qualifications to participate in cross-chain execution. However, daily cross-chain execution does not directly use long-term identity keys for signing. Instead, a short-term session authorization mechanism is used to derive a unique short-term session key pair for each specific cross-chain execution request, in order to minimize the exposure frequency of long-term identity keys on the execution hot path.

[0046] When a user submits a cross-chain execution request along with a capability credential, the request is forwarded to the relay execution logic within the trusted execution environment. The capability credential is structured data issued by an authorizing party, describing the scope of execution permissions the holder possesses under specific conditions. Its content typically includes: user identification, permitted cross-chain pairs or business scenarios, permitted asset types or state ranges, the credential's effective and expiration times, and other constraint parameters defined by governance policies. Upon receiving the capability credential, the relay logic verifies the credential's signature validity, permission boundaries, executable target chain range, and effective time window item by item. After successful credential verification, the trusted execution environment generates a short-term session key pair for this execution request; the session public key is denoted as [key name missing]. The session private key is recorded as And set the validity period of the session key pair. .

[0047] After generating the session key pair, construct the following session binding record:

[0048]

[0049] in, This is the public key for the session corresponding to this session. This is the expiration timestamp for the session, indicating the final moment when the session key pair becomes valid. Based on the session binding record, the session handle is further calculated:

[0050]

[0051] in, H is the session handle, used as a unique index for this session in the registry and subsequent verification steps; H is the hash function, which performs a one-way mapping on the concatenated string within the parentheses. A decentralized identifier for relay nodes; This is the public key for this session; Session validity period; This is a random number, used to ensure that different session handles are generated even with the same parameters, thus preventing handle collisions. (Symbol) This indicates a byte concatenation operation.

[0052] After the session handle is calculated, the following session registration entries will be created:

[0053]

[0054] Register to the session registry. Among them, Indicated by Register an entry for the session using the index key. This is the identifier of the relay node to which it belongs. For the corresponding session public key, This is the expiry date.

[0055] In addition to recording the basic fields mentioned above, the session registry also maintains a session status field for each session record. The session status describes the current lifecycle stage of the session and includes at least the following values: CREATED indicates that the session key has been generated within the trusted execution environment but has not yet been registered with the registry; ACTIVE indicates that the session has been registered and is currently within its valid time window, and can be used for actual cross-chain execution; EXPIRED indicates that the session has exceeded its set validity period and is no longer eligible for execution; REVOKED indicates that the session has been actively revoked by the governance module, relay gateway, or a preset revocation authorization entity; CONSUMED indicates that the session has been successfully used to complete a cross-chain execution and has entered the consumed state. During the source chain locking step and the target chain execution step, only sessions in the ACTIVE state are considered valid; any other state is deemed invalid, and the corresponding execution request will be rejected.

[0056] In addition, the session registry can further record extended information such as the relay identity of the session binding, session creation time, revocation time or revocation reason, the scope of the target chain or business scope allowed to be called, and the maximum number of executions allowed, to support the needs of fine-grained permission control and audit tracing.

[0057] When the trusted execution environment restarts or recovers abnormally, the system rereads the session state from sealed storage, the external registry, or the governance node. If the session state cannot be recovered, or the recovered state is inconsistent with the local hardware integrity verification result, the corresponding session is immediately marked as invalid, and the session derivation process needs to be re-executed to obtain a new valid session. Temporary sessions that fail to be persisted are considered invalid after a restart and must not be used for cross-chain execution.

[0058] After session registration is complete, the source chain gateway queries the session registry based on the session handle κ carried in this execution request and reads the corresponding session entry. The source chain gateway then sequentially checks the existence and validity of the session: verifying that the session registry contains a session handle κ. For the indexed entry; confirm that the session is currently in the ACTIVE state; confirm that the current time has not exceeded the session validity period. Confirm that the session has not been revoked or consumed; and confirm the identity of the relay node as stated. The identity is consistent with the bound identity recorded in the session registration entry. Furthermore, the source chain gateway verifies the signature attached to this execution request, confirming that the signature was created using the session private key. The generated signature covers the key parameter fields of this cross-chain request and conforms to the permission constraints in the capability credential.

[0059] After all the above verifications pass, the source chain gateway performs a locking operation. The specific form of the locking operation varies depending on the business scenario; it can be freezing on-chain assets, exclusive use of state variables, reservation of business resources, or cross-chain state marking of specific on-chain objects. After the locking operation is completed, the source chain generates a locked state record and triggers a locking event to notify the relay node that subsequent cross-chain commits are possible.

[0060] Once the locking is complete, the source chain gateway generates a source chain locking snapshot record, which is represented as a tuple:

[0061]

[0062] in, The cross-chain execution identifier is a unique identifier for this cross-chain execution request, used to track the execution status of this cross-chain operation throughout the entire process, and serves as the core identifier for single consumption control; ℓ is the locked business tag, describing the business type or asset class corresponding to this lock; The session handle is consistent with the entry index in the session registry and is used to associate session information on the target chain side; srcID is the source chain identifier, which identifies the blockchain network that initiated this locking operation; st is the locking state, which records the current state of the locking operation. When the locking is completed normally, the value is LOCKED. The source chain transaction hash is the hash value of the on-chain transaction that completed the locking operation. The lock event hash, which is the hash value of the lock event data generated by the source chain; 'a' is the snapshot timestamp, recording the time value at which the snapshot was generated, used for subsequent freshness verification; 'a' is the locked object, describing the specific content of the asset, state, or business object locked this time; 's' is the authorized signature, a signature value generated by a pre-registered authorized signer based on the content of the above fields.

[0063] The signature content of the authorized signature s is at least And all or part of the fields in 'a', the specific coverage is determined by the consortium governance strategy. Authorized signatures can be generated by a single authorized signer, or jointly by multiple authorized signers according to a threshold signature method. Threshold signatures require a preset threshold number of authorized parties to constitute a valid signature. The target chain receives... Then, the authorized signature s is verified based on the public key of the signer recorded in the pre-maintained authorized list. If the signature verification fails or the signer is not in the authorized list, the target chain directly refuses to execute.

[0064] Source chain locked snapshot record It can also carry extended fields according to specific business needs, including target chain identifier, asset type, business call method name, lock timeout time, revocation identifier, target execution sequence number, session creation time and other business constraint parameters, to adapt to the information transmission needs of different cross-chain business scenarios.

[0065] The authorized signer list is maintained by the governance contract, registration module, or consortium management node. It supports adding, revoking, and rotating authorized signers, and identifies the current valid list version through a version number or effective block height. When an authorized signer is revoked, their subsequent signatures are no longer accepted by the target chain. The authorized list can also be maintained separately according to target chain identifier, business type, or chain pair relationship to support imposing differentiated authorization boundary constraints on different cross-chain businesses.

[0066] Relay nodes continuously monitor locking events on the source chain. Upon detecting a locking event generated by the source chain gateway, the relay node extracts the locking event data and the corresponding source chain locking snapshot record. The relay node then assembles the relay message. The relay message must contain at least a description of the intent for this cross-chain execution and key parameter fields. The signature field is generated by the relay node using the currently active session private key. A signature is generated for key fields of the relay message. The signature must cover the key fields of the cross-chain request, including the cross-chain execution identifier τ, the session handle κ, and the source chain identifier srcID, to ensure that the consistency of fields between the relay message and the corresponding source chain lock snapshot record can be verified by the target chain. The relay node then forwards the relay message, session signature, and source chain lock snapshot record. The entire process is submitted to the target chain gateway or target execution module to initiate the target chain execution process.

[0067] During the relay message submission process, the actual cross-chain execution operation of the relay node is performed using the session key sksess rather than the long-term identity key. The signature and long-term identity key do not undergo any cryptographic operations on the hot path of cross-chain execution, thus strictly limiting the risk of exposure of long-term credentials to the identity access and session authorization stages, and achieving decoupling of long-term identity and short-term execution permissions.

[0068] After receiving the relay message, session signature, and source chain lock snapshot record submitted by the relay node, the target chain sequentially performs proof-gated verification on each condition. The target chain state update operation is only performed when all conditions are met. The following provides a detailed explanation of each step according to the execution order of the verification.

[0069] The first step in the target chain proof-gated verification is session validity verification. The target chain relies on the session handle carried in the relay message. Initiate a query to the session registry to confirm... The indexed session record exists, and the session is currently in the ACTIVE state and has not yet expired. The session was not actively revoked, and the identity of the relay node bound to the session was also considered. Consistent with the source of the relay message declaration. If the session does not exist, is inactive, has expired, or has been revoked, the target chain immediately terminates execution without changing any target chain state.

[0070] The second step is session signature verification. The target chain retrieves the signature from the session registry. Corresponding session public key The public key is used to verify the session signature attached to the relay message, confirming that the signature was indeed created by the sender. The generated signature must cover the key fields of this cross-chain request. The signature's coverage must include at least the cross-chain execution identifier. Session handle The source chain identifier (srcID) is used to ensure that relay messages cannot be misappropriated or forged between different cross-chain execution instances. Execution is immediately rejected if verification fails.

[0071] The third step is the authorization signature verification for locking the snapshot, which includes two sub-steps: snapshot signature verification and authorization list verification. The target chain locks the snapshot record from the source chain. Extract the authorized signature s, verify the signer's identity against the pre-maintained authorized list, confirm that the signer who generated the authorized signature is in the currently valid authorized list, and verify that signature s is valid. The correctness of the corresponding fields is checked. If the signature is missing, the signature value fails verification, or the signer is not in the authorized list, the target chain will immediately terminate execution.

[0072] The fourth step is field consistency verification. The target chain will verify the cross-chain execution identifier τ and session handle recorded in the relay message. and the source chain identifier srcID, which is respectively associated with the source chain lock snapshot record. Each field in the corresponding record is compared item by item to confirm that all three are completely consistent. This consistency verification ensures that relay nodes cannot reuse snapshot records for a specific cross-chain execution for execution requests with different parameters, and also prevents fields from being tampered with by intermediate links. If the verification fails, execution is terminated immediately.

[0073] The fifth step is freshness verification. Target chain verification. The `st` field in the lock status field is set to `LOCKED`, and the snapshot timestamp is verified. Within the preset freshness window. The freshness window is a pre-defined time interval set by governance policies or chain configuration parameters. It restricts the acceptance and execution of outdated snapshot records to prevent historical locked records from being submitted to the target chain after their lock validity period expires, leading to unexpected execution. The freshness window can be configured differently according to chain type, business type, or risk level. If st is not LOCKED or If the freshness window is exceeded, execution will be terminated immediately.

[0074] The sixth step is the uniqueness verification of the cross-chain execution identifier, i.e., single-consumption verification. The target chain queries the processed set P and checks the cross-chain execution identifier. Does it already exist in set P? The processed set P is a data structure maintained by the target chain to record all successfully consumed cross-chain execution identifiers. Its function is to implement strict one-time consumption control for the same cross-chain request. If If it has already appeared in P, it means that the cross-chain execution identifier has been consumed. The target chain directly refuses to execute and returns a duplicate processing error, without changing the target chain state.

[0075] Once all six verification steps above have passed, the target chain can then perform a target chain state update operation. The specific content of the target chain state update operation depends on the business scenario and includes, but is not limited to: performing a minting operation on the corresponding asset on the target chain, performing an unlocking operation on a pre-locked asset on the target chain, synchronously writing the state changes occurring on the source chain to the target chain, issuing business credentials to a designated recipient, activating business permissions for a specific account or contract, and confirming the completion status of a specific cross-chain business order.

[0076] After the target chain state update operation is successfully executed, the cross-chain execution identifier is atomically set. Write to the processed set P, ensuring that the write operation and the state update operation are within the same indivisible transaction. Only after the state update is successful... The state is written to P; if the state update fails for any reason, then Do not write to P to ensure that The uniqueness verification will still pass upon subsequent resubmissions, providing conditions for possible retries. If any step of the target chain's proof-gated verification fails, the entire target chain execution process will immediately terminate, and the state of any asset or contract on the target chain will remain unchanged. It will not be written to P.

[0077] After the target chain completes its state update, it sends an execution confirmation notification to the source chain or governance module. Upon receiving the execution confirmation notification, the source chain marks the corresponding cross-chain execution identifier τ as completed, thus bringing the cross-chain execution to its final state.

[0078] In some cases, the source chain may have completed locking and generated a source chain lock snapshot, but the target chain may fail to complete execution within a preset time window. This could be due to network failures, target chain overload, premature session termination, or the target chain continuously refusing execution without a viable remedy. In these situations, the system supports triggering a timeout recovery process from the source chain or the governance module.

[0079] The triggering conditions for the timeout recovery process include: the timestamp of the source chain lock snapshot record exceeds the preset validity period, the target chain execution continues to fail and there is no successful remedy path, the session is revoked, causing the cross-chain request to be unable to continue to be executed, and the governance policy determines that the locked assets should be returned to the original owner.

[0080] The timeout recovery process includes: releasing the lock on the corresponding locked object on the source chain and returning the locked asset or state to the original owner; generating a recovery event record on the source chain; and marking the corresponding cross-chain execution identifier τ as either refunded or recovered on the source chain. After the recovery process is complete, if the target chain subsequently receives another object carrying the same... If the target chain fails to execute the request, it will refuse to execute because the corresponding lock state field on the source chain side will not meet the LOCKED condition. This prevents the refunded cross-chain request from triggering repeated execution on the target chain after the timeout is restored.

[0081] To support the aforementioned timeout recovery mechanism, the core state transitions throughout the cross-chain execution process must adhere to the following constraints: an illegal state cannot directly transition to a successful execution state; the same cross-chain execution identifier... A completed state can only be entered once on a successful execution path; once a refund or recovery is completed, the same cross-chain execution identifier must not be treated as a completely new, unprocessed request and accepted again.

[0082] At the system level, the execution logic of each of the above stages is carried out by corresponding functional modules. The Identity Access Module is responsible for generating long-term identity key pairs and binding hardware proofs within the trusted execution environment, serving as the starting point of the entire system's trust chain. The Session Authorization Module completes the derivation of session key pairs, calculation of session handles, and maintenance of the session registry within the trusted execution environment, providing independent, time-sensitive execution authorization for each cross-chain execution request. The Source Chain Locking Module receives valid session credentials output by the Session Authorization Module, completes the locking operation at the source chain gateway, and generates a locking snapshot record, responsible for transmitting the locking state result to the relay node in a verifiable, structured form. The Target Chain Proof Gating Module performs gating verification item by item according to the six verification steps described in this implementation, serving as the core guarantee for the target chain's security. The Processed Record Module maintains the processed set P, atomically writing the cross-chain execution identifier after a successful state update, supporting the single-consumption control mechanism. The Timeout Recovery Module triggers a recovery process when execution times out or fails, ensuring that assets on the source chain side are properly disposed of and maintaining the overall system's eventual consistency.

Claims

1. A cross-chain execution control method based on identity-bound trusted execution environment relay, characterized in that, include: The identity access process involves generating a long-term identity key pair for the relay node within a trusted execution environment, generating a hardware certificate based on the long-term identity public key, and submitting a registration request to the identity registration module in conjunction with organizational endorsement. The identity registration module then verifies the certificate signature, hardware certificate, public key binding relationship, and organizational identifier to complete the relay identity registration. The session authorization step involves verifying the user's capability credentials within a trusted execution environment. Once the verification is successful, a short-term session key pair is derived, a session handle is generated, and the session handle is registered in the session registry. In the source chain locking step, the source chain gateway queries the session registry based on the session handle. After the session is valid and the signature verification is successful, it locks the object to be transferred and generates a source chain locking snapshot record. The relay submission step involves the relay node listening for the lock event and then submitting the relay message, session signature, and source chain lock snapshot record to the target chain. The target chain execution steps include proof gating verification and target chain state update operations. Specifically, the target chain sequentially performs proof gating verification on session validity, session signature, authorization signature for locking snapshot, field consistency, freshness, and uniqueness of cross-chain execution identifier. If the verification passes, the target chain state update operation is performed, and the cross-chain execution identifier is written to the processed set atomically. If the verification fails, the execution is terminated and the target chain state is not changed.

2. The cross-chain execution control method based on identity-bound trusted execution environment relay according to claim 1, characterized in that, The hardware proof is generated by the trusted execution environment based on the long-term identity public key, and is used to prove that the long-term identity key pair was generated by the trusted execution environment and that the private key does not leave the trusted execution environment; the identity registration module performs the following verifications on the registration request: verifying that the certificate signature is legal and valid, verifying that the hardware proof binding public key is consistent with the long-term identity public key, verifying that the organization identifier is consistent with the hardware execution environment, and verifying that the long-term identity public key has not been revoked; if any verification fails, the relay identity will not be accepted.

3. The cross-chain execution control method based on identity-bound trusted execution environment relay according to claim 1, characterized in that, The session handle is generated by the trusted execution environment through a hash operation on the relay identity, session public key, session validity period, and random number; the session registry records the session handle, session public key, relay identity, session validity period, session status, and revocation reason; the session status includes at least active, expired, revoked, and consumed; After registration, a session enters an active state. After reaching its expiration date or being revoked, it enters an expired or revoked state. After the target chain is successfully executed once, it enters a consumed state. If the corresponding session state cannot be restored from the sealed storage or external registry after the trusted execution environment restarts, the session will be marked as invalid and a new session will be required to be derived. Sessions in an inactive state are deemed invalid in both the source chain locking step and the target chain execution step.

4. The cross-chain execution control method based on identity-bound trusted execution environment relay according to claim 1, characterized in that, The source chain lock snapshot record includes at least the cross-chain execution identifier, lock business tag, session handle, source chain identifier, lock status, source chain transaction hash, lock event hash, snapshot timestamp, authorized signature, and lock object. The source chain lock snapshot record is generated by a single authorized signer or by multiple authorized signers jointly generating it according to a threshold signing method. The target chain verifies the authorized signature based on the public key of the signers in the authorized list. If the verification fails, the execution is terminated. The authorized list is maintained by the governance contract, registration module, or alliance management node, and supports the addition, revocation, and rotation of authorized signers. The current valid list version is identified by the version number or effective block height.

5. The cross-chain execution control method based on identity-bound trusted execution environment relay according to claim 1, characterized in that, The proof gating verification in the target chain execution steps includes: querying the session registry based on the session handle and verifying the session status; verifying that the relay message is signed by the session private key and that the signature content covers the key fields of the cross-chain request; verifying the authorization signature of the locked snapshot in the source chain lock snapshot record, the verification including snapshot signature verification and authorization list verification; verifying that the relay message is consistent with the cross-chain execution identifier, session handle and source chain identifier in the source chain lock snapshot record; verifying that the lock status is locked and the snapshot timestamp is within a preset freshness window; checking that the cross-chain execution identifier does not exist in the processed set; if any step fails to verify, the target chain execution is immediately terminated.

6. The cross-chain execution control method based on identity-bound trusted execution environment relay according to claim 5, characterized in that, The cross-chain execution flag is written to the processed set only atomically after the target chain state update operation is successfully executed. If the state update fails, it will not be written to the processed set; if the same cross-chain execution identifier is received subsequently, the target chain will refuse to execute it again by querying the processed set; after the refund is restored, the source chain will mark the corresponding cross-chain execution identifier as refunded and release the locked state.

7. The cross-chain execution control method based on identity-bound trusted execution environment relay according to claim 1, characterized in that, The target chain state update operation includes at least one of asset minting, asset unlocking, state synchronization, certificate issuance, permission activation, or order confirmation. After the target chain completes the state update, it sends an execution confirmation notification to the source chain or governance module. The source chain marks the corresponding cross-chain execution identifier as completed based on the execution confirmation notification.

8. A cross-chain execution control system based on identity-bound trusted execution environment relay, characterized in that, It includes an identity access module, a session authorization module, a source chain locking module, a target chain proof gating module, a processed record module, and a timeout recovery module; The identity access module is used to generate long-term identity key pairs and complete hardware proof binding; The session authorization module is used to derive session key pairs, generate session handles, and maintain the session registry. The source chain locking module is used to perform locking operations and generate source chain locking snapshot records; The target chain proof gating module is used to sequentially verify session validity, session signature, authorization signature for locking snapshot, field consistency, freshness, and uniqueness of cross-chain execution identifier, and to perform target chain state update after the verification is passed; The processed record module is used to maintain the processed set and atomically writes the cross-chain execution identifier after the target chain state is successfully updated. The timeout recovery module is used to unlock and return the object to be transferred when a timeout occurs or execution fails.

Images