Dynamic access and chain-chain intercommunication method for cross-chain system

Abstract

The invention relates to the technical field of block chains, in particular to a dynamic access and chain-chain intercommunication method for a cross-chain system. The method comprises the steps of constructing a multi-level self-adaptive multi-chip parallel cross-chain architecture, performing main chain global consensus anchoring, performing multi-chip chain parallel processing, realizing fragment extension and load balancing through a verifiable random function, and ensuring safety and high efficiency in combination with a committee rotation and cross-chip collaboration mechanism. A dynamic access mechanism based on a chain ID and route packaging is realized, elastic access of six types of 120 isomorphic / isomerous chains such as a Changsafety chain and Ethereum is supported, and automatic access process, route synchronization and legality verification are included; five intercommunication modes including an innovative agent mode are executed, and heterogeneous scene transaction forwarding, verification, state synchronization and result feedback are completed by means of a forwarding scheduler. According to the method, the expansibility bottleneck of a traditional cross-chain system is broken through, the access flexibility and the intercommunication adaptability are improved, the performance and safety requirements of different scenes are met, multi-chain cooperation is supported, and a cross-chain cooperation normal form is optimized.

Description

Technical Field

[0001] This invention relates to the field of blockchain technology, and more specifically to a method for dynamic access and inter-chain communication for cross-chain systems. Background Technology

[0002] As a key evolutionary direction of next-generation information and communication technology, blockchain technology provides a new path for trusted collaborative networks across industries through innovative mechanisms such as distributed ledgers and smart contracts. However, in terms of existing technology, the blockchain ecosystem exhibits highly diversified characteristics. Different platforms have formed a heterogeneous development pattern due to differences in application scenarios and original design intentions. The lack of interoperability between chains hinders the flow of information and value, giving rise to closed "value silos" and "data barriers."

[0003] In the current blockchain technology environment, the lack of effective interaction capabilities and compatibility mechanisms between different blockchain platforms prevents the smooth transfer, sharing, and interaction of information (such as data and transaction records) and value (such as digital assets and proof of stake) between chains. Specifically, due to differences in underlying technical architecture (such as consensus mechanisms, data structures, and encryption algorithms) and protocol rules (such as transaction formats and smart contract standards), different blockchains form relatively independent and closed systems. For example, a blockchain based on the UTXO model and a blockchain based on the account model have different data representation and processing methods. Without interoperability, they cannot directly exchange data or transfer assets. Blockchains using different consensus mechanisms (such as PoW, PoS, and PBFT) also have incompatible rules in transaction verification and block generation, which also hinders inter-chain collaboration. This closed nature makes each blockchain like an "island," with its information and value confined within its own system, making it difficult to effectively connect with other blockchains. This creates a "data barrier" that hinders information sharing and value circulation, restricting the collaborative application of blockchain technology in a wider range of scenarios.

[0004] Cross-chain technology, as the core hub for connecting heterogeneous blockchains, can solve problems such as the isolation and fragmentation of different blockchains, lack of interoperability, and difficulty in ensuring cross-chain security, greatly expanding the application boundaries of blockchain. However, traditional cross-chain technology has many limitations:

[0005] Traditional single cross-chain models such as sidechains and relays tend to limit the scalability of cross-chain architectures, failing to provide high scalability for multi-chain parallelism, cross-chain communication, and massive transaction processing, and making it difficult to achieve scalability and high concurrency for large-scale cross-chain transaction processing.

[0006] Traditional sidechain models typically rely on one-way or two-way anchoring to the main chain. Each sidechain has a relatively fixed processing capacity, and its interaction with the main chain can easily become a bottleneck. Relay models, on the other hand, use a relay chain as the core hub, requiring all cross-chain transactions to pass through it. When the relay chain faces a large number of cross-chain requests, its own processing capacity limits the overall system's scalability. In this single-chain model, true parallel processing across multiple chains is difficult to achieve, and cross-chain communication efficiency decreases as the number of chains increases. This makes it unsuitable for handling massive transaction scenarios, resulting in poor scalability and concurrency performance in large-scale cross-chain transactions.

[0007] Heterogeneous blockchains differ in their underlying implementations, such as consensus mechanisms and chain structures, resulting in vastly different access rules and making it difficult to achieve dynamic access to large-scale heterogeneous blockchains.

[0008] Different blockchains may employ different consensus mechanisms, such as Proof-of-Work (PoW), Proof-of-Stake (PoS), and Practical Byzantine Fault Tolerance (PBFT). These mechanisms differ in their rules regarding transaction verification and block generation. Chain structures also vary, with some based on the UTXO model and others on the account model, resulting in significant differences in data storage and processing methods. These differences in underlying implementation lead to substantial variations in access requirements, interface specifications, and other access rules for each chain. Dynamically integrating a large number of heterogeneous blockchains of different types into the same cross-chain system requires adapting to various rules, which is extremely difficult and hinders efficient large-scale dynamic integration.

[0009] The tight coupling of various cross-chain interaction key technologies has made the cross-chain interaction mechanism rigid and unable to meet the differentiated needs of different access blockchains and different cross-chain applications in terms of performance, security, privacy, etc.

[0010] In traditional cross-chain systems, key technologies involved in cross-chain interaction, such as routing, verification, and consensus, are often tightly bound together, forming a fixed whole. When facing different blockchains for access, due to differences in their performance characteristics (such as processing speed and throughput), security requirements (such as encryption strength and attack prevention capabilities), and privacy protection requirements (such as data anonymization and access control), this rigid mechanism cannot flexibly adjust to adapt to these differences, making it difficult to meet the diverse needs of different scenarios. For example, some cross-chain applications have extremely high requirements for transaction speed, while others place greater emphasis on transaction security and privacy; a fixed interaction mechanism cannot simultaneously accommodate these different needs.

[0011] These issues collectively constrain the development of blockchain cross-chain technology, and breakthrough technologies are urgently needed to optimize the cross-chain collaboration paradigm. Summary of the Invention

[0012] In view of this, the present invention provides a dynamic access and inter-chain communication method for cross-chain systems, aiming to solve the problems of insufficient architectural scalability and performance in traditional cross-chain systems, difficulties in large-scale dynamic access caused by the different access rules of heterogeneous blockchains, and rigid cross-chain interaction mechanisms that cannot meet differentiated needs. This improves the scalability, universality, and adaptability of cross-chain systems, enables flexible access and efficient interoperability of various homogeneous / heterogeneous blockchains, supports the differentiated needs of different cross-chain applications in terms of performance and security, and fully supports dynamic access and cross-chain interaction between 120 parallel chains of 6 types (specifically referring to Chang'an Chain, Ethereum, Haihe Smart Chain, BUBI Chain, Hyperledger Fabric, and FISCO BCOS), optimizing the cross-chain collaboration paradigm.

[0013] HyperledgerFabric, meaning "Super Ledger Fabric" in Chinese, is an open-source enterprise-grade consortium blockchain platform developed under the leadership of the Linux Foundation. It supports modular architecture and pluggable components, making it suitable for building complex enterprise-grade blockchain applications.

[0014] FISCO BCOS stands for "Financial Blockchain Operating System". It is a domestically developed consortium blockchain platform that focuses on providing stable and efficient blockchain infrastructure support for the financial sector and other scenarios with high requirements for security and compliance.

[0015] To achieve the above objectives, the present invention adopts the following technical solution:

[0016] A method for dynamic access and inter-chain communication in cross-chain systems, characterized by the following steps:

[0017] Construct a multi-level adaptive multi-shard parallel cross-chain architecture, which includes a main chain and multiple shard chains. The main chain is responsible for global consensus anchoring and cross-shard transaction routing, while the multiple shard chains execute business sharding in parallel.

[0018] To achieve a dynamic access mechanism for cross-chain systems, a mapping table between chain IDs and physical addresses is generated by assigning a unique digital identity to each parachain and binding it to a physical address, and the routing protocol is encapsulated to shield the underlying addressing details.

[0019] It implements cross-chain interoperability mode, based on the forwarding scheduler, supporting five cross-chain interoperability modes: relay mode, gateway mode, direct connection mode, sidechain mode, and proxy mode, to realize transaction processing between heterogeneous chains.

[0020] In one specific implementation scheme, the construction of a multi-level adaptive multi-shard parallel cross-chain architecture includes:

[0021] Shards are dynamically expanded by proportionally allocating shards and nodes using a verifiable random function; the main chain nodes verify the correctness of the random number to confirm that the shard committee formation process has not been tampered with; nodes are classified into different levels based on the number of unconfirmed transactions within a shard, node verification speed, and historical accuracy, and nodes are dynamically allocated to different shards to achieve load balancing.

[0022] In one specific implementation, the multi-level adaptive multi-shard parallel cross-chain architecture further includes a multi-shard adaptive iteration mechanism:

[0023] In the initial phase, a trusted committee of 3f+1 nodes is formed by the main chain genesis nodes, where f is the number of malicious nodes tolerable. Nodes compete for shard committee membership based on concise proof-of-work. When at least 2 / 3 of the total number of shard nodes have completed the calculation, the trusted committee verifies and generates the first shard committee. At the end of each period, the trusted committee constructs a Merkle tree based on the current shard's UTXO and submits the root node data as a reference for new members to update their UTXOs. In the next period, members of each shard committee are re-elected.

[0024] In one specific implementation, the multi-level adaptive multi-shard parallel cross-chain architecture also includes a cross-shard collaborative processing mechanism:

[0025] Cross-shard transaction processing is decoupled into inter-shard interaction and intra-shard interaction. Inter-shard interaction achieves a consistent state view by maintaining a list of valid public keys, providing a signature sharing and generation interface, and aggregating public key verification. Intra-shard interaction achieves efficient communication consistency through a fast Byzantine fault-tolerant protocol with master node proposal and slave node voting. A general description interface for heterogeneous cross-shard data is defined to achieve one-time encapsulation of heterogeneous transactions and cross-shard generality.

[0026] In one specific feasible implementation, the mechanism for implementing dynamic access to cross-chain systems includes:

[0027] The chain ID is generated based on the chain type, genesis block hash, or other unique parameters, and its global uniqueness is ensured by a hash function. The chain's physical address information, such as IP address and port, is bound to the chain ID, and the generated mapping table is stored in the routing table module by the main chain node for unified management.

[0028] In one specific implementation, the encapsulation of the routing protocol to shield the underlying addressing details includes:

[0029] The addressing and communication functions between blockchains are encapsulated in the routing layer, and the routing protocol manages the cross-chain transaction transmission path. When the application layer calls the preset addressing interface, the interface internally maps the receiving chain ID of the transaction to the physical address and forwards it to the target chain through the routing layer.

[0030] In one specific implementation, the dynamic access mechanism further includes an automated access process:

[0031] The new chain submits an access request containing the chain ID, physical address, and consensus algorithm to the main chain access management module. After verifying the validity of the request, the access management module automatically writes the mapping relationship between the chain ID and the physical address into the routing table and synchronizes it to all shard nodes via broadcast.

[0032] In one specific implementation scheme, the proxy pattern is implemented by:

[0033] The forwarding scheduler loads the node-shard mapping configuration, initializes the shard chain identity manager, and enables transaction listening and block commit confirmation services. After receiving a cross-chain transaction initiated by a user, it determines the shard node corresponding to the sending chain according to the configuration, verifies the legality of the shard's block submission, and forwards it to the receiving chain's shard node via the gRPC protocol. If a contract call is involved, it forwards the call request through the virtual machine middleware, verifies the block after the contract is executed, and synchronizes it to the receiving chain.

[0034] In one specific implementation scheme, the interoperability verification process in the proxy mode includes:

[0035] After verifying the validity of the signature and balance of the cross-shard transaction, the shard node sends it to the forwarding scheduler via the gRPC protocol. The scheduler performs a global verification of the transaction, confirming that it is not duplicated and the timestamp is not out of order. It then calls the verification logic of the corresponding consensus type to complete the cross-shard consensus verification. The scheduler sends a readiness to execute message to the receiving shard and related shards, and summarizes the execution results of each shard to ensure state consistency.

[0036] In one specific implementation scheme, the relay mode is based on a relay chain, and completes the storage, verification and forwarding of cross-chain transactions through the collaboration of on-chain smart contracts and off-chain gateways;

[0037] The gateway mode achieves data exchange and forwarding through a trusted connection between off-chain gateways using a standard protocol, with authentication and signature verification performed by both gateways.

[0038] The direct connection mode achieves direct data interaction without intermediaries by establishing a direct communication channel;

[0039] The sidechain mode uses a dedicated lightweight sidechain to achieve information aggregation and forwarding between multiple main chains, and assumes the role of temporary transaction matching and transfer.

[0040] Compared with existing technologies, the dynamic access and inter-chain communication method for cross-chain systems described in this invention addresses the problems of insufficient scalability of traditional cross-chain system architectures, difficulties in accessing heterogeneous blockchains, and rigid cross-chain interaction mechanisms. By constructing a multi-level adaptive multi-shard parallel cross-chain architecture, combined with a dynamic access mechanism and an inter-chain communication mode, it achieves flexible access and efficient interoperability of various homogeneous / heterogeneous blockchains, effectively improving the scalability, universality, and adaptability of cross-chain systems, and has the following beneficial effects:

[0041] By employing a hierarchical multi-shard structure model, a multi-shard adaptive iteration mechanism, and a cross-shard collaborative processing mechanism, the performance bottleneck of large-scale expansion of blockchain cross-chain transactions is overcome, achieving efficient and scalable cross-chain processing.

[0042] By using chain digital identity identification and physical address identification, routing protocol and unified communication architecture, flexible addressing protocol and automated access process, it supports dynamic access of 6 types of blockchains, including Chang'an Chain, Ethereum, Haihe Smart Chain, Bubi Chain, Hyperledger Fabric and FISCO BCOS financial blockchain operating system, to improve the manageability and scalability of the system in scenarios with multi-chain heterogeneity and rapid growth in the number of chains.

[0043] By supporting five inter-chain communication modes—relay, gateway, direct connection, sidechain, and proxy—the proxy mode, as an innovative mode, focuses on solving the problem of trusted interaction in complex environments between heterogeneous chains. The other four modes cover the needs of mainstream cross-chain scenarios, enabling concurrent and efficient processing of cross-chain transactions. It meets the differentiated needs of different access blockchains and different cross-chain applications in terms of performance, security, etc., fully supports dynamic access and cross-chain interaction between multiple chains, and optimizes the cross-chain collaboration paradigm. Attached Figure Description

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

[0045] Figure 1 This is a diagram of a multi-level adaptive multi-chip parallel cross-chain architecture.

[0046] Figure 2 This is a diagram of the dynamic access architecture for cross-chain systems.

[0047] Figure 3 This is a diagram of the cross-chain system's interoperability architecture. Detailed Implementation

[0048] The technical solutions in the embodiments of the present invention will be clearly and completely described below. 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.

[0049] This invention addresses the scalability bottlenecks, difficulties in heterogeneous chain access, and rigid inter-chain communication modes of existing cross-chain systems. It presents a dynamic access and inter-chain communication method for cross-chain systems, achieving dynamic access and efficient interoperability of heterogeneous blockchains by constructing a multi-level adaptive multi-shard parallel cross-chain architecture, a dynamic access mechanism, and a cross-chain interoperability mode. Specifically, the multi-level adaptive multi-shard parallel cross-chain architecture serves as the foundation, supporting the expansion and collaboration of large-scale cross-chain transactions; the dynamic access mechanism enables flexible access and routing management for different types of blockchains; and the inter-chain communication mode meets the cross-chain interaction needs in various scenarios through differentiated methods. These three elements work synergistically to solve the problems of insufficient scalability, difficulties in heterogeneous access, and rigid interaction mechanisms in traditional cross-chain systems. Its core technical solution comprises three main technical modules:

[0050] 1. Cross-chain architecture innovation: Design a multi-level adaptive multi-shard parallel cross-chain architecture. Through a layered multi-shard structure (the main chain coordinates global consensus and routing, while shard chains execute business in parallel) and an adaptive iteration mechanism (dynamic node allocation and secure committee rotation), it breaks through the scalability bottleneck of traditional cross-chain systems and supports efficient processing of large-scale cross-chain transactions.

[0051] 2. Innovative Access Mechanism: A dynamic access mechanism for cross-chain systems is designed. By assigning a unique chain ID to heterogeneous chains and binding it to a physical address, combined with routing protocol encapsulation (suppressing underlying addressing details), elastic access and plug-and-play functionality for heterogeneous chains are achieved, solving the problems of complex and poor compatibility in traditional cross-chain access processes.

[0052] 3. Interoperability Mode Innovation: Design a cross-chain interoperability mode for the cross-chain system. Based on the forwarding scheduler, propose an innovative proxy mode that is compatible with four existing modes: relay, gateway, direct connection, and sidechain. This forms a cross-chain interoperability system with "five modes working together" to meet the inter-chain transaction processing needs in different scenarios and solve the problems of single interoperability mode and insufficient adaptability in traditional interoperability modes.

[0053] Through the synergy of the three major technical modules mentioned above, this invention achieves high scalability, flexible dynamic access, and interoperability adaptability of the cross-chain system, effectively supporting complex business scenarios involving multi-chain collaboration. The system architecture effectively solves the performance bottleneck of large-scale cross-chain transaction expansion. The core steps of this architecture in solving the performance bottleneck of large-scale cross-chain transaction expansion include:

[0054] Hierarchical multi-shard structure model: The main chain and multiple shard chains work together. The main chain is responsible for global consensus anchoring and cross-shard transaction routing, while multiple shard chains process business shards in parallel and achieve dynamic expansion of shards through verifiable random functions (VRFs), thereby improving the horizontal scalability of the system.

[0055] Multi-shard adaptive iteration mechanism: Based on the simplified proof-of-work (PoW) to select nodes and establish an initial trusted committee, combined with the Merkle root data constructed by the current shard UTXO, the committee can be rotated safely and efficiently, ensuring the security of the system iteration process;

[0056] Cross-shard collaborative processing mechanism: Decouples inter-shard interaction from intra-shard interaction. Inter-shards achieve a consistent state view through a multi-signature protocol, while intra-shards adopt a fast Byzantine fault-tolerant protocol to improve communication efficiency. Combined with a general security structure model for cross-shard transactions, it supports general processing of heterogeneous transactions and improves the compatibility and processing efficiency of cross-chain transactions.

[0057] This invention provides an implementation scheme for constructing a multi-level adaptive multi-shard parallel cross-chain architecture:

[0058] The multi-level adaptive multi-shard parallel cross-chain architecture achieves efficient cross-chain transaction processing through the collaboration of the main chain and multiple shards. Specifically, it includes a hierarchical multi-shard structure model, a multi-shard adaptive iteration mechanism, and a cross-shard collaborative processing mechanism. This invention... Figure 1 The main chain-shard chain layered architecture shown achieves "multi-level adaptive" cross-chain architecture:

[0059] Layered multi-shard: The main chain focuses on global consensus anchoring and cross-shard routing (such as main chain nodes verifying shard blocks through Merkle tree roots), while shard chains carry out business transactions in parallel (shard chains 1, 2...n execute consensus independently). By “main chain coordination + shard parallelism”, the performance bottleneck of traditional single-chain architecture is broken through.

[0060] Adaptive iteration: relying on Figure 1 The "committee establishment - dynamic node allocation" process in the middle uses a verifiable random function (VRF) to achieve dynamic shard expansion (node ​​transfer across shards), and a Byzantine fault-tolerant committee (3f+1 model) to ensure iteration security, thus solving the problem of "difficulty in balancing scalability and security" in cross-chain systems; the following is combined with Figure 1 Details are as follows:

[0061] (I) Hierarchical Multi-Piece Structure Model

[0062] The hierarchical multi-shard structure model consists of a main chain and multiple shard chains (shard chain 1, shard chain 2, ..., shard chain n):

[0063] As the core of cross-chain coordination, the main chain is responsible for global consensus anchoring, recording the election results of shard committees, and routing and verifying cross-shard transactions.

[0064] Multi-shard chains are business shards that execute in parallel, independently carrying out the execution and consensus of specific transactions.

[0065] 1. Fragmented Dynamic Expansion (VRF Driver)

[0066] To achieve dynamic expansion of shards, a Verifiable Random Function (VRF) distributed random number generation algorithm is used to allocate shards and nodes. Figure 1 The process of "dynamic node allocation" between the main chain and shard chains:

[0067] Input parameters: VRF takes the current timestamp, the set of node IDs, and the random number from the previous period as input;

[0068] Output: Output the current random number and proof of its correctness (satisfying the SHA-256 hash function constraint);

[0069] Main chain verification: Main chain nodes verify the correctness proof of the VRF to confirm the validity of the random numbers, ensuring the randomness and fairness of the sharding committee member election, supporting large-scale sharding expansion, and aligning with... Figure 1 The architecture logic of "dynamic flow of nodes across shards" in China.

[0070] 2. Load balancing (node-level scheduling)

[0071] The main chain nodes verify the protocol through the consensus results, confirm the validity of the consensus of each shard, and achieve load balancing. Figure 1 An architecture where the main chain centrally manages shards, and the sharded chains run services in parallel:

[0072] Block verification: After the sharding committee generates a block, the main chain nodes verify the matching between the block header hash and the Merkle tree root to determine the validity of the block;

[0073] Load calculation: Calculate the remaining load based on the number of unconfirmed transactions within the shard (remaining load = maximum processing capacity of the shard - number of unconfirmed transactions);

[0074] Node grading: Based on the node verification speed (unit: transactions / second) and historical accuracy (value 0-1), the node grading is determined by the formula "Node grade = k × verification speed + m × historical accuracy" (k and m are dynamically adjustable weighting coefficients).

[0075] Dynamic scheduling: The main chain schedules nodes to different levels based on their priority. Figure 1 The diagram shows different shard chains, such as shard chain 1 and shard chain 2. By real-time sensing of shard load and issuing node allocation instructions through the main chain, the business processing needs of each shard chain are matched, resolving the load imbalance issue in the cross-chain system and improving overall throughput.

[0076] (II) Multi-piece adaptive iterative mechanism

[0077] The multi-shard adaptive iterative mechanism ensures the security and efficiency of the cross-chain system through the establishment of an initial trusted committee and the rotation of sharding committees. Figure 1 The "Committee Establishment" and "Main Chain-Sharding Chain Hierarchical Architecture" in China:

[0078] 1. Initial Trust Commission (Byzantine Fault Tolerance)

[0079] In the initial phase, the main chain genesis nodes form an initial trusted committee that meets Byzantine fault tolerance requirements:

[0080] Size Design: The committee size is typically set to 3f+1 (where f is the number of malicious nodes tolerated), to resist attacks from f malicious nodes. Figure 1 The hierarchical positioning of the "Trustworthy Committee" in China;

[0081] Sharding Committee Election: All nodes compete for sharding committee membership based on Proof-of-Work (PoW). Nodes complete the PoW proof by calculating a random number that satisfies the condition "hash value (random number || previous block hash) < target value".

[0082] Committee Generation: Once at least 2 / 3 of the total number of shard nodes have completed the PoW computation, the trusted committee verifies the results and generates the first shard committee. This process is repeated to determine the members of each shard committee in the first period and the trusted committee in the next period, ensuring that the number of honest nodes in a single shard is greater than 2 / 3, thus ensuring consensus security and aligning with [the established principles]. Figure 1 The logical structure of the main chain, committee, and shard chains.

[0083] 2. Committee rotation (Merkel tree synchronization)

[0084] At the end of each period, the Trusted Committee constructs a Merkle tree and submits root node data (generated by concatenating transaction output hashes) based on the current transaction output state of the shard (such as the unspent transaction outputs in the UTXO model). New committee members update their own transaction output state with reference to the root node data, preventing malicious data interference and improving the efficiency of committee reconstruction.

[0085] Upon entering the next phase, members of each sub-committee will be re-elected to ensure a safe rotation. This data flow and operational process relies on... Figure 1 The interactive architecture of the main chain, shard chains, and committee ensures the security and efficiency of the cross-chain system's iterative operation.

[0086] (III) Cross-Segment Collaborative Processing Mechanism

[0087] The cross-slice collaborative processing mechanism decouples inter-slice and intra-slice interactions, combining multi-signature and fast consensus protocols to achieve efficient processing of cross-slice transactions. Figure 1 Presented main chain-shard chain architecture:

[0088] 1. Inter-chip interaction (multi-signature verification)

[0089] During inter-chip interaction, a reliable multi-signature protocol is constructed:

[0090] The main chain maintains a list of valid public keys, and each node uses its private key to generate and share signatures with other nodes.

[0091] An aggregated signature is generated using an aggregation algorithm. Main chain nodes verify the signature's validity using the aggregated public key, achieving a consistent state view across shards in scenarios without a trusted party. Figure 1 The main chain provides a unified verification logic for cross-shard interactions between shard chains.

[0092] 2. In-game interaction (Fast Byzantine fault tolerance)

[0093] The in-game interaction uses a fast Byzantine fault-tolerant protocol:

[0094] The transaction is proposed by the master node within the shard chain and confirmed by the slave nodes through voting.

[0095] Simplify the complexity of messages within the shard, achieve efficient intra-shard communication consistency, and fit the requirements. Figure 1 The collaboration process of internal nodes in the sharding chain.

[0096] 3. Heterogeneous cross-chip transaction processing (general interface adaptation)

[0097] For heterogeneous cross-shard transactions (such as data heterogeneity between UTXO and account models, and heterogeneous smart contract call behavior), a general security structure model for cross-shard transactions is constructed, defining a general description interface containing the following fields:

[0098] Transaction ID, sender information, receiver information, data structure type, and consensus mechanism type.

[0099] Cross-chip processing flow:

[0100] Sender sharding: Based on its own data structure type and consensus mechanism type, dynamically generate transaction data that adapts to the receiver sharding rules (such as converting the UTXO model sender to the account model balance change record);

[0101] Receiver sharding: Based on interface fields, perform data structure transformation and consensus verification to achieve one-time encapsulation of heterogeneous transactions and cross-shard compatibility.

[0102] This process relies on Figure 1The main chain-shard chain interaction architecture ensures compatibility and processing efficiency in heterogeneous cross-chain scenarios. The dynamic cross-chain system access mechanism enables elastic access to heterogeneous chains, supporting dynamic access to 120 homogeneous / heterogeneous blockchains across six types, including Chang'an Chain, Ethereum, Haihe Smart Chain, Bubi Chain, Hyperledger Fabric, and FISCO BCOS (Financial Blockchain Operating System). Its core steps include:

[0103] Digital identity and physical address identification: A unique digital identity (chain ID) is generated for each chain, and the physical address information such as the IP address and port of the communication node is bound to the chain ID. A mapping table is generated and stored in the routing table module to provide a basis for cross-chain addressing.

[0104] Routing Protocol and Unified Communication Architecture: The addressing and communication functions between blockchains are encapsulated in the routing layer. The routing protocol manages the cross-chain transaction transmission path. The application layer can initiate cross-chain operations by calling the preset addressing interface without having to worry about the underlying addressing details.

[0105] Flexible addressing protocol and automated access process: After a new chain submits an access request containing information such as chain ID, physical address, and consensus algorithm, the main chain access management module automatically verifies the legality of the request. If the request is approved, the mapping relationship is written into the routing table and synchronized to all nodes in the network to achieve dynamic access.

[0106] This invention provides the following implementation scheme for a dynamic access mechanism for cross-chain systems:

[0107] The cross-chain system dynamic access mechanism supports flexible access to heterogeneous parallel chains. This is achieved through chain digital identity and physical address identification, routing protocols and a unified communication architecture, and automated access processes. The dynamic access mechanism of this invention, through… Figure 2 The "chain ID-routing table-gateway" collaborative architecture shown implements the core logic of "chain ID + route encapsulation":

[0108] Chain ID generation: Based on parameters such as the genesis block hash and chain type of the parachain (e.g., the formula Chain ID = hash(genesis block hash || chain type)), a globally unique identifier is generated, corresponding to... Figure 2 The "routing table" records the chain IDs;

[0109] Routing encapsulation: A gateway binds physical addresses (IP, Port) to chain IDs, encapsulating underlying addressing details (e.g., when the application layer calls the CrossChainCall interface, routing is done directly via the chain ID), enabling "plug-and-play" elastic access to heterogeneous chains and matching... Figure 2 The dynamic access process of "parallel chain-gateway-main chain" in China; the following is combined with Figure 2 Details are as follows:

[0110] (I) Blockchain Digital Identity Identification and Physical Address Determination

[0111] Each parallel chain to be connected needs to complete the allocation of a chain digital identity (chain ID) and the assignment of a physical address, corresponding to... Figure 2 The access architecture of "parallel chain-gateway-main chain / shard chain" in China:

[0112] 1. Chain ID generation (globally unique guarantee)

[0113] Assign a unique digital identity (chain ID) to each parachain. The chain ID is generated based on the following parameters to ensure global uniqueness:

[0114] Chain type (e.g., public chain, consortium chain);

[0115] Genesis block hash;

[0116] Consensus mechanism type (such as PoW, PoS).

[0117] Example of generation method: Calculated using the SHA-256 hash function, the formula is "Chain ID = Hash(Genesis Block Hash || Chain Type || Consensus Mechanism Type)", corresponding to... Figure 2 The logic for recording chain IDs in the "routing table".

[0118] 2. Physical address binding (the foundation of cross-chain addressing)

[0119] Parallel chains bind the physical address information (such as IP address and port) of their communication nodes to the chain ID, generating a mapping table (chain ID:(IP, Port)), which is then stored in the routing table module of the main chain nodes for unified management. Figure 2 The architectural positioning of the "routing table" in China.

[0120] This mapping table provides the foundation for cross-chain addressing, avoids address conflicts, and ensures accurate routing of cross-chain transactions.

[0121] (II) Routing Protocols and Unified Communication Architecture

[0122] To simplify cross-chain communication, addressing and communication functions between blockchains are encapsulated based on a routing protocol. Figure 2 The interaction logic between "gateway-routing protocol-main chain / shard chain" in China:

[0123] 1. Routing protocol design (shielding low-level details)

[0124] The routing protocol is responsible for managing the transmission path of cross-chain transactions and implements the following functions:

[0125] Path optimization: Calculate the optimal transmission path for cross-chain transactions using algorithms (e.g., based on network latency and node load);

[0126] Protocol encapsulation: The underlying blockchain addressing logic (such as physical address resolution and communication protocol adaptation) is encapsulated in the routing layer, providing a unified calling interface upwards. Figure 2 The functional positioning of "routing protocol" in China.

[0127] 2. Unified communication interface (application layer simplified call)

[0128] The application layer initiates cross-chain operations by calling a pre-defined cross-chain API (such as CrossChainCall(TX)), without needing to concern itself with the underlying details.

[0129] Interface Functionality: The interface internally queries the routing table, maps the receiving chain ID of the transaction to the physical address, and forwards it to the target chain through the routing layer;

[0130] Process Example: When the application layer initiates a cross-chain transaction, the interface automatically parses the receiving chain ID in the transaction, obtains the corresponding IP address and port from the routing table, and sends the transaction data to the communication node of the target chain through the routing layer. Figure 2 The data flow logic of "parallel chain-gateway-routing protocol" in China.

[0131] (III) Automated Access Process

[0132] When a new parallel link is integrated into the cross-chain system, an automated process is initiated based on the addressing protocol. Figure 2 The access architecture of "parallel chain-gateway-main chain" in China:

[0133] 1. Submitting an access request (basic information declaration)

[0134] The new parachain submits an access request to the main chain's access management module. The request includes the following information:

[0135] Chain ID (generation rules are described above);

[0136] Physical address information (IP, Port);

[0137] Consensus algorithm types;

[0138] Smart contract preset conditions (such as contract state, contract value), corresponding to Figure 2 The configuration logic of "smart contracts" in China.

[0139] 2. Legality Verification (Access Security Assurance)

[0140] The main link enters the management module to verify the validity of the request:

[0141] Chain ID uniqueness: Check if the same chain ID already exists in the routing table;

[0142] Physical address reachability: Verify the communication reachability of physical addresses through network probing;

[0143] Smart contract compliance: Verify whether preset conditions (such as contract state and contract value) comply with cross-chain system rules. Figure 2 The verification function of "smart contracts" in China.

[0144] 3. Routing table synchronization (access effective)

[0145] Once verification is successful, the main link will automatically execute the following steps in the management module:

[0146] Write the mapping relationship between chain ID and physical address into the routing table;

[0147] The routing table update is synchronized to all shard nodes via broadcast protocol. Figure 2 The dynamic maintenance logic of the "routing table" in the middle.

[0148] Once a new chain node joins, it can conduct cross-chain transactions and message passing with other chains through the routing layer, achieving dynamic access. The cross-chain system's inter-chain interoperability mode enables efficient cross-chain transaction processing, meeting the differentiated needs of various business systems in inter-chain communication scenarios. It supports five interoperability modes: relay, gateway, direct connection, sidechain, and proxy. The characteristics of each mode are as follows:

[0149] Relay Mode: Cross-chain communication is achieved based on the relay chain. Through collaboration between on-chain smart contracts and off-chain gateways, cross-chain transactions are stored, verified, and forwarded. As a communication hub, the relay chain maintains the consistency of cross-chain transaction states and the traceability of transaction logs. It is suitable for inter-chain transaction scenarios with indirect communication between multiple chains and weak mutual trust relationships, and has the advantages of decentralization, high security, and transaction traceability.

[0150] Gateway mode: Through trusted connections between off-chain gateways, data exchange and forwarding between chains are completed based on standard protocols (such as HTTP and WebSocket). Authentication and signature verification are performed by both gateways. It is suitable for business systems with high trust in the peer chain and frequent interactions, and has the advantages of high communication efficiency and low deployment cost.

[0151] Direct connection mode: Establishes a direct communication channel between two chains to achieve direct data interaction without intermediaries. It is suitable for high-performance, low-latency cross-chain call scenarios (such as chain-to-chain communication within a consortium with a high degree of mutual trust), and has the advantages of low latency and high throughput.

[0152] Sidechain mode: Build a dedicated lightweight sidechain for information aggregation and forwarding between multiple main chains, and take on the role of temporary transaction matching and transfer. It is suitable for cross-chain businesses with high-frequency interaction but no need to be permanently on the chain (such as points redemption and short-term data transfer), and has the advantages of low resource consumption and high transaction throughput.

[0153] Proxy mode: Cross-chain message proxy transmission, signature verification and notarization are completed through off-chain proxy services (such as forwarding schedulers). The integrity and legality of messages are verified by trusted middleware components. It is suitable for non-peer inter-chain communication, chain environment constraints or heterogeneous and complex scenarios, and has the advantage of strong compatibility.

[0154] This invention provides an implementation scheme for the execution mode of the cross-chain system interoperability mode as follows:

[0155] The cross-chain system supports five inter-chain interoperability modes: relay mode, gateway mode, direct connection mode, sidechain mode, and proxy mode, meeting the cross-chain needs of different scenarios. The inter-chain interoperability mode of this invention, through... Figure 3 The "forwarding scheduler-sharding-main chain" interaction architecture shown achieves the design goal of "5 modes of collaboration":

[0156] Agent model innovation: relying on the "load balancing-state caching-transaction scheduling" function of the forwarding scheduler (such as...) Figure 3 (Module design of the forwarding scheduler) supports non-peer communication between heterogeneous chains (such as cross-consensus mechanism interaction between shard A and shard B);

[0157] Multi-mode compatibility: Relay mode communicates indirectly through "main chain - shard - smart contract" ( Figure 3 In the message bus-transaction forwarding scheduler process, gateway mode directly forwards messages via inter-chip communication. Figure 3 Inter-chain communication links (with direct connection, sidechain, and proxy modes) are adapted to different scenarios, forming a complete interoperability system and solving the problem of the single nature of traditional cross-chain modes; the following is combined with Figure 3 Details are as follows:

[0158] (I) Relay mode (indirect communication, weak trust scenario)

[0159] The relay mode enables cross-chain communication based on the relay chain, corresponding to Figure 3 The cross-chain architecture in China is "parallel chain-shard-main chain-shard-parallel chain":

[0160] 1. Collaboration Process (Smart Contract + Off-Chain Gateway)

[0161] Transaction notarization: Cross-chain transactions are first sent to a smart contract on the relay chain to record the transaction status and logs;

[0162] Legality verification: The relay chain smart contract verifies the legality of transactions (such as signature validity and balance adequacy);

[0163] Off-chain forwarding: Transactions are forwarded to the target chain via an off-chain gateway. Figure 3 The functional logic of the "Message Bus - Transaction Forwarding Scheduler" in China;

[0164] Result feedback: After the target chain executes the transaction, the result is fed back to the relay chain to achieve indirect communication, which is suitable for multi-chain scenarios with weak mutual trust.

[0165] (ii) Gateway mode (direct communication, high trust scenario)

[0166] Gateway mode enables cross-chain interaction through trusted connections between off-chain gateways, corresponding to Figure 3 The architectural logic of "sharding-inter-shard communication-sharding" in China:

[0167] 1. Communication process (standard protocol + signature verification)

[0168] Trust gateway establishment: Off-chain gateways for both cross-chain parties establish communication connections based on standard protocols (such as HTTP and WebSocket);

[0169] Transaction forwarding: After receiving a cross-chain transaction, the gateway performs authentication and signature verification on the transaction (such as verifying the sender's signature and verifying transaction parameters);

[0170] Direct forwarding: Transactions are forwarded directly to the target chain via a trusted connection, reducing intermediate steps. This is suitable for business systems with frequent interactions and a high degree of mutual trust. Figure 3 The low-latency, high-throughput design of "inter-chip communication" in China.

[0171] (III) Direct connection mode (intermediary-free communication, high-performance scenarios)

[0172] The direct connection mode establishes a direct communication channel between the two chains, enabling direct data interaction without intermediaries. Figure 3 The minimalist architecture of "parallel chain A - shard A - shard B - parallel chain B":

[0173] 1. Channel establishment (dedicated link, low latency)

[0174] Two chains within the same institution or trust domain are directly connected via a dedicated communication link (such as a private network or high-speed channel);

[0175] Cross-chain transactions do not require third-party forwarding and are transmitted directly between chains, making them suitable for high-performance, low-latency scenarios (such as real-time data synchronization). Figure 3 The logic for supporting direct connection channels in "inter-chip communication" in China.

[0176] (iv) Sidechain mode (lightweight relay, high frequency scenario)

[0177] The sidechain model constructs dedicated lightweight sidechains for information aggregation and forwarding between multiple main chains, corresponding to... Figure 3 Extension of the "main chain-sharding-message bus" architecture:

[0178] 1. Intermediate process (temporary matching to reduce main chain load)

[0179] Sidechain positioning: Sidechains serve as intermediaries for temporary transaction matching and transfer, without needing to permanently record all transactions on the blockchain;

[0180] High-frequency transaction processing: High-frequency, small-value transactions are first processed on the sidechain (such as transaction matching and temporary accounting);

[0181] Result Synchronization: The final transaction results are synchronized to the main chain. This is suitable for businesses with high-frequency interactions and low requirements for permanent storage (such as points redemption and short-term data transfer). Figure 3 The layered design logic of the "transaction cache and storage" module.

[0182] The inter-chain interoperability model based on the proxy is a newly constructed interoperability model in this invention. It is mainly based on the forwarding scheduler of the cross-chain system, and its core steps include:

[0183] Forwarding scheduler design: The forwarding scheduler distributes cross-chain transactions to the corresponding shard nodes for consensus processing and block production according to predefined forwarding rules (such as the configuration of the correspondence between nodes and shards); after the shard submits the block, the scheduler verifies the legality of the block (such as the uniqueness of global transactions and the correctness of the timing), parses the block result and returns a response to the user node;

[0184] Interoperability verification process: After cross-shard transactions are verified by shard nodes (signature and balance validity), they are forwarded by the scheduler via a remote procedure call protocol (such as gRPC). The scheduler verifies the transaction sequence (timestamp) and cross-shard consensus (matching the consensus type of the receiving chain) to ensure the consistency of the state of cross-chain transactions.

[0185] (V) Agency Model (Heterogeneous and Complex Scenarios, Core of Innovation)

[0186] The proxy pattern, implemented based on a forwarding scheduler, is an innovative mode of this invention. It is suitable for non-peer-to-peer communication and heterogeneous complex scenarios. Figure 3 The core architecture of "forwarding scheduler-sharding-main chain-sharding" in China:

[0187] 1. Forwarding Scheduler Design (Process-Driven, Intelligent Routing)

[0188] When the forwarding scheduler starts, it performs the following initialization and processing procedures:

[0189] Configuration loading: Loads the mapping configuration between nodes and shards, and records the shard to which each node belongs;

[0190] Module initialization: Initialize the sharded chain identity manager, transaction listening service, and block commit confirmation service;

[0191] Transaction forwarding:

[0192] After a parachain user node initiates a cross-chain transaction (including the sending chain ID, receiving chain ID, and transaction data), the forwarding scheduler determines the shard node corresponding to the sending chain based on the configuration.

[0193] Each shard executes its own consensus mechanism to generate blocks and submits them to the shard validator of the scheduler.

[0194] The validator confirms the legitimacy of a block through global checks (such as preventing duplicate transactions and verifying transaction sequence).

[0195] Once the verification is successful, the scheduler sends the transaction to the receiving chain shard node via a remote procedure call protocol (such as gRPC).

[0196] If a contract call is involved, the scheduler forwards the call request through the virtual machine middleware. After the contract is executed, the updated state is packaged into a block, and after verification by the scheduler, the execution state is synchronized to the receiving chain shard nodes. Figure 3 The collaborative logic of "forwarding scheduler - transaction forwarding scheduler - consensus module" in China.

[0197] 2. Interoperability Verification Process (End-to-End Verification, Consistent Status)

[0198] When executing cross-chain transactions, the following verification process must be followed to ensure the consistency of cross-chain transactions:

[0199] Intra-shard verification: Shard A node verifies the signature validity (such as public key verification) and balance adequacy of cross-shard transactions;

[0200] Global verification by the scheduler: After a transaction is sent to the forwarding scheduler, the scheduler queries the global transaction sequence number and timestamp to confirm that the transaction is not duplicated and that the timing is correct.

[0201] Consensus type adaptation verification: Based on the consensus type of the receiving chain (such as PoW, PoS), call the corresponding verification logic to complete cross-shard consensus verification;

[0202] Results Feedback and Synchronization: After successful verification, the scheduler adds the transaction to the pending list and sends a readiness-to-execute message to the receiving shard B and related shards; after shard B and related shards execute the transaction and update their local state, they report the execution results via a remote procedure call protocol; the scheduler aggregates the results to ensure the consistency of cross-shard transaction states. Figure 3 The entire chain of security logic is implemented in the "message bus - verification service - transaction cache".

[0203] The following is a specific implementation example.

[0204] This technical solution addresses key issues such as interoperability of data formats across multiple blockchain chains, highly scalable access to parallel chains, and cross-chain data operation execution, solving the challenges of large-scale cross-chain link access and interoperability. Specifically, it comprises three core components: a multi-level adaptive multi-shard parallel cross-chain architecture, a dynamic access mechanism for cross-chain systems, and a cross-chain interoperability mode.

[0205] (1) Multi-level adaptive multi-slice parallel cross-chain architecture

[0206] This section constructs a multi-level, adaptive, multi-shard parallel cross-chain architecture, providing a cross-chain foundation for dynamic access and inter-chain interoperability, such as... Figure 1 As shown, a highly efficient and scalable cross-chain model is achieved through a hierarchical multi-shard structure model, a multi-shard adaptive iteration mechanism, and a cross-shard collaborative processing mechanism, breaking through the performance bottleneck of large-scale expansion of blockchain cross-chain transactions. Specifically, the following steps are included:

[0207] 1) Hierarchical multi-piece structure model

[0208] Step S1: Construct a multi-level cross-chain architecture

[0209] The multi-layered cross-chain architecture comprises a main chain and multiple shards. The main chain, as the core of cross-chain coordination, is responsible for global consensus anchoring, recording shard committee election results, and handling cross-shard transaction routing and verification. Multiple shards are parallel business shards, carrying out specific transaction execution. A Verifiable Random Function (VRF) distributed random number generation algorithm is used to proportionally allocate shards and nodes, reducing the input size of a single election and achieving large-scale scalability of shards. Specifically, VRF input parameters include the current timestamp T, the set of node IDs N, and the previous period's random number R_prev. The output random number R and a correctness proof π satisfy the hash function constraint H(R||π)=H_prev, where H is the SHA-256 hash function and H_prev is the hash value of the previous period. Main chain nodes verify π, checking whether H(R||π) equals H_prev to confirm that the committee formation process has not been tampered with, ensuring the randomness and fairness of shard committee members.

[0210] Step S2: Consensus Result Verification and Load Balancing

[0211] Through the consensus result verification protocol, the main-chain nodes can confirm that the consensus reaching protocol of each shard runs correctly and generate valid blocks. After the shard committee generates a block, the main-chain nodes verify whether the block header hash H_blk matches the Merkle root M_root through a light client to confirm the validity of the block. At the same time, based on the number of unconfirmed transactions U within the shard, the remaining load L = U_max - U (U_max is the maximum processing capacity of the shard) is calculated, and the node level t is divided in combination with the node verification speed v (transactions per second) and the historical accuracy rate α (between 0 and 1), where t = k * v + m * α, and k and m are weight coefficients. Nodes are dynamically allocated to different shards to solve the problem of load imbalance and improve throughput.

[0212] 2) Multi-Shard Adaptive Iterative Mechanism

[0213] Step S1: Establishment of the Initial Trusted Committee

[0214] In the initial stage, the main-chain genesis nodes form a trusted committee with a size of 3f + 1, where f is the number of malicious nodes tolerated. All nodes compete for membership in the shard committee by solving calculations based on the Simple Proof of Work (PoW) mechanism, that is, calculating a nonce that satisfies H(nonce||prev_hash) < target. When nodes that complete the calculation account for N ≥ 2 / 3 of the total number of shard nodes, the trusted committee verifies its correctness and generates the committee for the first shard. Repeat this process until the committee members of all shards in the first epoch and the trusted committee for the next epoch are determined. Based on the Simple Proof of Work mechanism and the membership list confirmation mechanism, it can be ensured that the number of honest nodes in a single shard is greater than 2 / 3.

[0215] Step S2: Rotation and Secure Update of the Shard Committee

[0216] At the end of each epoch when switching to the next epoch, the trusted committee constructs a Merkle tree based on the address transaction type (UTXO) of the current shard and submits the root node data M. M = H(h1||h2||...||h n ), h i = H(tx i ), UTXO = {tx1, tx2,..., tx n}, where || represents the concatenation operation of hash values, H(·) is a secure hash function, and tx i represents the i-th unspent transaction output. The submitted root node data will be used as a reference for new members to update their UTXOs from old members, preventing malicious nodes from sending incorrect UTXO data. In addition, this method also improves the reconstruction efficiency of the committee. After entering the next epoch, the election of committee members for each shard will start again, implementing a secure and efficient shard committee rotation mechanism.

[0217] 3) Cross-chip collaborative processing mechanism

[0218] Step S1: Responsive Sharded Transaction Processing Protocol

[0219] Cross-shard transaction processing is decoupled into two processes: inter-shard interaction and intra-shard interaction. First, for inter-shard interaction, a reliable multi-signature protocol is constructed. This involves maintaining a valid public key list PK_list, providing a signature sharing and generation interface Sig_i = Sign(SK_i, PK_list[j]), where SK_i represents the private key of the i-th shard node, PK_list[j] refers to the public key of the j-th shard node in the public key list, Sign() represents the signature from node i to node j, and Verify(AggSig, Pk) is used to verify the aggregated public key. list The algorithm, AggSig = Aggregate(Sig_1, Sig_2, ..., Sig_n), implements a consistent state view across all cross-shard nodes in the absence of a trusted party. Secondly, for intra-shard interactions, to reduce message complexity within shards, a Fast Byzantine Fault Tolerance (FBFT) protocol is used, employing a master node proposal and slave node voting mechanism to achieve efficient intra-shard communication consistency. Finally, combining inter-shard multi-signature aggregation algorithms and intra-shard FBFT protocols, input availability authentication is provided while simultaneously processing transactions, ensuring real-time transaction responses.

[0220] Step S2: General processing of heterogeneous cross-chip transactions

[0221] For cross-shard requests involving heterogeneous transactions, including scenarios with heterogeneous data (such as UTXO models and account models) and heterogeneous behaviors (such as smart contract calls), a general security structure model for cross-shard transactions is constructed to achieve one-time encapsulation and cross-shard compatibility of heterogeneous transactions. A general description interface for heterogeneous cross-shard data is defined as TX = {tx_id, sender, receiver, data_model, consensus_type}, where data_model represents the data structure type and consensus_type represents the sharding consensus mechanism. During cross-shard transaction processing, TX data conforming to the receiver's sharding rules is dynamically generated based on the sender's shard's data_model and consensus_type. For example, if the sender uses a UTXO model and the receiver uses an account model, the UTXO input / output list is converted into the account model's balance change records. After receiving the TX data, the receiver shard performs data structure and consensus verification based on data_model and consensus_type.

[0222] (2) Dynamic access mechanism for cross-chain systems

[0223] This section establishes a dynamic access mechanism for cross-chain systems, supporting flexible access for homogeneous / heterogeneous parallel chains, such as... Figure 2 As shown. This cross-chain system's dynamic access mechanism supports dynamic access for 120 homogeneous / heterogeneous blockchains across six types: Ethereum, Chang'an Chain, BUBI Chain, Haihe Smart Chain, Hyperledger Fabric, and FISCO BCOS. The specific steps include:

[0224] 1) Chain digital identity identification and physical address identification

[0225] Step S1: Assign Chain Digital Identity

[0226] Each parachain to be integrated into the cross-chain system first needs to be assigned a unique digital identity, commonly known as a chain ID. The chain ID can be generated based on the chain type, genesis block hash, or other unique parameters, and is used to identify each independent parachain in the cross-chain system. The main chain generates a unique chain ID using the hash function Chain_ID = H(Genesis_Hash||Type||Consensus) (H is the SHA-256 algorithm), ensuring global uniqueness.

[0227] Step S2: Physical address binding and storage

[0228] Each parachain to be connected binds its communication node's physical address information, such as IP address and port, to its chain ID, generating a mapping table {Chain_ID:(IP,Port)}. This binding ensures that each chain can address and communicate in the cross-chain network using its unique identifier. The main chain node stores this mapping table in its routing table module for unified management and maintenance, enabling cross-chain addressing. Through this mechanism, chains in the cross-chain system can communicate seamlessly, avoiding address conflicts or incorrect addressing.

[0229] 2) Routing protocols and unified communication architecture

[0230] Step S1: Encapsulate routing protocol

[0231] To further simplify the cross-chain communication process, functionality is encapsulated based on a routing protocol. Addressing and communication between blockchains are encapsulated in the routing layer. The routing protocol manages and coordinates the transmission paths of cross-chain transactions, ensuring messages are transmitted between different parachains via the optimal path. The encapsulated addressing interface establishes a mapping between chain IDs, chain types, and physical addresses, and passes this information to the routing layer. The routing layer handles the forwarding of cross-chain messages, ensuring each cross-chain request is correctly routed to the target parachain.

[0232] Step S2: Simplify application layer calls

[0233] By encapsulating addressing and communication functions within the routing layer, the application layer only needs to call the preset addressing interface CrossChainCall(TX) to achieve cross-chain operations, without needing to concern itself with the underlying addressing details. By querying the routing table {Chain_ID:(IP,Port)}, the interface internally maps the receiving chain ID of TX to the physical address, and forwards it to the target chain through the routing layer.

[0234] 3) Flexible addressing protocols and automated access procedures

[0235] Step S1: Automatic Access Application

[0236] To support dynamic parachain access, an automated parachain access process is built based on an addressing protocol. This automated access application process automatically creates a unique chain ID for each newly accessed blockchain and binds its physical address to that chain ID. Afterward, the blockchain to be accessed submits an access request (including chain ID, physical address, consensus algorithm, etc.) to the main chain access management module.

[0237] Step S2: Complete access and synchronization

[0238] The access management module verifies the legitimacy of requests, such as checking the uniqueness of the chain ID and the reachability of the physical address. If successful, it automatically writes {Chain_ID:(IP,Port)} into the routing table and synchronizes it to all shard nodes via broadcast messages. After a new chain node joins the cross-chain system, it can conduct cross-chain transactions and message passing with other connected chains through the routing layer.

[0239] (3) Cross-chain system interoperability mode

[0240] This section establishes a cross-chain system interoperability model, enabling efficient concurrent processing of cross-chain transactions and ensuring interconnectivity between parallel chains, such as... Figure 3 As shown. This cross-chain system supports five inter-chain interoperability modes, including relay mode, gateway mode, direct connection mode, sidechain mode, and proxy mode. The proxy mode is a newly constructed interoperability mode in this invention, primarily implemented based on the cross-chain system's forwarding scheduler. The proxy mode interoperability specifically includes the following steps:

[0241] 1) Forwarding Scheduler Design

[0242] The forwarding scheduler is the module in a cross-chain system responsible for handling transaction requests. It processes cross-chain transaction requests from parachain users and, according to predefined forwarding rules, sends the transactions to the corresponding shards for consensus processing and block production. Blocks submitted by shards are verified by the scheduler, which then parses the block results and sends a response to the user. The forwarding scheduler includes the following steps:

[0243] Step S1: Start the forwarding scheduler

[0244] At startup, the configuration of all nodes and their shard correspondences is loaded, the shard to which each node belongs is recorded, the shard chain identity manager is initialized, and the transaction listening service and block commit confirmation service are started.

[0245] Step S2: User Transaction Initiation and Forwarding

[0246] Parachain user nodes initiate cross-chain transactions (TX) via a client (including the sending chain ID From_Chain, the receiving chain ID To_Chain, and the transaction data Data). The transaction forwarding scheduler determines the corresponding shard node for the sending chain based on the node shard mapping configuration. Each shard executes its own consensus mechanism to generate a block. The generated block is submitted to the shard validator of the forwarding scheduler to verify the legality of the block transaction (a global check prevents duplicate transactions and out-of-order transactions). Upon successful verification, the verification result is returned to the forwarding scheduler, and the block is simultaneously transmitted to the transaction forwarding scheduler. The scheduler then sends the TX to the receiving chain shard node via the gRPC protocol.

[0247] Step S3: Contract Invocation Processing

[0248] After receiving and verifying a block, the forwarding scheduler, if encountering a contract call transaction, forwards the call request to the contract execution via the virtual machine middleware. After the contract executes, it packages the updated state into a block. The block is then submitted back to the forwarding scheduler, which verifies the block's validity and synchronizes the execution state to the receiving chain shard nodes via the gRPC protocol.

[0249] 2) Interoperability Verification Process

[0250] During the interoperability process between parallel blockchains, the scheduler node and shard nodes exchange information efficiently and with low latency to verify the correctness of transaction information, ensuring rapid processing of cross-shard transactions and consistency of the global state. The interoperability verification process includes the following steps:

[0251] Step S1: Cross-Segment Transaction Forwarding

[0252] Parachain user nodes initiate cross-shard transactions TX in shard A. The node in shard A verifies the validity of TX by checking whether the signature Sig satisfies Verify(Sig,TX,PK_sender) and whether the balance is sufficient. After successful verification, the transaction is sent to the forwarding scheduler node via the gRPC protocol.

[0253] Step S2: Global Verification and Coordination

[0254] After receiving a transaction (TX), the forwarding scheduler node first performs a global verification. It queries the TX_ID using the global transaction sequence number and confirms that the timestamp T is not out of order, thus confirming that the TX is not duplicated. Next, it performs cross-shard consensus verification. Based on the consensus type of the receiving chain, it invokes the corresponding verification logic, such as Proof-of-Work (PoW) verification or Proof-of-Stake (PoS) verification. After successful verification, the TX is added to the pending list, and a readiness-to-execute message is sent via gRPC to the receiving shard B and other shards that need to participate in the state update.

[0255] Step S3: Transaction Execution and State Synchronization

[0256] After receiving confirmation from the scheduler node, shard B node and other relevant shard nodes begin executing transactions and updating their respective local states. Once the transaction is complete, shard B node and other relevant shard nodes again report the execution result to the scheduler node via gRPC. The scheduler node aggregates the feedback from all shard nodes to ensure cross-shard transaction state consistency and records the final result.

[0257] The example above designs and employs a dynamic cross-chain system access mechanism, enabling various homogeneous / heterogeneous parallel chains to flexibly access the cross-chain system and achieve adaptive access for different blockchains. This mechanism supports dynamic access for 120 homogeneous / heterogeneous blockchains across six types, including Chang'an Chain, Ethereum, Haihe Smart Chain, BUBI Chain, Hyperledger Fabric, and FISCO BCOS.

[0258] The dynamic access mechanism is a fundamental capability module of the cross-chain system, responsible for the automatic registration, access, and routing management of homogeneous / heterogeneous chains, supporting the system's elastic scaling of the number of chains and heterogeneous compatibility. Specific functions are as follows:

[0259] Chain registration and identification: Supports access to the system from various blockchain systems (such as Chang'an Chain, Ethereum, Haihe Smart Chain, Bubi Chain, Hyperledger Fabric, FISCO BCOS). When accessing the system, a unique ChainID is assigned to each chain and a chain information directory is established.

[0260] Dynamic discovery and management: Through the dynamic access protocol stack deployed by the off-chain gateway, the automatic discovery, configuration and cross-chain capability verification of new access chains are realized;

[0261] Cross-chain routing synchronization: Synchronizes new link entry information to the parallel chain routing table to enable dynamic path calculation during cross-chain transactions;

[0262] Chain status monitoring: Supports chain node status monitoring and connectivity detection, providing real-time chain health data support for cross-chain calls.

[0263] This mechanism significantly improves the manageability and scalability of the system in scenarios with multi-chain heterogeneity and rapid growth in the number of chains, providing a good supporting environment for cross-chain interoperability modules.

[0264] To verify the above technical solution, the dynamic access and cross-chain interaction effects of 120 homogeneous / heterogeneous blockchains across six types were tested. The six blockchains selected for testing included Chang'an Chain (version 2.3.1), Ethereum (version 1.10), Haihe Smart Chain (version 2.0), BUBI Chain (version 3.0), Hyperledger Fabric (version 2.5), and FISCO BCOS (version 2.2). Each type was configured with 20 chains, totaling 120 chains, deployed on 20 Huawei Cloud application chain servers (each running one of the six types of chains). The server hardware was an x1e.16u.32g instance, equipped with a 3rd generation Intel Xeon Scalable processor (base frequency 2.8GHz / turbo frequency 3.5GHz), 32GB of memory, a 40GB hard drive, and the operating system Ubuntu 20.04, relying on Go 1.18 and corresponding chain deployment tools (such as Chainmaker, Geth, etc.).

[0265] During the integration process, each new chain submits a request containing its chain ID, physical address, and consensus algorithm. The main chain then connects to the management module to verify the uniqueness of the chain ID, the reachability of the physical address, and the compliance of the smart contract. Once verified, the mapping relationship is written into the routing table and broadcast to all shard nodes. Real-world testing shows that all chains successfully integrated, the routing table can be updated incrementally in real time, there were no data conflicts when 10 new parachains were added, and the chains maintain stable connectivity through heartbeat monitoring.

[0266] After 120 links were added, cross-chain interactions functioned normally in all five modes: In relay mode, cross-chain requests initiated by any source chain to the target chain were processed by the relay chain, and the target chain was able to correctly execute contract calls and return receipts; in gateway mode, high-frequency interactions between mutually trusted chains were efficiently forwarded through trusted connections of off-chain gateways; in direct connection mode, a direct channel was established between high-trust chains within the consortium to achieve low-latency direct communication; in sidechain mode, as a lightweight relay, the results of high-frequency temporary transactions were synchronized to the main chain with low resource consumption; and in proxy mode, transaction verification and contract calls in heterogeneous scenarios were completed through a forwarding scheduler, ensuring cross-chain state consistency.

[0267] The adaptation measures for heterogeneous characteristics have been tested and proven effective: the dynamic access layer encapsulates and shields the underlying address differences through chain IDs and routing protocols, supporting the connection of different consensus algorithms; the general description interface of the data interaction layer enables the conversion between the UTXO model and the account model, as well as different contract standards; the diversified design of the interoperability mode layer adapts to different scenarios. Real-world testing verifies that cross-chain transactions between any two blockchains can be executed correctly, and the proxy mode performs stably in complex scenarios such as non-peer-to-peer chain communication.

[0268] The above example also designs a cross-chain interoperability mode, enabling efficient concurrent processing of cross-chain transactions, improving the processing speed of cross-shard transactions, and ensuring interoperability between blockchains. This mode supports five interoperability modes: relay mode, gateway mode, direct connection mode, sidechain mode, and proxy mode. Among them, the proxy mode concept is a newly constructed interoperability mode in this invention.

[0269] The inter-chain interoperability mode is a core capability module of the cross-chain system, responsible for the trusted interoperability of data, assets, and instructions between parallel chain systems, ensuring the security, consistency, and efficiency of cross-chain interactions. This module supports the following five cross-chain interoperability modes to meet the needs of different business systems in inter-chain communication scenarios:

[0270] Relay Mode: Cross-chain communication is achieved based on a relay chain. Through the collaboration of on-chain smart contracts and off-chain gateways, cross-chain transactions are notarized, verified, and forwarded. The relay chain acts as a communication hub, maintaining the state consistency of cross-chain transactions and the traceability of transaction logs. It is suitable for indirect communication between multiple chains and inter-chain transactions with weak mutual trust, and has the advantages of decentralization, high security, and transaction traceability.

[0271] Gateway mode: A trusted connection is established between off-chain gateways, and data exchange and forwarding between chains are completed through standard protocols. Authentication and signature verification are performed by both chain gateways. This mode is suitable for business systems with strong trust relationships and frequent interactions between peer chains, and has the advantages of high communication efficiency and low deployment cost.

[0272] Direct connection mode: A direct communication channel is established between two chains for direct data interaction without intermediaries. It is suitable for high-performance, low-latency cross-chain call scenarios. It is also suitable for internal chain-to-chain communication with high mutual trust and the ability to build consortia, offering advantages of low latency and high throughput.

[0273] Sidechain mode: A dedicated lightweight chain is built as a sidechain for information aggregation and forwarding between multiple main chains, serving as a temporary transaction matching and intermediary. It is suitable for cross-chain businesses with high-frequency interactions but no need for permanent on-chain storage, offering advantages such as low resource consumption and high transaction throughput.

[0274] Proxy Mode: This mode utilizes off-chain proxy services to handle cross-chain message transmission, signature verification, and notarization. The proxy service uses a trusted middleware component to verify message integrity and legitimacy. It is suitable for non-peer-to-peer chain communication, scenarios with limited chain environments, or heterogeneous and complex environments, and boasts strong compatibility.

[0275] This model enables efficient interconnection and flexible expansion of cross-chain systems by supporting five differentiated interoperability methods. Among them, the proxy mode, as an innovation, focuses on solving the problem of trusted interaction in complex environments between heterogeneous chains, while the four basic modes of relay, gateway, direct connection, and sidechain cover the needs of mainstream cross-chain scenarios.

[0276] The various embodiments described in this specification are presented in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. The above description of the disclosed embodiments enables those skilled in the art to make or use the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A dynamic access and chain-chain intercommunication method for a cross-chain system, characterized in that, The method comprises the following steps: A multi-level adaptive multi-piece parallel cross-chain architecture is constructed, which includes a main chain and multiple piece chains, wherein the main chain is responsible for global consensus anchoring and cross-piece transaction routing, and the multiple piece chains perform business sharding in parallel; A dynamic access mechanism for the cross-chain system is implemented, which assigns a unique chain digital identity to each parallel chain and binds it to a physical address, generates a mapping table of chain ID and physical address, and encapsulates the routing protocol to mask the underlying addressing details; A chain-to-chain interconnection mode for the cross-chain system is implemented, which supports five cross-chain interconnection modes, i.e., relay mode, gateway mode, direct connection mode, side chain mode and proxy mode, based on a forwarding scheduler, to realize transaction processing between heterogeneous chains.

2. The method of claim 1, wherein, The construction of the multi-level adaptive multi-piece parallel cross-chain architecture comprises: The shards and nodes are proportionally allocated by a verifiable random function to achieve dynamic expansion of shards; the main chain nodes verify the correctness of the random number to confirm that the shard committee formation process has not been tampered with; the nodes are divided into different shards based on the number of unconfirmed transactions in the shard, the node verification speed and the historical accuracy rate to achieve load balancing.

3. The method of claim 2, wherein, The multi-level adaptive multi-piece parallel cross-chain architecture further comprises a multi-piece adaptive iteration mechanism: In the initial stage, the main chain genesis node forms a trusted committee with a number of 3f+1, wherein f is the number of tolerated malicious nodes; the nodes compete for shard committee membership based on a simple proof of work, and when no less than 2 / 3 of the total number of shard nodes complete the calculation, the first committee of the shard is verified and generated by the trusted committee; at the end of each period, the trusted committee constructs a Merkle tree based on the UTXO of the current shard and submits the root node data as a reference for updating the UTXO of the new members, and the members of each shard committee are re-elected in the next period.

4. The method of claim 2, wherein, The multi-level adaptive multi-piece parallel cross-chain architecture further comprises a cross-piece collaborative processing mechanism: Cross-piece transaction processing is decoupled into inter-shard interaction and intra-shard interaction; inter-shard interaction realizes a consistent view of the state by maintaining a list of valid public keys, providing a signature sharing generation interface and aggregated public key verification; intra-shard interaction realizes efficient communication consistency through a fast Byzantine fault tolerance protocol with a master node proposal and a slave node vote; A general description interface for heterogeneous cross-piece data is defined to realize one-time encapsulation of heterogeneous transactions and cross-piece generalization.

5. The method of claim 1, wherein, The implementation of the dynamic access mechanism for the cross-chain system comprises: The chain ID is generated based on the type of the chain, the genesis block hash or other unique parameters, and the global uniqueness is ensured through a hash function; the IP address, port and other physical address information of the chain are bound to the chain ID, and the generated mapping table is stored in the routing table module by the main chain node for unified management.

6. The method of claim 5, wherein, The encapsulation of the routing protocol to mask the underlying addressing details comprises: The addressing and communication functions between blockchains are encapsulated in the routing layer, and the routing protocol manages the cross-chain transaction delivery path; when the application layer calls the preset addressing interface, the interface internally maps the receiving chain ID of the transaction to the physical address and forwards it to the target chain through the routing layer.

7. The method of claim 5, wherein the method is a cross-chain system-oriented dynamic access and chain-chain intercommunication method. The dynamic access mechanism further comprises an automated access process: The new chain submits an access request containing a chain ID, a physical address, and a consensus algorithm to a main chain access management module; after verifying the legality of the request, the access management module automatically writes the mapping relationship between the chain ID and the physical address into a routing table and synchronizes it to all shard nodes through broadcasting.

8. The method of claim 1, wherein, The implementation of the proxy mode includes: The forwarding scheduler loads the node and shard correspondence configuration, initializes the shard chain identity manager, starts the transaction monitoring and block submission confirmation service; after receiving the cross-chain transaction initiated by the user, it determines the corresponding shard node of the sending chain according to the configuration, verifies the legality of the shard block submission, and forwards it to the receiving chain shard node through the gRPC protocol; if it involves contract calling, the calling request is forwarded through the virtual machine middleware, and after the contract is executed, the block is verified and synchronized to the receiving chain.

9. The method of claim 8, wherein, The interconnection verification process in the proxy mode includes: After the shard node verifies the legality of the signature and balance of the cross-shard transaction, it is sent to the forwarding scheduler through the gRPC protocol; the scheduler performs global verification on the transaction, confirms that it is not repeated and the timestamp is not out of order, calls the verification logic of the corresponding consensus type to complete the cross-shard consensus verification; sends a message to prepare for execution to the receiving shard and related shards, and aggregates the execution results of each shard to ensure state consistency.

10. The method of claim 1, wherein, The relay mode is based on a relay chain, and cross-chain transaction evidence, verification and forwarding are completed through the cooperation of on-chain smart contracts and off-chain gateways; The gateway mode completes data exchange and forwarding through trust connections between off-chain gateways in a standard protocol, and authentication and signature verification are performed by both gateways; The direct connection mode realizes direct data interaction without intermediaries by establishing a direct communication channel; The side chain mode realizes information aggregation and forwarding between multiple main chains through a special lightweight side chain, and assumes the role of temporary transaction matching and transfer.

Images