Blockchain system architecture based on libp2p communication and cross-chain method thereof

Abstract

The application discloses a blockchain system architecture based on Libp2p communication and a cross-chain method thereof. The architecture comprises a data layer, a network layer, a consensus layer, a smart contract layer and an application layer. The data layer, the consensus layer, the smart contract layer and the application layer are consistent with the layering of a traditional alliance chain Hyperledger Fabric. The application introduces a Libp2p protocol in the network layer, realizes the decentralization of network communication, and guarantees the safe and reliable transmission of data in three aspects of identity authentication, node routing and channel encryption. The proxy cross-chain method comprises cross-chain SDK calling of an on-chain user, communication interaction between proxy relays, and verification interaction of SPV nodes with the on-chain user and the proxy relay respectively. The method realizes cross-chain asset and data exchange in a notary manner, solves the data island problem between blockchains, and has high universality and safety, and can be widely applied to blockchain cross-chain transaction scenes.

Description

Technical Field

[0001] This application relates to the field of blockchain application technology, and in particular to a blockchain system architecture based on Libp2p communication and its cross-chain method. Background Technology

[0002] With the development of blockchain technology, its security vulnerabilities have become increasingly prominent. In the five-layer blockchain architecture proposed by Hyperledger Fabric, the RPC (Remote Procedure Call) protocol is widely used in network layer construction. However, recent research has revealed security vulnerabilities in this protocol. The industry urgently needs more secure communication methods to ensure the normal operation of the decentralized financial system. Libp2p, as an emerging network communication protocol, has demonstrated significant advantages in network decentralization and communication security and reliability. By building a fully decentralized peer-to-peer network, Libp2p greatly improves the network's robustness and resistance to attacks; through advanced authentication, node routing, and channel encryption mechanisms, Libp2p ensures secure and reliable communication between nodes, preventing data from being illegally stolen and tampered with.

[0003] It can be seen that there are information silos between different blockchains, which restricts information communication and development in the industry. Summary of the Invention

[0004] Based on this, the embodiments of this application provide a blockchain system architecture based on Lipp2p communication and its cross-chain method. This application integrates the advantages of Lipp2p with proxy cross-chain, breaks down the barriers between different blockchains, and realizes secure and reliable centralized cross-chain interaction.

[0005] Firstly, a blockchain system architecture based on Libp2p communication is provided, including a data layer, a network layer, a consensus layer, a smart contract layer, and an application layer, specifically:

[0006] The data layer is responsible for the storage and management of basic data in the blockchain system, and ensures the integrity, immutability and permanent storage of the data through preset encryption algorithms and data structures.

[0007] The network layer includes Libp2p, which is responsible for command interaction between blockchain clients and servers, as well as communication and data distribution between blockchain nodes. It ensures distributed and secure data transmission through authentication, node routing, and channel encryption.

[0008] The consensus layer is responsible for achieving asynchronous consistency of ledger records across multiple nodes in the blockchain, and ensures the overall security and integrity of the blockchain through consensus algorithms and incentive mechanisms.

[0009] The smart contract layer is responsible for writing and implementing specific business logic. It automatically executes complex business logic in different scenarios through a virtual machine and relies on the transaction verification and block generation mechanism provided by the consensus layer to ensure the legality and consistency of transactions.

[0010] The application layer is responsible for combining blockchain technology with application scenarios, and realizing the implementation of business requirements through interaction interfaces with the blockchain network and a visual interface.

[0011] Optionally, the data layer includes a hash algorithm, timestamps, Merkle root trees, and hash pointers;

[0012] The hash algorithm includes an algorithm that unidirectionally maps input data to a fixed-length hash value, which can verify data integrity and is used for the generation of blocks and transactions;

[0013] The timestamp includes a descriptive feature of the time the block was generated, which can prevent replay attacks and ensure the temporal order of transactions.

[0014] The Merkle root tree combines all transaction hash values ​​in pairs within a block and hashes them layer by layer until the final root hash value is generated. During verification, the declaring party needs to provide all the combined hash values ​​along the path from the transaction location to the root hash. The verifying party only needs to perform a limited number of hash operations and compare whether the generated root hash is consistent with the original root hash to quickly verify whether the transaction exists.

[0015] The hash pointer value is derived from the hash value of a single block of data after processing by a hash algorithm. Each block contains a unique hash pointer, which points to the adjacent previous block, ensuring that the entire chain cannot be tampered with.

[0016] Optionally, the network layer includes Libp2p, wherein:

[0017] Libp2p ensures the legitimacy of node identities through an authentication mechanism, optimizes communication paths between nodes through a node routing mechanism, and protects the security of data transmission through a channel encryption mechanism.

[0018] Optionally, the consensus layer includes a consensus mechanism and an SPV module, wherein:

[0019] The consensus mechanism includes at least TBFT, RAFT, and DPOS, and uses voting to verify and endorse the legality and validity of ledger data, ensuring asynchronous consistency of the blockchain while preventing malicious tampering and fraud.

[0020] The SPV module is a lightweight verification module that only synchronizes block header information locally and quickly verifies the validity of transactions through interaction with full nodes.

[0021] Optionally, the smart contract layer includes a transaction SDK and a business SDK, wherein:

[0022] The transaction SDK is responsible for handling data consistency, transaction commit, transaction status recording, and rollback functions, ensuring data consistency and atomicity in multiple transaction steps;

[0023] The business SDK is a set of functions and tools for implementing business logic and blockchain interaction in different real-world scenarios.

[0024] Optionally, the application layer includes blockchain dual-carbon, blockchain environmental protection, and blockchain finance;

[0025] The blockchain-based environmental protection includes using distributed ledgers to ensure the sharing and exchange of key data among various ecological and environmental protection organizations.

[0026] The blockchain finance mentioned above includes using the decentralized, immutable, traceable, secure, and transparent nature of blockchain to optimize financial service processes.

[0027] Secondly, a cross-chain method based on Libp2p communication is provided, implemented in any of the blockchain system architectures described in the first aspect above, including the following steps:

[0028] S1. The client initiates a cross-chain request T to the cross-chain proxy.

[0029] S2. The cross-chain proxy parses the cross-chain request T and converts it into a data format T conforming to ChainA. A The system queries the routing path from the cross-chain proxy to node X using Libp2p's node routing mechanism, establishes a connection with node X of ChainA using Libp2p's authentication mechanism, and transmits data T to node X using Libp2p's secure channel mechanism. A ;

[0030] Node X in S3 and ChainA is determined by T A The content involves invoking the transaction contract to execute the corresponding business contract. After passing the on-chain consensus, the transaction execution result R is returned to the cross-chain proxy via the Libp2p technology stack in step S2. A ;

[0031] S4, SPV A Monitor and synchronize the latest transaction information of ChainA in real time;

[0032] S5, Proxy calls SPV A Transaction verification interface for R A Perform verification: If verification is successful, then convert T. A R ATo conform to ChainB's data format T B R AB And via the Libp2p technology stack in step S2, T is sent to node Y in ChainB. B R AB If verification fails, a "Fail" response is returned to the Client. TA ;

[0033] S6, the Y node in ChainB is based on T B The content calls the transaction contract to execute the corresponding business contract. After passing the on-chain consensus, the transaction execution result R is returned to the Proxy via the Libp2p technology stack in step S2. B ;

[0034] S7, SPV B Monitor and synchronize the latest transaction information of ChainB in real time;

[0035] S8, Proxy calls SPV B Transaction verification interface for R B Perform verification: If verification is successful, return a "Success" response to the Client. TA If verification fails, a "Fail" response is returned to the Client. TB .

[0036] Optionally, in step S2, the Libp2p authentication mechanism process includes the following steps:

[0037] A1. The newly joined node N1 in the Libp2p network first uses an asymmetric encryption algorithm to generate a key pair P. pub and P pri and store locally;

[0038] A2, Node N1 is based on P pub Generate a unique identifier ID for node N1 using the corresponding hash algorithm. N1 And associate it with its own characteristics;

[0039] A3. When nodes N1 and N2 establish a connection, they first exchange unique identifiers and parse out the encoding format and hash algorithm; then they obtain each other's public keys through network queries.

[0040] A4. The sender uses the receiver's public key to encrypt the data, and the receiver uses their local private key to decrypt it, thus achieving encrypted data transmission.

[0041] Optionally, in step S2, the node routing mechanism of Libp2p includes the following steps:

[0042] B1. Each node maintains a routing table, which includes the bootstrap node and adjacent known nodes when it is built. The routing table divides the recorded routing objects into different levels; each level represents the set of other nodes within a specific distance range from this node.

[0043] B2. Each node requests to discover new nodes from the routing object at fixed intervals, calculates the distance between the two points based on the response ID, and places the pair into the corresponding level.

[0044] B3. Once the target node ID is known, traverse the routing table. If the ID exists, route directly. If it does not exist, calculate the level of the target node ID and poll the nodes at that level until the target node path is found.

[0045] Optionally, in step S2, the Libp2p secure channel mechanism process includes the following steps:

[0046] C1. After successful identity authentication, both nodes exchange public information and calculate the shared key P using a zero-knowledge key exchange algorithm. share ;

[0047] C2, based on P share Encrypt the transmission using the corresponding communication encryption method;

[0048] C3. Verify the integrity of the transmitted message using a preset encoding method, and request retransmission for data packets with missing integrity.

[0049] The beneficial effects of the technical solutions provided in this application include at least the following:

[0050] This application introduces a Libp2p module at the network layer, ensuring decentralization, security, and reliability of data interaction between blockchain nodes in three parts: authentication, node routing, and channel encryption. This solves the problem of traditional consortium blockchain data transmission being easily intercepted and tampered with. The constructed Libp2p-based proxy cross-chain method integrates the advantages of Libp2p and proxy cross-chain, breaking down barriers between different blockchains and achieving secure and reliable centralized cross-chain interaction, providing technical support for the development of blockchain cross-chain services. Attached Figure Description

[0051] To more clearly illustrate the embodiments of this application or the technical solutions in 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 merely exemplary, and those skilled in the art can derive other embodiments based on the provided drawings without creative effort.

[0052] Figure 1This is a diagram illustrating the architecture of a blockchain cross-chain system based on Libp2p communication.

[0053] Figure 2 This is a flowchart of a cross-chain proxy process based on Lipp2p communication.

[0054] In the diagram: 1. Data layer; 2. Network layer; 3. Consensus layer; 4. Smart contract layer; 5. Application layer. Detailed Implementation

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

[0056] The architecture comprises a data layer, network layer, consensus layer, smart contract layer, and application layer. The data layer, consensus layer, smart contract layer, and application layer are consistent with the layering of a traditional consortium blockchain, Hyperledger Fabric. That is, the application layer completes specific business operations by calling the business logic functions provided by the smart contract layer, and communicates with blockchain nodes through the network layer to submit transaction requests and receive transaction results. Figure 1 As shown, in order to solve the problems of data hijacking and tampering in blockchain peer-to-peer communication, this application introduces the Libp2p stack in network layer 2. Under the premise of maintaining decentralization, it ensures the security and reliability of communication between blockchain nodes from three aspects: identity verification, node routing, and channel encryption.

[0057] Data layer 1 is responsible for the storage and management of basic data in the blockchain system;

[0058] Specifically, Data Layer 1 includes a hash algorithm, timestamps, a Merkle root tree, and hash pointers. The hash algorithm maps input data one-way to a fixed-length hash value, verifying data integrity and used for block and transaction generation. Timestamps are identifiable descriptions of the block's creation time, preventing replay attacks and ensuring the temporal order of transactions. The Merkle root tree combines the hash values ​​of all transactions within a block in pairs, hashing layer by layer until the final root hash value is generated. During verification, the declaring party must provide all combined hash values ​​along the path from the transaction's location to the root hash. The verifying party only needs to perform a finite number of hash operations, comparing the generated root hash with the original root hash to quickly verify the existence of the transaction. The hash pointer value originates from the hash value of a single block's data after processing by the hash algorithm. Each block contains a unique hash pointer, pointing to the adjacent previous block, ensuring the overall chain is immutable.

[0059] Network layer 2 is responsible for command interaction between blockchain clients and servers, as well as communication and data distribution between blockchain nodes;

[0060] Specifically, network layer 2 includes Lipp2p; Lipp2p includes authentication, node routing, and channel encryption, using multiple layers and mechanisms to ensure secure and reliable transmission between blockchain nodes.

[0061] Consensus layer 3 is responsible for achieving asynchronous consistency of ledger records across multiple nodes in the blockchain;

[0062] Specifically, consensus layer 3 includes a consensus mechanism and an SPV module. The consensus mechanism includes TBFT, RAFT, DPOS, etc., which use voting to verify and endorse the legality and validity of ledger data, ensuring asynchronous consistency of the blockchain while preventing malicious tampering and fraud. The SPV module is a lightweight verification module that only synchronizes block header information locally and quickly verifies the validity of transactions through interaction with full nodes.

[0063] The smart contract layer 4 is responsible for writing and implementing business logic;

[0064] Specifically, the smart contract layer 4 includes a transaction SDK and a business SDK. The transaction SDK is responsible for handling functions such as data consistency, transaction commit, transaction status recording, and rollback, ensuring data consistency and atomicity across multiple transaction steps. The business SDK provides functions and tools for interacting with the blockchain in different real-world scenarios, focusing on the implementation of business functions.

[0065] Layer 5 should be responsible for combining blockchain technology with application scenarios; specifically, application layer 5 includes blockchain dual-carbon, blockchain environmental protection, and blockchain finance; blockchain dual-carbon refers to using blockchain technology to serve dual-carbon related fields and businesses; blockchain environmental protection refers to using distributed ledgers to ensure the sharing and exchange of key data among various ecological and environmental protection agencies; blockchain finance refers to using the decentralized, tamper-proof, traceable, secure, and transparent characteristics of blockchain to improve traditional financial business processes and achieve cost reduction and efficiency improvement.

[0066] Reference Figure 2 As shown, to address the issue of data and business isolation across different blockchains, this application proposes a proxy cross-chain method based on Lipp2p communication. This method breaks down data barriers while ensuring security and reliability, enabling cross-blockchain data and value transfer. The method includes the following steps:

[0067] Step 1: The client initiates a cross-chain request T to the cross-chain proxy.

[0068] Step 2: The cross-chain proxy parses the cross-chain request T and converts it into a data format T that conforms to ChainA. AThe system queries the routing path from the cross-chain proxy to node X using Libp2p's node routing mechanism, establishes a connection with node X of ChainA using Libp2p's authentication mechanism, and transmits data T to node X using Libp2p's secure channel mechanism. A ;

[0069] The Libp2p authentication mechanism includes the following steps, where steps 21-24 correspond to steps A1-A4 mentioned above:

[0070] 21) The newly joined node N1 in the Libp2p network first generates a key pair P using a suitable asymmetric encryption algorithm (such as Ed25519, Secp256k1). pub and P pri and store locally;

[0071] 22) Node N1 is based on P pub Generate a unique identifier ID for node N1 using a suitable hash algorithm (such as SHA-256 or SHA-1). N1 And associate it with its own characteristics (such as IP address and port number);

[0072] 23) When nodes N1 and N2 establish a connection, they first exchange unique identifiers and parse out the encoding format and hash algorithm; then they obtain each other's public keys through network queries.

[0073] 24) The sender uses the receiver's public key to encrypt the data, and the receiver uses its local private key to decrypt it, thus achieving encrypted data transmission.

[0074] The Libp2p node routing mechanism includes the following steps, which are independent of steps 21-24 above. Steps 25-27 correspond to steps B1-B3 above, respectively. Specifically:

[0075] 25) Each node maintains a routing table, which includes the bootstrap node and adjacent known nodes. The routing table divides the recorded route objects into different levels. Each level represents the set of other nodes within a specific distance range from this node;

[0076] 26) Each node requests the discovery of new nodes from the routing object at fixed intervals, calculates the distance between the two points based on the response ID, and places the pair into the corresponding level;

[0077] 27) Once the target node ID is known, traverse the routing table. If the ID exists, route directly. If it does not exist, calculate the level of the target node ID and poll the nodes at that level until the target node path is found.

[0078] Steps 28-30 correspond to steps C1-C3 above, respectively. The Libp2p secure channel mechanism includes the following steps:

[0079] 28) After successful authentication, both nodes exchange public information and calculate the shared key P using an appropriate zero-knowledge key exchange algorithm (such as Diffie-Hellman). share ;

[0080] 29) Based on P share Use appropriate communication encryption methods (such as TLS 1.3, Noise) for encrypted transmission;

[0081] 30) Use appropriate encoding methods (such as MAC) to verify the integrity of transmitted messages, and request retransmission for data packets with missing integrity.

[0082] Step 3: Node X in Chain A, according to T A The content involves invoking the transaction contract to execute the corresponding business contract. After passing the on-chain consensus, the transaction execution result R is returned to the cross-chain proxy via the Libp2p technology stack in step S2. A ;

[0083] Step 4, SPV A Monitor and synchronize the latest transaction information of ChainA in real time;

[0084] Step 5: Proxy calls SPV A Transaction verification interface for R A Perform verification: If verification is successful, then convert T. A R A To conform to ChainB's data format T B R AB And via the Libp2p technology stack in step S2, T is sent to node Y in ChainB. B R AB If verification fails, a "Fail" response is returned to the Client. TA ;

[0085] Step 6: The Y node in ChainB is based on T B The content calls the transaction contract to execute the corresponding business contract. After passing the on-chain consensus, the transaction execution result R is returned to the Proxy via the Libp2p technology stack in step S2. B ;

[0086] Step 7, SPV B Monitor and synchronize the latest transaction information of ChainB in real time;

[0087] Step 8: Proxy calls SPV B Transaction verification interface for R B Perform verification: If verification is successful, return a "Success" response to the Client. TA If verification fails, a "Fail" response is returned to the Client. TB .

[0088] This application provides a blockchain system architecture and cross-chain method based on Lipp2p communication, which solves the problems of centralization, easy hijacking and tampering of traditional RPC communication networks. It deeply integrates the unique advantages of Lipp2p and proxy cross-chain, successfully breaks down information barriers between different blockchains, and realizes secure and reliable decentralized cross-chain interaction.

[0089] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0090] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this patent application should be determined by the appended claims.

Claims

1. A cross-chain method based on Libp2p communication, characterized in that, When applied to a blockchain system architecture based on Libp2p communication, the following steps are included: S1, Client Client To cross-chain proxy Proxy Initiate a cross-chain request T ; S2, cross-chain proxy Proxy Parsing cross-chain requests T Transform cross-chain requests T To comply with ChainA Data format T A Query cross-chain proxies through Libp2p's node routing mechanism. Proxy arrive X The node's routing path is determined through Libp2p's authentication mechanism. ChainA node X Establish a connection and transmit data through Libp2p's secure channel mechanism. X Node transmission T A ; S3 ChainA Nodes in X according to T A The content calls the transaction contract to execute the corresponding business contract. After passing the on-chain consensus, it is sent to the cross-chain proxy via the Libp2p technology stack in step S2. Proxy Return transaction execution result R A ; S4 SPV A Listen and synchronize in real time ChainA Latest transaction information; S5 Proxy Call SPV A Transaction verification interface R A Perform verification: If verification is successful, then convert. T A , R A To comply with ChainB Data format T B , R AB And via the Libp2p technology stack in step S2, to ChainB Nodes in Y send T B , R AB If verification fails, then send to Client Return transaction failure response Fail TA ; S6 ChainB In Y Nodes based on T B The content calls the transaction contract to execute the corresponding business contract. After passing the on-chain consensus, it is then transmitted to the relevant party via the Libp2p technology stack in step S2. Proxy Return transaction execution result R B ; S7 SPV B Listen and synchronize in real time ChainB Latest transaction information; S8 Proxy Call SPV B Transaction verification interface R B Perform verification: If verification is successful, then send to Client Transaction successful response Success TA If verification fails, then send to Client Return transaction failure response Fail TB ; The blockchain system architecture based on Libp2p communication includes a data layer, a network layer, a consensus layer, a smart contract layer, and an application layer. The data layer is responsible for the storage and management of basic data in the blockchain system, and ensures the integrity, immutability and permanent storage of the data through preset encryption algorithms and data structures. The network layer includes Libp2p, which is responsible for command interaction between blockchain clients and servers, as well as communication and data distribution between blockchain nodes. It ensures distributed and secure data transmission through authentication, node routing, and channel encryption. The consensus layer is responsible for achieving asynchronous consistency of ledger records across multiple nodes in the blockchain, and ensures the overall security and integrity of the blockchain through consensus algorithms and incentive mechanisms. The smart contract layer is responsible for writing and implementing specific business logic. It automatically executes complex business logic in different scenarios through a virtual machine and relies on the transaction verification and block generation mechanism provided by the consensus layer to ensure the legality and consistency of transactions. The application layer is responsible for combining blockchain technology with application scenarios, and realizing the implementation of business requirements through interaction interfaces with the blockchain network and a visual interface.

2. The cross-chain method according to claim 1, characterized in that, In step S2, the Libp2p authentication mechanism process includes the following steps: A1. Newly joined nodes in the Libp2p network N 1 First, a key pair is generated using an asymmetric encryption algorithm. P pub and P pri and store locally; A2, Node N 1 based on P pub Nodes are generated using the corresponding hash algorithm. N 1 Unique identifier ID N1 And associate it with its own characteristics; A3, Node N 1 and N 2 When establishing a connection, they first exchange unique identifiers and parse out the encoding format and hash algorithm; then they obtain each other's public keys through network queries. A4. The sender uses the receiver's public key to encrypt the data, and the receiver uses their local private key to decrypt it, thus achieving encrypted data transmission.

3. The cross-chain method according to claim 1, characterized in that, In step S2, the node routing mechanism of Libp2p includes the following steps: B1. Each node maintains a routing table, which includes the bootstrap node and adjacent known nodes when it is built. The routing table divides the recorded routing objects into different levels; each level represents the set of other nodes within a specific distance range from this node. B2. Each node requests to discover new nodes from the routing object at fixed intervals, calculates the distance between the two points based on the response ID, and places the pair into the corresponding level. B3. Once the target node ID is known, traverse the routing table. If the ID exists, route directly. If it does not exist, calculate the level of the target node ID and poll the nodes at that level until the target node path is found.

4. The cross-chain method according to claim 1, characterized in that, In step S2, the Libp2p secure channel mechanism process includes the following steps: C1. After successful identity authentication, both nodes exchange public information and calculate the shared key using a zero-knowledge key exchange algorithm. P share ; C2, based on P share Encrypt the transmission using the corresponding communication encryption method; C3. Verify the integrity of the transmitted message using a preset encoding method, and request retransmission for data packets with missing integrity.

5. The cross-chain method according to claim 1, characterized in that, The data layer includes a hash algorithm, timestamps, Merkle root trees, and hash pointers; The hash algorithm includes an algorithm that unidirectionally maps input data to a fixed-length hash value, which can verify data integrity and is used for the generation of blocks and transactions; The timestamp includes a descriptive feature of the time the block was generated, which can prevent replay attacks and ensure the temporal order of transactions. The Merkle root tree combines all transaction hash values ​​in pairs within a block and hashes them layer by layer until the final root hash value is generated. During verification, the declaring party needs to provide all the combined hash values ​​along the path from the transaction location to the root hash. The verifying party only needs to perform a limited number of hash operations and compare whether the generated root hash is consistent with the original root hash to quickly verify whether the transaction exists. The hash pointer value is derived from the hash value of a single block of data after processing by a hash algorithm. Each block contains a unique hash pointer, which points to the adjacent previous block, ensuring that the entire chain cannot be tampered with.

6. The cross-chain method according to claim 1, characterized in that, The network layer includes Libp2p, wherein: Libp2p ensures the legitimacy of node identities through an authentication mechanism, optimizes communication paths between nodes through a node routing mechanism, and protects the security of data transmission through a channel encryption mechanism.

7. The cross-chain method according to claim 1, characterized in that, The consensus layer includes a consensus mechanism and an SPV module, wherein: The consensus mechanism includes at least TBFT, RAFT, and DPOS, and uses voting to verify and endorse the legality and validity of ledger data, ensuring asynchronous consistency of the blockchain while preventing malicious tampering and fraud. The SPV module is a lightweight verification module that only synchronizes block header information locally and quickly verifies the validity of transactions through interaction with full nodes.

8. The cross-chain method according to claim 1, characterized in that, The smart contract layer includes a transaction SDK and a business SDK, wherein: The transaction SDK is responsible for handling data consistency, transaction commit, transaction status recording, and rollback functions, ensuring data consistency and atomicity in multiple transaction steps; The business SDK is a set of functions and tools for implementing business logic and blockchain interaction in different real-world scenarios.

9. The cross-chain method according to claim 1, characterized in that, The application layer includes blockchain dual-carbon, blockchain environmental protection, and blockchain finance; The blockchain-based environmental protection includes using distributed ledgers to ensure the sharing and exchange of key data among various ecological and environmental protection organizations. The blockchain finance mentioned above includes using the decentralized, immutable, traceable, secure, and transparent nature of blockchain to optimize financial service processes.

Images