Cross-chain bridge-removing main side chain interaction method, device and system

Abstract

The present application relates to the technical field of blockchain, and discloses a main side chain interaction method, device and system of a cross-chain bridge, to simplify and improve the interaction efficiency and throughput between the main side chain. The method comprises: the main side chain respectively creates a batch interaction contract; the side chain consensus node embeds an interaction event listening, information package processing and consensus program in the original consensus program; the proposal node listens to the side chain batch contract event, extracts the blocks within the preset height and event information according to the batch information, sorts and generates an information package; the information package is sent to other nodes as a consensus proposal; based on the consensus program, the votes are counted, and after enough agreement is obtained and confirmed, the information package to be submitted and the submission node are determined; the submission node starts a timer and calls the main chain batch contract for submission; the submission node tracks whether the submission is successful within the threshold: if yes, it is broadcasted and recorded; otherwise, it is terminated and the failure is broadcasted, other nodes select a new submission node according to the view switching or preset rules to continue until the submission is successfully submitted to the main chain.

Description

Technical Field

[0001] This invention relates to the field of blockchain technology, and in particular to a method, apparatus and system for main-side chain interaction without cross-chain bridges. Background Technology

[0002] Existing blockchain systems can be broadly categorized into permissioned and permissionless blockchains. Permissioned blockchains are typically used in consortium scenarios, where node identities are controlled, and they offer good performance, governance, and access control capabilities. Permissionless blockchains, on the other hand, are designed for open networks, featuring public verifiability, open access, and high liquidity, making them suitable as public settlement layers, asset-bearing layers, or cross-system interaction layers.

[0003] In practical applications, a common requirement is to synchronize confirmed transaction results, interaction messages, or state changes from within a consortium blockchain (also known as a "sidechain," which will not be elaborated upon further) to the public blockchain (also known as the "main chain") to complete public settlement, state anchoring, or main-sidechain interaction calls. Existing blockchain systems such as Figure 1 As shown, the consensus system, sorting system, and bridge verification system are each undertaken by different sets of nodes. The main chain and side chain interaction messages adopt the form of cross-chain bridges, which are extracted, verified and submitted to the target chain by independent bridge services or independent bridge committees. The specific process is as follows: consensus is first completed within the consortium chain, the sorter is responsible for organizing the messages in the chain into batches, and then handing them over to the bridge service for execution. The results are usually submitted to the public chain (i.e., Layer 1 in the diagram) by independent gateways or centralized services.

[0004] exist Figure 1 In this design, the in-chain sorting confirmation and out-of-chain interaction execution are separated into two phases and two sets of roles. The bridge service is completed by physically independent nodes, which presents the following problems: 1. Consensus confirmation is separated from external submission.

[0005] While transactions within a consortium blockchain are confirmed using a hybrid consensus mechanism (HotStuff, a secure consensus algorithm ensuring consistency) + Conflux (a tree-graph structure allowing the network to process transactions with extremely high concurrency) or other BFT (Byzantine Fault Tolerance) mechanisms, the entities submitting these results to Conflux L1 are often additionally deployed submission services or centralized gateways. This introduces a new trust dependency between "in-chain confirmation" and "out-of-chain settlement."

[0006] 2. The bridge validator and the consensus validator are separated.

[0007] Cross-chain bridges typically maintain an independent set of verification nodes. Bridge verifiers need to verify the source, order, and legitimacy of cross-chain messages again, resulting in duplicate verification, redundant construction of the identity system, and increased system complexity.

[0008] 3. The sorting results may not be consistent with the order in which the main and side chain interaction messages are pushed forward.

[0009] If the sorter, bridge service, and on-chain consensus are not unified, the generation order, submission order, and execution order of the main chain and side chain interaction payloads may deviate from the final confirmation order within the consortium chain, thereby introducing risks of out-of-order delivery, duplicate submissions, or inconsistent states.

[0010] 4. Insufficient decentralization.

[0011] Even if the consortium blockchain itself adopts HotStuff+Conflux hybrid consensus or other BFT mechanisms to achieve in-chain decentralization, when submitting batch transactions to the public blockchain and promoting the interaction payload between the main chain and the side chain, it mostly relies on a single submission node or a few bridge service nodes, forming a new single point of failure.

[0012] 5. High system maintenance and auditing costs.

[0013] When consensus nodes, commit nodes, and bridge verification nodes are independent, the system needs to maintain multiple sets of key systems, permission systems, scheduling strategies, and failover logic, which increases the operational burden. Summary of the Invention

[0014] The purpose of this invention is to disclose a method, apparatus and system for main-side chain interaction without cross-chain bridges, so as to simplify and improve the interaction efficiency and throughput between main and side chains.

[0015] To achieve the above objectives, this invention discloses a method for main-side chain interaction to eliminate cross-chain bridges, comprising: Step S1: Create batch interaction contracts for collaborative processing on the main chain and side chain respectively. The consensus nodes in the side chain embed interactive event listening programs, information packet processing programs and consensus programs for centralized processing of batch events into the traditional consensus program based on single event transactions. Step S2: After the proposal node in the current view listens to the interaction event triggered by the sidechain batch interaction contract, it extracts the block information and event information within the preset block height range according to the batch information recorded in the interaction event, and forms the main-sidechain interaction information package according to the block order. Step S3: The proposal node sends the main-sidechain interaction information packet as a consensus proposal to other consensus nodes; Step S4: Based on the consensus procedure, count the number of votes returned by the voting nodes. When the main-side chain interaction information packet obtains a preset number of agreeing votes in the consensus process and meets the confirmation conditions, the main-side chain interaction information packet is determined as a packet to be submitted, and the submission node is determined according to the consensus result. Step S5: The submitting node starts the submitting timer and calls the main chain batch interaction contract to submit the information package to be submitted to the main chain; the submitting node tracks whether the information package to be submitted is successfully submitted within the set time threshold; if the submission is successful, it broadcasts the submission success message to other consensus nodes and records the submission result; if the submission is not successful within the set time threshold, proceed to step S6. Step S6: The submitting node terminates the current submission process and broadcasts a submission failure message to other consensus nodes. Other consensus nodes determine a new submitting node according to the view switching rules or preset node selection rules in the consensus procedure. The new submitting node continues to execute step S5 until the packet to be submitted is successfully submitted to the main chain.

[0016] Preferably, the main-sidechain interaction information package includes a batch number, starting block height, ending block height, block hash record, event record, and commit status.

[0017] Preferably, in step S3, other consensus nodes act as voting nodes to verify the main-side chain interaction information package. The verification includes whether the batch number is continuous, whether the block height range conforms to the preset rules, whether the block hash record is consistent with the block hash queried by this node, and whether the event record comes from the batch interaction contract.

[0018] Preferably, the submission node determined in step S4 is a proposal node in the current view, or a node determined from the consensus nodes based on the consensus result.

[0019] Preferably, during the submission of the information packet, the submitting node determines the processing status information of each event sent in the data packet based on the receipt so that other participating nodes can synchronize.

[0020] Preferably, if the receipt shows that the transaction was executed successfully, the corresponding event is marked as successful and the corresponding transaction hash is saved; if the receipt shows that the transaction was executed unsuccessfully, the corresponding event is marked as unsuccessful and the reason for failure is recorded; if no receipt has been found, the event is kept in the pending confirmation state.

[0021] Preferably, when a single event in the data packet is successfully executed, the data packet to be submitted is determined to have been successfully submitted and the current batch number is saved so that the next interactive event can determine the new batch information by incrementing by 1; for events in the data packet to be submitted that show a transaction execution failure or a pending confirmation status, the user initiates a separate process based on a single event transaction.

[0022] To achieve the above objectives, the present invention also discloses a consensus node, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the above-described method.

[0023] To achieve the above objectives, the present invention also discloses a main-side chain interaction system without cross-chain bridges, including a main chain and a side chain. Each consensus node on the side chain includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the above-described method.

[0024] In summary, the common core technologies of the main-side chain interaction method, apparatus, and system disclosed in this invention, which eliminates cross-chain bridges, lie in: the creation of batch interaction contracts for both the main and side chains; the embedding of interaction event listening, information packet processing, and consensus procedures into the original consensus program by the side chain consensus nodes; the listening of side chain batch contract events, the extraction of block and event information within a preset height based on batch information, and the generation of information packets; the sending of the information packets as consensus proposals to other nodes; the determination of the information packets to be submitted and the submission nodes based on the statistical voting of the consensus program and after obtaining sufficient agreement and confirmation; the starting of a timer by the submission node, and the invocation of the main chain batch contract for submission; the tracking of whether the submission is successful within a threshold: if successful, it is broadcast and recorded; otherwise, it is terminated and a failure is broadcast, and other nodes select a new submission node according to view switching or preset rules to continue until the submission is successfully made to the main chain. Essentially, this invention discloses a two-layer collaborative mechanism that integrates permissioned and permissionless chains. Consortium chain validators simultaneously assume the responsibilities of sorting confirmation within the permissioned chain and external submission, public proof, and main-side chain interaction promotion within the permissionless chain, thereby simplifying and improving the interaction efficiency and throughput between the main and side chains. The specific mechanisms for achieving this effect are distributed across the following dimensions: 1. The confirmation and submission of cross-chain messages are unified and completed by the sidechain consensus node, eliminating the additional trust dependence and single point of failure risk brought by the independent bridge service, and realizing the integration of consensus and submission.

[0025] 2. Reusing existing consensus nodes for the verification and submission of main chain and side chain interaction messages avoids the separation of bridge validators and consensus validators, saves the time of repeated verification and the redundant construction of identity system, and effectively reduces system complexity.

[0026] 3. The generation order, consensus order, and submission order of the main chain and side chain interaction message packets are strictly consistent with the final confirmation order within the consortium chain, thereby eliminating the risks of out-of-order delivery, duplicate submissions, or inconsistent states.

[0027] 4. By adopting a fault tolerance mechanism that reselects the submission node based on view switching or preset rules after submission timeout, reliable submission is still possible even when a single submission node fails, thus improving the decentralization and robustness of the system.

[0028] 5. It reduces the key system, permission policies and failover logic that need to be maintained, significantly reducing system operation and maintenance and auditing costs.

[0029] 6. Batch events are processed centrally, and the interactive content is switched regularly as the batch information is updated, which saves resources and ensures the orderly progress of interactive events.

[0030] The present invention will now be described in further detail with reference to the accompanying drawings. Attached Figure Description

[0031] The accompanying drawings, which form part of this application, are used to provide a further understanding of the invention. The illustrative embodiments of the invention and their descriptions are used to explain the invention and do not constitute an undue limitation of the invention. In the drawings: Figure 1 This is a schematic diagram of an existing system architecture that enables main-sidechain interaction based on cross-chain bridges.

[0032] Figure 2 This is a schematic diagram of the main-side chain interaction method for removing cross-chain bridges disclosed in an embodiment of the present invention.

[0033] Figure 3 This is a schematic diagram of the system architecture for implementing main-side chain interaction without cross-chain bridges, as disclosed in an embodiment of the present invention. Detailed Implementation

[0034] The embodiments of the present invention will be described in detail below with reference to the accompanying drawings, but the present invention can be implemented in many different ways as defined and covered by the claims.

[0035] Example 1 This embodiment discloses a method for main-sidechain interaction without cross-chain bridges, such as... Figure 2 As shown, it includes: Step S1: Create batch interaction contracts for collaborative processing on the main chain and side chain respectively. The consensus nodes in the side chain embed interactive event listening programs, information packet processing programs and consensus programs for centralized processing of batch events into the traditional consensus program based on single event transactions.

[0036] In this step, for example, a batch typically corresponds to 256 block heights. The block height is a position at the ledger level, incremented by 1 only after a block is successfully committed.

[0037] Step S2: After the proposal node in the current view listens to the interaction event triggered by the sidechain batch interaction contract, it extracts the block information and event information within the preset block height range according to the batch information recorded in the interaction event, and forms the main-sidechain interaction information package according to the block order.

[0038] In this step, a view can be viewed as a numbered consensus round led by a single leader. The leader is a monotonically increasing integer, and each view is bound to a pre-known single leader. For example, the remainder when the view number is divided by the consensus node number determines which node will be the proposing node (or leader node). The view number represents the timeline at the consensus protocol level, incrementing by 1 each time the proposing node changes.

[0039] When a view successfully completes consensus, its corresponding block acquires a height. If a view times out and jumps directly to the next view, only the view number is incremented, not the block height. Therefore, the two increment independently, and the view number can be much larger than the block height (in the event of consecutive failures).

[0040] In a consortium blockchain, the verification members are fixed and registered with their real names, so the rules for who should be the proposal node in which view are completely transparent.

[0041] Optionally, the main-sidechain interaction information package includes a batch number, starting block height, ending block height, block hash record, event record, and commit status.

[0042] Step S3: The proposal node sends the main-sidechain interaction information packet as a consensus proposal to other consensus nodes.

[0043] In this step, other consensus nodes act as voting nodes to verify the main-sidechain interaction information packets. The verification includes whether the batch number is consecutive, whether the block height range conforms to the preset rules, whether the block hash record is consistent with the block hash queried by this node, and whether the event record comes from the batch interaction contract.

[0044] Step S4: Based on the consensus procedure, count the number of votes returned by the voting nodes. When the main-side chain interaction information packet obtains a preset number of agreeing votes in the consensus process and meets the confirmation conditions, the main-side chain interaction information packet is determined as a packet to be submitted, and the submission node is determined according to the consensus result.

[0045] Optionally, the submission node determined in this step may be a proposal node in the current view, or a node determined from the consensus nodes based on the consensus results.

[0046] Step S5: The submitting node starts the submitting timer and calls the main chain batch interaction contract to submit the information package to be submitted to the main chain; the submitting node tracks whether the information package to be submitted is successfully submitted within the set time threshold; if the submission is successful, it broadcasts the submission success message to other consensus nodes and records the submission result; if the submission is not successful within the set time threshold, proceed to step S6.

[0047] Preferably, during the submission of the data packet, the submitting node can further determine the processing status information of each event sent in the data packet based on the receipt, so that other participating nodes can synchronize. If the receipt shows that the transaction was executed successfully, the corresponding event is marked as successful and the corresponding transaction hash is saved; if the receipt shows that the transaction was executed unsuccessfully, the corresponding event is marked as unsuccessful and the reason for failure is recorded; if no receipt has been found, the event is kept in a pending confirmation state. Specifically, when a single event in the data packet is executed successfully, the data packet to be submitted is determined to have been successfully submitted, and the current batch number is saved so that the next interaction event can determine the new batch information by incrementing by 1.

[0048] Step S6: The submitting node terminates the current submission process and broadcasts a submission failure message to other consensus nodes. Other consensus nodes determine a new submitting node according to the view switching rules or preset node selection rules in the consensus procedure. The new submitting node continues to execute the submission until the packet to be submitted is successfully submitted to the main chain.

[0049] In this embodiment, for events in the pending data packet that indicate transaction execution failure or pending confirmation, the user initiates a separate single-event transaction process. In other words, if a batch corresponds to 256 block heights, this embodiment, based on the above steps, can process 256 events at once under ideal conditions; while for the small number of failed events during batch processing, the process switches to a single-event transaction process upon user request; thus ensuring overall transmission efficiency while flexibly handling special cases.

[0050] Example 2 This embodiment discloses a consensus node, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the method of Embodiment 1 described above.

[0051] Optionally, in this embodiment, the consensus node adopts a hybrid consensus mechanism of HotStuff + Conflux. In addition to the interactive event extraction module, main-side chain interactive information packet generation module, listening module, timer, information packet submission module, and broadcast module required by the above method, its internal logic functions also need to be equipped with the following conventional functional modules: Main-sidechain interaction contract management module: used to complete the instantiation of smart contracts related to main-sidechain interaction, contract call encapsulation, call parameter construction, and unified management of contract interfaces.

[0052] The batch interaction contract, which is the focus of this embodiment, can be used to verify whether the source of the submitted transaction is legal, whether the batch is valid, whether the main chain and side chain interaction information package corresponds to the confirmed result of the consortium chain, and to execute subsequent registration, settlement or interaction calls.

[0053] Unified Identity System Management Module: This module reuses the HotStuff validator identity system and provides a unified account capability interface to the outside world. It manages the address mapping, signing capabilities, sending permissions, and account context required during the interaction between the main chain and the side chain, and maintains consistency with the consortium chain validator identity system.

[0054] Main chain RPC (Remote Procedure Call) interaction module: used to establish HTTP or WebSocket communication connections with the main chain to complete log query, transaction sending, status query, receipt confirmation and block listening.

[0055] Example 3 This embodiment discloses a main-side chain interaction system without cross-chain bridges, including a main chain and a side chain. Each consensus node on the side chain includes a memory, a processor, and a computer program stored in the memory and capable of running on the processor. When the processor executes the computer program, it implements the method described in Embodiment 1 above.

[0056] In summary, the core technology of the main-side chain interaction method, apparatus, and system for eliminating cross-chain bridges disclosed in the above embodiments of the present invention lies in: the main chain and side chain respectively create batch interaction contracts; the side chain consensus node embeds interaction event listening, information packet processing, and consensus program into the original consensus program; the proposal node listens to the side chain batch contract events, extracts block and event information within a preset height according to the batch information, and sorts and generates an information packet; the information packet is sent as a consensus proposal to other nodes; based on the consensus program's statistical voting, after obtaining sufficient agreement and confirmation, the information packet to be submitted and the submission node are determined; the submission node starts a timer and calls the main chain batch contract to submit; the submission node tracks whether the submission is successful within a threshold: if successful, it broadcasts and records; otherwise, it terminates and broadcasts failure, and other nodes select a new submission node according to view switching or preset rules to continue until the submission is successfully submitted to the main chain. Its essence discloses a method such as... Figure 3 The illustrated two-layer collaborative mechanism integrating permissioned and permissionless blockchains involves consortium blockchain validators simultaneously undertaking the responsibilities of order confirmation within the permissioned blockchain and external submission, public proof, and main-side chain interaction within the permissionless blockchain. This simplifies and improves the efficiency and throughput of interactions between the main and side chains. The specific mechanisms that achieve this effect are distributed across the following dimensions: 1. The confirmation and submission of cross-chain messages are unified and completed by the sidechain consensus node, eliminating the additional trust dependence and single point of failure risk brought by the independent bridge service, and realizing the integration of consensus and submission.

[0057] 2. Reusing existing consensus nodes for the verification and submission of main chain and side chain interaction messages avoids the separation of bridge validators and consensus validators, saves the time of repeated verification and the redundant construction of identity system, and effectively reduces system complexity.

[0058] 3. The generation order, consensus order, and submission order of the main chain and side chain interaction message packets are strictly consistent with the final confirmation order within the consortium chain, thereby eliminating the risks of out-of-order delivery, duplicate submissions, or inconsistent states.

[0059] 4. By adopting a fault tolerance mechanism that reselects the submission node based on view switching or preset rules after submission timeout, reliable submission is still possible even when a single submission node fails, thus improving the decentralization and robustness of the system.

[0060] 5. It reduces the key system, permission policies and failover logic that need to be maintained, significantly reducing system operation and maintenance and auditing costs.

[0061] 6. Batch events are processed centrally, and the interactive content is switched regularly as the batch information is updated, which saves resources and ensures the orderly progress of interactive events.

[0062] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for removing cross-chain bridges and facilitating main-sidechain interactions, characterized in that, include: Step S1: Create batch interaction contracts for collaborative processing on the main chain and side chain respectively. The consensus nodes in the side chain embed interactive event listening programs, information packet processing programs and consensus programs for centralized processing of batch events into the traditional consensus program based on single event transactions. Step S2: After the proposal node in the current view listens to the interaction event triggered by the sidechain batch interaction contract, it extracts the block information and event information within the preset block height range according to the batch information recorded in the interaction event, and forms the main-sidechain interaction information package according to the block order. Step S3: The proposal node sends the main-sidechain interaction information packet as a consensus proposal to other consensus nodes; Step S4: Based on the consensus procedure, count the number of votes returned by the voting nodes. When the main-side chain interaction information packet obtains a preset number of agreeing votes in the consensus process and meets the confirmation conditions, the main-side chain interaction information packet is determined as a packet to be submitted, and the submission node is determined according to the consensus result. Step S5: The submitting node starts the submitting timer and calls the main chain batch interaction contract to submit the information package to be submitted to the main chain; The submission node tracks whether the packet to be submitted is successfully submitted within a set time threshold. If the submission is successful, broadcast the success message to other consensus nodes and record the submission result; If the submission is not successful within the set time threshold, proceed to step S6; Step S6: The submitting node terminates the current submit process and broadcasts a submit failure message to other consensus nodes; Other consensus nodes determine a new submission node based on the view switching rules or preset node selection rules in the consensus procedure. The new submission node then continues to execute step S5 until the packet to be submitted is successfully submitted to the main chain.

2. The method for removing cross-chain bridges and facilitating main-side chain interactions according to claim 1, characterized in that, The main-sidechain interaction information package includes batch number, starting block height, ending block height, block hash record, event record, and commit status.

3. The method for removing cross-chain bridges and the interaction between main and side chains according to claim 2, characterized in that, In step S3, other consensus nodes, acting as voting nodes, verify the main-sidechain interaction information packet. The verification includes whether the batch number is consecutive, whether the block height range conforms to the preset rules, whether the block hash record is consistent with the block hash queried by this node, and whether the event record originates from the batch interaction contract.

4. The method for main-side chain interaction to remove cross-chain bridges according to claim 1, characterized in that, The submission node determined in step S4 is either the proposal node in the current view or a node determined from the consensus nodes based on the consensus result.

5. The method for removing cross-chain bridges and the interaction between main and side chains according to any one of claims 1 to 4, characterized in that, Also includes: During the submission of the information packet, the submitting node determines the processing status information of each event sent in the data packet based on the receipt, so that other participating nodes can synchronize.

6. The method for removing cross-chain bridges and the interaction between main and side chains according to claim 5, characterized in that, If the receipt shows that the transaction was executed successfully, the corresponding event is marked as successful and the corresponding transaction hash is saved; if the receipt shows that the transaction was executed unsuccessfully, the corresponding event is marked as unsuccessful and the reason for failure is recorded; if no receipt has been found, the event is kept in the pending confirmation state.

7. The method for removing cross-chain bridges and the interaction between main and side chains according to claim 6, characterized in that, When a single event in the data packet is executed successfully, the data packet to be submitted is determined to have been successfully submitted and the current batch number is saved so that the next interactive event can determine the new batch information by incrementing by 1. For events in the pending information package that indicate a transaction execution failure or a pending confirmation status, the user shall initiate a separate transaction process based on a single event.

8. A consensus node, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method described in any one of claims 1 to 7.

9. A bridge-free main-side chain interaction system, comprising a main chain and side chains, wherein each consensus node on the side chain includes a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method described in any one of claims 1 to 7.

Images