Cross-chain methods and systems based on model context protocols

Abstract

This invention discloses a cross-chain method and system based on a model context protocol in the field of intelligent decision-making technology. Applied to network systems, the system includes a source chain protocol layer, a transmission and verification layer, and a target chain protocol layer. The transmission and verification layer connects the source chain protocol layer and the target chain protocol layer. The cross-chain method includes the source chain protocol layer obtaining business intent on the source chain and transforming the abstract business intent into verifiable model context data packets. The transmission and verification layer includes an independent relay verification network with multiple verification nodes, which decentralize the network system. The core entity of the target chain protocol layer is the gateway executing the contract. This invention, by creating and transmitting standardized model context data packets, encapsulates the application layer's state and logic, fundamentally filling the gap in context understanding in existing technologies, and enabling cross-chain communication to possess scenario-based and intelligent capabilities.

Description

Technical Field

[0001] This invention relates to the field of intelligent decision-making technology, specifically a cross-chain method and system based on a model context protocol. Background Technology

[0002] In existing technologies, the general messaging protocol disclosed in the white paper "LayerZero: An Omnichain Interoperability Protocol" published by LayerZero Labs achieves reliable byte message transmission between chains by deploying light nodes (Endpoints) on each chain and relying on a decentralized oracle and relay network. However, the core design of the current technology only stays at the transport layer. Since it does not specify the format and semantics of the message content, a "semantic gap" still exists between upper-layer applications. Developers are forced to develop a large number of non-standard, peer-to-peer application layer protocols. When implementing complex, stateful cross-chain applications (such as cross-chain governance and multi-step DeFi combinations), there are limitations such as high integration costs and strong system fragility.

[0003] Furthermore, while the Inter-Blockchain Communication Protocol (IBC) specification published by the Interchain Foundation achieves efficient and secure interoperability between homogeneous or semi-homogeneous blockchains that follow its specifications through standardized data packets, channels, and connection abstractions, its deep coupling with the underlying framework of the Cosmos SDK results in a severe lack of universality. This makes it difficult to directly apply to heterogeneous blockchains like Ethereum and Solana, whose underlying architectures and consensus mechanisms are completely different. Especially when building an open network that needs to connect heterogeneous ecosystems, existing technologies suffer from the drawback of not being able to natively access these networks and having to rely on trusted third-party bridges. This makes it difficult to meet the fully open interoperability requirements of future Web3 multi-chain ecosystems. At the same time, existing technologies lack the ability to describe complex application-layer states and business logic, leading to a "semantic gap" that restricts cross-ecosystem collaboration of decentralized applications (DApps), making it difficult to effectively understand deep interactions and semantics. Summary of the Invention

[0004] The purpose of this invention is to provide a cross-chain method and system based on a model context protocol, which solves the problem of lack of deep interaction and semantic understanding in current blockchain cross-chain technology.

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

[0006] Firstly, a cross-chain method based on a model context protocol is provided, applied to a network system. The system includes a source chain protocol layer, a transmission and verification layer, and a target chain protocol layer. The transmission and verification layer connects the source chain protocol layer and the target chain protocol layer. The cross-chain method includes:

[0007] The source chain protocol layer obtains the business intent on the source chain and transforms the abstract business intent into a verifiable model context data packet.

[0008] The transmission and authentication layer includes an independent relay authentication network, which includes multiple authentication nodes, and the multiple authentication nodes decentralize the network system;

[0009] The core entity of the target chain protocol layer is the gateway executing the contract. The target chain protocol layer receives and executes cross-chain instructions on the target chain of the target chain protocol layer and verifies the security of the transaction process.

[0010] As a further aspect of the present invention: the source chain protocol layer obtains the business intent on the source chain and transforms the abstracted business intent into a verifiable model context data packet, including:

[0011] The key state of the upper-layer application contract is obtained. When the key state changes to a state that requires cross-chain communication, a function is called to trigger the context to generate a contract, thus forming a cross-chain interaction.

[0012] The context generates a contract that passes in the core business parameters required to trigger the current cross-chain interaction, wherein the core business parameters include the user address, the new state value, and the target chain asset ID;

[0013] The core payload of generating contract aggregation and constructing model context data packets based on the aforementioned context;

[0014] Construct a Model Context Data Package (MCP) and generate a contract assignment sequence number for the context;

[0015] Based on the aforementioned context, a contract is generated to trigger a public on-chain event. By triggering a public on-chain event, the complete MCP data structure can be recorded as a parameter of the event in the source chain's transaction log, achieving complete decoupling between on-chain state changes and cross-chain message passing, which greatly improves the system's security and modularity.

[0016] As a further aspect of the present invention: the core payload of generating contract aggregation and constructing model context data packets based on the context includes:

[0017] Obtain the core business parameters and read the association status between the core business parameters and the contract in the source chain;

[0018] Based on a standard data format, the core business parameters and the associated status are serialized and encoded, wherein the standard data format is a binary format;

[0019] As a further aspect of the present invention: the binary format includes JSON format and Protobuf format. By using JSON format, it is easier to call data, and by using Protobuf format, it is possible to improve the processing efficiency on the chain.

[0020] Based on the current business intent, generate an instruction script describing the operation to be performed on the target chain. The instruction script includes the target function signature, parameter construction method, and condition judgment operation. Alternatively, the instruction script is a series of atomic operations.

[0021] As a further aspect of the present invention: the instruction script is used to specify the target function signature, parameter construction method, condition judgment or a series of atomic operations corresponding to the target chain.

[0022] As a further aspect of the present invention: the construction of the Model Context Data Package (MCP), which generates a contract allocation sequence number for the context, includes:

[0023] A sequence number is assigned based on the upper-layer application contract, wherein the sequence number is strictly monotonically increasing and unique throughout the lifecycle of the assigned contract;

[0024] Recording the sequence number in the storage variable of the context generation contract ensures that each model context data packet sent has a unique identifier, thereby preventing replay attacks at the protocol level.

[0025] As a further aspect of the present invention: the transmission and authentication layer includes an independent relay authentication network, the relay authentication network including multiple authentication nodes, and the multiple authentication nodes decentralize the network system, including:

[0026] Multiple verification nodes listen for and capture events that generate contract broadcasts from the contexts they support;

[0027] When the verification node captures a new event, it performs a finality confirmation operation. The finality confirmation operation refers to waiting for the block containing the event to continue to generate a sufficient number of new blocks to ensure that the event record has been stabilized on the chain and is irreversible. By having the verification node perform the finality confirmation operation, the risks caused by short-term blockchain forks or reorganizations can be effectively mitigated.

[0028] Each verification node independently verifies the validity of the model context data packet;

[0029] Based on a cryptographic hash algorithm, the verification node is driven to process the model context data packet using its own private key to generate a unique data digest;

[0030] The data digest is cryptographically signed to generate independent valid signature data.

[0031] As a further aspect of the present invention: the transmission and authentication layer includes an independent relay authentication network, the relay authentication network includes multiple authentication nodes, the multiple authentication nodes decentralize the network system, and further includes:

[0032] Based on a P2P network, the verification nodes broadcast and synchronize their signatures to each other until the number of signatures of the hash value of the same model context data packet collected by each verification node exceeds a preset consensus threshold. The scattered signatures will be aggregated into a single network consensus credential. When the number of signatures of the hash value of the same model context data packet collected by each verification node exceeds the preset consensus threshold, it indicates that the entire network system has reached a consensus on the authenticity and validity of the message. At this time, the scattered signatures will be aggregated into a single, unforgeable network consensus credential (Consensus Proof). The consensus threshold can be more than two-thirds of the verification nodes in the network.

[0033] Once the network consensus certificate is obtained, one or more relay nodes in the relay verification network will use the original model context data packet and the aggregated network consensus certificate as parameters to package them into a transaction and submit it to the target chain protocol layer for processing.

[0034] As a further aspect of the present invention: the core entity of the target chain protocol layer is a gateway execution contract. The target chain protocol layer receives and executes cross-chain instructions on the target chain of the target chain protocol layer, and verifies the security of the transaction process, including:

[0035] The gateway executes the contract's entry function to receive transactions and verifies the network public credentials in the received transactions;

[0036] The signer's public key or derived address for each signature is recovered based on a public key recovery mechanism. This public key or derived address is then compared with a list of trusted verifier addresses pre-stored within the gateway's execution contract. The public key recovery mechanism is the `ecrecover` function. By comparing the signer's public key or derived address with the list of trusted verifier addresses pre-stored within the gateway's execution contract, the legitimacy of the signer and the compliance of the number of valid signatures can be ensured, thus completing the credential verification.

[0037] Once the signature verification is successful, the gateway executes the contract to check the sequence number in the header of the model context data packet.

[0038] As a further aspect of the present invention: after the signature verification is successful, the gateway executes the contract to check the sequence number in the header of the model context data packet, including:

[0039] Query the state mapping of the executed sequence number recorded inside the model context data packet, and check whether the sequence number is marked as used;

[0040] When the serial number is marked as in use, the transaction will immediately fail and be rolled back;

[0041] When a serial number is marked as unused, its status is immediately marked as used, thereby ensuring the atomicity and uniqueness of the operation and realizing the anti-replay verification of the serial number.

[0042] As a further aspect of the present invention: after the signature verification is successful, the gateway executes the contract to check the sequence number in the header of the model context data packet, which further includes:

[0043] Once the security check passes, the gateway executes the execution logic script in the core payload of the model context data packet, which is parsed by the contract.

[0044] Based on the low-level dynamic invocation function and script instructions of the smart contract platform, invocation data is dynamically constructed and a call to the target DApp contract is initiated. By dynamically constructing invocation data and initiating a call to the target DApp contract based on the low-level dynamic invocation function and script instructions of the smart contract platform, the flexibility and forward compatibility of cross-chain methods can be greatly improved. After the gateway executes the contract and completes the dynamic invocation, it captures the execution result of the dynamic invocation, wherein the execution result includes success, failure, and return value.

[0045] As a further aspect of the present invention: after the gateway executes the contract and completes the dynamic call, it captures the execution result of the dynamic call, wherein the execution result includes success, failure, and a return value, including:

[0046] The gateway execution contract encapsulates the execution result into a receipt data packet;

[0047] By employing a re-triggering chain to broadcast the event to the relay verification network, which then transmits it back to the source chain, and transmitting it back to the source chain through the relay verification network using the same secure process, a complete cross-chain communication loop capable of status confirmation is formed, completing result capture and optional back transmission.

[0048] Secondly, a cross-chain system based on a model context protocol is provided, applied to the cross-chain method based on the model context protocol as described above, wherein the cross-chain system includes:

[0049] The data acquisition and transformation module is configured such that the source chain protocol layer acquires the business intent on the source chain and transforms the abstract business intent into a verifiable model context data packet.

[0050] The system decentralization module is configured such that the transmission and verification layer includes an independent relay verification network, the relay verification network includes multiple verification nodes, and the multiple verification nodes decentralize the network system;

[0051] The security verification module is configured such that the core entity of the target chain protocol layer is the gateway executing the contract. The target chain protocol layer receives and executes cross-chain instructions on the target chain of the target chain protocol layer to verify the security of the transaction process.

[0052] Compared with the prior art, the beneficial effects of the present invention are:

[0053] 1. This invention encapsulates the application layer's state and logic by creating and transmitting standardized model context data packets, fundamentally filling the gap in context understanding in existing technologies and enabling cross-chain communication to have scenario-based and intelligent capabilities.

[0054] 2. This invention provides a universal cross-chain framework for the application layer, enabling DApps on different chains to perform complex logical interactions as securely and conveniently as calling local functions, breaking down the barriers that prevent application functions from being combined due to different underlying architectures.

[0055] 3. By defining a set of standardized protocols and interfaces, this invention greatly reduces the threshold and cost for developers to build and maintain cross-chain distributed applications, and avoids the inefficient work of repeatedly designing private communication schemes for each pair of interactive applications.

[0056] 4. This invention creatively proposes a model context protocol, which can standardize the rules and standards of cross-chain communication at the application layer. By defining and constructing a standardized model context data packet rich in application layer information, the state, execution conditions, data model and verification credentials required by the target chain are atomically encapsulated. Through secure transmission with the help of a decentralized relay verification network, the target chain in cross-chain communication can fully understand the business intent of the source chain and execute the corresponding logic, thereby elevating inter-chain interaction from the asset level to the application logic level. This provides a technical foundation for building a highly collaborative distributed cross-chain application ecosystem and is conducive to improving the functionality of cross-chain communication.

[0057] 5. This invention generates a contract based on the aforementioned context to trigger a public on-chain event, which allows the complete MCP data structure to be recorded as a parameter of the event in the source chain's transaction log. This achieves complete decoupling between on-chain state changes and cross-chain message transmission, greatly improving the system's security and modularity. Attached Figure Description

[0058] Figure 1 This is a diagram illustrating the overall architecture of the present invention;

[0059] Figure 2 This is a flowchart illustrating the execution process in a specific embodiment of the present invention;

[0060] Figure 3 This is a diagram of the internal data structure of the present invention;

[0061] Figure 4 This is a diagram illustrating the method steps of the present invention;

[0062] Figure 5 This is a system module diagram of the present invention.

[0063] In the diagram: 1. Data acquisition and transformation module; 2. System decentralization module; 3. Security verification module. Detailed Implementation

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

[0065] Example:

[0066] Please see Figure 4In this embodiment of the invention, a cross-chain method based on a model context protocol is applied to a network system. The system includes a source chain protocol layer, a transmission and verification layer, and a target chain protocol layer. The transmission and verification layer is used to connect the source chain protocol layer and the target chain protocol layer. The cross-chain method includes the following steps:

[0067] S1: The source chain protocol layer obtains business intent on the source chain and transforms the abstract business intent into a verifiable MCP;

[0068] S2: The transmission and authentication layer includes an independent relay authentication network, which includes multiple authentication nodes, and these multiple authentication nodes decentralize the network system.

[0069] S3: The core entity of the target chain protocol layer is the gateway that executes contracts. The target chain protocol layer receives and executes cross-chain instructions on the target chain of the target chain protocol layer and verifies the security of the transaction process.

[0070] In this embodiment, the business intent is an abstract idea, and the verifiable data packet is a standardized data packet.

[0071] In this embodiment, step S1 includes:

[0072] S11: Obtain the key state of the upper-layer application contract. When the key state changes to a state that requires cross-chain communication, trigger the context to generate a contract by calling a function to form a cross-chain interaction.

[0073] S12: Generate the contract in the context with the core business parameters required to trigger the current cross-chain interaction. The core business parameters include the user address, the new state value, and the target chain asset ID.

[0074] S13: Core payload for generating contract aggregation and constructing MCP based on context;

[0075] S14: Construct the MCP and generate a contract assignment sequence number for the context;

[0076] S15: Context-based contract generation triggers a public on-chain event. By triggering a public on-chain event, the complete MCP data structure can be recorded as a parameter in the source chain's Log, achieving complete decoupling between on-chain state changes and cross-chain message passing, greatly improving the system's security and modularity.

[0077] In this embodiment, step S13 includes:

[0078] S131: Obtain core business parameters and read the association status between the core business parameters and the contract in the source chain;

[0079] S132: Based on the standard data format, the core business parameters and associated status are serialized and encoded, wherein the standard data format is a binary format;

[0080] S133: Based on the current business intent, generate an instruction script describing the operation to be performed on the target chain. The instruction script includes the target function signature, parameter construction method, and condition judgment operation. Alternatively, the instruction script is a series of atomic operations.

[0081] Preferably, the binary format includes JSON and Protobuf formats. Using JSON format facilitates data retrieval, while using Protobuf format improves on-chain processing efficiency.

[0082] Preferably, the instruction script is used to specify the signature of the target function, the parameter construction method, the condition judgment, or a series of atomic operations corresponding to the target chain.

[0083] In this embodiment, step S14 includes:

[0084] S141: Assign a sequence number based on the upper-layer application contract, wherein the sequence number is strictly monotonically increasing and unique throughout the lifetime of the assigned contract;

[0085] S142: Record the serial number in the storage variable of the context-generated contract. By recording the serial number in the contract's storage variable, it can be ensured that each issued MCP has a unique identifier, thereby preventing replay attacks from the protocol level.

[0086] In this embodiment, step S2 includes:

[0087] S21: Multiple validator nodes listen for and capture events that generate contract broadcasts from the contexts they support;

[0088] S22: When a validator node captures a new event, it performs a finality confirmation operation. The finality confirmation operation refers to waiting for the block containing the event to continue to generate a sufficient number of new blocks to ensure that the event record has been stabilized on the chain and is irreversible. By having the validator node perform the finality confirmation operation, the risks caused by short-term blockchain forks or reorganizations can be effectively mitigated.

[0089] S23: Each verification node independently verifies the validity of the MCP;

[0090] S24: Based on a cryptographic hash algorithm, the verification node uses its own private key to process the MCP and generate a unique data digest;

[0091] S25: Cryptographically sign the data digest to generate independent valid signature data.

[0092] Preferably, step S2 further includes:

[0093] S26: Based on the P2P network, verification nodes broadcast and synchronize their signatures to each other until the number of signatures with the same MCP hash value collected by each verification node exceeds a preset consensus threshold. The scattered signatures will be aggregated into a single network consensus credential. When the number of signatures with the same MCP hash value collected by each verification node exceeds the preset consensus threshold, it indicates that the entire network system has reached a consensus on the authenticity and validity of the message. At this time, the scattered signatures will be aggregated into a single, unforgeable network consensus credential. The consensus threshold can be more than two-thirds of the verification nodes in the network.

[0094] S27: Obtain the network consensus certificate. One or more relay nodes in the relay verification network use the original MCP and the aggregated network consensus certificate as parameters to package them into a transaction and submit it to the target chain protocol layer for processing.

[0095] In this embodiment, step S3 includes:

[0096] S31: The gateway executes the contract's entry function to receive transactions and verifies the network public credentials in the received transactions;

[0097] S32: Recover the signer's public key or derived address for each signature based on the public key recovery mechanism, and compare the signer's public key or derived address with the list of trusted verifier addresses pre-stored in the gateway execution contract. The public key recovery mechanism is the ecrecover function.

[0098] S33: After the signature verification is successful, the gateway executes the contract to check the sequence number in the MCP packet header.

[0099] In this embodiment, by comparing the signer's public key or derived address with the list of trusted verifier addresses pre-stored in the gateway execution contract, the legitimacy of the signer and the compliance of the number of valid signatures can be ensured, thus completing the credential verification.

[0100] In this embodiment, step S33 includes:

[0101] S31: Query the status mapping of the executed sequence number in the MCP internal record, and check whether the sequence number has been marked as used;

[0102] S32: When the serial number is marked as used, the transaction will immediately fail and be rolled back;

[0103] S33: When a serial number is marked as unused, its status is immediately marked as used, thereby ensuring the atomicity and uniqueness of the operation and realizing the anti-replay verification of the serial number.

[0104] In this embodiment, the state mapping is mapping(uint64 =>bool) usedNonces.

[0105] In this embodiment, step S33 further includes:

[0106] S34: After the security check passes, the gateway executes the execution logic script in the contract parsing MCP core payload;

[0107] S35: Based on the low-level dynamic invocation function and script instructions of the smart contract platform, dynamically construct invocation data and initiate invocations to the target DApp contract. By dynamically constructing invocation data and initiating invocations to the target DApp contract based on the low-level dynamic invocation function and script instructions of the smart contract platform, the flexibility and forward compatibility of cross-chain methods can be greatly improved.

[0108] S36: After the gateway executes the contract and completes the dynamic call, it captures the execution result of the dynamic call, which includes success, failure and return value.

[0109] In this embodiment, step S36 includes:

[0110] S361: The gateway executes the contract and encapsulates the execution result into a receipt data packet;

[0111] S362: The event is broadcast to the relay verification network by triggering the chain again, and the relay verification network transmits it back to the source chain.

[0112] In this embodiment, by transmitting the data back to the source chain through the relay verification network using the same secure process, a complete cross-chain communication loop capable of status confirmation is formed, completing result capture and optional back transmission.

[0113] This embodiment creatively proposes a Model Context Protocol (MCP), which standardizes the rules and standards for cross-chain communication at the application layer. By defining and constructing a standardized MCP rich in application layer information, it atomically encapsulates the source chain application's state, execution conditions, the target chain's required data model, and verification credentials, and securely transmits them using a decentralized relay verification network. In this way, cross-chain communication is no longer a simple "instruction" transmission, but a complex "scenario" migration, enabling the target chain to fully understand the source chain's business intent and execute corresponding logic. This elevates inter-chain interaction from the asset level to the application logic level, providing a solid technical foundation for building a next-generation, powerful, and highly collaborative distributed cross-chain application ecosystem.

[0114] Please see Figure 5 This embodiment provides a cross-chain system based on a model context protocol, applied to the cross-chain method based on a model context protocol as described above. The cross-chain system includes a data acquisition and transformation module 1, a system decentralization module 2, and a security verification module 3. The data acquisition and transformation module 1 is configured such that the source chain protocol layer acquires business intent on the source chain and transforms the abstract business intent into verifiable model context data packets. The system decentralization module 2 is configured such that the transmission and verification layer includes an independent relay verification network, which includes multiple verification nodes, and the multiple verification nodes decentralize the network system. The security verification module 3 is configured such that the core entity of the target chain protocol layer is a gateway executing the contract, and the target chain protocol layer receives and executes cross-chain instructions on the target chain of the target chain protocol layer to verify the security of the transaction process.

[0115] Please see Figure 1 Each of the N source chains includes a user or a DApp. Each user generates a contract and interacts with the corresponding context, broadcasting the MCP to the relay verification network. The relay verification network contains K verification nodes. After the K verification nodes reach a consensus, the M target chains are submitted. Each target chain contains a corresponding verification node. Each verification node corresponds to a target DApp and interacts with it. The target DApp sends the execution result to the verification node it interacted with.

[0116] Please see Figure 2 When a user or source chain DApp initiates a cross-chain request to the source chain, the source chain protocol layer obtains the business intent on the source chain, transforms the abstract business intent into a verifiable MCP, and encapsulates the MCP. The source chain then broadcasts the MCP generation event to the relay verification network. The relay verification network verifies the MCP and reaches a consensus. After reaching a consensus, the MCP and multi-signature certificate are submitted to the target chain. The target chain verifies the certificate and parses the MCP, while simultaneously calling the target contract and passing data to the target DApp. After the target DApp executes the business logic, it returns the execution result to the target chain. The target chain generates a receipt MCP and broadcasts the receipt event to the relay verification network.

[0117] Please see Figure 3 MCP contains header information, core payload, and security credentials. The header information includes source chain information, target chain information, sequence number, and timestamp. The core payload includes business status data and execution logic script. The security credentials include source chain status proof and network consensus credentials.

[0118] This embodiment encapsulates the application layer's state and logic by creating and transmitting standardized model context data packets, fundamentally filling the gap in context understanding in existing technologies. This enables cross-chain communication to have scenario-based and intelligent capabilities. By providing a universal application layer cross-chain framework, DApps on different chains can perform complex logical interactions as securely and conveniently as calling local functions, breaking down the barriers that prevent application functions from being combined due to different underlying architectures.

[0119] This embodiment significantly reduces the barrier and cost for developers to build and maintain cross-chain distributed applications by defining a standardized protocol and interface. It avoids the inefficient work of repeatedly designing private communication schemes for each pair of interactive applications and creatively proposes a model context protocol, which can standardize the rules and standards of application-layer cross-chain communication. By defining and constructing a standardized model context data packet rich in application-layer information, the state, execution conditions, data model, and verification credentials required by the target chain are atomically encapsulated. Through secure transmission with the help of a decentralized relay verification network, the target chain in cross-chain communication can fully understand the business intent of the source chain and execute the corresponding logic. This elevates inter-chain interaction from the asset level to the application logic level, providing a technical foundation for building a highly collaborative distributed cross-chain application ecosystem and improving the functionality of cross-chain communication.

[0120] This embodiment generates a contract based on the context to call the network system and trigger a public on-chain event. The complete MCP data structure can be recorded as a parameter of the event in the source chain's transaction log, achieving complete decoupling between on-chain state changes and cross-chain message passing, which greatly improves the system's security and modularity.

[0121] The above are merely preferred embodiments of the present invention, but the scope of protection of the present invention is not limited thereto. Any equivalent substitutions or modifications made by those skilled in the art within the scope of the technology disclosed in the present invention, based on the technical solution and inventive concept of the present invention, should be covered within the scope of protection of the present invention.

Claims

1. A cross-chain method based on a model context protocol, characterized in that, Applied to a network system, the system includes a source chain protocol layer, a transmission and verification layer, and a target chain protocol layer. The transmission and verification layer is used to connect the source chain protocol layer and the target chain protocol layer. The cross-chain method includes: The source chain protocol layer obtains the business intent on the source chain and transforms the abstract business intent into a verifiable model context data packet. The transmission and authentication layer includes an independent relay authentication network, which includes multiple authentication nodes, and the multiple authentication nodes decentralize the network system; The core entity of the target chain protocol layer is the gateway executing the contract. The target chain protocol layer receives and executes cross-chain instructions on the target chain of the target chain, and verifies the security of the transaction process. The source chain protocol layer obtains the business intent on the source chain and transforms the abstract business intent into a verifiable model context data packet, including: The key state of the upper-layer application contract is obtained. When the key state changes to a state that requires cross-chain communication, a function is called to trigger the context to generate a contract, thus forming a cross-chain interaction. The context generates a contract that passes in the core business parameters required to trigger the current cross-chain interaction, wherein the core business parameters include the user address, the new state value, and the target chain asset ID; The core payload of generating contract aggregation and constructing model context data packets based on the aforementioned context; Construct a model context data package and generate a contract assignment sequence number for the context; obtain the core business parameters and read the association status between the core business parameters and the contract in the source chain; Based on a standard data format, the core business parameters and the associated status are serialized and encoded, wherein the standard data format is a binary format; Based on the current business intent, generate an instruction script describing the operation to be performed on the target chain. The instruction script includes the target function signature, parameter construction method, and condition judgment operation, or the instruction script is a series of atomic operations. Based on the aforementioned context, a contract is generated that triggers a public on-chain event.

2. The cross-chain method based on the model context protocol according to claim 1, characterized in that: The construction of the model context data packet, generating a contract allocation sequence number for the context, includes: A sequence number is assigned based on the upper-layer application contract, wherein the sequence number is strictly monotonically increasing and unique throughout the lifecycle of the assigned contract; The serial number is recorded in the storage variable of the context-generated contract.

3. The cross-chain method based on the model context protocol according to claim 2, characterized in that: The transmission and authentication layer includes an independent relay authentication network, which comprises multiple authentication nodes. These authentication nodes decentralize the network system, including: Multiple verification nodes listen for and capture events that generate contract broadcasts from the contexts they support; When the verification node captures a new event, the verification node performs a final confirmation operation; Each verification node independently verifies the validity of the model context data packet; Based on a cryptographic hash algorithm, the verification node is driven to process the model context data packet using its own private key to generate a unique data digest; The data digest is cryptographically signed to generate independent valid signature data.

4. The cross-chain method based on the model context protocol according to claim 3, characterized in that: The transmission and authentication layer includes an independent relay authentication network, which comprises multiple authentication nodes. These authentication nodes are decentralized within the network system. The layer also includes: Based on the P2P network, the verification nodes broadcast to each other and synchronize their signatures until the number of signatures of the hash value of the same model context data packet collected by each verification node exceeds the preset consensus threshold. The scattered signatures will be aggregated into a single network consensus credential. Once the network consensus certificate is obtained, one or more relay nodes in the relay verification network will use the original model context data packet and the aggregated network consensus certificate as parameters to package them into a transaction and submit it to the target chain protocol layer for processing.

5. The cross-chain method based on the model context protocol according to claim 4, characterized in that: The core entity of the target chain protocol layer is the gateway execution contract. The target chain protocol layer receives and executes cross-chain instructions on the target chain of the target chain, and verifies the security of the transaction process, including: The gateway executes the contract's entry function to receive transactions and verifies the network public credentials in the received transactions; The signer's public key or derived address for each signature is recovered based on the public key recovery mechanism. The signer's public key or derived address is then compared with the list of trusted verifier addresses pre-stored in the gateway's execution contract. The public key recovery mechanism is the ecrecover function. Once the signature verification is successful, the gateway executes the contract to check the sequence number in the header of the model context data packet.

6. The cross-chain method based on the model context protocol according to claim 5, characterized in that: Once the signature verification is successful, the gateway executes the contract to check the sequence number in the header of the model context data packet, including: Query the state mapping of the executed sequence number recorded inside the model context data packet, and check whether the sequence number is marked as used; When the serial number is marked as in use, the transaction will immediately fail and be rolled back; When a serial number is marked as unused, its status is immediately marked as used. Once the security check passes, the gateway executes the execution logic script in the core payload of the model context data packet, which is parsed by the contract. Based on the low-level dynamic calling function and script instructions of the smart contract platform, call data is dynamically constructed and calls to the target DApp contract are initiated. After the gateway executes the contract and completes the dynamic call, it captures the execution result of the dynamic call, wherein the execution result includes success, failure and return value.

7. The cross-chain method based on the model context protocol according to claim 6, characterized in that: After the signature verification is successful, the gateway executes the contract and completes the dynamic call, then captures the execution result of the dynamic call. The execution result includes success, failure, and a return value, including: The gateway execution contract encapsulates the execution result into a receipt data packet; The event is broadcast to the relay verification network by a re-triggering chain, which then transmits it back to the source chain.

8. A cross-chain system based on a model context protocol, characterized in that, The cross-chain system, applied to the model context protocol-based cross-chain method as described in any one of claims 1-7, comprises: The data acquisition and transformation module (1) is configured to acquire business intent on the source chain at the source chain protocol layer and transform the abstract business intent into verifiable model context data packets. The system decentralization module (2) is configured such that the transmission and verification layer includes an independent relay verification network, the relay verification network includes multiple verification nodes, and the multiple verification nodes decentralize the network system; The security verification module (3) is configured such that the core entity of the target chain protocol layer is the gateway executing the contract. The target chain protocol layer receives and executes cross-chain instructions on the target chain of the target chain protocol layer to verify the security of the transaction process.

Images