A consortium blockchain self-discovery method based on multiple consortium blockchains and multiple relay chains.

Abstract

This invention relates to a self-discovery method for consortium blockchains based on multiple consortium blockchains and multiple relay chains, belonging to the field of blockchain technology. The method includes steps such as setting a unique identifier, generating cross-chain contract consortium routing information, and data transmission. This invention enables the self-discovery of consortium blockchains and facilitates resource sharing, laying a reliable foundation for data sharing. Simultaneously, since direct connections between individual consortium members are no longer required, the risk of network attacks is reduced, security is improved, and the method is easy to promote and apply.

Description

Technical Field

[0001] This invention belongs to the field of blockchain technology, specifically relating to a self-discovery method for consortium blockchains based on multiple consortium blockchains and multiple relay chains. Background Technology

[0002] In large-scale consortium blockchain systems, multiple consortia are connected through multiple relay chains. A cross-chain gateway or relay chain needs to be deployed between every two consortium blockchains. If any two consortia are not directly connected via a relay chain, they cannot interact across chains. Therefore, this results in high deployment costs and hinders the promotion and expansion of consortia.

[0003] Because multiple consortia deploy cross-chain gateways or relay chains between every two consortia, it means that all consortia's networks must be interconnected, resulting in an increasing number of open network ports and raising cybersecurity risks. Therefore, overcoming the shortcomings of existing technologies is a pressing issue that needs to be addressed in the current blockchain technology field. Summary of the Invention

[0004] The purpose of this invention is to address the shortcomings of existing technologies and provide a consortium blockchain self-discovery method based on multiple consortium blockchains and multiple relay chains.

[0005] To achieve the above objectives, the technical solution adopted by the present invention is as follows:

[0006] A consortium blockchain self-discovery method based on multiple consortium blockchains and multiple relay chains includes:

[0007] Step (1), set a unique identifier: each alliance sets a unique identifier;

[0008] The method for setting the unique identifier is as follows: first, use the organization name + department name + UUID, and then use the sha256 digest algorithm to calculate the digest, which serves as the unique identifier of the consortium; each unique identifier is associated with the node information of this consortium chain, and is also associated with the consortium information that has cross-chain relationships with this consortium.

[0009] Step (2), generation of cross-chain contract alliance routing information: broadcast the routing information of each alliance to the alliances connected to it, and then each alliance will synchronize and integrate all the routing information received to obtain its cross-chain contract alliance routing information;

[0010] Step (3), data transmission:

[0011] (3.1) The business system of the starting alliance prepares the data to be sent to the destination alliance and then calls the interface of the starting alliance's cross-chain contract; the interface of the starting alliance's cross-chain contract receives the data to be sent and the destination alliance to be sent, and performs path query;

[0012] (3.2) The starting alliance cross-chain contract sends the data to the first transit alliance in the path through the cross-chain gateway and the relay chain; after receiving the data, the first transit alliance signs the data and the routing information from the starting alliance to the first transit alliance and stores it in the first transit alliance; then, the first transit alliance returns the storage result to the starting alliance cross-chain.

[0013] (3.3) The first transit alliance cross-chain contract sends the data with added routing information to the second transit alliance in the path through the cross-chain gateway and relay chain; after receiving the data, the second transit alliance signs the data and the routing information from the starting alliance to the second transit alliance and stores it in the second transit alliance; then, the second transit alliance returns the storage result to the first transit alliance; and so on; until it is transmitted to the last transit alliance cross-chain;

[0014] (3.4) The last relay alliance cross-chain contract sends the data with added routing information to the destination alliance in the path through the cross-chain gateway and relay chain; after receiving the data, the destination alliance signs the data and the routing information from the starting alliance to the destination alliance and stores it in the destination alliance.

[0015] (3.5) After receiving the data, the destination consortium notifies its business system to process the data; after processing, it begins to broadcast in reverse along the routing information; after each consortium chain receives the broadcast, it performs the corresponding notarization.

[0016] Furthermore, preferably, the node information includes an IP address and a communication port.

[0017] Furthermore, preferably, the alliance information that has cross-chain communication with the alliance includes the unique identifier of the alliance that has cross-chain communication with the alliance and its communication information.

[0018] Furthermore, preferably, if the routing information of a certain alliance changes, the change is broadcast to the alliances connected to it. After receiving the broadcast, the connected alliance changes its own cross-chain contract alliance routing information and broadcasts the change to the alliances connected to it, and so on, until the routing of the entire alliance is consistent.

[0019] Furthermore, preferably, heartbeats are periodically sent to the connected consortium, and the connected consortium replies with its own cross-chain contract consortium routing information upon receiving the heartbeats.

[0020] Furthermore, preferably, the result of the notarization is the notarized transaction TxHash1.

[0021] Furthermore, preferably, if the data is sent via anonymous routing, the sending method is as follows:

[0022] 1) The initial alliance prepares the interactive data to be sent to the destination alliance. The interactive data includes a header and a data body. The data body is the data that the destination alliance needs to process. The data body is encrypted using the destination alliance's public key. The header is used to indicate the routing and forwarding path. The header includes a header identifier code that is encrypted with preset characters using the public keys of each relay alliance and the destination alliance respectively.

[0023] 2) The initial consortium sends the data body storage address and the boot header to all consortium chains connected to it. The connected consortiums attempt to decrypt the boot identifier code in the boot header. If the preset characters can be decrypted correctly, the data body is read from the storage address; if the preset characters cannot be decrypted, no operation is performed.

[0024] 3) A consortium that can correctly decrypt the preset characters removes the boot identifier that it can correctly decrypt from the boot header. Then, the consortium stores the data body on the relay chain and sends the boot header to all the consortium chains it is connected to. All the consortium chains it is connected to attempt to decrypt the boot identifier in the boot header. If they can correctly decrypt the preset characters, they read the data body from the storage address. If they cannot decrypt the preset characters, they do nothing. This process continues until only one boot identifier is decrypted in the boot header. Then, this consortium becomes the destination consortium. The destination consortium reads the data body from the storage address.

[0025] 4) The destination alliance decrypts the data body using its private key and processes the data body. The processing result is then encrypted using the initial alliance's private key and used as the data body. Preset characters are encrypted using the public keys of each relay alliance and the destination alliance to form a boot identifier code, which forms the boot header. The boot header and the data body are then transmitted back to the initial alliance in the manner described in steps 2) to 3).

[0026] Furthermore, preferably, the encryption method uses envelope encryption.

[0027] Furthermore, preferably, all relay alliances store the hash values ​​of the header and data body when forwarding the header and data body.

[0028] The smart contract of this invention is a standard cross-chain smart contract. This contract can automatically register and discover cross-chain consortia. To enhance system privacy, the contract should also have node discovery control capabilities, allowing registration on both public and private consortium chains. Furthermore, the smart contract should have routing functionality, enabling the consortium initiating a transaction to send the contract through multiple chains to the target chain.

[0029] Compared with the prior art, the beneficial effects of this invention are as follows:

[0030] (1) Resource sharing is realized: Due to the self-discovery mechanism, alliances can easily know which alliances they are participating in, which lays a reliable foundation for data sharing;

[0031] (2) Improved security: Since direct connections between each pair within the alliance are no longer required, the risk of network attacks is reduced;

[0032] (3) Improved efficiency of establishing cross-chain mechanisms in consortium blockchains: With the help of the self-discovery mechanism, offline negotiation between consortium blockchains is no longer required, which improves the efficiency of establishing cross-chain mechanisms.

[0033] (4) It provides a brand-new cross-chain mechanism: With the help of the established relay chain, it is possible to realize cross-chain data between two non-directly related consortium chains, thereby saving the work of negotiation and establishing a relay chain and providing a cross-chain mechanism for permissions. Attached Figure Description

[0034] Figure 1 This is a diagram of the cross-consortium blockchain system architecture in an application example;

[0035] Figure 2 This is a flowchart illustrating the self-discovery process of cross-chain contracts in an application example.

[0036] Figure 3 This is a timing diagram for how Confederation D sends data to Confederation E in an application example. Detailed Implementation

[0037] The present invention will now be described in further detail with reference to the embodiments.

[0038] Those skilled in the art will understand that the following embodiments are for illustrative purposes only and should not be construed as limiting the scope of the invention. Where specific techniques or conditions are not specified in the embodiments, they are performed in accordance with the techniques or conditions described in the literature in the field or according to the product instructions. Materials or equipment whose manufacturers are not specified are all conventional products that can be obtained by purchase.

[0039] A consortium blockchain self-discovery method based on multiple consortium blockchains and multiple relay chains includes:

[0040] Step (1), set a unique identifier: each alliance sets a unique identifier;

[0041] The method for setting the unique identifier is as follows: first, use the organization name + department name + UUID, and then use the sha256 digest algorithm to calculate the digest, which serves as the unique identifier of the consortium; each unique identifier is associated with the node information of this consortium chain, and is also associated with the consortium information that has cross-chain relationships with this consortium.

[0042] Step (2), generation of cross-chain contract alliance routing information: broadcast the routing information of each alliance to the alliances connected to it, and then each alliance will synchronize and integrate all the routing information received to obtain its cross-chain contract alliance routing information;

[0043] Step (3), data transmission:

[0044] (3.1) The business system of the starting alliance prepares the data to be sent to the destination alliance and then calls the interface of the starting alliance's cross-chain contract; the interface of the starting alliance's cross-chain contract receives the data to be sent and the destination alliance to be sent, and performs path query;

[0045] (3.2) The starting alliance cross-chain contract sends the data to the first transit alliance in the path through the cross-chain gateway and the relay chain; after receiving the data, the first transit alliance signs the data and the routing information from the starting alliance to the first transit alliance and stores it in the first transit alliance; then, the first transit alliance returns the storage result to the starting alliance cross-chain.

[0046] (3.3) The first transit alliance cross-chain contract sends the data with added routing information to the second transit alliance in the path through the cross-chain gateway and relay chain; after receiving the data, the second transit alliance signs the data and the routing information from the starting alliance to the second transit alliance and stores it in the second transit alliance; then, the second transit alliance returns the storage result to the first transit alliance; and so on; until it is transmitted to the last transit alliance cross-chain;

[0047] (3.4) The last relay alliance cross-chain contract sends the data with added routing information to the destination alliance in the path through the cross-chain gateway and relay chain; after receiving the data, the destination alliance signs the data and the routing information from the starting alliance to the destination alliance and stores it in the destination alliance.

[0048] (3.5) After receiving the data, the destination consortium notifies its business system to process the data; after processing, it begins to broadcast in reverse along the routing information; after each consortium chain receives the broadcast, it performs the corresponding notarization.

[0049] Specifically, the node information includes IP address and communication port.

[0050] Specifically, the information about alliances that have cross-chain relationships with the alliance includes the unique identifier of the alliance and its communication information.

[0051] Specifically, if the routing information of a certain alliance changes, the change is broadcast to the alliances connected to it. After receiving the broadcast, the connected alliance changes its own cross-chain contract alliance routing information and broadcasts the change to the alliances connected to it. This process continues until the routing of the entire alliance is consistent.

[0052] Specifically, it periodically sends heartbeats to the connected alliances, and the connected alliances reply with their own cross-chain contract alliance routing information after receiving the heartbeats.

[0053] Specifically, the result of the notarization is the notarized transaction TxHash1.

[0054] Specifically, if the data is sent via anonymous routing, the sending method is as follows:

[0055] 1) The initial alliance prepares the interactive data to be sent to the destination alliance. The interactive data includes a header and a data body. The data body is the data that the destination alliance needs to process. The data body is encrypted using the destination alliance's public key. The header is used to indicate the routing and forwarding path. The header includes a header identifier code that is encrypted with preset characters using the public keys of each relay alliance and the destination alliance respectively.

[0056] 2) The initial consortium sends the data body storage address and the boot header to all consortium chains connected to it. The connected consortiums attempt to decrypt the boot identifier code in the boot header. If the preset characters can be decrypted correctly, the data body is read from the storage address; if the preset characters cannot be decrypted, no operation is performed.

[0057] 3) A consortium that can correctly decrypt the preset characters removes the boot identifier that it can correctly decrypt from the boot header. Then, the consortium stores the data body on the relay chain and sends the boot header to all the consortium chains it is connected to. All the consortium chains it is connected to attempt to decrypt the boot identifier in the boot header. If they can correctly decrypt the preset characters, they read the data body from the storage address. If they cannot decrypt the preset characters, they do nothing. This process continues until only one boot identifier is decrypted in the boot header. Then, this consortium becomes the destination consortium. The destination consortium reads the data body from the storage address.

[0058] 4) The destination alliance decrypts the data body using its private key and processes the data body. The processing result is then encrypted using the initial alliance's private key and used as the data body. Preset characters are encrypted using the public keys of each relay alliance and the destination alliance to form a boot identifier code, which forms the boot header. The boot header and the data body are then transmitted back to the initial alliance in the manner described in steps 2) to 3).

[0059] Specifically, the encryption method uses envelope encryption.

[0060] Specifically, all relay alliances will store the hash values ​​of the boot header and data body when forwarding them.

[0061] Application Examples

[0062] 1. Cross-consortium blockchain system architecture

[0063] Taking the interaction between 5 consortium blockchains as an example, the architecture diagram is as follows: Figure 1 As shown. The self-discovery mechanisms of several other consortium blockchains are similar. From Figure 1 As can be seen, cross-chain communication between different consortium blockchains is achieved through a cross-chain gateway and a relay chain. To enable cross-chain communication between two consortium blockchains, a smart contract related to the cross-chain gateway needs to be deployed in each consortium blockchain. By modifying the smart contract of the cross-chain gateway, the attributes and methods related to the cross-consortium blockchain self-discovery smart contract can be inherited or implemented, thereby realizing a self-discovery mechanism for large-scale consortium blockchains. Apart from the consortium blockchain's own ID and private cross-chain functionality, the data in the cross-chain gateway contracts between different consortium blockchains should eventually be synchronized and consistent.

[0064] Here, we assume that to achieve data interaction between consortium blockchain E and consortium blockchain D, the following operations are required in the existing technology: 1. The administrators of consortium blockchain D and consortium blockchain E reach an offline agreement to create a cross-chain service; 2. A relay chain is created between consortium blockchain D and consortium blockchain E; 3. Cross-chain smart contracts are deployed on consortium blockchain D and consortium blockchain E; 4. Cross-chain gateways are deployed on consortium blockchain D and consortium blockchain E.

[0065] By modifying the existing cross-chain smart contract, the contract has a self-discovery mechanism for public members of the consortium. Assuming that consortium chains D and E are public, the administrators of consortium chains D and E can easily know that each other exists in the consortium through the modified cross-chain smart contract, without the need to reach an agreement offline. At the same time, due to the modification of the cross-chain smart contract, the contract has the function of synchronizing data transaction requests, and there is no need to build a relay chain between consortium chains D and E.

[0066] 2. Essential data structures for cross-chain smart contracts

[0067] The required contract attributes are shown in Table 1.

[0068] Table 1

[0069] property Attribute Description kChainID The consortium blockchain ID where the cross-chain smart contract resides is: sha256 (organization name + department name + UUID). kSelf DiscoveryStatus Cross-chain smart contract chain self-discovery status (public / private): Indicates whether the chain is willing to be discovered by other chains that are not directly connected. kSelfDiscoveryVersion Cross-chain smart contract self-discovery version number: an identifier when the cross-chain consortium reaches its final state. kVersion Cross-chain smart contract version number: used to identify contract upgrades kPublicChainName Name of the consortium blockchain hosting the cross-chain smart contract: Institution Name + Department Name kPublicRoutes Cross-chain consortium routing table (dynamic data): It is a Map structure where the key is the target kChainID and the value is the route to the target consortium chain. kMyChainRoutes The routing table for direct cross-chain communication with this chain is a Map structure, where the key is the target kChainID and the value is the route to the target consortium chain.

[0070] The essential contract methods are shown in Table 2.

[0071] Table 2

[0072] Method Name Method Description broadcastKMyChainRoutes Self-owned route broadcasting is used to broadcast the routing table known to the contract. broadcastKPublicRoutes Known route broadcasting is used to broadcast publicly available routing tables known to the contract. sortOutRoutes Route organization is used to consolidate routing information; this method is called every time a broadcast is received. listenKRoutes Listen for broadcasts to receive broadcast information from cross-chain connections. saveRoutes Storage routing to blockchain getRoutes Retrieve all routing information and provide it to the organization administrator to query the routing information of other organizations. getPublicChainName Retrieve "Organization Name + Department Name" via kChainID

[0073] To ensure all consortium blockchains can achieve self-discovery, they need to uniformly inherit and implement the essential attributes and methods defined above (of course, attribute and method names can be defined according to actual circumstances). Once all consortium blockchains have inherited and implemented these essential attributes and methods, self-discovery between consortium blockchain organizations can be achieved. Furthermore, because the `getPublicChainName` method is provided, consortium system administrators can easily find publicly available consortium organizations within the entire cross-chain system by calling this method.

[0074] 3. Cross-chain contract self-discovery process

[0075] Figure 2 Each consortium within the consortium needs a unique identifier. Since consortium cross-chain transactions typically occur between institutions or departments, we can use the institution name + department name + UUID, and then calculate the digest using the SHA256 digest algorithm, which serves as the unique identifier for that consortium. Each unique identifier is associated with node information within the consortium's blockchain, including IP address, communication port, etc.; each unique identifier is also associated with information about consortia that have cross-chain relationships with this consortium, such as... Figure 1 In the architecture, the unique identifier of Alliance A should be associated with the unique identifiers of Alliance E and Alliance B, as well as communication information.

[0076] pass Figure 2 After the process is completed, once the entire cross-chain alliance is successfully created, some alliances may be added or deleted (including non-public ones). Once an alliance that is cross-chained with is added or deleted (including non-public ones), the node needs to change according to the already registered routing information and broadcast the change to the alliance connected to it. After receiving the broadcast, the alliance connected to it changes its own cross-chain contract alliance routing information and broadcasts the change to the alliance connected to it. This process continues until the routing of the entire alliance is consistent.

[0077] Because some nodes within a cross-chain consortium experience message delays, this can eventually lead to inconsistencies in routing information within the cross-chain smart contracts. To ensure data consistency, the cross-chain smart contracts need to periodically (the heartbeat interval should be configurable) send heartbeats to the consortium they are connected to. Upon receiving the heartbeat, the connected consortium replies with its own cross-chain contract consortium routing information. Through this periodic heartbeat, the cross-chain system is ensured to be consistent and usable in most cases.

[0078] 4. Taking Alliance D and Alliance E as examples, describe the data transmission process.

[0079] 1) such as Figure 3 Alliance D prepares the data to be sent to Alliance E. This data is usually prepared by Alliance D's business system. After the business system is prepared, it calls the interface of Alliance D's cross-chain contract.

[0080] 2) The cross-chain contract interface of consortium D receives the data to be sent and the destination consortium chain E, and begins to query the path from D to E. Figure 2 It can be seen that in order to send data from Confederation D to Confederation E, it is necessary to route through Confederation B and Confederation A.

[0081] 3) The cross-chain contract of Consortium D sends data to Consortium B through the cross-chain gateway and relay chain;

[0082] 4) After receiving the data, Consortium B signs the data and routing information D->B with Consortium B's ID and stores it in Consortium Chain B.

[0083] 5) Consortium B returns the result of the previous notarization step to Consortium D. The main thing returned here is the transaction TxHash1 notarized by Consortium B.

[0084] 6) Consortium B's cross-chain contract will send data with added routing information to Consortium A through the cross-chain gateway / relay chain;

[0085] 7) When Consortium A's cross-chain contract receives data from Consortium B, it signs the data and routing information D->B->A and stores it in Consortium Chain A.

[0086] 8) Alliance A returns the result of the previous notarization step to Alliance B. The main thing returned here is the transaction hash notarized by Alliance A.

[0087] 9) Consortium A's cross-chain contract sends data with added routing information to Consortium E through the cross-chain gateway and relay chain;

[0088] 10) When the cross-chain contract of Consortium E receives data from Consortium A, it stores the data and routing information D->B->A->E in the consortium chain E after it is signed by Consortium E.

[0089] 11) Since Alliance E is the destination node, after receiving the data, the destination alliance notifies Alliance E's business system to process the data; after processing, it starts broadcasting in reverse along the routing information, that is, E->A->B->D;

[0090] 12) After receiving the broadcast, each consortium blockchain will store the processing results and routes (same as the forward request) as evidence.

[0091] 5. Taking Alliance D and Alliance E as examples, describe the anonymous routing and forwarding process.

[0092] 1) Alliance D prepares the interaction data to be sent to Alliance E. The interaction data includes a header and a data body. The data body is the data that Alliance E needs to process. The data body is encrypted using Alliance E's public key. The header is used to indicate the routing forwarding path. The header includes a header identifier code that is encrypted with preset characters using the public keys of Alliance B, Alliance A and Alliance E respectively.

[0093] 2) Alliance D sends the data body storage address and boot header to Alliance B. Alliance B attempts to decrypt the boot identifier code in the boot header. If the preset characters can be decrypted correctly, the data body is read from the storage address.

[0094] 3) Consortium B removes the boot identifier that it can correctly decrypt from the boot header, stores the data body in the relay chain, and then sends the boot header to all the consortium chains it is connected to, namely Consortium A and Consortium C.

[0095] 4) Since Consortium C failed to decrypt the boot identifier code in the boot header, Consortium C did not perform any operation. Consortium A was able to decrypt one of the boot identifier codes correctly. Therefore, Consortium A read the data body from the relay chain and stored it in the relay chain.

[0096] 5) Consortium A removes the boot identifier that it can correctly decrypt from the boot header, and then sends the boot header to all the consortium chains it is connected to, i.e., Consortium E;

[0097] 6) Alliance E attempts to decrypt the boot identifier code in the boot header and is able to correctly decrypt the preset characters. Since there is only one boot identifier code, Alliance E can determine that it is the recipient of the data body. Alliance E reads the data body from the storage address.

[0098] 7) Consortium E uses its private key to decrypt the data body, processes the data body, encrypts the processing result using the private key of Consortium D, and uses the public keys of Consortium B, Consortium A, and Consortium D to encrypt preset characters to form a boot identifier code, which forms a boot header. The boot header and the data body are then transmitted back to Consortium D in the manner described in steps 2) to 6).

[0099] In step 3), Consortium B needs to store the data body in the relay chain with Consortium A, and also in the relay chain with Consortium C, so there will be two storage addresses.

[0100] When the data is large, it can be encrypted using an envelope.

[0101] When forwarding the header and data body, Alliance B and Alliance A will store the hash values ​​of the header and data body as evidence.

[0102] The aforementioned anonymous routing process enables data from Consortium D to Consortium E to be forwarded by Consortium B, but Consortium B is unaware of the recipient of the data. Consortium A is only connected to Consortium B and Consortium E, therefore Consortium A knows the recipient of the data. However, Consortium A cannot know the sender of the data, i.e., it is unaware that the data was generated by Consortium D. This anonymous routing process provides a way to anonymously forward cross-chain data.

[0103] The foregoing has shown and described the basic principles, main features, and advantages of the present invention. Those skilled in the art should understand that the present invention is not limited to the above embodiments. The embodiments and descriptions in the specification are merely illustrative of the principles of the invention. Various changes and modifications can be made to the invention without departing from its spirit and scope, and all such changes and modifications fall within the scope of the present invention as claimed. The scope of protection of this invention is defined by the appended claims and their equivalents.

Claims

1. A consortium blockchain self-discovery method based on multiple consortium blockchains and multiple relay chains, characterized in that, include: Step (1), set a unique identifier: each consortium blockchain is assigned a unique identifier; The method for setting the unique identifier is as follows: first, use the organization name + department name + UUID, and then use the sha256 digest algorithm to calculate the digest, which serves as the unique identifier of the consortium blockchain; each unique identifier is associated with the node information of this consortium blockchain, and is also associated with the consortium blockchain information that has cross-chain functionality with this consortium blockchain. Step (2), generation of cross-chain contract consortium routing information: broadcast each consortium routing information to the consortium chain connected to it, and then each consortium chain will synchronize and integrate all the routing information received to obtain its cross-chain contract consortium routing information; Step (3), data transmission: (3.1) The business system of the initiating alliance cross-chain prepares the data to be sent to the destination alliance cross-chain, and then calls the interface of the initiating alliance cross-chain contract; the interface of the initiating alliance cross-chain contract receives the data to be sent and the destination alliance cross-chain to be sent, and performs path query; (3.2) The starting alliance cross-chain contract sends the data to the first transit alliance cross-chain in the path through the cross-chain gateway and the relay chain; after receiving the data, the first transit alliance cross-chain signs the data and the routing information from the starting alliance cross-chain to the first transit alliance cross-chain, and then stores the evidence in the first transit alliance cross-chain; then, the first transit alliance cross-chain returns the evidence storage result to the starting alliance cross-chain. (3.3) The first transit alliance cross-chain contract will send the data with added routing information to the second transit alliance cross-chain in the path through the cross-chain gateway and relay chain; After receiving the data, the second transit alliance cross-chain will sign the data and the information of the originating alliance cross-chain to the second transit alliance cross-chain, and then store the evidence in the second transit alliance cross-chain. Then, the second intermediary consortium cross-chain returns the evidence storage result to the first intermediary consortium cross-chain; and so on; until it is transmitted to the last intermediary consortium cross-chain; (3.4) The last relay alliance cross-chain contract will send the data with added routing information to the destination alliance cross-chain in the path through the cross-chain gateway and relay chain; After receiving the data, the destination consortium cross-chain will sign the data and the routing information from the originating consortium cross-chain to the destination consortium cross-chain, and then store the evidence on the destination consortium cross-chain. (3.5) After receiving the data, the consortium's cross-chain system notifies its business system to process the data; Once processing is complete, the broadcast begins in reverse along the routing information; each consortium blockchain receives the broadcast and performs the corresponding notarization.

2. The consortium blockchain self-discovery method based on multiple consortium blockchains and multiple relay chains according to claim 1, characterized in that, The node information includes IP address and communication port.

3. The consortium blockchain self-discovery method based on multiple consortium blockchains and multiple relay chains according to claim 1, characterized in that, The information about consortium blockchains that have cross-chain relationships with the consortium blockchain includes the unique identifiers and communication information of the consortium blockchains that have cross-chain relationships with the consortium blockchain.

4. The consortium blockchain self-discovery method based on multiple consortium blockchains and multiple relay chains according to claim 1, characterized in that, If the routing information of a consortium blockchain changes, the change is broadcast to the consortium blockchains connected to it. Upon receiving the broadcast, the connected consortium blockchain changes its own cross-chain contract consortium blockchain routing information and simultaneously broadcasts the change to the connected consortium blockchains. This process continues until the routing of the entire consortium blockchain is consistent.

5. The consortium blockchain self-discovery method based on multiple consortium blockchains and multiple relay chains according to claim 1, characterized in that, It periodically sends heartbeats to the consortium blockchains it is connected to, and the consortium blockchains connected to it reply with their own cross-chain contract consortium blockchain routing information after receiving the heartbeats.

6. The consortium blockchain self-discovery method based on multiple consortium blockchains and multiple relay chains according to claim 1, characterized in that, The result of the notarization is the notarized transaction TxHash1.

7. The consortium blockchain self-discovery method based on multiple consortium blockchains and multiple relay chains according to claim 1, characterized in that, If the data is sent via an anonymous route, the sending method is as follows: 1) The interaction data to be sent to the destination alliance cross-chain includes a header and a data body. The data body is the data that the destination alliance cross-chain needs to process. The data body is encrypted using the public key of the destination alliance cross-chain. The header is used to indicate the routing and forwarding path. The header includes a header identifier code that encrypts preset characters using the public keys of each transit alliance cross-chain and the destination alliance cross-chain respectively. 2) The initial consortium cross-chain sends the data body storage address and the boot header to all the consortium chains connected to it. The connected consortium chains attempt to decrypt the boot identifier code in the boot header. If the preset characters can be decrypted correctly, the data body is read from the storage address; if the preset characters cannot be decrypted, no operation is performed. 3) A consortium chain that can correctly decrypt the preset characters removes the boot identifier that it can correctly decrypt from the boot header. Then, the consortium chain stores the data body in the relay chain and sends the boot header to all the consortium chains it is connected to. All the consortium chains it is connected to attempt to decrypt the boot identifier in the boot header. If they can correctly decrypt the preset characters, they read the data body from the storage address. If the preset characters cannot be decrypted, no operation is performed; this process continues until only one boot identifier is found in the boot header, at which point the consortium blockchain becomes the destination consortium cross-chain; the destination consortium cross-chain reads the data body from the storage address. 4) After the destination consortium cross-chain decrypts the data body using its private key, it processes the data body. The processing result is then encrypted using the private key of the starting consortium cross-chain and used as the data body. Preset characters are encrypted using the public keys of each transit consortium cross-chain and the destination consortium cross-chain to form a boot identifier code, which forms the boot header. The boot header and the data body are then transmitted back to the starting consortium cross-chain in the manner described in steps 2) to 3).

8. The consortium blockchain self-discovery method based on multiple consortium blockchains and multiple relay chains according to claim 7, characterized in that, The encryption method uses envelope encryption.

9. The consortium blockchain self-discovery method based on multiple consortium blockchains and multiple relay chains according to claim 7, characterized in that, When forwarding the bootstrap header and data body, all intermediary alliances will store the hash values ​​of the bootstrap header and data body as evidence.

Images