CN117951217A

CN117951217A - Cross-chain configuration method, device, equipment, system and medium based on multi-block chain

Info

Publication number: CN117951217A
Application number: CN202211298596.9A
Authority: CN
Inventors: 朱耿良
Original assignee: Tencent Technology Shenzhen Co Ltd
Current assignee: Tencent Technology Shenzhen Co Ltd
Priority date: 2022-10-20
Filing date: 2022-10-20
Publication date: 2024-04-30

Abstract

The embodiment of the application provides a multi-blockchain-based cross-chain configuration method, a device, equipment, a system and a medium, comprising the following steps: when receiving a configuration transaction sent by a management object based on a configuration transaction and used for crossing a chain configuration target chain and determining that the transaction type of the configuration transaction is a blocking transaction type, the first chain calls a chain management configuration contract on the first chain to execute the configuration transaction to generate a first configuration transaction identifier; when the state of the configuration transaction corresponding to the first configuration transaction identifier is determined to be the first transaction locking state based on the received first locking statement transaction, generating first transaction locking information, and writing the first transaction locking information into a first chain; when the configuration modification transaction sent by the management object based on the first transaction locking information on the first chain is acquired, the first cross-chain configuration item in the configuration modification transaction is configured to the target chain in a cross-chain manner through the cross-chain relay. The application can ensure the consistency and reliability of the configuration information on each block chain independent of each other.

Description

Cross-chain configuration method, device, equipment, system and medium based on multi-block chain

Technical Field

The present application relates to the field of blockchain technologies, and in particular, to a method, apparatus, device, system, and medium for cross-chain configuration based on multiple blockchains.

Background

In the application scenario of the multi-block chain, due to the independence among the block chains in the multi-block chain, the common node on each block chain is required to independently configure some basic data information of the chain where the common node is located.

For example, for the independent blockchain a and blockchain B, the configuration information such as the block-out time, the block size, and the business logic rule on the blockchain a may be configured by the consensus node on the blockchain a alone, and the configuration information such as the block-out time, the block size, and the business logic rule on the blockchain B may be configured by the consensus node on the blockchain B alone. Obviously, for the consensus nodes on the two chains (i.e., the blockchain a and the blockchain B), there is a difference between the configuration information due to the difference of the services to be executed by each chain, so that it is difficult to ensure the consistency of the configuration information on each chain independent from each other.

Disclosure of Invention

The embodiment of the application provides a multi-blockchain-based cross-chain configuration method, device, equipment, system and medium, which can ensure the consistency and reliability of configuration information on each blockchain mutually independent by introducing a configuration mechanism such as a configuration lock between each blockchain mutually independent.

In one aspect, the embodiment of the application provides a multi-blockchain-based cross-chain configuration method, which is executed by a first consensus node, wherein a multi-blockchain comprises a first chain associated with the first consensus node and a target chain to be subjected to cross-chain configuration; the first link network corresponding to the first link and the target link network corresponding to the target link are isolated through cross-link relay, and the method comprises the following steps:

when receiving a configuration transaction which is sent by a management object based on the configuration transaction and is used for cross-chain configuration of a target chain, determining the transaction type of the configuration transaction;

When the transaction type of the configuration transaction is a blocking transaction type, a chain management configuration contract on a first chain is called to execute the configuration transaction, and a first configuration transaction identifier corresponding to the configuration transaction is generated; the first configuration transaction identifier is used for indicating the cross-chain relay to send a first configuration lock acquisition transaction to a target consensus node associated with a target chain; the first configuration lock acquisition transaction is used for indicating the target consensus node to acquire a blocked chain configuration lock corresponding to the blocked transaction type from a chain configuration contract on the target chain, and the service state of the target chain is configured into a first service locking state through the blocked chain configuration lock;

Receiving a first locking claim transaction sent by a cross-chain relay; the first lock claim transaction is determined when the cross-chain relay detects that the target chain is in a first traffic lock state;

When the state of the configuration transaction corresponding to the first configuration transaction identifier is determined to be the first transaction locking state based on the first locking declaration transaction, generating first transaction locking information corresponding to the first locking declaration transaction, and writing the first transaction locking information into a first chain;

when the configuration modification transaction sent by the management object based on the first transaction locking information on the first chain is obtained, a first cross-chain configuration item in the configuration modification transaction is obtained, and the first cross-chain configuration item is cross-chain configured to the target chain through the cross-chain relay, so that the target consensus node unlocks the target chain in the first transaction locking state through the blocking-type chain configuration lock.

When the number of the target chains is multiple and the configuration resources indicated by the configuration transaction belong to the global configuration resources, the chain management configuration corresponding to the global configuration resources is approximately equal to the platform configuration contract on the first chain;

invoking a chain management configuration contract on a first chain to execute a configuration transaction, and generating a first configuration transaction identifier corresponding to the configuration transaction, wherein the method comprises the following steps:

Writing the configuration transaction into a platform configuration contract, calling a blocking transaction configuration method in the platform configuration contract, and executing the configuration transaction to obtain chain identifications of a plurality of target chains indicated by the configuration transaction;

And generating a first configuration transaction identifier corresponding to the configuration transaction based on the identifiers of the target chains.

Wherein the multi-block chain comprises a traffic backbone managed by the first consensus node through the first chain and a traffic sub-chain independent of the traffic backbone; the traffic backbone comprises one or more of a second chain and a third chain that are independent of the first chain; the sub-link consensus network corresponding to the service sub-link is formed by a consensus node in a second link network corresponding to the second link and a consensus node in a third link network corresponding to the third link; wherein the second chain network is independent of the third chain network; the service sub-chain is authorized to be created by a service object requesting to execute the target service through the first consensus node; one target service corresponds to one service sub-chain; the plurality of target chains includes a traffic sub-chain and a traffic backbone.

Wherein the multi-block chain comprises a traffic sub-chain and second and third chains managed by the first consensus node through a full platform configuration contract on the first chain; the sub-link consensus network corresponding to the service sub-link is formed by a consensus node in a second link network corresponding to the second link and a consensus node in a third link network corresponding to the third link; wherein the second chain network is independent of the third chain network; the service sub-chain is authorized to be created by a service object requesting to execute the target service through the first consensus node; one target service corresponds to one service sub-chain; when the target chain is a business sub-chain, a second chain or a third chain and the configuration resources indicated by the configuration transaction belong to independent configuration resources, the chain management configuration corresponding to the independent configuration resources is approximately equal to the target chain management configuration contract on the first chain; the target chain management configuration contract includes a chain management configuration contract for configuring the second chain, a chain management configuration contract for configuring the third chain, or a sub-chain management configuration contract for configuring the business sub-chain.

When the number of the target chains is multiple and the configuration resources indicated by the configuration transaction belong to the global configuration resources, the chain management configuration corresponding to the global configuration resources is approximately equal to the platform configuration contract on the first chain; the configuration transaction comprises a second cross-chain configuration item associated with the configuration transaction; the method further comprises the steps of:

when the transaction type of the configuration transaction is a non-blocking transaction type, calling a platform configuration contract on a first chain to execute the configuration transaction, and generating a second configuration transaction identifier corresponding to the configuration transaction; the second configuration transaction identifier is used for indicating the cross-chain relay to send a second configuration lock acquisition transaction to a target consensus node associated with the target chain; the second configuration lock acquisition transaction is used for indicating the target consensus node to acquire a non-blocking chain configuration lock corresponding to the non-blocking transaction type from a chain configuration contract on the target chain, and the service state of the target chain is configured into a second service locking state through the non-blocking chain configuration lock;

Receiving a second locking claim transaction sent by the cross-chain relay; the second lock claim transaction is determined by the cross-chain relay upon detecting that the target chain is in a second traffic lock state;

and when the state of the configuration transaction corresponding to the second configuration transaction identifier is determined to be the second transaction locking state based on the second locking statement transaction, generating second transaction locking information corresponding to the second locking statement transaction, and writing the second transaction locking information into the first chain.

The method comprises the steps of calling a platform configuration contract on a first chain to execute a configuration transaction, generating a second configuration transaction identifier corresponding to the configuration transaction, and comprising the following steps:

Writing the configuration transaction with the second cross-link configuration item into a platform configuration contract, calling a non-blocking transaction configuration method in the platform configuration contract on the first link, and executing the configuration transaction to obtain a link identifier of a target link indicated in the configuration transaction and the second cross-link configuration item;

And generating a second configuration transaction identifier corresponding to the configuration transaction based on the chain identifier of the target chain and the second cross-chain configuration item.

In one aspect, an embodiment of the present application provides a multi-blockchain-based cross-chain configuration method, where a multi-blockchain includes a first chain and a target chain; the method is performed by a cross-chain relay; the cross-link relay is used for isolating a first link network corresponding to the first link and a target link network corresponding to the target link; the method comprises the following steps:

When a first configuration transaction identifier corresponding to a configuration transaction on a first chain is detected, a first configuration lock acquisition transaction is sent to a target consensus node in a target chain network; the first configuration transaction identifier is generated by calling a chain management configuration contract on the first chain to execute a configuration transaction when the transaction type of the configuration transaction of a first consensus node in the first chain network is a blocking transaction type, wherein the configuration transaction is sent by a management object requesting to execute the configuration transaction; the first configuration lock acquisition transaction is used for indicating the target consensus node to acquire a blocked chain configuration lock corresponding to the blocked transaction type from a chain configuration contract on the target chain, and the service state of the target chain is configured into a first service locking state through the blocked chain configuration lock;

When the target chain is detected to be in a first service locking state, a first locking statement transaction is sent to a first consensus node; the first locking declaration transaction is used for indicating the first consensus node to generate first transaction locking information corresponding to a first locking declaration transaction for writing into the first chain when the state of the configuration transaction corresponding to the configuration transaction identifier is determined to be a first transaction locking state based on the first locking declaration transaction;

when a configuration modification transaction on a first chain is detected, acquiring a first cross-chain configuration item in the configuration modification transaction; the configuration modification transaction is sent by the management object based on the first transaction locking information on the first chain;

And configuring the first cross-link configuration item to the target link in a cross-link mode, so that the target consensus node unlocks the target link in the first service locking state through the blocking-type link configuration lock.

The cross-chain configuration of the first cross-chain configuration item to the target chain comprises the following steps:

Constructing a first release lock transaction based on the first cross-chain configuration item; the first lock release transaction is used for indicating the target consensus node to call a lock release method in the chain configuration contract to release the blocked chain configuration lock when writing the first cross-chain configuration item into the chain configuration contract, and changing the service state of the target chain from a first service locking state to a service unlocking state;

The first release lock transaction is sent to the target consensus node.

Wherein the method further comprises:

Accumulating the chain locking time length of the target chain in the first service locking state, and when the chain locking time length reaches the accumulated locking time length threshold of the blocking chain configuration lock, sending a timeout release lock transaction to the target consensus node, wherein the timeout release lock transaction is used for indicating the target consensus node to call a lock release method in a chain configuration contract on the target chain to release the blocking chain configuration lock, and changing the service state of the target chain from the first service locking state to the service unlocking state.

Wherein the method further comprises:

and when the target chain is detected not to be in the first service locking state, sending a first locking failure transaction to the first consensus node, and sending a first locking failure release lock transaction to the target consensus node, wherein the first locking failure release lock transaction is used for indicating the target consensus node to call a lock release method in a chain configuration contract on the target chain to release the blocking chain configuration lock.

Wherein the configuration transaction includes a second cross-chain configuration item associated with the configuration transaction; the method further comprises the steps of:

When a second configuration transaction identifier corresponding to the configuration transaction on the first chain is detected, a second configuration lock acquisition transaction is sent to a target consensus node in the target chain network, wherein the second configuration transaction identifier is generated by calling a management configuration contract on the first chain to execute the configuration transaction when the transaction type of the configuration transaction of the first consensus node in the first chain network in the configuration transaction is a non-blocking transaction type, and the configuration transaction is sent by a management object requesting to execute the configuration transaction; the second configuration lock acquisition transaction is used for indicating the target consensus node to acquire a non-blocking chain configuration lock corresponding to the non-blocking transaction type from a chain configuration contract on the target chain, and the service state of the target chain is configured into a second service locking state through the non-blocking chain configuration lock;

When the target chain is detected to be in a second service locking state, sending a second locking statement transaction to the first consensus node; the second locking declaration transaction is used for indicating the first consensus node to generate second transaction locking information corresponding to a second locking declaration transaction for writing the first chain when the state of the configuration transaction corresponding to the configuration transaction identifier is determined to be a second transaction locking state based on the second locking declaration transaction;

And configuring the second cross-link configuration item to the target link in a cross-link mode, so that the target consensus node unlocks the target link in the second service locking state through the non-blocking link configuration lock.

Wherein cross-configuring the second cross-chain configuration item to the target chain comprises:

Constructing a second release lock transaction based on the second cross-chain configuration item, and sending the second release lock transaction to the target consensus node; the second lock release transaction is used for indicating the target consensus node in the target chain to release the non-blocking chain configuration lock by calling a lock release method in the chain configuration contract on the target chain when the second cross-chain configuration item is written into the chain configuration contract, and changing the service state of the target chain from the second service locking state to the service unlocking state.

Wherein the second configuration lock acquisition transaction is further for instructing the target consensus node to acquire a block buffer height from a chain configuration contract on the target chain, the block buffer height being used to characterize a maximum gap height of a resulting block on the target chain before the traffic state of the target chain is configured to the second traffic lock state by the non-blocking chain configuration lock.

Wherein the method further comprises:

and when the target chain is detected not to be in the second service locking state, sending a second locking failure transaction to the first consensus node, and sending a second locking failure release lock transaction to the target consensus node, wherein the second locking failure release lock transaction is used for indicating the target consensus node to call a lock release method in a chain configuration contract on the target chain to release the non-blocking chain configuration lock.

In one aspect, an embodiment of the present application provides a multi-blockchain-based cross-chain configuration device, where the device operates on a first consensus node, and a multi-blockchain includes a first chain associated with the first consensus node and a target chain to be cross-chain configured; the first link network corresponding to the first link and the target link network corresponding to the target link are isolated through cross-link relay, and the device comprises:

The determining module is used for determining the transaction type of the configuration transaction when receiving the configuration transaction which is sent by the management object based on the configuration transaction and is used for cross-chain configuration target chain;

The calling module is used for calling a chain management configuration contract on a first chain to execute the configuration transaction when the transaction type of the configuration transaction is the blocking type transaction type, and generating a first configuration transaction identifier corresponding to the configuration transaction; the first configuration transaction identifier is used for indicating the cross-chain relay to send a first configuration lock acquisition transaction to a target consensus node associated with a target chain; the first configuration lock acquisition transaction is used for indicating the target consensus node to acquire a blocked chain configuration lock corresponding to the blocked transaction type from a chain configuration contract on the target chain, and the service state of the target chain is configured into a first service locking state through the blocked chain configuration lock;

the receiving module is used for receiving a first locking statement transaction sent by the cross-chain relay; the first lock claim transaction is determined when the cross-chain relay detects that the target chain is in a first traffic lock state;

The generation module is used for generating first transaction locking information corresponding to the first locking statement transaction and writing the first transaction locking information into the first chain when the state of the configuration transaction corresponding to the first configuration transaction identifier is determined to be the first transaction locking state based on the first locking statement transaction;

The first acquisition module is used for acquiring a first cross-link configuration item in the configuration modification transaction when acquiring the configuration modification transaction sent by the management object based on the first transaction locking information on the first link;

And the first configuration module is used for cross-chain configuration of the first cross-chain configuration item to the target chain through the cross-chain relay so as to enable the target consensus node to unlock the target chain in the first service locking state through the blocking chain configuration lock.

The calling module comprises:

The calling subunit is used for writing the configuration transaction into the platform configuration contract, calling a blocking transaction configuration method in the platform configuration contract, and executing the configuration transaction to obtain chain identifications of a plurality of target chains indicated by the configuration transaction;

And the generating subunit is used for generating a first configuration transaction identifier corresponding to the configuration transaction based on the identifiers of the target chains.

When the number of the target chains is multiple and the configuration resources indicated by the configuration transaction belong to the global configuration resources, the chain management configuration corresponding to the global configuration resources is approximately equal to the platform configuration contract on the first chain; the configuration transaction comprises a second cross-chain configuration item associated with the configuration transaction;

The calling module is also used for calling the platform configuration contract on the first chain to execute the configuration transaction when the transaction type of the configuration transaction is the non-blocking transaction type, and generating a second configuration transaction identifier corresponding to the configuration transaction; the second configuration transaction identifier is used for indicating the cross-chain relay to send a second configuration lock acquisition transaction to a target consensus node associated with the target chain; the second configuration lock acquisition transaction is used for indicating the target consensus node to acquire a non-blocking chain configuration lock corresponding to the non-blocking transaction type from a chain configuration contract on the target chain, and the service state of the target chain is configured into a second service locking state through the non-blocking chain configuration lock;

the receiving module is also used for receiving a second locking statement transaction sent by the cross-chain relay; the second lock claim transaction is determined by the cross-chain relay upon detecting that the target chain is in a second traffic lock state;

The generating module is further configured to generate second transaction locking information corresponding to the second locking claim transaction and write the second transaction locking information into the first chain when the state of the configuration transaction corresponding to the second configuration transaction identifier is determined to be the second transaction locking state based on the second locking claim transaction.

Wherein, the calling module includes:

the calling sub-module is used for writing the configuration transaction with the second cross-link configuration item into the platform configuration contract, calling a non-blocking transaction configuration method in the platform configuration contract on the first link, and executing the configuration transaction to obtain the link identification of the target link indicated in the configuration transaction and the second cross-link configuration item;

The generation sub-module is used for generating a second configuration transaction identifier corresponding to the configuration transaction based on the chain identifier of the target chain and the second cross-chain configuration item.

In one aspect, an embodiment of the present application provides a multi-blockchain-based cross-chain configuration device, where a multi-blockchain includes a first chain and a target chain, the device operates on a cross-chain relay, and the cross-chain relay is used to isolate a first chain network corresponding to the first chain and a target chain network corresponding to the target chain, where the device includes:

The sending module is used for sending a first configuration lock acquisition transaction to a target consensus node in a target chain network when a first configuration transaction identifier corresponding to a configuration transaction on a first chain is detected; the first configuration transaction identifier is generated by calling a chain management configuration contract on the first chain to execute a configuration transaction when the transaction type of the configuration transaction of a first consensus node in the first chain network is a blocking transaction type, wherein the configuration transaction is sent by a management object requesting to execute the configuration transaction; the first configuration lock acquisition transaction is used for indicating the target consensus node to acquire a blocked chain configuration lock corresponding to the blocked transaction type from a chain configuration contract on the target chain, and the service state of the target chain is configured into a first service locking state through the blocked chain configuration lock;

The sending module is further used for sending a first locking statement transaction to the first consensus node when the target chain is detected to be in a first service locking state; the first locking declaration transaction is used for indicating the first consensus node to generate first transaction locking information corresponding to a first locking declaration transaction for writing into the first chain when the state of the configuration transaction corresponding to the configuration transaction identifier is determined to be a first transaction locking state based on the first locking declaration transaction;

The second acquisition module is used for acquiring a first cross-chain configuration item in the configuration modification transaction when the configuration modification transaction on the first chain is detected; the configuration modification transaction is sent by the management object based on the first transaction locking information on the first chain;

and the second configuration module is used for cross-chain configuration of the first cross-chain configuration item to the target chain so as to enable the target consensus node to unlock the target chain in the first service locking state through the blocking chain configuration lock.

Wherein the second configuration module comprises:

A building unit for building a first release lock transaction based on the first cross-chain configuration item; the first lock release transaction is used for indicating the target consensus node to call a lock release method in the chain configuration contract to release the blocked chain configuration lock when writing the first cross-chain configuration item into the chain configuration contract, and changing the service state of the target chain from a first service locking state to a service unlocking state;

And the sending subunit is used for sending the first lock release transaction to the target consensus node.

Wherein, the sending module is further used for: accumulating the chain locking time length of the target chain in the first service locking state, and when the chain locking time length reaches the accumulated locking time length threshold of the blocking chain configuration lock, sending a timeout release lock transaction to the target consensus node, wherein the timeout release lock transaction is used for indicating the target consensus node to call a lock release method in a chain configuration contract on the target chain to release the blocking chain configuration lock, and changing the service state of the target chain from the first service locking state to the service unlocking state.

Wherein, the sending module is further used for: and when the target chain is detected not to be in the first service locking state, sending a first locking failure transaction to the first consensus node, and sending a first locking failure release lock transaction to the target consensus node, wherein the first locking failure release lock transaction is used for indicating the target consensus node to call a lock release method in a chain configuration contract on the target chain to release the blocking chain configuration lock.

Wherein the configuration transaction includes a second cross-chain configuration item associated with the configuration transaction;

The sending module is further configured to send a second configuration lock acquisition transaction to a target consensus node in the target chain network when a second configuration transaction identifier corresponding to the configuration transaction on the first chain is detected, wherein the second configuration transaction identifier is generated by calling a management configuration contract on the first chain to execute the configuration transaction when the transaction type of the configuration transaction of the first consensus node in the first chain network is a non-blocking transaction type, and the configuration transaction is sent by a management object requesting to execute the configuration transaction; the second configuration lock acquisition transaction is used for indicating the target consensus node to acquire a non-blocking chain configuration lock corresponding to the non-blocking transaction type from a chain configuration contract on the target chain, and the service state of the target chain is configured into a second service locking state through the non-blocking chain configuration lock;

the sending module is further used for sending a second locking statement transaction to the first consensus node when the target chain is detected to be in a second service locking state; the second locking declaration transaction is used for indicating the first consensus node to generate second transaction locking information corresponding to a second locking declaration transaction for writing the first chain when the state of the configuration transaction corresponding to the configuration transaction identifier is determined to be a second transaction locking state based on the second locking declaration transaction;

And the second configuration module is also used for cross-chain configuration of the second cross-chain configuration item to the target chain so as to enable the target consensus node to unlock the target chain in the second service locking state through the non-blocking chain configuration lock.

Wherein the second configuration module comprises:

a building unit for building a second release lock transaction based on the second cross-chain configuration item;

A transmitting subunit configured to transmit a second lock release transaction to the target consensus node; the second lock release transaction is used for indicating the target consensus node in the target chain to release the non-blocking chain configuration lock by calling a lock release method in the chain configuration contract on the target chain when the second cross-chain configuration item is written into the chain configuration contract, and changing the service state of the target chain from the second service locking state to the service unlocking state.

Wherein, the sending module is further used for:

In one aspect, an embodiment of the present application provides a multi-blockchain-based cross-chain configuration system, where the system includes: a first consensus node in a first chain network, a target consensus node in a target chain network, and a cross-chain relay; the first link network and the target link network are isolated through a cross-link relay;

The first consensus node is used for determining the transaction type of the configuration transaction when receiving the configuration transaction which is sent by the management object based on the configuration transaction and is used for crossing a chain configuration target chain, and calling a chain management configuration contract on the first chain to execute the configuration transaction when the transaction type of the configuration transaction is a blocking transaction type to generate a first configuration transaction identifier corresponding to the configuration transaction;

The cross-chain relay is used for sending a first configuration lock acquisition transaction to a target consensus node in a target chain network when a first configuration transaction identifier corresponding to a configuration transaction on a first chain is detected;

The target consensus node is used for acquiring a blocking chain configuration lock corresponding to the blocking transaction type from a chain configuration contract on a target chain, and configuring the service state of the target chain into a first service locking state through the blocking chain configuration lock;

The cross-link relay is used for sending a first locking statement transaction to the first consensus node when the target link is detected to be in a first service locking state;

The first consensus node is further configured to generate first transaction locking information corresponding to a first lock claim transaction of the first chain and write the first transaction locking information into the first chain when the state of the configuration transaction corresponding to the configuration transaction identifier is determined to be the first transaction locking state based on the first lock claim transaction;

The first consensus node is further used for acquiring a first cross-link configuration item in the configuration modification transaction when acquiring the configuration modification transaction sent by the management object based on the first transaction locking information on the first link;

the cross-chain relay is further configured to cross-chain configure the first cross-chain configuration item to the target chain upon detecting a configuration modification transaction on the first chain.

An aspect of an embodiment of the present application provides a computer device, including a memory and a processor, where the memory is connected to the processor, and the memory is used to store a computer program, and the processor is used to call the computer program, so that the computer device performs the method provided in the foregoing aspect of the embodiment of the present application.

An aspect of an embodiment of the present application provides a computer readable storage medium, in which a computer program is stored, the computer program being adapted to be loaded and executed by a processor, to cause a computer device having a processor to perform the method provided in the above aspect of an embodiment of the present application.

According to one aspect of the present application there is provided a computer program product or computer program comprising computer instructions stored in a computer readable storage medium. The processor of the computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device performs the method provided in the above aspect.

In the embodiment of the application, a first consensus node on a first chain can receive a configuration transaction for cross-chain configuration target chain, and execute the configuration transaction when the transaction type of the configuration transaction is a blocking transaction type, and generate a first configuration transaction identifier corresponding to the configuration transaction; and then, the target consensus node can acquire a blocking type chain configuration lock corresponding to the blocking type transaction type through the first configuration transaction identifier, lock the service state of the target chain through the blocking type chain configuration lock, and configure the cross-chain configuration item configured for the target chain on the first chain to the target chain through the cross-chain relay after the service state of the target chain is locked. Therefore, the embodiment of the application can uniformly manage the configuration information of other chains through the first consensus node on the first chain so as to ensure the consistency of the configuration information on the chains. Meanwhile, when the business state of the target chain is locked, the first consensus node can generate corresponding transaction locking information and write the corresponding transaction locking information into the first chain, so that the scrutiny and traceability of the configuration of the target chain can be effectively ensured; in addition, a configuration mechanism such as a blocking chain configuration lock is introduced, so that synchronous validation of configuration can be realized, strict execution of business logic is ensured, and consistency and reliability of configuration information on each block chain independent of each other can be ensured.

Drawings

In order to more clearly illustrate the embodiments of the invention or the technical solutions in the prior art, the drawings that are required in the embodiments or the description of the prior art will be briefly described, it being obvious that the drawings in the following description are only some embodiments of the invention, and that other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.

FIG. 1 is a schematic diagram of a hierarchical architecture of a blockchain network provided by an embodiment of the present application;

FIG. 2 is a schematic diagram of a multi-blockchain-based blockchain electronic bill platform according to an embodiment of the present application;

FIG. 3 is a schematic diagram of a multi-blockchain-based cross-chain configuration provided by an embodiment of the present application;

FIG. 4 is a flowchart of a multi-blockchain-based cross-chain configuration method according to an embodiment of the present application;

FIG. 5 is a flowchart of a multi-blockchain-based cross-chain configuration method according to an embodiment of the present application;

FIG. 6 is a flowchart of a multi-blockchain-based cross-chain configuration method according to an embodiment of the present application;

FIG. 7 is a flowchart of a multi-blockchain-based cross-chain configuration method according to an embodiment of the present application;

FIG. 8 is a flowchart of a multi-blockchain-based cross-chain configuration method according to an embodiment of the present application;

FIG. 9 is a flowchart of a multi-blockchain-based cross-chain configuration method according to an embodiment of the present application;

FIG. 10 is a schematic diagram of a multi-blockchain-based cross-chain configuration device according to the present application;

FIG. 11 is a schematic diagram of a multi-blockchain-based cross-chain configuration device according to the present application;

FIG. 12 is a schematic diagram of a computer device according to an embodiment of the present application;

FIG. 13 is a schematic diagram of a multi-blockchain-based cross-chain configuration system according to an embodiment of the present application.

Detailed Description

The following description of the embodiments of the present invention will be made clearly and completely with reference to the accompanying drawings, in which it is apparent that the embodiments described are only some embodiments of the present invention, but not all embodiments. All other embodiments, which can be made by those skilled in the art based on the embodiments of the invention without making any inventive effort, are intended to be within the scope of the invention.

Referring to fig. 1, fig. 1 is a schematic diagram of a hierarchical structure of a blockchain network according to an embodiment of the present application. The hierarchical structure shown in fig. 1 is applied to a blockchain system corresponding to a multi-service cooperation processing platform, and the blockchain network corresponding to the blockchain system comprises a service network deployed in a public network and a plurality of consensus networks deployed in a private cloud. As shown in fig. 1, the service network herein may be the service network 400a shown in fig. 1, and the plurality of consensus networks herein may specifically include the consensus network 100a, the consensus network 200a, and the consensus network 300a shown in fig. 1.

In the service network 400a shown in fig. 1, a plurality of service nodes are deployed, where the plurality of service nodes may specifically include the service node 110a, the service node 110b, the service node 110c, the service node 110d, the service node 110e, the service node 110f, the service nodes 110g, …, and the service node 110n shown in fig. 1. It should be noted, however, that the number of service nodes deployed in the service network 400a will not be limited. It should be appreciated that the service nodes in the service network 400a need not participate in billing. Furthermore, as shown in fig. 1, for each service node operating in the service network 400a, one or more of the plurality of consensus networks may be accessed through a network communication, and the number of consensus networks that each service object accesses through a corresponding service node will not be limited. It will be appreciated that the various consensus networks may also interact with each other in the form of network communications.

It should be appreciated that in the consensus network 100a shown in fig. 1, a plurality of consensus nodes are deployed, where the plurality of consensus nodes may specifically include the consensus node 10a, the consensus node 10b, the consensus node 10c, and the consensus node 10d shown in fig. 1. It should be noted that the number of consensus nodes deployed in the consensus network 100a will not be limited here. Further, as shown in FIG. 1, for a plurality of consensus nodes operating in the consensus network 100a, the commonly maintained blockchain is specifically the blockchain 10e shown in FIG. 1.

Similarly, in the consensus network 200a shown in fig. 1, a plurality of consensus nodes are deployed, where the plurality of consensus nodes may specifically include the consensus node 11a, the consensus node 11b, the consensus node 11c, and the consensus node 11d shown in fig. 1. It should be noted that the number of consensus nodes deployed in the consensus network 200a will not be limited here. Further, as shown in FIG. 1, for a plurality of consensus nodes operating in the consensus network 200a, the commonly maintained blockchain is specifically blockchain 11e shown in FIG. 1.

Similarly, in the consensus network 300a shown in fig. 1, a plurality of consensus nodes are deployed, where the plurality of consensus nodes may specifically include the consensus node 12a, the consensus node 12b, the consensus node 12c, and the consensus node 12d shown in fig. 1. It should be noted that the number of consensus nodes deployed in the consensus network 300a will not be limited here. Further, as shown in FIG. 1, for a plurality of consensus nodes operating in the consensus network 300a, the commonly maintained blockchain is specifically the blockchain 12e shown in FIG. 1.

For ease of understanding, in the embodiments of the present application, service nodes and consensus nodes located in the blockchain system may be collectively referred to as blockchain nodes (simply referred to as nodes), and the consensus network 100a, the consensus network 100b, and the consensus network 100c participating in the blockchain system may be collectively referred to as a core consensus network, and each node in the core consensus network may be collectively referred to as a core node.

It should be understood that, in the above-mentioned blockchain system, the blockchain stored on each node in the consensus network 100a (for example, the core nodes of the consensus node 10a, the consensus node 10b, the consensus node 10c, and the consensus node 10 d) is the blockchain 10e, where the blockchain 10e may be the first chain, and the consensus network corresponding to the first chain (i.e., the consensus network 100 a) may be the first chain network, and the consensus nodes in the first chain network may be collectively referred to as the first consensus node. The blockchain stored on each node in the consensus network 200a (e.g., the core nodes of the consensus node 11a, the consensus node 11b, the consensus node 11c, and the consensus node 11 d) is a blockchain 11e, where the blockchain 11e may be a second chain, and the consensus network corresponding to the second chain (i.e., the consensus network 200 a) may be a second chain network, and the consensus nodes in the second chain network may be collectively referred to as a second consensus node. The blockchain stored on each node in the consensus network 300a (e.g., the core nodes of the consensus node 12a, the consensus node 12b, the consensus node 12c, and the consensus node 12 d) is a blockchain 12e, where the blockchain 12e may be a third chain, and the consensus network corresponding to the third chain (i.e., the consensus network 300 a) may be a third chain network, and the consensus nodes in the third chain network may be collectively referred to as a third consensus node.

It should be understood that, in order to cope with some special scenarios (such as some scenarios that need to process temporary services with a larger data volume in real time, etc.), the present application is implemented in the three-chain system related to the foregoing blockchain system (i.e., the three-chain system constructed by the first chain, the second chain and the third chain), one or more subchain consensus networks with the foregoing temporary task as a dimension may be temporarily created, and the blockchains corresponding to the subchain consensus networks constructed by these may be referred to as service subchains.

Wherein it is understood that the sub-chain consensus nodes in the sub-chain consensus network may be from a second consensus node in the second chain network and a third consensus node in the third chain network. That is, the sub-link consensus network corresponding to the target service is constructed by managing the consensus nodes based on the consensus nodes (such as the consensus node 11a and the consensus node 11b in fig. 1) selected from the second link network and the consensus nodes (such as the consensus node 12a and the consensus node 12b in fig. 1) selected from the third link network.

It should be understood that, for example, taking a blockchain system as an example of a blockchain electronic bill system, in the blockchain electronic bill system, the temporary service corresponding to the business subchain is to verify whether the bill template used by 100 bills is the latest bill template, at this time, the subchain consensus node in the business subchain can verify whether the bill template used by the 100 bills is the latest bill template, and then return a verification result. For another example, in the blockchain electronic bill system, the temporary service corresponding to the service sub-chain is used for checking whether the tax counting rule in the electronic bill is correct, and the sub-chain consensus node in the service sub-chain can verify whether the tax counting in the bill is correct according to the asset mapping relationship, and returns a verification result. For ease of understanding, the foregoing temporary services may be collectively referred to as target services in embodiments of the present application. It should be understood that the number of the service sub-chains is not limited in the embodiment of the present application, for example, 2 service sub-chains, 5 service sub-chains, 40 service sub-chains, etc. may be created according to the temporary service form, and the service sub-chains may be closed according to the service requirement.

It is understood that the second chain and the third chain in the foregoing three-chain system may be referred to as a service main chain, where the service main chain and the service sub-chain are independent of each other, and the foregoing first chain may perform data interaction with the service main chain and the service sub-chain through corresponding cross-chain relay. The cross-chain relay may be an independent service device capable of probing data on the service backbone or the service sub-chain.

It should be understood that the blockchain according to the embodiments of the present application is a novel application mode of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanism, and encryption algorithm, and is mainly used for sorting data according to time sequence, encrypting an account book, so that the account book cannot be tampered and forged, and meanwhile, performing verification, storage, and update of data. A blockchain is essentially a de-centralized database in which each node stores one and the same blockchain.

In the above-mentioned blockchain system, the core node may be responsible for the consensus in the core consensus network where the corresponding blockchain is located, that is, the core node may be the consensus node in the core consensus network where the corresponding blockchain is located. For any one of the three core consensus networks, the specific process of writing the transaction data in the core consensus network into the corresponding blockchain ledger (e.g., the distributed database) may be that the user client sends the transaction data to a certain service node, and then the transaction data is transferred between the service nodes in the service network in the blockchain network in a baton manner until the corresponding core consensus node in the blockchain network (e.g., the consensus node 11b in the consensus network 200 a) receives the transaction data, at this time, the consensus node (e.g., the consensus node 11b in the consensus network 200 a) packages the transaction data into a block so that the block passing through the consensus can be written into the distributed database of the core consensus network (e.g., the consensus network 200 a) after the consensus passes.

Optionally, it may be understood that, after the consensus is passed, the block carrying the transaction data and other blocks associated with the block may be written in parallel into the distributed database through the storage layer of the core consensus network (e.g., the consensus network 200 a) where the block chain structure of the block chain is located, so that the limitation of the block chain structure may be broken through from the root, and further, the storage efficiency of the data storage may be effectively improved.

It will be appreciated, among other things, that in the above-described blockchain system, a smart contract may be deployed on the blockchain of the corresponding core consensus network, which in the blockchain system may be understood as a code executed by blockchain nodes (i.e., consensus nodes) through which any logic may be executed and the result obtained. For example, a user may invoke an intelligent contract already deployed on a blockchain (e.g., blockchain 11 e) of a corresponding core consensus network (e.g., consensus network 200a described above) by initiating a transaction request via a user client.

Specifically, the service node in the service network may send the transaction service request to the consensus node (e.g., consensus node 11a shown in fig. 1) in the corresponding core consensus network, so as to authenticate the identity of the user sending the transaction service request through the chain entry of the corresponding core consensus network, and allow the transaction service request sent by the user to be sent to other consensus nodes (e.g., consensus node 11b shown in fig. 1) in the corresponding core consensus network when the identity authentication is successful, so as to invoke the intelligent contracts running in the consensus nodes (e.g., consensus node 11a and consensus node 11b shown in fig. 1) to execute the transaction service requested by the user.

It should be appreciated that one or more smart contracts may be deployed on a blockchain (e.g., blockchain 11 e) of the core consensus network (e.g., consensus network 200 a) that may be distinguished by a contract invocation address, a contract identification number (Identity document, ID), or a contract name, and that the contract invocation address or contract identification number or contract name of the smart contract may be carried in a transaction request initiated by a user client to thereby specify the smart contract that needs to be run. Or when the management object client initiates a configuration transaction for a certain blockchain, the intelligent contract to be run can be determined according to the configuration resources indicated by the configuration transaction. In the above blockchain system, a full platform configuration contract may be deployed in the management chain, where the full platform configuration contract may include a chain management configuration contract, where the chain management configuration contract includes an intelligent contract corresponding to a global configuration resource (the global configuration resource may be specific to all blockchains in the blockchain system) and an intelligent contract corresponding to an independent configuration resource (the independent configuration resource is specific to only a blockchain in the blockchain system), according to the configuration resource indicated by the configuration transaction, the configuration transaction corresponding to the configuration transaction may be executed by calling the intelligent contract corresponding to the global configuration resource or the intelligent contract corresponding to the independent configuration resource, so as to obtain a configuration transaction identifier corresponding to the configuration transaction, and further according to the configuration transaction identifier, a cross-chain configuration item for performing chain configuration on the blockchain is stored into respective local caches and local storages of each node through mutual authentication of each consensus node in the blockchain, and an execution result of the configuration transaction may be returned to the client.

Note that the local cache here is a system memory created in the storage layer, and the local storage here is a hard disk space created in the storage layer for data storage. Therefore, when a certain consensus node in the core consensus network is down (i.e. down machine) or the system fails, the phenomenon that data cannot be read because the data in the system memory disappears is avoided, namely the consensus node can also read the data through the local storage created in the storage layer.

It should be appreciated that in the above-described blockchain system, a point-To-point (P2P, peer To Peer) network may be formed between any two blockchain nodes in any one of the consensus networks (e.g., the consensus network 100a, the consensus network 200a, or the consensus network 300 a), and the P2P protocol may be used in the point-To-point network, where the P2P protocol is an application layer protocol running on top of a transmission control protocol (TCP, transmission Control Protocol) protocol, and there is no need for a central node between blockchain nodes To maintain network state, and instead each blockchain node maintains node state of the whole network or its neighboring blockchain node connection state through broadcast interactions with neighboring blockchain nodes. In a distributed system, any device, such as a server, terminal, etc., may be added as blockchain nodes, where each blockchain node may include a hardware layer, a middle layer, an operating system layer, and an application layer.

It should be understood that, the specific application scenario of the multi-service collaboration processing platform may be an electronic bill transfer scenario under a blockchain electronic bill platform, a blockchain medical prescription transfer scenario, and so on. Under the electronic bill circulation scene under the blockchain electronic bill platform, the first chain can be a management chain in the blockchain electronic bill platform, the second chain can be a bill chain in the blockchain electronic bill platform and the third chain can be an application contract chain in the blockchain electronic bill platform; when the blockchain system is applied to the blockchain electronic bill platform, a safe and reliable blockchain electronic bill three-chain network can be constructed based on the first chain, the second chain and the third chain, and in the blockchain electronic bill three-chain network, when the business is independently executed in the three consensus networks, business execution results obtained by independently executing the business can be respectively stored in the blockchain account book of the corresponding blockchain. For another example, in a blockchain medical prescription transfer scenario, the first chain may be a management chain in a blockchain medical prescription platform, the second chain may be a prescription chain in a blockchain electronic medical prescription platform, and the third chain may apply a contractual chain for a prescription in a blockchain medical prescription platform. When the blockchain system is applied to the blockchain medical prescription platform, a safe and reliable blockchain electronic medical prescription triple-link network can be constructed based on the first chain, the second chain and the third chain, and in the blockchain electronic medical prescription triple-link network, when the business is independently executed in the three consensus networks, business execution results obtained by independently executing the business can be respectively stored in the blockchain ledgers of the corresponding blockchains.

For ease of understanding, the following description will be made with reference to fig. 2, where fig. 2 is a schematic view of a multi-blockchain-based blockchain electronic bill platform according to an embodiment of the present application. The blockchain electronic bill platform can be a specific service platform in the above blockchain system, and it should be understood that in the blockchain electronic bill platform, in order to reduce the promiscuity of data storage on a chain, a blockchain-based multi-chain system of blockchain electronic bills is proposed, and the multi-chain system mainly relates to a blockchain electronic bill three-chain network shown in fig. 2. As shown in fig. 2, the blockchain electronic ticket triplex network has a management chain, a ticket chain and an application contract chain deployed therein. The management chain may be the first chain, the management chain network corresponding to the management chain may be the first chain network, the bill chain may be the second chain, the bill chain network corresponding to the bill chain may be the second chain network, the application contract chain may be the third chain, and the application contract chain network corresponding to the application contract chain may be the third chain network.

It can be understood that in a business scenario in which a blockchain is used as a blockchain electronic bill circulation, the functional characteristics of independently executing different businesses can be provided for the whole blockchain electronic bill platform through the mutual cooperation among a management chain, a bill chain and an application contract chain, so that a safe and efficient business flow system can be constructed on the premise of the mutual cooperation of three chains. It should be appreciated that a multi-chain system is taken as an example of a three-chain system under which the management chain, ticket chain and application contract chain are all independently built, i.e. the consensus node for maintaining the management chain is different from the consensus node for maintaining the ticket chain and from the consensus node for maintaining the application contract chain. The management chain can be used for providing management functional characteristics for the whole blockchain electronic bill platform, and the bill chain can be used for providing the functional characteristics of bill business with different business authority types for the whole blockchain electronic bill platform. It will be appreciated that a consensus node deployed in a bill chain network may maintain business logic of electronic bills over a full life cycle through a bill chain, e.g., may manage the full life cycle of all issued electronic bills through the bill chain. For example, the full life cycle of the electronic bill herein includes the issuing of the electronic bill, the circulation of the electronic bill, the reimbursement of the electronic bill, and the like. It should be appreciated that in a blockchain network corresponding to an overall service, the bill chains maintained by the consensus nodes are characterized by high performance and low latency.

It should be appreciated that, in an embodiment of the present application, to ensure the security and independence of electronic tickets written in a ticket chain, embodiments of the present application propose that a more standard, flexible and fully functional derivative service can be provided by another blockchain (i.e., the application contract chain shown in fig. 2) independent of the management chain and the ticket chain, i.e., the application contract chain herein can develop the functional characteristics of the derivative service for the electronic ticket provided by the entire blockchain electronic ticket platform. It may be appreciated that the common node deployed in the application contract link network may carry, through the application contract link, derivative services corresponding to the bill service that may be changed, for example, the derivative services herein may specifically include the credit investigation service, the qualification identification service, and the like. It should be appreciated that in the blockchain network corresponding to the overall business, the application contract chain maintained by the second consensus node may support the government affair collaboration department and the federation chain partner shown in fig. 2 (i.e., the business association department shown in fig. 2), develop the intelligent contract related to the derivative business (for example, the derivative business contract shown in fig. 2) by acquiring the application contract template on the management across the chain through the tax application contract (open contract deployment contract) shown in fig. 2, and deploy the derivative business contract on the application contract chain after being checked by the tax management department. It should be appreciated that smart contracts deployed on an application contract chain may enable flexible upgrades and changes of smart contracts through virtual machine compatible contracts, it should be appreciated that application contract chains have the highest openness compared to management chains and ticket chains, and support complex smart contract logic with more participants and constantly dynamically changing, with relatively lower performance than ticket chains.

As shown in fig. 2, the management chains deployed in the blockchain electronic bill triplex network are independent of bill chains and application contract chains, namely, the three independently built blockchains are mutually independent, but the three independently built blockchains can perform data interaction in a manner of cross-chain relay, namely, cross-chain interaction can be performed among the three chains.

Among other things, it should be appreciated that the consensus algorithm employed by the management chain is different from the consensus algorithm employed by the ticket chain, and also different from the consensus algorithm employed by the application contract chain.

Specifically, 1.1) the consensus algorithm associated with the management chain is an immediate deterministic consensus algorithm, for example, the immediate deterministic consensus algorithm herein may be PBFT (PRACTICAL BYZANTINE FAULT TOLERANCE, practical bayer fault tolerance) consensus algorithm, by which PBFT the status of a proposed block to be uplink may be immediately determined. It should be appreciated that the management chain is a blockchain in the management chain network described above, and that the management consensus node (i.e., the first consensus node described above) in the management chain network may be engaged in management by the tax administration as shown in fig. 2.

It will be appreciated that the aforementioned tax administration may exercise management responsibilities through the management consensus node deployed in the management chain network. For example, the management responsibilities herein may specifically include managing information inside a government department (e.g., information about personnel inside a tax administration department), managing business logic rules of an overall business (e.g., derivative business contracts for executing business logic of derivative business running on an application contract chain), managing metadata information of the overall business (e.g., access traffic at each chain entry under a three-chain system), managing identity management and rights management of participants of the overall business (e.g., business objects such as individual users, enterprise users, tax business participants, etc.). It should be appreciated that in a blockchain network corresponding to an overall service, the management chain maintained by the management consensus node is a relatively more stable, least data-scale, but most secure blockchain.

It should be appreciated that the inside participant associated with the management chain may be a tax management department as shown in fig. 2, e.g., the tax management department may manage some of the inside states of the tax management department via an inside management contract on the management chain when accessing the management chain as an inside participant, e.g., each person in the tax management department may be managed, e.g., a specific tax manager, tax developer, tax auditor, etc., may be configured among the persons in the tax management department. In addition, when the tax administration department is used as an internal participant to access the management chain, the tax administration department can also manage some parameters in the three-chain system through an internal management contract on the management chain; for example, when the tax administration department is used as an internal party to access the administration chain, the node number parameter corresponding to the number of the consensus nodes on each chain participating in the consensus can be limited by an internal administration contract on the administration chain.

1.2 The consensus algorithm associated with the bill chain is another immediate deterministic consensus algorithm, for example, the immediate deterministic consensus algorithm here may be TBFT (Tower Byzantine Fault Tolerance, tower type bayer fault tolerance) consensus algorithm, and the TBFT consensus algorithm is a bayer fault tolerance algorithm, and can ensure the safe operation of the whole bill chain network system under the condition that the number of bayer nodes (i.e. the number of wrongly used nodes in the bill chain network) is less than 1/3 of the total number of nodes of the bill chain network. The TBFT consensus algorithm can immediately determine the state of a proposed block to be uplink, and the method has higher performance, fewer block chain link points and continuously generates blocks by the block chain nodes. It should be appreciated that the consensus nodes in the bill chain network may be engaged in management by the aforementioned tax administration, e.g., a specific tax personnel in the tax administration may control the number of consensus nodes in the bill chain network by means of an internal management contract in the management chain. For another example, tax office terminals corresponding to specific tax personnel in tax administration may participate in constructing the bill chain network.

It should be appreciated that the greatest difference between the TBFT consensus algorithm and the PBFT consensus algorithm described above is that: PBFT the consensus algorithm has a fixed leader node (i.e., a master node) for packaging transactions in the transaction pool, and when the leader node fails, the leader node is replaced by using a view-change sub-protocol (i.e., a master node switching sub-protocol); in TBFT consensus algorithm, the leader node is rotated based on a rotation mechanism, for example, when the current node is regarded as a leader node, each time X blocks (X values can be configured) are submitted, the leader node is automatically rotated to the next node. This means that a consensus node in the bill chain network to which the bill chain corresponds can be used for consecutive outgoing blocks.

1.3 The consensus algorithm associated with the application contract chain is yet another instant deterministic consensus algorithm, for example, the instant deterministic consensus algorithm herein may be a PoS (proof-of-interest) consensus algorithm by which the network security of the application contract chain network in which the application contract chain is located may be maintained, and by which the status of a proposed block to be uplinked may be immediately determined. It can be appreciated that the consensus nodes in the application contract chain network can be jointly participated in and managed by the tax administration department and government cooperation department shown in fig. 2, and a large participating organization (i.e. a large enterprise in the alliance chain, which is the business association department shown in fig. 2).

It should be appreciated that for the intelligent contracts in the blockchain electronic ticket triplex network, the following distinction exists:

2.1 It should be appreciated that a language-specific smart contract engine may be supported on the management chain as shown in fig. 2, through which the above-described management consensus node may deploy language-specific smart contracts on the management chain, such as the above-described object rights management contracts, object identity management contracts, metadata management contracts, and internal management contracts, and full platform configuration contracts shown in fig. 2, may be deployed on the management chain. It should be appreciated that these intelligent contracts may be developed and managed by specific tax managers in tax authorities. The management authority of the management object and the service access authority of the service object can be managed by calling the object authority management contract; invoking an object identity management contract can manage the identity information of a management object or the identity information of a business object; invoking a metadata management contract may manage metadata on the blockchain; invoking the full platform configuration contract may manage the cross-chain configuration.

2.2 Intelligent contracts with specific bill business logic built into the bill chain as shown in fig. 2, and these intelligent contracts (e.g., electronic bill issuing contracts, electronic bill transfer contracts, electronic bill red punching contracts, electronic bill archiving contracts as shown in fig. 2 above) can be updated as bill business is updated. For example, the embodiment of the application can update the bill business logic in the electronic bill issuing contract through the metadata information read from the management chain, and further update and process the bill business according to the updated electronic bill issuing contract. This means that the ticket chain does not support a separate smart contract engine, and naturally does not support the deployment of other contracts on the ticket chain that are not related to ticket business. The advantage of doing so is that the bill chain only runs business logic related to the electronic bill and is not influenced by other intelligent contracts, so that the bill chain can run more independently and stably and is more resistant to attack.

2.3 Multi-language, turing-complete developer-oriented intelligent contracts supported on the application contract chain, such as shown in FIG. 2, the developer may be able to compatible with the mainstream EVM virtual machine through the virtual machine compatible contract when accessing the application contract chain through the application contract chain portal, so that various new business contracts may be deployed and run on the compatible virtual machine, such as derivative business contracts associated with derivative businesses (e.g., the lottery businesses described above) may be deployed on the application contract chain. For another example, a derivative application contract associated with another derivative service (e.g., the tax refund service described above) may be deployed on an application contract chain.

It should be appreciated that in a blockchain electronic ticket triplex network, as shown in fig. 2, the public network participants associated with the management chain may be individual users and enterprise users as shown in fig. 2. Similarly, as shown in FIG. 2, the public network participants associated with the ticket chain may be the various electronic ticket streaming systems shown in FIG. 2. The electronic bill flow systems herein specifically include electronic bill business issuing systems (e.g., tax office systems) in various places, electronic bill issuing service providers, financial tax related systems in large enterprises, and the like. Similarly, as shown in FIG. 2, the public network participants associated with the application contract chain may be tax service participants and developers as shown in FIG. 2.

Specifically, 3.1) the chain entry associated with the management chain may be the management chain entry shown in fig. 2. When an individual user (e.g., user a) and an enterprise user (e.g., enterprise B) shown in fig. 2, etc. are used as public network participants, a management chain can be accessed through the management chain entry, and further services such as identity registration and identity authorization can be performed through the management chain. 3.2 A chain entry associated with the bill chain may be a bill chain entry as shown in fig. 2. When the electronic bill flow system (for example, large enterprise users) and the like in each place shown in fig. 2 are taken as public network participants, bill chains can be accessed through the bill chain entrance, and then electronic bill issuing service, electronic bill circulation service, electronic bill red punching service and electronic bill archiving service can be executed through the bill chains. 3.3 A chain entry associated with an application contract chain may be the application contract chain entry shown in fig. 2. When the tax service participant and the developer shown in fig. 2, etc. are used as public network participants, the application contract chain can be accessed through the application contract chain entry, and further, derivative service contracts can be deployed on the application contract chain, so that derivative services related to the electronic bill can be executed through the deployed derivative service contracts.

It can be understood that the management chain entry shown in fig. 2 may be specifically a tax administration department entry, through which identity recognition and service guidance can be performed on individuals, legal persons, entities, etc. that need to access the management chain.

It should be understood that the bill chain entry shown in fig. 2 may be specifically an electronic bill service entry, through which transaction service data (which may also be referred to as transaction data) of an electronic bill requested to be issued by a certain service object (e.g., enterprise B) may be received. Thus, when the bill consensus node receives the transaction data through the electronic bill service entrance, whether the access identity and the access authority of the transaction data sender (namely the enterprise B) meet the contract state requirement of the identity authority in the management chain or not is judged, and when verification is passed, a corresponding electronic bill can be opened according to the transaction data.

It will be appreciated that the application contract portal shown in fig. 2 may be specifically a tax derived service portal, through which a derived service associated with a ticket service that is requested to participate by a service object (e.g., a tax service participant shown in fig. 2) may be received. It should be appreciated that the tax service participant and developer shown in fig. 2 may, after obtaining the service participation license credential of the authorized object issued by the tax administration, verify the service participation license credential submitted by the service object (e.g., tax service participant or developer) through the application contract chain entry, and may further allow the service object to access the application contract chain to execute the derivative service associated with the aforementioned ticket service on the application contract chain when the verification is successful.

As shown in fig. 2, the internal party participating in the maintenance management chain may be a tax management department shown in fig. 2, where the tax management department is mainly used for configuring and managing internal state parameters on the management chain, and may also be used for changing the metadata information (e.g., tax metadata) to be uplink (e.g., may update an electronic ticket template, update a tax rule, etc.), and may be used for managing identities and rights of various service parties maintained on the management chain (e.g., freezing enterprise billing qualification, limiting enterprise billing amount, etc.).

As shown in fig. 2, the internal party participating in maintaining the bill chain may be an electronic bill data center shown in fig. 2, where the electronic bill data center may be specifically an electronic bill data center, and the electronic bill data center (for example, the electronic bill data center) may be used for performing work such as under-chain backup, statistics, data analysis, and examination on massive amounts of bill data recorded on the bill chain.

As shown in fig. 2, the internal parties participating in the maintenance application contract chain may be the government affair cooperation department and the business association department shown in fig. 2. It should be appreciated that, in addition to tax administration, the internal parties involved in maintaining the application contract chain, other departments in the system alliance chain (i.e., the aforementioned government affair collaboration departments) and parties (i.e., the aforementioned business association departments) may each further execute corresponding derivative business through derivative business contracts on the application contract chain upon accessing the application contract chain. It can be understood that the government affair cooperation department, the business association department and the like shown in fig. 2 are taken as tax business participants, and the access application contract chain has the advantage of flexibly running various extensible derivative businesses in the support of complete intelligent contract statement period so as to ensure the flexibility of business change.

It can be appreciated that, in the three-link network of the blockchain electronic ticket shown in fig. 2, corresponding intelligent contracts can be built in.

4.1) For intelligent contracts built into the management chain, as shown in fig. 2, the object identity management contract built into the management chain may specifically be a user management contract, through which the identities of the accessors (e.g., public network participants) and the participants (e.g., internal participants) under the entire three-chain system may be managed. It should be appreciated that the accessors and participants herein may include tax manager, government collaboration department, local tax office, billing service, reimbursement service, tax audit department, etc., in particular. 4.2) for the intelligent contracts built into the bill chain, as shown in FIG. 2, the intelligent contracts built into the bill chain may include bill chain configuration contracts and bill business contracts associated with electronic bill lifecycles. The bill transaction contracts herein may specifically include an electronic bill issuing contract for providing an electronic bill issuing transaction, an electronic bill transfer contract for providing an electronic bill transfer transaction, an electronic bill red-strike contract for providing an electronic bill red-strike transaction, and an electronic bill archiving contract for providing an electronic bill archiving transaction as shown in fig. 2. The bill chain configuration contract is used for recording configuration items on the bill chain.

4.3) For the intelligent contracts built in the application contract chain, as shown in fig. 2, the intelligent contracts built in the ticket chain may include application chain configuration contracts, and may further include various contracts (e.g., virtual machine compatible contracts, tax application contracts, derivative business contracts, etc. shown in fig. 2) that are participated in deployment by tax derivative business participants (i.e., derivative business objects, e.g., tax business participants shown in fig. 2). For example, the derivative service contract may be an electronic ticket-based credit investigation service contract, through which credit investigation data of a certain enterprise can be analyzed and obtained. As another example, derivative business contracts herein may also be, in particular, on-chain lottery business contracts and talent incentive contracts deployed to encourage invoicing, tax refund business contracts, and the like. The application contract chain configuration contract is used for recording configuration items on the chain.

It should be understood that, for the management chain shown in fig. 2, the management chain is mainly used for processing management traffic flows with smaller data volume and more constant state, and the whole management chain has relatively low openness and can be used for internal management of some tax data. For the bill chain shown in fig. 2, the real-time bill service flow with some data volume in high-frequency request state can be processed, the openness of the whole bill chain is relatively high, the related authority in the life cycle of the electronic bill can be allowed to participate in the corresponding bill service, for example, the consensus node corresponding to the proxy server can be allowed to issue the electronic bill for a certain user who currently requests to issue an invoice. In addition, for the application contract chain shown in fig. 2, the size of the data volume can be free from limitation, the frequency fluctuation of service change is relatively large, and various collaboration services, derivative services, exploratory services and the like can be processed mainly through the application contract chain. It should be appreciated that the application contract chain has the highest openness, can run participants authorized by the management chain to deploy intelligent contracts on the application contract chain, run exploratory derivative businesses, and the like.

Further, referring to fig. 3, an embodiment of the present application provides a schematic diagram of a cross-link configuration for a target link. As shown in fig. 3, a first chain, a second chain, a third chain, a service sub-chain 1, and a service sub-chain 2 may be included in a blockchain system. It should be understood that the second chain to be configured, the third chain to be configured, the service sub-chain to be configured 1, and the service sub-chain to be configured 2 may be referred to as target chains, and the consensus node of the chain related to the target chains may be referred to as target consensus nodes, and furthermore, the second chain and the third chain may also be referred to as service backbones; in the embodiment of the application, the cross-link relay can be adopted to isolate the first link network corresponding to the first link and the target link network corresponding to the target link. It should be understood that the number of service sub-chains in the embodiment of the present application is not limited.

For ease of understanding, the core consensus network in which the first chain is located (i.e., the first chain network) is taken as an example of the consensus network 100a shown in fig. 1, and in this case, the consensus node participating in maintaining the first chain may be the first consensus node. As shown in fig. 3, the foregoing first chain has deployed thereon a plurality of intelligent contracts for cross-chain configuration, which may be run on a first consensus node. The first chain is deployed with a full platform configuration contract, and the invocation of the full platform configuration contract can implement basic configuration of the service main chain and the service sub-chain. The full platform configuration contract may enable global configuration and individual configuration of the business backbone or business sub-chains. In fig. 3, the full platform configuration contract includes a chain management configuration contract including a platform configuration contract for global configuration and a target chain management configuration contract for configuring a certain chain alone. The target chain management configuration contract may include a chain management configuration contract of the second chain, a chain management configuration contract of the third chain, or a sub-chain management configuration contract of the business sub-chain.

It will be appreciated that both the business backbone (i.e., second and third chains) and the business sub-chains may be globally configured when the platform configuration contract described above is invoked. It should be appreciated that invoking the platform configuration contract may configure the metadata, base information (e.g., chain names of certain chains, management objects that manage certain chains, time to generate a block, etc.) and the like in the second chain, third chain, business sub-chain 1, and business sub-chain 2 across chains. For example, taking a first chain as an example of a management chain in a blockchain electronic bill platform, invoking a platform configuration contract can perform cross-chain configuration on some tax metadata (such as tax rule change, etc.), basic information (such as a chain name of an application contract chain, a chain name of a bill chain, management objects for managing some chains, time for generating a block, etc.).

It should be understood that when the chain management configuration contract of the second chain, the chain management configuration contract of the third chain and the sub-chain management configuration contract of the service sub-chain are respectively called, the first chain is respectively configured separately, the second chain is respectively configured separately, and the service sub-chain is respectively configured separately. The individual configuration at this time may include generating a block size, some business rules on the chain. For example, taking a first chain as a management chain in a blockchain electronic bill platform, taking a target chain as a bill chain as an example, invoking a chain management configuration contract of the bill chain can upgrade invoices on the bill chain, change invoice flow on the bill chain, and the like. For another example, taking the first chain as the management chain in the blockchain medical prescription platform and the target chain as the prescription chain as an example, invoking the chain management configuration contract of the prescription chain can configure the prescription templates on the prescription chain, change the prescription flow on the prescription chain, and the like.

For ease of understanding, taking the core consensus network where the second chain is located (i.e., the second chain network described above) as an example of the consensus network 200a shown in fig. 1, a chain configuration contract is disposed on the second chain, and the chain configuration contract on the second chain may run on a second consensus node participating in maintaining the second chain. The chain configuration contract of the second chain records the configuration items of the present chain (such as the size of the generation block, the bill template, etc.).

Similarly, for ease of understanding, taking the core consensus network in which the third chain is located (i.e., the third chain network) as an example of the consensus network 300a shown in fig. 1, a chain configuration contract is disposed on the third chain, and the chain configuration contract on the third chain may specifically run on a consensus node participating in maintaining the third chain. It should be appreciated that the link configuration contract for the third link records the configuration items (e.g., size of the generation block, ticket template, etc.) for the present link. It will be further understood that, in fig. 3, the service sub-chains 1 and 2 may be deployed with sub-chain configuration contracts, where the sub-chain configuration contracts of the service sub-chains may specifically run on sub-chain consensus nodes participating in maintaining the corresponding service sub-chains.

It will be understood that, in fig. 3, the link configuration contract of the second link, the link configuration contract of the third link, the sub-link configuration contract in the service sub-link 1, and the sub-link configuration contract in the service sub-link 2 all include both a blocking link configuration lock and a non-blocking link configuration lock. Taking a block chain to be configured across chains as a target chain, the target chain can be one or more of a second chain, a third chain and a service sub-chain; when the blocking type chain configuration lock is obtained, the target chain can be locked through the blocking type chain configuration lock, normal service cannot be carried out on the target chain, and the target chain does not carry out normal service until the target chain is unlocked through the blocking type chain configuration lock. And when the non-blocking chain configuration lock is obtained, a block buffer height (such as N) is provided, N blocks can still be generated on the target chain before the service state of the target chain is configured into the second service locking state, after N blocks are generated, the target chain stops normal service and cannot generate new blocks until the target chain is unlocked through the non-blocking chain configuration lock, and normal service is not performed on the target chain.

For example, the management object may send, based on the configuration transaction, a configuration transaction for performing cross-link configuration on the target link to a first consensus node in the first link, where the first consensus node determines a transaction type of the configuration transaction, and when the transaction type is a blocking transaction type, the first consensus node may generate, based on the above-mentioned chain management configuration contract, a first configuration transaction identifier corresponding to the configuration transaction, and when the cross-link relay detects the first configuration transaction identifier on the first link, may send, to the target consensus node associated with the target link, a first lock acquisition transaction. Then, the target chain can acquire the blocked chain configuration lock corresponding to the blocked transaction type of the configuration transaction from the chain configuration contract on the target chain according to the first lock acquisition transaction, and the target consensus node can configure the service state of the target chain into a first service locking state through the blocked chain configuration lock, and at the moment, the normal service is stopped on the target chain.

Wherein, it should be understood that the configuration transaction related to the embodiment of the present application refers to performing cross-link configuration on a target link, and the configuration transaction may include at least one of the following: a chain identification of a target chain to be configured across chains, and a across-chain configuration item for configuring the target chain. For example, in the blockchain electronic bill platform, the target chain is a bill chain, the management object may be an administrator for managing the bill chain, and the configuration transaction may include a chain identifier of the bill chain, update an invoice template in the bill chain, configure tax rule, and the like. For another example, in the blockchain electronic bill platform, the target chain is an application contract chain, the management object may be a government affair cooperation department, a business association department and the like for managing the application contract chain, and the configuration transaction may include a chain identifier of the application contract chain, an application development rule update in the application contract chain and the like.

Further, it may be understood that when the target chain is detected to be in the first service locking state, the cross-chain relay may send a first locking declaration transaction to the first consensus node, so that when the first consensus node on the first chain determines that the state of the configuration transaction corresponding to the first configuration transaction identifier is the first service locking state based on the first locking declaration transaction, the first transaction locking information corresponding to the first locking declaration transaction is generated, the first transaction locking information is generated into a block, the first chain is written after other consensus nodes in the first chain network agree on the block, then the management object sends a configuration modification transaction based on the first transaction locking information on the first chain, the first consensus node in the first chain may acquire a first cross-chain configuration item in the configuration modification transaction, and cross-chain the first cross-chain configuration item to the target chain through the cross-chain relay, so that the target consensus node unlocks the target chain in the first service locking state through the blocking chain configuration lock.

It should be understood that when the transaction type is a non-blocking type transaction type, the first consensus node may generate a second configuration transaction identifier corresponding to the configuration transaction based on the chain management configuration contract, and when the cross-chain relay detects the second configuration transaction identifier on the first chain, the cross-chain relay may send a second lock acquisition transaction to the target consensus node associated with the target chain, and the target chain acquires the non-blocking type chain configuration lock corresponding to the non-blocking type transaction type and the block buffer height from the chain configuration contract on the target chain according to the second lock acquisition transaction, and when the interval height of the blocks generated on the target chain reaches the block buffer height, the target consensus node may configure the service state of the target chain to be the second service locking state through the non-blocking type chain configuration lock, and at this time, normal service is stopped on the target chain.

Further, it may be understood that when the target chain is detected to be in the second service locking state, the cross-chain relay sends a second locking declaration transaction to the second consensus node, so that when the first consensus node on the first chain determines that the state of the configuration transaction corresponding to the second configuration transaction identifier is the second transaction locking state based on the second locking declaration transaction, the second transaction locking information corresponding to the second locking declaration transaction is generated, the second transaction locking information is generated into a block, the second transaction locking information is written into the second chain after the block is commonly known, then the management object sends a configuration modification transaction based on the second transaction locking information on the first chain, the first consensus node in the first chain can acquire a second cross-chain configuration item in the configuration modification transaction, and cross-chain configure the second cross-chain configuration item to the target chain through the cross-chain relay, so that the target consensus node unlocks the target chain in the second service locking state through the non-blocking chain configuration lock.

It may be understood that the common node according to the embodiment of the present application may be an independent physical server, or may be a server cluster or a distributed system formed by a plurality of physical servers, or may be a cloud server that provides cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDNs, and basic cloud computing services such as big data and an artificial intelligence platform.

When the management object performs the cross-link configuration on the target chain, a prompt interface or a popup window may be displayed when data such as the management license credential of the management object is acquired, where the prompt interface or the popup window is used to prompt that the management object is currently collecting the management license credential, and only after the management object is acquired to send a confirmation operation to the prompt interface or the popup window, the relevant step of data acquisition is started, otherwise, the process is ended.

In addition, it will be understood that in the specific embodiment of the present application, identity information of management objects such as users, enterprises, institutions, etc. may be involved, and when the above embodiments of the present application are applied to specific products or technologies, permission or consent of service objects such as users, enterprises, institutions, etc. needs to be obtained, and collection, use and processing of relevant data need to comply with relevant laws and regulations and standards of relevant countries and regions.

The specific process of performing the cross-link configuration on the management chain for the target chain may be referred to as embodiments corresponding to fig. 4 to fig. 9 below.

Further, referring to fig. 4, fig. 4 is a schematic diagram illustrating a multi-blockchain-based cross-chain configuration method according to an embodiment of the present application, as shown in fig. 4, the method may be performed by a first common node associated with the first chain, for example, the first common node may be any common node in the common network 100a shown in fig. 1. The method may specifically include the following steps S401 to S405.

Step S401, when receiving a configuration transaction sent by a management object based on a configuration transaction and used for cross-chain configuration target chain, determining a transaction type of the configuration transaction.

The management object according to the embodiment of the present application may be a management user of a target chain (for example, the target chain is an application contract chain in the above-mentioned blockchain electronic bill platform, and the management object may be a government affair coordination department, a business association department, etc.), and the configuration transaction includes a chain identifier of the target chain. It will be appreciated that the multi-block chain may comprise a first chain, a traffic backbone managed by the first consensus node via the first chain, and a traffic sub-chain independent of the traffic backbone comprising one or more of a second chain and a third chain independent of the first chain.

It should be appreciated that the second chain network to which the second chain corresponds is independent of the third chain network to which the third chain corresponds. The first link network corresponding to the first link and the target link network corresponding to the target link can be isolated through the cross-link relay, namely, the first link network and the target link network perform data interaction through the cross-link relay. For example, in the above-mentioned blockchain electronic bill platform, when the target chain is a second chain (such as the bill chain), the first chain network (i.e., the management chain network) and the second chain network (bill chain network) corresponding to the second chain may be isolated by the cross-chain relay, and the first chain network and the second chain network perform data interaction by the cross-chain relay; for another example, when the target link is a third link (e.g., the application contract link described above), the first link network and the third link network (application contract link network) corresponding to the third link may be isolated by the cross-link relay, and the first link network and the third link network may perform data interaction by the cross-link relay. For another example, when the target link is a service sub-link, the first link network and the sub-link consensus network corresponding to the service sub-link may be isolated by the cross-link relay, and the first link network and the sub-link consensus network may perform data interaction by the cross-link relay.

The sub-link consensus network corresponding to the service sub-link is formed by a consensus node in a second link network corresponding to the second link and a consensus node in a third link network corresponding to the third link; the service sub-chain is authorized to be created by a service object requesting to execute the target service through the first consensus node; one target service corresponds to one service sub-chain. That is, when a temporary service (i.e., a target service) occurs, a service object (e.g., an enterprise a, a personal user, etc.) may request to execute the target service in a first link network corresponding to the first link, and after the first consensus node in the first link network performs authorization verification on the service object, a sub-link consensus network for processing the target service may be created together according to a consensus node selected from among consensus nodes in the second link network and a consensus node selected from among consensus nodes in the third link network. At this time, the consensus node in the sub-chain consensus network may also be referred to as a verification node.

For example, in a blockchain electronic bill platform, the target service is to verify whether the format of 100 invoices is correct; at this time, the service object may request to execute the target service from a first consensus node in the management chain network (i.e., the first chain network), and the first consensus node may perform authorization verification on the service object, and after the authorization verification, construct a sub-chain consensus network for verifying a format of 100 invoices through a consensus node voted by a ticket consensus node in the ticket chain network and a consensus node voted by an consensus node in the application contract chain network. The consensus node in the sub-chain consensus network can verify whether the format of 100 invoices is correct and return the final execution result to the business object.

It will be appreciated that the number of target chains may be one or more, and embodiments of the present application are not limited in this regard. When the number of target chains is one, the target chains may be service sub-chains or service backbones, for example, the above-described blockchain electronic bill platform may contain a management chain (i.e., a first chain), a service backbone contains a bill chain (i.e., a second chain), an application contract chain (i.e., a third chain), a service sub-chain 1, and a service sub-chain 2. The target chain may be a bill chain, an application contract chain, or a business sub-chain. When the number of the target chains is plural, the plural target chains may include a service sub-chain and a service main chain, for example, the block chain electronic bill platform may include the service main chain (i.e., include a bill chain independent of a management chain and an application contract chain) and 2 service sub-chains independent of the service main chain (i.e., a service sub-chain 1 and a service sub-chain 2), and the plural target chains may include the bill chain, the application contract chain and the service sub-chain 1; or the multiple target chains may comprise the bill chain and business sub-chain 2 described above.

It may be understood that, when the business object wants to perform cross-chain configuration on a certain blockchain (i.e. a target chain), a configuration transaction for cross-chain configuration target chain may be sent to a first common node in the first chain network based on a configuration transaction, and when the first common node receives the configuration transaction sent by the management object based on the configuration transaction for cross-chain configuration target chain, the first common node may acquire a management license credential of the management object, verify the management license credential of the management object, and if the verification passes, determine a transaction type of the configuration transaction. It may be appreciated that the foregoing configuration transaction may further indicate a transaction type of the configuration transaction, and the first consensus node may directly determine the transaction type of the configuration transaction in the configuration transaction.

The transaction types involved in the embodiment of the present application can be classified into a blocking type transaction type and a non-blocking type transaction type. Different configuration transaction identifications corresponding to the configuration transactions may be generated based on the differences between the blocking transaction type and the non-blocking transaction type. When the transaction type is a blocking transaction type, step S402 may be performed to generate a first configuration transaction identification.

Step S402, when the transaction type of the configuration transaction is a blocking type transaction type, a chain management configuration contract on a management chain is called to execute the configuration transaction, and a first configuration transaction identifier corresponding to the configuration transaction is generated; the first configuration transaction identifier is used for indicating the cross-chain relay to send a first configuration lock acquisition transaction to a target consensus node associated with a target chain; the first configuration lock acquisition transaction is used for indicating the target consensus node to acquire a blocked chain configuration lock corresponding to the blocked transaction type from a chain configuration contract on the target chain, and the service state of the target chain is configured into a first service locking state through the blocked chain configuration lock.

It is understood that the first configuration transaction identifier is a transaction identifier for characterizing the configuration transaction, and the first configuration transaction identifier may be a number, a character, or a character string formed by the data and the character. For example, for configuration transaction x, invoking a chain management configuration contract on the management chain to perform a configuration transaction corresponding to configuration transaction x may generate a configuration transaction identification ID-x corresponding to configuration transaction x.

When the transaction type of the configuration transaction is a blocking transaction type, the first consensus node may call a chain management configuration contract on a management chain to execute the configuration transaction, and generating the first configuration transaction identifier corresponding to the configuration transaction may include the following two ways:

(1) When the number of the target chains is multiple, the configuration transaction performs cross-chain configuration for the multiple target chains, and at this time, the configuration resources indicated by the configuration transaction belong to global configuration resources, and the chain management configuration corresponding to the global configuration resources is approximately equal to the platform configuration contract on the first chain. Wherein it should be understood that the global configuration resource is a resource configured for all blockchains, and the global configuration resource may contain cross-chain configuration items. The cross-chain configuration items in the global configuration resource are configured on a plurality of target chains, for example, the cross-chain configuration items can be used for modifying chain names on the plurality of target chains and modifying block-out time on the plurality of target chains.

It should be understood that the platform configuration contract includes two configuration methods, namely, a blocking type transaction configuration method and a non-blocking type transaction configuration method, through which the configuration method to be invoked by the first consensus node when performing cross-chain configuration can be determined. When the transaction type of the configuration transaction is the blocking transaction type, the first common node writes the configuration transaction into the platform configuration contract, then determines a configuration method to be executed as a blocking transaction configuration method in the platform configuration contract according to the blocking transaction type, and calls the blocking transaction configuration method to execute the configuration transaction to obtain chain identifications of a plurality of target chains indicated by the configuration transaction, and then can generate a first configuration transaction identification corresponding to the configuration transaction based on the chain identifications of the plurality of target chains.

(2) It is understood that the target chain may be a second chain, a third chain, or a traffic sub-chain. The second and third chains are managed by the first consensus node through a full platform configuration contract on the first chain, the full platform configuration contract comprising a chain management configuration contract. When the configuration resources indicated by the configuration transaction belong to independent configuration resources, the chain management configuration corresponding to the independent configuration resources is approximately equal to a target chain management configuration contract on the first chain; the target chain management configuration contract may include a chain management configuration contract for configuring the second chain, a chain management configuration contract for configuring the third chain, or a sub-chain management configuration contract for configuring the business sub-chain. The independent allocation resource herein refers to a resource that is configured for a block chain alone, such as configuring the size of a block for a target chain alone, upgrading the traffic on the target chain, and so on.

It should be understood that when the target chain is the second chain, the target chain management configuration contract includes a chain management configuration contract for configuring the second chain, and when the transaction type of the configuration transaction is a blocking transaction type, the configuration transaction may be written into the chain management configuration contract of the second chain, and then the blocking transaction configuration method in the chain management configuration contract of the second chain is called to execute the configuration transaction, so as to obtain a chain identifier of the second chain indicated by the configuration transaction, and generate a first configuration transaction identifier corresponding to the configuration transaction based on the chain identifier of the second chain.

When the target chain is the third chain, the target chain management configuration contract comprises a chain management configuration contract for configuring the third chain, when the transaction type of the configuration transaction is a blocking type transaction type, the configuration transaction can be written into the chain management configuration contract of the third chain, then a blocking type transaction configuration method in the chain management configuration contract of the third chain is called to execute the configuration transaction, the chain identification of the third chain indicated by the configuration transaction is obtained, and the first configuration transaction identification corresponding to the configuration transaction is generated based on the chain identification of the third chain.

When the target link is a service sub-link, the target link management configuration contract comprises a sub-link management configuration contract for configuring the service sub-link, when the transaction type of the configuration transaction is a blocking transaction type, the configuration transaction can be written into the sub-link management configuration contract, then a blocking transaction configuration method in the sub-link management configuration contract is called to execute the configuration transaction, the link identification of the service sub-link indicated by the configuration transaction is obtained, and a first configuration transaction identification corresponding to the configuration transaction is generated based on the link identification of the service sub-link.

Step S403, receiving a first locking statement transaction sent by a cross-chain relay; the first lock claim transaction is determined by the cross-chain relay upon detecting that the target chain is in a first traffic lock state.

Wherein it is to be appreciated that when the cross-chain relay detects that the target chain is in a first traffic lock state, a first lock claim transaction can be generated based on the first traffic lock state and the first lock claim transaction can be sent to the cross-chain relay. Accordingly, the first consensus node may receive a first lock claim transaction sent across chain relays. The first lock declaration transaction may be used to declare that a target chain has been successfully locked, on which normal traffic cannot be performed, or to declare that the first configuration transaction identity is successfully locked, i.e., to let the first consensus node associated with the first chain determine that the state of the configuration transaction corresponding to the first configuration transaction identity is in the first transaction locked state.

Step S404, when the state of the configuration transaction corresponding to the first configuration transaction identifier is determined to be the first transaction locking state based on the first locking statement transaction, first transaction locking information corresponding to the first locking statement transaction is generated, and the first transaction locking information is written into the management chain.

It may be understood that the first consensus node may determine, based on the first lock claim transaction, that a state of a configuration transaction corresponding to the first configuration transaction identifier is a first transaction locking state, and when determining that the state of the configuration transaction corresponding to the first configuration transaction identifier is the first transaction locking state, generate first transaction locking information corresponding to the first lock claim transaction, package the first transaction locking information into a block, perform consensus through other consensus nodes in the first chain network, and then write the block into the first chain after the consensus passes. The first transaction locking information may be used to indicate that the resource associated with the configuration transaction has been locked on the target chain, which is temporarily unavailable for normal traffic. Wherein, it should be understood that, the first cross-link configuration item indicates a configuration resource needing to configure the target link, for example, the target link is a bill link, and the first cross-link configuration item may indicate to update the bill template resource for the bill link; as another example, the first cross-chain configuration item indicates that tile size resources are configured for the bill chain.

Step S405, when a configuration modification transaction sent by a management object based on first transaction locking information on a first chain is obtained, a first cross-chain configuration item in the configuration modification transaction is obtained, and the first cross-chain configuration item is configured to a target chain in a cross-chain manner through a cross-chain relay, so that a target consensus node unlocks the target chain in a first transaction locking state through a blocking chain configuration lock.

It should be understood that, the management object obtains the first transaction locking information from the first chain, knows that the current target chain has been successfully locked, and can send a configuration modification transaction for the target chain to the associated first consensus node on the first chain, where the configuration modification transaction includes a first cross-chain configuration item; the first consensus node receives the configuration modification transaction, acquires a first cross-link configuration item from the configuration modification transaction, and then cross-links the first cross-link configuration item to the target link through cross-link relay.

In the embodiment of the application, a first consensus node on a first chain can receive a configuration transaction for cross-chain configuration target chain, and execute the configuration transaction when the transaction type of the configuration transaction is a blocking transaction type, and generate a first configuration transaction identifier corresponding to the configuration transaction; and then, the target consensus node can acquire a blocking type chain configuration lock corresponding to the blocking type transaction type through the first configuration transaction identifier, lock the service state of the target chain through the blocking type chain configuration lock, and configure the cross-chain configuration item configured for the target chain on the first chain to the target chain through the cross-chain relay after the service state of the target chain is locked. It can be seen that, in the embodiment of the present application, the configuration information of the other chains can be uniformly managed through the first consensus node (for example, 10a shown in fig. 1) on the first chain, so as to ensure the consistency of the configuration information on the chains. Meanwhile, when the business state of the target chain is locked, the first consensus node can generate corresponding transaction locking information and write the corresponding transaction locking information into the first chain, so that the scrutiny and traceability of the configuration of the target chain can be effectively ensured; in addition, a configuration mechanism such as a blocking chain configuration lock is introduced, so that synchronous validation of configuration can be realized, strict execution of business logic is ensured, and consistency and reliability of configuration information on each block chain independent of each other can be ensured.

Further, referring to fig. 5, fig. 5 is a schematic diagram illustrating a multi-blockchain-based cross-chain configuration method according to an embodiment of the present application, as shown in fig. 5, the method may be performed by a first common node associated with the first chain, for example, the first common node may be any common node in the common network 100a shown in fig. 1. The method may specifically include the following step S501-step S508.

Step S501, when a configuration transaction for cross-chain configuration target chain sent by a management object based on the configuration transaction is received, determining a transaction type of the configuration transaction.

Step S502, when the transaction type of the configuration transaction is a blocking type transaction type, a chain management configuration contract on a first chain is called to execute the configuration transaction, and a first configuration transaction identifier corresponding to the configuration transaction is generated; the first configuration transaction identifier is used for indicating the cross-chain relay to send a first configuration lock acquisition transaction to a target consensus node associated with a target chain; the first configuration lock acquisition transaction is used for indicating the target consensus node to acquire a blocked chain configuration lock corresponding to the blocked transaction type from a chain configuration contract on the target chain, and the service state of the target chain is configured into a first service locking state through the blocked chain configuration lock;

Step S503, receiving a first locking statement transaction sent by a cross-chain relay; the first lock claim transaction is determined when the cross-chain relay detects that the target chain is in a first traffic lock state;

step S504, when the state of the configuration transaction corresponding to the first configuration transaction identifier is determined to be the first transaction locking state based on the first locking declaration transaction, generating first transaction locking information corresponding to the first locking declaration transaction, and writing the first transaction locking information into the first chain;

Step S505, when a configuration modification transaction sent by a management object based on first transaction locking information on a first chain is obtained, a first cross-chain configuration item in the configuration modification transaction is obtained, and the first cross-chain configuration item is cross-chain configured to a target chain through a cross-chain relay, so that a target consensus node unlocks the target chain in a first service locking state through a blocking chain configuration lock.

The specific implementation manner of the steps S501 to S505 may refer to the specific implementation manner of the steps S401 to S405, and will not be described herein.

Step S506, when the transaction type of the configuration transaction is a non-blocking transaction type, calling a chain management configuration contract on the first chain to execute the configuration transaction, and generating a second configuration transaction identifier corresponding to the configuration transaction; the second configuration transaction identifier is used for indicating the cross-chain relay to send a second configuration lock acquisition transaction to a target consensus node associated with the target chain; the second configuration lock acquisition transaction is used for indicating the target consensus node to acquire a non-blocking chain configuration lock corresponding to the non-blocking transaction type from a chain configuration contract on the target chain, and the service state of the target chain is configured into a second service locking state through the non-blocking chain configuration lock.

It may be understood that the configuration transaction includes a chain identifier of the target chain and a second cross-chain configuration item associated with the configuration transaction, where the second configuration transaction identifier is used to characterize a transaction identifier of the configuration transaction, and the second configuration transaction identifier may be a number, a character, or a character string formed by the data and the character. For example, for configuration transaction X, invoking a chain management configuration contract on the management chain to perform a configuration transaction corresponding to configuration transaction X may generate a configuration transaction identification ID-X corresponding to configuration transaction X.

When the transaction type of the configuration transaction is a non-blocking transaction type, the first consensus node may call a chain management configuration contract on a management chain to execute the configuration transaction, and generating the second configuration transaction identifier corresponding to the configuration transaction may include the following two ways:

(1) It will be appreciated that the multi-block chain to which the present application relates comprises a traffic backbone managed by a first consensus node via a first chain and a traffic sub-chain independent of the traffic backbone; the traffic backbone comprises one or more of a second chain and a third chain that are independent of the first chain; the sub-link consensus network corresponding to the service sub-link is formed by a consensus node in a second link network corresponding to the second link and a consensus node in a third link network corresponding to the third link; wherein the second chain network is independent of the third chain network; the service sub-chain is authorized to be created by a service object requesting to execute the target service through the first consensus node; one target service corresponds to one service sub-chain.

When the number of the target chains is a plurality of, the plurality of target chains comprise a service sub-chain and a service main chain; the configuration transaction performs cross-chain configuration for a plurality of target chains, and at this time, the configuration resources indicated by the configuration transaction belong to global configuration resources, and the chain management configuration corresponding to the global configuration resources is about a platform configuration contract on the first chain. It should be understood that the platform configuration contract includes two configuration methods, namely, a blocking type transaction configuration method and a non-blocking type transaction configuration method, through which the configuration method to be invoked by the first consensus node when performing cross-chain configuration can be determined. When the transaction type of the configuration transaction is a non-blocking transaction type, the first consensus node can write the configuration transaction into the platform configuration contract, then determine a configuration method to be executed as a non-blocking transaction configuration method in the platform configuration contract according to the non-blocking transaction type, call the non-blocking transaction configuration method to execute the configuration transaction, obtain chain identifications of a plurality of target chains indicated by the configuration transaction and a second cross-chain configuration item, and then generate a second configuration transaction identification corresponding to the configuration transaction based on the chain identifications of the plurality of target chains and the second cross-chain configuration item.

(2) It is understood that the target chain may be a second chain, a third chain, or a traffic sub-chain. The second and third chains are managed by the first consensus node through a full platform configuration contract on the first chain. The full platform configuration contract includes a chain management configuration contract. When the configuration resources indicated by the configuration transaction belong to independent configuration resources, the chain management configuration corresponding to the independent configuration resources is approximately equal to a target chain management configuration contract on the first chain; the target chain management configuration contract includes a chain management configuration contract for configuring the second chain, a chain management configuration contract for configuring the third chain, or a sub-chain management configuration contract for configuring the business sub-chain. The independent allocation resource herein refers to a resource that is configured for a block chain alone, such as configuring the size of a block for a target chain alone, upgrading the traffic on the target chain, and so on.

It should be understood that when the target chain is the second chain, the target chain management configuration contract includes a chain management configuration contract for configuring the second chain, and when the transaction type of the configuration transaction is a non-blocking transaction type, the configuration transaction may be written into the chain management configuration contract of the second chain, and then the non-blocking transaction configuration method in the chain management configuration contract of the second chain is called to execute the configuration transaction, so as to obtain a chain identifier and a second cross-chain configuration item of the second chain indicated by the configuration transaction, and generate a second configuration transaction identifier corresponding to the configuration transaction based on the chain identifier and the second cross-chain configuration item of the second chain.

When the target chain is the third chain, the target chain management configuration contract comprises a chain management configuration contract for configuring the third chain, when the transaction type of the configuration transaction is a non-blocking transaction type, the configuration transaction can be written into the chain management configuration contract of the third chain, then a non-blocking transaction configuration method in the chain management configuration contract of the third chain is called to execute the configuration transaction, the chain identification and the second cross-chain configuration item of the third chain indicated by the configuration transaction are obtained, and a second configuration transaction identification corresponding to the configuration transaction is generated based on the chain identification and the second cross-chain configuration item of the third chain.

When the target link is a service sub-link, the target link management configuration contract comprises a sub-link management configuration contract for configuring the service sub-link, when the transaction type of the configuration transaction is a non-blocking transaction type, the configuration transaction can be written into the sub-link management configuration contract, then a non-blocking transaction configuration method in the sub-link management configuration contract is called to execute the configuration transaction, the link identification of the service sub-link indicated by the configuration transaction is obtained, and a second configuration transaction identification corresponding to the configuration transaction is generated based on the link identification of the service sub-link.

Step S507, receiving a second locking statement transaction sent by a cross-chain relay; the second lock claim transaction is determined by the cross-chain relay upon detecting that the target chain is in a second traffic lock state.

Wherein it should be understood. When the cross-chain relay detects that the target chain is in a second service locking state, a second locking claim transaction can be generated based on the second service locking state, and the second locking claim transaction can be sent to the cross-chain relay. Accordingly, the first consensus node may receive a second lock claim transaction sent across chain relays. The second lock declaration transaction may be used to declare that the target chain has been successfully locked, which target chain cannot be in normal traffic, or to declare that the second configuration transaction identification is successfully locked, i.e., to let the first consensus node associated with the first chain determine that the state of the configuration transaction corresponding to the second configuration transaction identification is in the second transaction locked state.

Step S508, when the state of the configuration transaction corresponding to the second configuration transaction identifier is determined to be the second transaction locking state based on the second locking statement transaction, generating second transaction locking information corresponding to the second locking statement transaction, and writing the second transaction locking information into the first chain.

It may be understood that the first consensus node may determine, based on the second lock claim transaction, that the state of the configuration transaction corresponding to the second configuration transaction identifier is a second transaction locking state, and when determining that the state of the configuration transaction corresponding to the second configuration transaction identifier is the second transaction locking state, generate second transaction locking information corresponding to the second lock claim transaction, package the second transaction locking information into a block, perform consensus through other consensus nodes in the first chain network, and then write the block into the first chain after the consensus passes. The second transaction locking information may be used to indicate that the resource associated with the configuration transaction has been locked on the target chain where normal traffic is temporarily disabled. Wherein it should be understood that the configuration resources that need to configure the target chain are indicated in the second cross-chain configuration item.

In the embodiment of the application, the first consensus node on the first chain can receive the configuration transaction for configuring the target chain in a cross-chain manner, generate a corresponding configuration transaction identifier according to the transaction type of the configuration transaction (such as the first configuration transaction identifier is correspondingly generated according to the blocking type of the transaction and the second configuration transaction identifier is correspondingly generated according to the non-blocking type of the transaction), then enable the target consensus node to acquire a corresponding configuration lock (the blocking type chain configuration lock or the non-blocking type chain configuration lock) through the corresponding configuration transaction identifier, lock the service state on the target chain through the corresponding configuration lock, and configure the cross-chain configuration item configured for the target chain on the first chain to the target chain through the cross-chain relay after locking the service state of the target chain. It can be seen that, in the embodiment of the present application, the configuration information of the other chains can be uniformly managed through the first consensus node (for example, 10a shown in fig. 1) on the first chain, so as to ensure the consistency of the configuration information on the chains. Meanwhile, when the business state of the target chain is locked, the first consensus node can generate corresponding transaction locking information and write the corresponding transaction locking information into the first chain, so that the scrutiny and traceability of the configuration of the target chain can be effectively ensured; in addition, a configuration mechanism such as a configuration lock is introduced, so that consistency and reliability of configuration information on each blockchain independent of each other can be ensured.

Further, referring to fig. 6, fig. 6 is a schematic diagram of a multi-block chain configuration method according to an embodiment of the present application, where the multi-block chain includes a first chain and a target chain; the method is performed by a cross-chain relay; the cross-chain relay is used for isolating a first chain network corresponding to the first chain and a target chain network corresponding to the target chain. The method may specifically include the following steps S601 to S604.

Step S601, when a first configuration transaction identifier corresponding to a configuration transaction on a first chain is detected, a first configuration lock acquisition transaction is sent to a target consensus node in a target chain network; the first configuration transaction identifier is generated by calling a management configuration contract on the first chain to execute a configuration transaction when the transaction type of the configuration transaction in the configuration transaction of the first consensus node in the first chain network is a blocking transaction type, and the configuration transaction is sent by a management object requesting to execute the configuration transaction; the first configuration lock acquisition transaction is used for indicating the target consensus node to acquire a blocked chain configuration lock corresponding to the blocked transaction type from a chain configuration contract on the target chain, and the service state of the target chain is configured into a first service locking state through the blocked chain configuration lock.

It may be understood that the configuration transaction includes a plurality of chain identifiers of the target chain, and one cross-chain relay according to the embodiment of the present application may correspond to one or more configuration transaction identifiers, that is, one cross-chain relay may forward a transaction associated with a corresponding configuration transaction. It should be appreciated that only the cross-chain relay to which the first configuration transaction identifier corresponds may forward the transaction associated with the first configuration transaction identifier.

Specifically, when the cross-link relay detects a first configuration transaction identifier corresponding to a configuration transaction on a first link, a first configuration lock acquisition transaction can be generated based on the first configuration transaction identifier, the first configuration lock acquisition transaction is sent to a target consensus node in a target link network, the target consensus node in the target link network can acquire a blocking link configuration lock corresponding to a blocking transaction type from a link configuration contract on the target link according to the first configuration lock acquisition transaction, and then the service state of the target link is configured to be a first service locking state through the blocking link configuration lock.

It can be understood that the link configuration contract of the target link may include two contract locks, namely a blocking link configuration lock and a non-blocking link configuration lock, and the blocking link configuration lock is adopted to configure the service state on the target link into a first service locking state, and normal service cannot be continued on the target link in the first service locking state, so that a new block is generated, and normal service can be restored only when the first cross-link configuration item configured for the target link is configured to the target link. Thus, when the first cross-link configuration item is configured to the target chain in a cross-link manner, the first cross-link configuration item to be configured can be configured to the target chain completely and synchronously through the blocking type chain configuration lock.

It will be appreciated that with the non-blocking chain configuration lock, a block buffer height may be provided that may be used to characterize the maximum separation height of the resulting blocks on the target chain before the traffic state of the target chain is configured to the second traffic lock state by the non-blocking chain configuration lock. That is, normal traffic on the target chain may be allowed to occur, creating a new block, before the traffic state on the target chain is configured to the second traffic lock state. And when the interval height of the obtained blocks on the target chain reaches the block buffer height, the service state of the target chain is configured into a second service locking state. For example, when the block buffer height is 100, and the space height of a new block generated on the target chain (for example, the space height of a block 1, a block 2 and a block 3 generated on the target chain in sequence refers to the height between the block 1 and the block 3) reaches 100, the traffic state of the target chain can be configured to be a second traffic locking state, and at this time, the target chain stops performing normal traffic and is not allowed to generate a new block. The on-link traffic can be restored only by waiting for the cross-link configuration items configured by the target link to be configured to the target link. By configuring the lock with a non-blocking chain, seamless configuration modification can be achieved, which is not perceived by the user, providing a better user experience.

It should be appreciated that configuring the traffic state on the target chain to a traffic lock state (e.g., the first traffic lock state described above) refers to locking resources or parameters on the target chain that are associated with the configuration transaction. When the target chain network acquires the blocked chain configuration lock based on the first configuration lock acquisition transaction, other configuration transaction identifiers cannot acquire any configuration lock (namely, the blocked chain configuration lock and the non-blocked chain configuration lock cannot be acquired), and only the blocked chain configuration lock is released, and the other configuration transaction identifiers cannot acquire the configuration lock.

Optionally, an accumulated lock duration threshold is set for the blocking chain configuration lock, and the accumulated lock duration threshold may be set according to requirements, for example, the accumulated lock duration threshold may be 1 hour, 30 minutes, two days, and so on. By such an accumulated lock duration threshold, it is avoided that the blocking chain configuration lock is always occupied by the target chain and cannot be used for other configuration transactions. Specifically, the cross-link relay may accumulate a chain locking time length of the target chain in the first service locking state, and send a timeout release lock transaction to the target consensus node when the chain locking time length reaches an accumulated locking time length threshold of the blocking chain configuration lock, where the timeout release lock transaction may be used to instruct the target consensus node to invoke a lock release method in the chain configuration contract to release the blocking chain configuration lock, and change the service state of the target chain from the first service locking state to the service unlocking state. It will be appreciated that the cross-chain relay may begin accumulating the chain lock duration from the beginning of the detection of the target chain being in the first traffic lock state until the accumulated chain lock duration reaches the accumulated lock duration threshold, and may send a timeout release lock transaction to the target consensus node. It should be appreciated that any configuration lock and timeout mechanism cannot be obtained by using the other configuration transaction identifiers, so that the consistency of configuration modification under multi-chain concurrency can be ensured, and the safety of metadata on the chain is ensured.

Step S602, when the target chain is detected to be in a first service locking state, a first locking statement transaction is sent to a first consensus node; the first locking claim transaction is used for indicating the first consensus node to generate first transaction locking information corresponding to the first locking claim transaction for writing the first chain when the state of the configuration transaction corresponding to the configuration transaction identifier is determined to be the first transaction locking state based on the first locking claim transaction.

It should be understood that, the target chain in the first service locking state cannot perform the normal service, and the target chain not in the first service locking state may perform the normal service. Under the condition, the cross-link relay can continuously send the transaction data to the target consensus node, and if the target consensus node in the target link cannot package the transaction data into blocks and does not return an execution result for the transaction data to the cross-link relay, the cross-link relay can detect that the target link is in a first service locking state. If the target consensus node in the target chain packages the transaction data into blocks, writes the blocks into the target chain after consensus of other consensus nodes on the target chain, and simultaneously returns an execution result for the transaction data to the cross-chain relay, the cross-chain relay can detect that the target chain is not in the first service locking state.

It may be understood that when the target chain is detected not to be in the first service locking state, the cross-chain relay may send a first locking failure transaction to the first consensus node, where the first locking failure transaction may be used to declare that the first configuration transaction identifier fails to lock, so that when the first consensus node in the first chain network determines, based on the first locking failure transaction, that the state of the configuration transaction corresponding to the first configuration transaction identifier is not the first transaction locking state, first transaction locking failure information corresponding to the first locking failure transaction written into the first chain is generated. It should be appreciated that the first transaction lock failure information is used to indicate that the target chain has failed to lock, and the management object may obtain the first transaction lock failure information from the first chain, so as to know that the configuration modification transaction cannot be submitted currently to implement the synchronous configuration.

Optionally, when detecting that the target chain is not in the first traffic lock state, the cross-chain relay may send a first lock failure release lock transaction to the target consensus node, where the first lock failure release lock transaction is used to instruct the target consensus node to invoke a lock release method in a chain configuration contract on the target chain to release the blocking chain configuration lock.

Step S603, when a configuration modification transaction on a first chain is detected, acquiring a first cross-chain configuration item in the configuration modification transaction; the configuration modification transaction is sent by the management object based on the first transaction locking information on the first chain.

Wherein, it can be understood that the management object can send the configuration modification transaction to the first consensus node in the first chain network based on the first transaction locking information, and the cross-chain relay can detect whether the configuration modification transaction on the first chain exists, and when the configuration modification transaction on the first chain is detected, a first cross-chain configuration item in the configuration modification transaction can be obtained.

Step S604, the first cross-link configuration item is cross-link configured to the target link, so that the target consensus node unlocks the target link in the first service locking state through the blocking-type link configuration lock.

It may be understood that the step of step-configuring the first step-link configuration item to the target link means step-relaying the first step-link configuration item to the target link, and then the target link may write the first step-link configuration item into a link configuration contract of the target link, and unlock the target link in the first service locking state through the blocking link configuration lock after writing the link configuration contract of the target link, thereby recovering normal service on the target link.

Alternatively, the cross-linking of the first cross-linking configuration item to the target chain may be in the form of a transaction. Specifically, the cross-link relay may construct a first release lock transaction based on a first cross-link configuration item, where the first lock release transaction (command & Unclock) includes the first cross-link configuration item, and the first release lock transaction is used to instruct the target consensus node to invoke a lock release method in the link configuration contract to release the blocked link configuration lock when writing the first cross-link configuration item into the link configuration contract, and change the service state of the target link from the first service locking state to the service unlocking state. The target chain in the service unlocking state can perform normal service.

It should be noted that only the cross-link relay corresponding to the first configuration transaction identifier can unlock the blocked link configuration lock in the target link, that is, when the first lock release transaction is sent to the target consensus node, the first configuration transaction identifier may be carried in the first lock release transaction, so that the target consensus node may write the first release lock transaction into the link configuration contract in the target link based on the first configuration transaction identifier, and invoke the lock release method in the link configuration contract to release the blocked link configuration lock.

In the embodiment of the application, a first consensus node on a first chain can receive a configuration transaction for configuring the target chain across chains, and execute the configuration transaction when the transaction type of the configuration transaction is a blocking transaction type, and generate a first configuration transaction identifier corresponding to the configuration transaction; and then, the target consensus node can acquire a blocking type chain configuration lock corresponding to the blocking type transaction type through the first configuration transaction identifier, lock the service state of the target chain through the blocking type chain configuration lock, and configure the cross-chain configuration item configured for the target chain on the first chain to the target chain through the cross-chain relay after locking the service state of the target chain. Therefore, the embodiment of the application can uniformly manage the configuration information of other chains through the first consensus node on the first chain so as to ensure the consistency of the configuration information on the chains. In addition, a configuration mechanism such as a blocking chain configuration lock is introduced, so that synchronous validation of configuration can be realized, strict execution of business logic is ensured, and consistency and reliability of configuration information on each block chain independent of each other can be ensured.

Further, referring to fig. 7, fig. 7 is a schematic diagram of a multi-block chain configuration method according to an embodiment of the present application, wherein the multi-block chain includes a first chain and a target chain; the method is performed by a cross-chain relay; the cross-chain relay is used for isolating a first chain network corresponding to the first chain and a target chain network corresponding to the target chain. The method may specifically include the following steps S701 to S703.

Step S701, when a second configuration transaction identifier corresponding to a configuration transaction on a first chain is detected, a second configuration lock acquisition transaction is sent to a target consensus node in a target chain network, wherein the second configuration transaction identifier is generated by calling a management configuration contract on the first chain to execute the configuration transaction when the transaction type of the configuration transaction of the first consensus node in the first chain network is a non-blocking transaction type, and the configuration transaction is sent by a management object requesting to execute the configuration transaction; the second configuration lock acquisition transaction is used for indicating the target consensus node to acquire a non-blocking chain configuration lock corresponding to the non-blocking transaction type from a chain configuration contract on the target chain, and the service state of the target chain is configured into a second service locking state through the non-blocking chain configuration lock. The configuration transaction includes a chain identification of the target chain and a second cross-chain configuration item associated with the configuration transaction. The second cross-chain configuration item includes content that needs to be configured for the target chain, e.g., the second cross-chain configuration item may be configured for the block size generated for the first chain.

Specifically, when the cross-link relay detects a second configuration transaction identifier corresponding to the configuration transaction on the first link, a second configuration lock acquisition transaction can be generated based on the second configuration transaction identifier, the second configuration lock acquisition transaction is sent to a target consensus node in the target link network, the target consensus node in the target link network can acquire a non-blocking link configuration lock corresponding to the non-blocking transaction type from a link configuration contract on the target link according to the second configuration lock acquisition transaction, and then the service state of the target link can be configured into a second service locking state through the non-blocking link configuration lock.

It can be understood that the link configuration contracts of the target link may include two contract locks, namely a blocking link configuration lock and a non-blocking link configuration lock, and the blocking link configuration lock is adopted to configure the service state on the target link into a first service locking state, while the target link in the first service locking state cannot generate a new block, stop the normal service, and restore the normal service only when the first cross-link configuration item configured for the target link is configured to the target link.

It will be appreciated that with non-blocking chain configuration locks, a block buffer height may be provided. That is, the target consensus node in the target chain needs to acquire the block cache height while acquiring the non-blocking chain configuration. The block buffer height may be used to characterize a maximum space height of the resulting blocks on the target chain before the traffic state of the target chain is configured to the second traffic lock state by the non-blocking chain configuration lock. That is, normal traffic may be performed on the target chain before the traffic state on the target chain is configured to the second traffic lock state, and the traffic state of the target chain is configured to the second traffic lock state when the space height of the blocks obtained on the target chain reaches the block buffer height. Normal traffic can be restored only if the second cross-link configuration item configured by the target link is waiting to be configured to the target link. By configuring the lock with a non-blocking chain, seamless configuration modification may be achieved, providing a better user experience.

It should be appreciated that configuring the traffic state on the target chain to a traffic lock state (e.g., the second traffic lock state described above) refers to locking resources or parameters on the target chain that are associated with the configuration transaction. When the target chain network acquires the non-blocking chain configuration lock based on the second configuration lock acquisition transaction, the other configuration transaction identifications cannot acquire any configuration lock (i.e., cannot acquire the blocking chain configuration lock and the non-blocking chain configuration lock), and only after the non-blocking chain configuration lock is released, the other configuration transaction identifications cannot acquire the configuration lock.

It should be understood that, before the service state of the target chain is configured to be the second service state by the non-blocking chain configuration lock, the cross-chain relay may send transaction data to a target consensus node in the target chain network, the target consensus node may package the received transaction data into blocks and perform consensus by other consensus nodes in the target chain, after the consensus passes, write the blocks into the target chain, and return an execution result of the transaction data to the cross-chain relay, and the target consensus node may continuously determine an interval height of a block obtained on the target chain, and when the interval height of the block obtained on the target chain reaches the block buffer height, may configure the service state of the target chain to be the second service locking state by the non-blocking chain configuration lock.

Step S702, when the target chain is detected to be in a second service locking state, a second locking statement transaction is sent to the first consensus node; the second lock claim transaction is used for indicating the first consensus node to generate second transaction locking information corresponding to a second lock claim transaction for writing the first chain when the state of the configuration transaction corresponding to the configuration transaction identifier is determined to be the second transaction locking state based on the second lock claim transaction.

It should be understood that, the target chain in the second service locking state is temporarily unable to perform normal service, and normal service may be performed on the target chain not in the second service locking state. Under the condition, the cross-link relay still transmits the transaction data to the target consensus node, and if the target consensus node cannot package the received transaction data into blocks or return the execution result of the transaction data to the cross-link relay, the target link can be detected to be in the second service locking state. If the target consensus node in the target chain can also execute the package of the transaction data into blocks and returns an execution result for the transaction data to the cross-chain relay, the target chain can be detected not to be in the second service locking state.

It may be appreciated that when the target chain is detected not to be in the second service locking state, the cross-chain relay may send a second locking failure transaction to the first consensus node, where the second locking failure transaction may be used to declare that the second configuration transaction identifier fails to lock, so that the first consensus node in the first chain network generates second transaction locking failure information corresponding to the second locking failure transaction written into the first chain when determining, based on the second locking failure transaction, that the state of the configuration transaction corresponding to the second configuration transaction identifier is not in the second transaction locking state. It should be appreciated that the second transaction lock failure information is used to indicate that the target chain has failed to lock, and the management object may obtain the second transaction lock failure information from the first chain, and determine that the target chain cannot be currently configured across chains based on the second transaction lock failure information.

Optionally, when the target link is detected not to be in the second service lock state, the cross-link relay may send a second lock failure release lock transaction to the target consensus node, where the second lock failure release lock transaction is used to instruct the target consensus node to invoke a lock release method in a link configuration contract on the target link to release the non-blocking link configuration lock.

Step S703, configuring the second cross-link configuration item to the target link in a cross-link manner, so that the target consensus node unlocks the target link in the second service locking state through the non-blocking link configuration lock.

It can be understood that the cross-link relay does not need to detect whether a configuration modification transaction exists on the management link, and when the target link is detected to be in the second service locking state, the configuration transaction contains a second cross-link configuration direction associated with the configuration transaction, and the cross-link relay can directly cross-link configure the two cross-link configuration items to the target link. Specifically, the cross-link relay may cross-link relay the second cross-link configuration item to the target link, and the target link may write the second cross-link configuration item into a link configuration contract of the target link, and unlock the target link in the second service locking state through the non-blocking link configuration lock after writing the link configuration contract of the target link, thereby recovering the normal service on the target link.

It should be appreciated that the target chain is cross-chain configured by either the blocking chain configuration lock or the non-blocking chain configuration lock, which differs primarily in that there are two phases of cross-chain configuration of the target chain by the blocking chain configuration lock (i.e., a first phase configures the traffic state of the target chain to be a first traffic lock state for initiating a configuration transaction, a second phase initiates a modify configuration transaction while the target chain is in the first traffic lock state, and configures a first cross-chain configuration item in the modify configuration transaction to the target chain by cross-chain relay). As in fig. 6 described above, the first stage may correspond to steps S601-S602, and the second stage is steps S603-S604. The synchronous effect of the cross-chain configuration can be achieved through two stages of cross-chain configuration of the blocking-type chain configuration lock on the target chain, better consistency is provided, and the target chain is temporarily unavailable. When the target chain is configured in a cross-chain manner through the non-blocking chain configuration lock, only one stage is needed, namely, a configuration transaction is initiated to configure the service state of the target chain into a second service locking state, and when the target chain is detected to be in the second service locking state, the cross-chain relay can directly configure a second cross-chain configuration item in the configuration transaction to the target chain; the target chain is configured in a non-blocking mode through the non-blocking chain configuration lock, so that the target chain is configured in a non-influencing mode, a user is not aware of the configuration, and more convenient and friendly user experience is provided.

In the embodiment of the application, the first consensus node on the first chain can execute the configuration transaction when receiving the configuration transaction for configuring the target chain across chains and determining that the transaction type of the configuration transaction is a non-blocking transaction type, and generate a second configuration transaction identifier corresponding to the configuration transaction; the inter-link relay can enable the target consensus node to acquire a non-blocking link configuration lock corresponding to the non-blocking transaction type through the second configuration transaction identifier, and lock the service state of the target link through the non-blocking link configuration lock; and then after the business state of the target chain is locked, configuring a second cross-chain configuration item configured for the target chain on the first chain to the target chain through cross-chain relay. Therefore, the embodiment of the application can uniformly manage the configuration information of other chains through the first consensus node on the first chain so as to ensure the consistency of the configuration information on the chains. In addition, a configuration mechanism such as a non-blocking chain configuration lock is introduced, so that seamless configuration modification can be realized, better user experience is provided, and consistency and reliability of configuration information on each block chain independent of each other can be ensured.

Further, referring to fig. 8, fig. 8 is a schematic diagram of a multi-blockchain-based cross-chain configuration method according to an embodiment of the present application, where a multi-blockchain includes a first chain and a target chain, and as shown in fig. 8, the method may be performed by a first consensus node in a first chain network corresponding to the first chain, a cross-chain relay, and a target consensus node in a target chain network corresponding to the target chain, and the cross-chain relay may be used to isolate the first chain network and the target chain network. The method may specifically include the following steps S801 to S813.

Step S801, a first consensus node receives a configuration transaction for configuring a target chain across chains, which is sent by a management object based on the configuration transaction.

Step S802, a first consensus node determines a transaction type of a configuration transaction.

In step S803, when the transaction type of the configuration transaction is a blocking type transaction type, the first consensus node invokes a chain management configuration contract on the first chain to execute the configuration transaction, and generates a first configuration transaction identifier corresponding to the configuration transaction.

Step S804, detecting a first configuration transaction identifier corresponding to the configuration transaction on the first link by the inter-link relay.

Step S805, when a first configuration transaction identifier corresponding to a configuration transaction on a first chain is detected, a cross-chain relay sends a first configuration lock acquisition transaction to a target consensus node in a target chain network.

Step S806, the target consensus node acquires a blocked link configuration lock corresponding to the blocked transaction type from the link configuration contract on the target link, and configures the service state of the target link into a first service locking state through the blocked link configuration lock.

It should be appreciated that the target consensus node receives a first configuration lock acquisition transaction sent across the chain relay and then acquires a blocked chain configuration lock corresponding to the blocked transaction type from a chain configuration contract on the target chain in accordance with the first configuration lock acquisition transaction.

Step S807, when the inter-link relay detects that the target link is in a first service locking state, a first locking statement transaction is sent to a first consensus node.

Wherein it should be appreciated that the cross-chain relay, upon detecting that the target chain is in a first traffic lock state, may generate a first lock declaration transaction based on the first traffic lock state, the first lock declaration transaction may be used to declare that the target chain has been successfully locked, or to declare that the first configuration transaction identifies that the lock was successful.

In step S808, when the first consensus node determines, based on the first locking claim transaction, that the state of the configuration transaction corresponding to the configuration transaction identifier is the first transaction locking state, first transaction locking information corresponding to the first locking claim transaction is generated, and the first transaction locking information is written into the first chain.

It should be understood that, when the first consensus node receives the first locking declaration transaction sent by the cross-chain relay, then determines that the state of the configuration transaction corresponding to the configuration transaction identifier is the first transaction locking state based on the first locking declaration transaction, and when the state of the configuration transaction corresponding to the configuration transaction identifier is determined to be the first transaction locking state, first transaction locking information can be generated based on the first locking declaration transaction, then the first transaction locking information is commonly known by other consensus nodes except for the target consensus node in the first chain, and after the common identification passes, a block is generated according to the first transaction locking information and written into the first chain.

Step S809, the first consensus node receives a configuration modification transaction by the management object based on the first transaction locking information transmission on the first chain.

Step 810, when obtaining a configuration modification transaction sent by the management object based on the first transaction locking information on the first chain, the first consensus node obtains a first cross-chain configuration item in the configuration modification transaction.

Step S811, when the cross-link relay detects a configuration modification transaction on the first link, the cross-link relay acquires a first cross-link configuration item in the configuration modification transaction.

Step S812, the cross-link relay cross-links the first cross-link configuration item to the target link.

Step S813, the target consensus node unlocks a target chain in a first service locking state through a blocking chain configuration lock.

Alternatively, it should be appreciated that an accumulated lock duration threshold may be set for the blocked chain configuration lock, by which it may be avoided that the blocked chain configuration lock is always occupied by the target chain and cannot be used for other configuration transactions. The target consensus node can accumulate the chain locking time length of the target chain in the first service locking state, and when the accumulated chain locking time length reaches the accumulated locking time length threshold value of the blocking type chain configuration lock, the target consensus node calls a lock release method to release the blocking type chain configuration lock, and changes the service state of the target chain from the first service locking state to the service unlocking state.

Alternatively, the cross-chain relay may accumulate the chain lock time length of the target chain detected to be in the first traffic lock state, and when the accumulated chain lock time length reaches the accumulated lock time length threshold of the blocking chain configuration lock, send a timeout release lock transaction to the target consensus node. After receiving the overtime release lock transaction, the target consensus node calls a lock release method to release the blocked chain configuration lock, and changes the service state of the target chain from a first service locking state to a service unlocking state.

In the embodiment of the application, a first consensus node on a first chain can receive a configuration transaction for cross-chain configuration target chain, and when the transaction type of the configuration transaction is a blocking transaction type, the configuration transaction is executed to generate a first configuration transaction identifier corresponding to the configuration transaction; then, the target consensus node acquires a blocking chain configuration lock corresponding to the blocking type of the transaction through the first configuration transaction identifier, and locks the service state of the target chain through the blocking chain configuration lock; after the traffic state of the target chain is locked, the cross-chain configuration item configured for the target chain on the first chain is configured to the target chain through cross-chain relay. Therefore, the embodiment of the application can uniformly manage the configuration information of other chains through the first consensus node on the first chain so as to ensure the consistency of the configuration information on the chains. Meanwhile, when the business state of the target chain is locked, the first chain can generate corresponding transaction locking information and write the corresponding transaction locking information into the first chain, so that the scrutiny and traceability of the configuration of the target chain can be effectively ensured; in addition, a configuration mechanism such as a blocking chain configuration lock is introduced, so that synchronous validation of configuration can be realized, strict execution of business logic is ensured, and consistency and reliability of configuration information on each block chain independent of each other can be ensured.

Further, referring to fig. 9, fig. 9 is a schematic diagram of a multi-blockchain-based cross-chain configuration method according to an embodiment of the present application, where a multi-blockchain includes a first chain and a target chain, and as shown in fig. 9, the method may be performed by a first consensus node in a first chain network corresponding to the first chain, a cross-chain relay, and a target consensus node in a target chain network corresponding to the target chain, and the cross-chain relay may be used to isolate the first chain network and the target chain network. The method may specifically include the following step S901 to step S910.

Step S901, a first consensus node receives a configuration transaction for configuring a target chain across chains, which is sent by a management object based on the configuration transaction.

Step S902, the first consensus node determines a transaction type of the configuration transaction.

In step S903, when the transaction type of the configuration transaction is a non-blocking transaction type, the first consensus node invokes a chain management configuration contract on the first chain to execute the configuration transaction, and generates a second configuration transaction identifier corresponding to the configuration transaction.

Step S904, when a second configuration transaction identifier corresponding to the configuration transaction on the first chain is detected, a second configuration lock acquisition transaction is sent to a target consensus node in the target chain network.

Step S905, when a second configuration transaction identifier corresponding to the configuration transaction on the first chain is detected, sending a second configuration lock acquisition transaction to a target consensus node in the target chain network.

Step S906, the target consensus node acquires a non-blocking type chain configuration lock corresponding to the non-blocking type transaction type from a chain configuration contract on the target chain, and configures the service state of the target chain into a second service locking state through the non-blocking type chain configuration lock.

It should be appreciated that the target consensus node receives the two configuration lock acquisition transactions sent across the chain relay and then acquires the non-blocking chain configuration lock corresponding to the non-blocking transaction type from the chain configuration contract on the target chain according to the second configuration lock acquisition transaction.

Step S907, when the inter-link relay detects that the target link is in the second service locking state, the inter-link relay sends a second locking statement transaction to the first consensus node.

In step S908, when the first consensus node determines, based on the second locking claim transaction, that the state of the configuration transaction corresponding to the configuration transaction identifier is the second transaction locking state, second transaction locking information corresponding to the second locking claim transaction is generated, and the second transaction locking information corresponding to the second locking claim transaction is written into the first chain.

It should be understood that, when the first consensus node receives the second locking claim transaction sent by the cross-chain relay, then determines that the state of the configuration transaction corresponding to the configuration transaction identifier is a second transaction locking state based on the second locking claim transaction, and when the state of the configuration transaction corresponding to the configuration transaction identifier is determined to be the second transaction locking state, second transaction locking information can be generated based on the second locking claim transaction, the second transaction locking information can be generated into a block, and the block containing the traumatic transaction locking information can be written into the first chain after passing through the consensus of other consensus nodes on the first chain.

Step S909, the cross-chain relay cross-configures the second cross-chain configuration item associated with the configuration transaction to the target chain.

Step S910, the target consensus node unlocks the target link in the second service locking state through the non-blocking link configuration lock.

In the embodiment of the application, a first consensus node on a first chain can receive a configuration transaction for cross-chain configuration target chain, and when the transaction type of the configuration transaction is a non-blocking transaction type, the configuration transaction is executed to generate a second configuration transaction identifier corresponding to the configuration transaction; then, the cross-link relay can enable the target consensus node to acquire a non-blocking link configuration lock corresponding to the non-blocking transaction type through the first configuration transaction identifier, and lock the service state of the target link through the non-blocking link configuration lock; after locking the traffic state of the target chain, a second cross-chain configuration item configured for the target chain on the first chain may be configured to the target chain through cross-chain relay. Therefore, the embodiment of the application can uniformly manage the configuration information of other chains through the first consensus node on the first chain so as to ensure the consistency of the configuration information on the chains. Meanwhile, when the business state of the target chain is locked, the first consensus node can generate corresponding transaction locking information and write the corresponding transaction locking information into the first chain, so that the scrutiny and traceability of the configuration process of the target chain can be effectively ensured; in addition, a configuration mechanism such as a non-blocking chain configuration lock is introduced, so that seamless configuration modification is realized, user experience is improved, and consistency and reliability of configuration information on each block chain independent of each other can be ensured.

Further, referring to fig. 10, fig. 10 is a schematic structural diagram of a multi-blockchain-based cross-chain configuration device according to the present application. As shown in fig. 10, a multi-blockchain based cross-chain configuration device 1 is operable on a first consensus node, the multi-blockchain including a first chain associated with the first consensus node and a target chain to be cross-chain configured; the first chain network corresponding to the first chain and the target chain network corresponding to the target chain are isolated by cross-chain relay, and the first consensus node may be any blockchain node in the first chain network (for example, the consensus network 100 a), for example, the first consensus node may be the consensus node 10a in the embodiment corresponding to fig. 1. It should be appreciated that the multi-blockchain-based cross-chain configuration device 1 may be a computer program (including program code) running in a blockchain node (e.g., the aforementioned consensus node 10 a), for example, the multi-blockchain-based cross-chain configuration device 1 may be an application software; it will be appreciated that the multi-blockchain-based cross-chain configuration device 1 may be used to perform the corresponding steps in the method provided by embodiments of the present application. As shown in fig. 10, the multi-blockchain-based cross-chain configuration device 1 may include: the device comprises a determining module 11, a calling module 12, a receiving module 13, a generating module 14, a first obtaining module 15 and a first configuring module 16;

A determining module 11, configured to determine a transaction type of a configuration transaction when receiving a configuration transaction sent by a management object based on the configuration transaction and used for cross-chain configuration target chain;

The calling module 12 is configured to call the chain management configuration contract on the first chain to execute the configuration transaction when the transaction type of the configuration transaction is the blocking type transaction type, and generate a first configuration transaction identifier corresponding to the configuration transaction; the first configuration transaction identifier is used for indicating the cross-chain relay to send a first configuration lock acquisition transaction to a target consensus node associated with a target chain; the first configuration lock acquisition transaction is used for indicating the target consensus node to acquire a blocked chain configuration lock corresponding to the blocked transaction type from a chain configuration contract on the target chain, and the service state of the target chain is configured into a first service locking state through the blocked chain configuration lock;

a receiving module 13 for receiving the first locking statement transaction transmitted by the cross-chain relay; the first lock claim transaction is determined when the cross-chain relay detects that the target chain is in a first traffic lock state;

The generating module 14 is configured to generate first transaction locking information corresponding to the first locking claim transaction and write the first transaction locking information into the first chain when determining that the state of the configuration transaction corresponding to the first configuration transaction identifier is the first transaction locking state based on the first locking claim transaction;

A first obtaining module 15, configured to obtain a first cross-link configuration item in a configuration modification transaction when obtaining a configuration modification transaction sent by a management object based on first transaction locking information on a first link;

the first configuration module 16 is configured to cross-link configure the first cross-link configuration item to the target link through the cross-link relay, so that the target consensus node unlocks the target link in the first service locking state through the blocking-type link configuration lock.

The calling module 12 includes:

A calling subunit 121, configured to write the configuration transaction into the platform configuration contract, call the blocking transaction configuration method in the platform configuration contract, and execute the configuration transaction to obtain the chain identifiers of the multiple target chains indicated by the configuration transaction;

The generating subunit 122 is configured to generate, based on the identifiers of the multiple target chains, a first configuration transaction identifier corresponding to the configuration transaction.

The calling module 12 is further configured to call the platform configuration contract on the first chain to execute the configuration transaction when the transaction type of the configuration transaction is a non-blocking transaction type, and generate a second configuration transaction identifier corresponding to the configuration transaction; the second configuration transaction identifier is used for indicating the cross-chain relay to send a second configuration lock acquisition transaction to a target consensus node associated with the target chain; the second configuration lock acquisition transaction is used for indicating the target consensus node to acquire a non-blocking chain configuration lock corresponding to the non-blocking transaction type from a chain configuration contract on the target chain, and the service state of the target chain is configured into a second service locking state through the non-blocking chain configuration lock;

A receiving module 13, configured to receive a second lock claim transaction sent by the cross-chain relay; the second lock claim transaction is determined by the cross-chain relay upon detecting that the target chain is in a second traffic lock state;

The generating module 14 is further configured to generate second transaction locking information corresponding to the second locking claim transaction and write the second transaction locking information into the first chain when it is determined that the state of the configuration transaction corresponding to the second configuration transaction identifier is the second transaction locking state based on the second locking claim transaction.

Wherein the calling module 12 comprises:

A calling sub-module 121, configured to write a configuration transaction with a second cross-link configuration item into a platform configuration contract, call a non-blocking transaction configuration method in the platform configuration contract on a first link, and execute the configuration transaction to obtain a link identifier of a target link indicated in the configuration transaction and the second cross-link configuration item;

The generating sub-module 122 is configured to generate a second configuration transaction identifier corresponding to the configuration transaction based on the chain identifier of the target chain and the second cross-chain configuration item.

The specific implementation manners of the determining module 11, the calling module 12, the receiving module 13, the generating module 14, the first obtaining module 15, and the first configuring module 16 may refer to the description of the step S401 to the step S405 in the embodiment corresponding to fig. 4 and the description of the step S501 to the step S508 in the embodiment corresponding to fig. 5, and will not be further described herein. It should be understood that the description of the beneficial effects obtained by the same method will not be repeated.

Further, referring to fig. 11, fig. 11 is a schematic structural diagram of a multi-blockchain-based cross-chain configuration device according to the present application. As shown in fig. 11, a multi-blockchain based cross-chain configuration device 2 may operate on a cross-chain relay, the multi-blockchain including a first chain associated with a first consensus node and a target chain to be cross-chain configured; the cross-chain relay is used to isolate the first chain network corresponding to the first chain from the target chain network corresponding to the target chain, it should be understood that the multi-blockchain-based cross-chain configuration device 2 may be a computer program (including program code) running in the cross-chain relay, for example, the multi-blockchain-based cross-chain configuration device 2 may be an application software; it will be appreciated that the multi-blockchain-based cross-chain configuration device 2 may be used to perform the corresponding steps in the methods provided by embodiments of the present application. As shown in fig. 11, the multi-blockchain-based cross-chain configuration device 2 may include: a transmitting module 21, a second acquiring module 22 and a second configuring module 23;

A sending module 21, configured to send a first configuration lock acquisition transaction to a target consensus node in a target chain network when a first configuration transaction identifier corresponding to a configuration transaction on a first chain is detected; the first configuration transaction identifier is generated by calling a chain management configuration contract on the first chain to execute a configuration transaction when the transaction type of the configuration transaction of a first consensus node in the first chain network is a blocking transaction type, wherein the configuration transaction is sent by a management object requesting to execute the configuration transaction; the first configuration lock acquisition transaction is used for indicating the target consensus node to acquire a blocked chain configuration lock corresponding to the blocked transaction type from a chain configuration contract on the target chain, and the service state of the target chain is configured into a first service locking state through the blocked chain configuration lock;

The sending module 21 is further configured to send a first lock claim transaction to the first consensus node when the target chain is detected to be in the first service lock state; the first locking declaration transaction is used for indicating the first consensus node to generate first transaction locking information corresponding to a first locking declaration transaction for writing into the first chain when the state of the configuration transaction corresponding to the configuration transaction identifier is determined to be a first transaction locking state based on the first locking declaration transaction;

A second obtaining module 22, configured to obtain a first cross-chain configuration item in the configuration modification transaction when the configuration modification transaction on the first chain is detected; the configuration modification transaction is sent by the management object based on the first transaction locking information on the first chain;

A second configuration module 23, configured to cross-link the first cross-link configuration item to the target link, so that the target consensus node unlocks the target link in the first traffic locking state through the blocking link configuration lock.

Wherein the second configuration module 23 comprises:

A building unit 231 for building a first release lock transaction based on the first cross-chain configuration item; the first lock release transaction is used for indicating the target consensus node to call a lock release method in the chain configuration contract to release the blocked chain configuration lock when writing the first cross-chain configuration item into the chain configuration contract, and changing the service state of the target chain from a first service locking state to a service unlocking state;

a transmitting subunit 232, configured to transmit the first lock release transaction to the target consensus node.

Wherein, the sending module 21 is further configured to: accumulating the chain locking time length of the target chain in the first service locking state, and when the chain locking time length reaches the accumulated locking time length threshold of the blocking chain configuration lock, sending a timeout release lock transaction to the target consensus node, wherein the timeout release lock transaction is used for indicating the target consensus node to call a lock release method in a chain configuration contract on the target chain to release the blocking chain configuration lock, and changing the service state of the target chain from the first service locking state to the service unlocking state.

Wherein, the sending module 21 is further configured to: and when the target chain is detected not to be in the first service locking state, sending a first locking failure transaction to the first consensus node, and sending a first locking failure release lock transaction to the target consensus node, wherein the first locking failure release lock transaction is used for indicating the target consensus node to call a lock release method in a chain configuration contract on the target chain to release the blocking chain configuration lock.

The sending module 21 is further configured to send, when detecting a second configuration transaction identifier corresponding to a configuration transaction on the first chain, a second configuration lock acquisition transaction to a target consensus node in the target chain network, where the second configuration transaction identifier is generated by calling a management configuration contract on the first chain to execute the configuration transaction when a transaction type of the configuration transaction in the configuration transaction by the first consensus node in the first chain is a non-blocking transaction type, and the configuration transaction is sent by a management object requesting to execute the configuration transaction; the second configuration lock acquisition transaction is used for indicating the target consensus node to acquire a non-blocking chain configuration lock corresponding to the non-blocking transaction type from a chain configuration contract on the target chain, and the service state of the target chain is configured into a second service locking state through the non-blocking chain configuration lock;

The sending module 21 is further configured to send a second lock statement transaction to the first consensus node when the target chain is detected to be in the second service lock state; the second locking declaration transaction is used for indicating the first consensus node to generate second transaction locking information corresponding to a second locking declaration transaction for writing the first chain when the state of the configuration transaction corresponding to the configuration transaction identifier is determined to be a second transaction locking state based on the second locking declaration transaction;

The second configuration module 23 is further configured to cross-link the second cross-link configuration item to the target link, so that the target consensus node unlocks the target link in the second traffic locking state through the non-blocking link configuration lock.

Wherein the second configuration module 23 comprises:

A building unit 231 for building a second release lock transaction based on the second cross-chain configuration item;

A transmitting subunit 232, configured to transmit the second lock release transaction to the target consensus node; the second lock release transaction is used for indicating the target consensus node in the target chain to release the non-blocking chain configuration lock by calling a lock release method in the chain configuration contract on the target chain when the second cross-chain configuration item is written into the chain configuration contract, and changing the service state of the target chain from the second service locking state to the service unlocking state.

Wherein, the sending module 21 is further configured to:

For specific implementation manners of the sending module 21, the second obtaining module 22, and the second configuring module 23, refer to the description of the step S601 to the step S604 in the embodiment corresponding to fig. 6 and the description of the step S701 to the step S703 in the embodiment corresponding to fig. 7, which will not be further described herein. It should be understood that the description of the beneficial effects obtained by the same method will not be repeated.

Further, referring to fig. 12, fig. 12 is a schematic structural diagram of a computer device according to an embodiment of the present application. As shown in fig. 12, the computer device 1000 may be a user terminal or a server, which is not limited herein. For ease of understanding, the present application is exemplified by a computer device as a server, and the computer device 1000 may include: processor 1001, network interface 1004, and memory 1005, in addition, the computer device 1000 may further comprise: a user interface 1003, and at least one communication bus 1002. Wherein the communication bus 1002 is used to enable connected communication between these components. The user interface 1003 may also include a standard wired interface, a wireless interface, among others. The network interface 1004 may optionally include a standard wired interface, a wireless interface (e.g., WI-FI interface). The memory 1005 may be a high-speed RAM memory or a non-volatile memory (non-volatile memory), such as at least one disk memory. The memory 1005 may also optionally be at least one storage device located remotely from the processor 1001. As shown in fig. 12, an operating system, a network communication module, a user interface module, and a device control application program may be included in the memory 1005, which is one type of computer-readable storage medium.

The network interface 1004 of the computer device 1000 may also provide network communication functions. In the computer device 1000 shown in fig. 12, the network interface 1004 may provide network communication functions; while user interface 1003 is primarily used as an interface for providing input to a user; the processor 1001 may be configured to invoke the device control application stored in the memory 1005 to execute the description of the multi-blockchain-based cross-chain configuration method in the embodiment corresponding to fig. 4 to 9, and may also execute the description of the multi-blockchain-based cross-chain configuration device (i.e. the multi-blockchain-based cross-chain configuration device 1 and the multi-blockchain-based cross-chain configuration device 2) in the embodiment corresponding to fig. 10 or 11, which are not described herein. In addition, the description of the beneficial effects of the same method is omitted.

Furthermore, it should be noted here that: the embodiment of the present application further provides a computer readable storage medium, in which the aforementioned computer program executed by the multi-blockchain-based cross-chain configuration device 1 and the multi-blockchain-based cross-chain configuration device 2 is stored, and the computer program includes computer instructions, when executed by a processor, can execute the description of the multi-blockchain-based cross-chain configuration method in the embodiment corresponding to fig. 4 to 9, and therefore, the description will not be repeated here. In addition, the description of the beneficial effects of the same method is omitted. For technical details not disclosed in the embodiments of the computer-readable storage medium according to the present application, please refer to the description of the method embodiments of the present application. As an example, computer instructions may be deployed to be executed on one computing device or on multiple computing devices at one site or distributed across multiple sites and interconnected by a communication network, where the multiple computing devices distributed across multiple sites and interconnected by a communication network may constitute a blockchain system.

In addition, it should be noted that: embodiments of the present application also provide a computer program product or computer program that may include computer instructions that may be stored in a computer-readable storage medium. The processor of the computer device reads the computer instructions from the computer readable storage medium, and the processor may execute the computer instructions, so that the computer device performs the description of the multi-blockchain-based cross-chain configuration method in the embodiment corresponding to fig. 4 to 9, which will not be described herein. In addition, the description of the beneficial effects of the same method is omitted. For technical details not disclosed in the computer program product or the computer program embodiments according to the present application, reference is made to the description of the method embodiments according to the present application.

Further, referring to fig. 13, fig. 13 is a schematic diagram of a cross-chain configuration system based on multi-block chains according to an embodiment of the present application. The multi-blockchain-based cross-chain configuration system 3 may include a consensus node 3a, a cross-chain relay 3b, and a consensus node 3c; the consensus node 3a and the consensus node 3c may interact through a cross-chain relay, where the consensus node 3a may be a first consensus node in the first chain network described in the embodiment corresponding to fig. 4 to fig. 9, and the first consensus node may be any block chain node in the consensus network 100a shown in fig. 1; the consensus node 3c may be a target consensus node in the target chain network described in the embodiment corresponding to fig. 4 to fig. 9, where the target consensus node may be any blockchain node in the consensus network 200a or the consensus network 300 shown in fig. 1, and will not be described further herein; the cross-chain relay 3b may be a cross-chain relay described in the above-described embodiments corresponding to fig. 4 to 9. In addition, the description of the beneficial effects of the same method is omitted.

Those skilled in the art will appreciate that implementing all or part of the above-described methods may be accomplished by way of a computer program in hardware associated with instructions, where the program may be stored on a computer readable storage medium, and where the program, when executed, may comprise the steps of the above-described embodiments of the methods. The storage medium may be a magnetic disk, an optical disk, a Read-Only Memory (ROM), a random access Memory (Random Access Memory, RAM), or the like.

The above disclosure is only a preferred embodiment of the present invention, and it should be understood that the scope of the invention is not limited thereto, and those skilled in the art will appreciate that all or part of the procedures described above can be performed according to the equivalent changes of the claims, and still fall within the scope of the present invention.

Claims

1. A method of multi-blockchain-based cross-chain configuration, the method performed by a first consensus node, the multi-blockchain including a first chain associated with the first consensus node and a target chain to be cross-chain configured; the first chain network corresponding to the first chain and the target chain network corresponding to the target chain are isolated through cross-chain relay, and the method comprises the following steps:

when receiving a configuration transaction sent by a management object based on a configuration transaction and used for configuring the target chain in a cross-chain manner, determining the transaction type of the configuration transaction;

When the transaction type of the configuration transaction is a blocking transaction type, calling a chain management configuration contract on the first chain to execute the configuration transaction, and generating a first configuration transaction identifier corresponding to the configuration transaction; the first configuration transaction identifier is used for indicating the cross-chain relay to send a first configuration lock acquisition transaction to a target consensus node associated with the target chain; the first configuration lock acquisition transaction is used for indicating the target consensus node to acquire a blocking type chain configuration lock corresponding to the blocking type transaction from a chain configuration contract on the target chain, and the service state of the target chain is configured to be a first service locking state through the blocking type chain configuration lock;

Receiving a first locking claim transaction sent by the cross-chain relay; the first lock claim transaction is determined by the cross-chain relay upon detecting that the target chain is in the first traffic lock state;

When the state of the configuration transaction corresponding to the first configuration transaction identifier is determined to be a first transaction locking state based on the first locking declaration transaction, generating first transaction locking information corresponding to the first locking declaration transaction, and writing the first transaction locking information into the first chain;

When the management object is obtained to modify a transaction based on the configuration sent by the first transaction locking information on the first chain, a first cross-link configuration item in the configuration modification transaction is obtained, and the first cross-link configuration item is configured to the target chain in a cross-link manner through the cross-link relay, so that the target consensus node unlocks the target chain in the first service locking state through the blocking-type chain configuration lock.

2. The method of claim 1, wherein when the number of target chains is plural and the configuration resources indicated by the configuration transaction belong to a global configuration resource, a chain management configuration corresponding to the global configuration resource is in close proximity to a platform configuration contract on the first chain;

The step of calling the chain management configuration contract on the first chain to execute the configuration transaction and generating a first configuration transaction identifier corresponding to the configuration transaction comprises the following steps:

Writing the configuration transaction into the platform configuration contract, calling a blocking transaction configuration method in the platform configuration contract, and executing the configuration transaction to obtain chain identifications of a plurality of target chains indicated by the configuration transaction;

3. The method of claim 2, wherein the multi-block chain comprises a traffic backbone managed by the first consensus node through the first chain and a traffic sub-chain independent of the traffic backbone; the traffic backbone comprises one or more of a second chain and a third chain that are independent of the first chain; the sub-link consensus network corresponding to the service sub-link is formed by a consensus node in a second link network corresponding to the second link and a consensus node in a third link network corresponding to the third link; wherein the second chain network is independent of the third chain network; the service sub-chain is authorized to be created by a service object requesting to execute a target service through the first consensus node; one target service corresponds to one service sub-chain; a plurality of the target chains comprise the traffic sub-chains and the traffic backbone.

4. The method of claim 1, wherein the multi-block chain comprises a traffic sub-chain and second and third chains managed by the first consensus node through a full platform configuration contract on the first chain; the sub-link consensus network corresponding to the service sub-link is formed by a consensus node in a second link network corresponding to the second link and a consensus node in a third link network corresponding to the third link; wherein the second chain network is independent of the third chain network; the service sub-chain is authorized to be created by a service object requesting to execute a target service through the first consensus node; one target service corresponds to one service sub-chain; when the target chain is the service sub-chain, the second chain or the third chain and the configuration resources indicated by the configuration transaction belong to independent configuration resources, the chain management configuration corresponding to the independent configuration resources is about a target chain management configuration contract on the first chain; the target chain management configuration contract includes a chain management configuration contract for configuring the second chain, a chain management configuration contract for configuring the third chain, or a sub-chain management configuration contract for configuring the business sub-chain.

5. The method of claim 1, wherein when the number of target chains is plural and the configuration resources indicated by the configuration transaction belong to a global configuration resource, a chain management configuration corresponding to the global configuration resource is in close proximity to a platform configuration contract on the first chain; the configuration transaction includes a second cross-chain configuration item associated with the configuration transaction; the method further comprises the steps of:

When the transaction type of the configuration transaction is a non-blocking transaction type, calling the platform configuration contract on the first chain to execute the configuration transaction, and generating a second configuration transaction identifier corresponding to the configuration transaction; the second configuration transaction identifier is used for indicating the cross-chain relay to send a second configuration lock acquisition transaction to a target consensus node associated with the target chain; the second configuration lock acquisition transaction is used for indicating the target consensus node to acquire a non-blocking chain configuration lock corresponding to the non-blocking transaction type from a chain configuration contract on the target chain, and the service state of the target chain is configured into a second service locking state through the non-blocking chain configuration lock;

Receiving a second locking claim transaction sent by the cross-chain relay; the second lock claim transaction is determined by the cross-chain relay upon detecting that the target chain is in the second traffic lock state;

And when the state of the configuration transaction corresponding to the second configuration transaction identifier is determined to be a second transaction locking state based on the second locking statement transaction, generating second transaction locking information corresponding to the second locking statement transaction, and writing the second transaction locking information into the first chain.

6. The method of claim 5, wherein the invoking the platform configuration contract on the first chain to perform the configuration transaction generates a second configuration transaction identification corresponding to the configuration transaction comprises:

Writing the configuration transaction with the second cross-chain configuration item into the platform configuration contract, calling a non-blocking transaction configuration method in the platform configuration contract on the first chain, and executing the configuration transaction to obtain a chain identification of the target chain and the second cross-chain configuration item indicated in the configuration transaction;

7. A multi-blockchain-based cross-chain configuration method, wherein the multi-blockchain comprises a first chain and a target chain; the method is performed by a cross-chain relay; the cross-link relay is used for isolating a first link network corresponding to the first link and a target link network corresponding to the target link; the method comprises the following steps:

when a first configuration transaction identifier corresponding to the configuration transaction on the first chain is detected, a first configuration lock acquisition transaction is sent to a target consensus node in the target chain network; the first configuration transaction identifier is generated by calling a chain management configuration contract on the first chain to execute the configuration transaction when the transaction type of the configuration transaction in the configuration transaction is a blocking transaction type, and the configuration transaction is sent by a management object requesting to execute the configuration transaction; the first configuration lock acquisition transaction is used for indicating the target consensus node to acquire a blocking type chain configuration lock corresponding to the blocking type transaction from a chain configuration contract on the target chain, and the service state of the target chain is configured to be a first service locking state through the blocking type chain configuration lock;

When the target chain is detected to be in the first service locking state, a first locking statement transaction is sent to the first consensus node; the first locking declaration transaction is used for indicating the first consensus node to generate first transaction locking information corresponding to the first locking declaration transaction for writing into the first chain when the state of the configuration transaction corresponding to the configuration transaction identifier is determined to be a first transaction locking state based on the first locking declaration transaction;

When a configuration modification transaction on the first chain is detected, acquiring a first cross-chain configuration item in the configuration modification transaction; the configuration modification transaction is sent by the management object based on the first transaction locking information on the first chain;

And configuring the first cross-link configuration item to the target link in a cross-link manner, so that the target consensus node unlocks the target link in the first service locking state through the blocking link configuration lock.

8. The method of claim 7, wherein the cross-chain configuring the first cross-chain configuration item to the target chain comprises:

Constructing a first release lock transaction based on the first cross-chain configuration item; the first lock release transaction is used for indicating the target consensus node to invoke a lock release method in a chain configuration contract to release the blocked chain configuration lock when writing the first cross-chain configuration item into the chain configuration contract, and changing the service state of the target chain from the first service locking state to the service unlocking state;

the first release lock transaction is sent to the target consensus node.

9. The method of claim 7, wherein the method further comprises:

Accumulating the chain locking time length of the target chain in the first service locking state, and sending a timeout release lock transaction to the target consensus node when the chain locking time length reaches the accumulated locking time length threshold of the blocking chain configuration lock, wherein the timeout release lock transaction is used for indicating the target consensus node to call a lock release method in the chain configuration contract on the target chain to release the blocking chain configuration lock, and changing the service state of the target chain from the first service locking state to the service unlocking state.

10. The method of claim 7, wherein the method further comprises:

And when the target chain is detected not to be in the first service locking state, sending a first locking failure transaction to the first consensus node, and sending a first locking failure release lock transaction to the target consensus node, wherein the first locking failure release lock transaction is used for indicating the target consensus node to call a lock release method in the chain configuration contract on the target chain to release the blocking chain configuration lock.

11. The method of claim 7, wherein the configuration transaction includes a second cross-chain configuration item associated with the configuration transaction; the method further comprises the steps of:

When a second configuration transaction identifier corresponding to a configuration transaction on a first chain is detected, a second configuration lock acquisition transaction is sent to a target consensus node in the target chain network, wherein the second configuration transaction identifier is generated by calling a management configuration contract on the first chain to execute the configuration transaction when the transaction type of the configuration transaction of a first consensus node in the first chain network is a non-blocking transaction type, and the configuration transaction is sent by a management object requesting to execute the configuration transaction; the second configuration lock acquisition transaction is used for indicating the target consensus node to acquire a non-blocking chain configuration lock corresponding to the non-blocking transaction type from a chain configuration contract on the target chain, and the service state of the target chain is configured into a second service locking state through the non-blocking chain configuration lock;

when the target chain is detected to be in the second service locking state, sending a second locking statement transaction to the first consensus node; the second locking declaration transaction is used for indicating the first consensus node to generate second transaction locking information corresponding to the second locking declaration transaction for writing into the first chain when the state of the configuration transaction corresponding to the configuration transaction identifier is determined to be a second transaction locking state based on the second locking declaration transaction;

12. The method of claim 11, wherein the cross-chain configuring the second cross-chain configuration item to the target chain comprises:

constructing a second release lock transaction based on the second cross-chain configuration item, and sending the second release lock transaction to a target consensus node; the second release lock transaction is used for indicating a target consensus node in the target chain to release the non-blocking chain configuration lock by calling a lock release method in the chain configuration contract on the target chain when writing the second cross-chain configuration item into the chain configuration contract, and changing the service state of the target chain from the second service locking state to the service unlocking state.

13. The method of claim 11, wherein the second configuration lock acquisition transaction is further to instruct the target consensus node to acquire a block buffer height from a chain configuration contract on the target chain, the block buffer height to characterize a maximum spacing height of resulting blocks on the target chain before configuring traffic states of the target chain to a second traffic lock state by the non-blocking chain configuration lock.

14. The method of claim 11, wherein the method further comprises:

And when the target chain is detected not to be in the second service locking state, sending a second locking failure transaction to the first consensus node, and sending a second locking failure release lock transaction to the target consensus node, wherein the second locking failure release lock transaction is used for indicating the target consensus node to call a lock release method in the chain configuration contract on the target chain to release the non-blocking chain configuration lock.

15. A multi-blockchain-based cross-chain configuration device, wherein the device is run on a first consensus node, the multi-blockchain comprising a first chain associated with the first consensus node and a target chain to be cross-chain configured; the first chain network corresponding to the first chain and the target chain network corresponding to the target chain are isolated through cross-chain relay, and the device comprises:

The determining module is used for determining the transaction type of the configuration transaction when receiving the configuration transaction which is sent by the management object based on the configuration transaction and is used for configuring the target chain in a cross-chain manner;

the calling module is used for calling a chain management configuration contract on the first chain to execute the configuration transaction when the transaction type of the configuration transaction is a blocking transaction type, and generating a first configuration transaction identifier corresponding to the configuration transaction; the first configuration transaction identifier is used for indicating the cross-chain relay to send a first configuration lock acquisition transaction to a target consensus node associated with the target chain; the first configuration lock acquisition transaction is used for indicating the target consensus node to acquire a blocking type chain configuration lock corresponding to the blocking type transaction from a chain configuration contract on the target chain, and the service state of the target chain is configured to be a first service locking state through the blocking type chain configuration lock;

The receiving module is used for receiving the first locking statement transaction sent by the cross-chain relay; the first lock claim transaction is determined by the cross-chain relay upon detecting that the target chain is in the first traffic lock state;

The generation module is used for generating first transaction locking information corresponding to the first locking statement transaction and writing the first transaction locking information into the first chain when the state of the configuration transaction corresponding to the first configuration transaction identifier is determined to be a first transaction locking state based on the first locking statement transaction;

and the first configuration module is used for configuring the first cross-link configuration item to the target link in a cross-link manner through the cross-link relay so as to enable the target consensus node to unlock the target link in the first service locking state through the blocking link configuration lock.

16. A multi-blockchain-based cross-chain configuration device, wherein the multi-blockchain includes a first chain and a target chain, the device operating on a cross-chain relay for isolating the first chain network corresponding to the first chain and the target chain network corresponding to the target chain, the device comprising:

The sending module is used for sending a first configuration lock acquisition transaction to a target consensus node in the target chain network when a first configuration transaction identifier corresponding to the configuration transaction on the first chain is detected; the first configuration transaction identifier is generated by calling a chain management configuration contract on the first chain to execute the configuration transaction when the transaction type of the configuration transaction in the configuration transaction is a blocking transaction type, and the configuration transaction is sent by a management object requesting to execute the configuration transaction; the first configuration lock acquisition transaction is used for indicating the target consensus node to acquire a blocking type chain configuration lock corresponding to the blocking type transaction from a chain configuration contract on the target chain, and the service state of the target chain is configured to be a first service locking state through the blocking type chain configuration lock;

The sending module is further configured to send a first locking statement transaction to the first consensus node when the target chain is detected to be in the first service locking state; the first locking declaration transaction is used for indicating the first consensus node to generate first transaction locking information corresponding to the first locking declaration transaction for writing into the first chain when the state of the configuration transaction corresponding to the configuration transaction identifier is determined to be a first transaction locking state based on the first locking declaration transaction;

17. A multi-blockchain-based cross-chain configuration system, the system comprising: a first consensus node in a first chain network, a target consensus node in a target chain network, and a cross-chain relay; the first chain network and the target chain network are isolated through a cross-chain relay;

the first consensus node is used for determining the transaction type of the configuration transaction when receiving the configuration transaction which is sent by the management object based on the configuration transaction and is used for configuring the target chain in a cross-chain manner, and calling a chain management configuration contract on the first chain to execute the configuration transaction when the transaction type of the configuration transaction is a blocking type transaction type so as to generate a first configuration transaction identifier corresponding to the configuration transaction;

The cross-chain relay is used for sending a first configuration lock acquisition transaction to a target consensus node in the target chain network when a first configuration transaction identifier corresponding to the configuration transaction on the first chain is detected;

The target consensus node is used for acquiring a blocked chain configuration lock corresponding to the blocked transaction type from a chain configuration contract on the target chain, and configuring the service state of the target chain into a first service locking state through the blocked chain configuration lock;

The cross-link relay is used for sending a first locking statement transaction to the first consensus node when the target link is detected to be in the first service locking state;

the first consensus node is further configured to generate first transaction locking information corresponding to the first locking declaration transaction of the first chain and write the first transaction locking information into the first chain when the state of the configuration transaction corresponding to the configuration transaction identifier is determined to be a first transaction locking state based on the first locking declaration transaction;

the first consensus node is further configured to obtain a first cross-link configuration item in a configuration modification transaction when obtaining the configuration modification transaction sent by the management object based on the first transaction locking information on the first link;

18. A computer device comprising a memory and a processor;

The memory is connected to the processor, the memory is used for storing a computer program, and the processor is used for calling the computer program to enable the computer device to execute the method of any one of claims 1-14.

19. A computer readable storage medium, characterized in that the computer readable storage medium has stored therein a computer program adapted to be loaded and executed by a processor to cause a computer device having the processor to perform the method of any of claims 1-14.

20. A computer program product comprising computer programs/instructions which, when executed by a processor, implement the method of any of claims 1-14.