Blockchain networking system and blockchain networking method

Abstract

This disclosure relates to a blockchain networking system and a blockchain networking method. The system includes multiple blockchain nodes, each maintaining a node index. The node index includes blockchain nodes that can establish communication with the blockchain node. A transaction initiator in a blockchain node is used to query a first node index of the transaction initiator based on the transaction recipient information. If the transaction recipient is not included in the first node index, the initiator sends a communication request to a target blockchain node in the first node index. The target blockchain node receiving the communication request is used to query a second node index maintained by itself based on the transaction recipient information. If the transaction recipient is included in the second node index, the target blockchain node determines a new target blockchain node from the second node index and forwards the communication request to the new target blockchain node.

Description

Technical Field

[0001] This disclosure relates to the field of blockchain technology, specifically to a blockchain networking system and a blockchain networking method. Background Technology

[0002] Blockchain is a technology that enables the collective maintenance of a reliable database in a decentralized and trustless manner. During the development of blockchain technology, different types of blockchains have emerged. These different types of blockchains may exhibit technological heterogeneity, making it difficult for them to effectively exchange data and transfer value.

[0003] In related technologies, cross-chain technologies such as sidechains / relays can be used to enable data flow between different blockchains, thereby meeting the cross-chain needs of single-chain to single-chain. However, these cross-chain methods are difficult to meet the needs of large-scale interconnection between multiple blockchains. Summary of the Invention

[0004] The purpose of this disclosure is to provide a blockchain networking system and a blockchain networking method to solve the aforementioned related technical problems.

[0005] To achieve the above objectives, according to a first aspect of the present disclosure, a blockchain networking system is provided, comprising multiple blockchain nodes, each blockchain node serving as a node in one or more blockchain networks, each blockchain node maintaining a node index, the node index including blockchain nodes capable of establishing communication with the blockchain node, wherein...

[0006] The transaction initiator among the plurality of blockchain nodes is used to query the first node index of the transaction initiator based on the transaction recipient information. If the transaction recipient is not included in the first node index, the transaction initiator sends a communication request to the target blockchain node in the first node index. The communication request includes the transaction initiator information and the transaction recipient information.

[0007] The target blockchain node that receives the communication request is to query the second node index it maintains based on the transaction recipient information. If the transaction recipient is included in the second node index, the communication request is sent to the transaction recipient. If the transaction recipient is not included in the second node index, a new target blockchain node is determined from the second node index, and the communication request is forwarded to the new target blockchain node.

[0008] Optionally, the transaction recipient is configured to, in response to receiving the communication request, establish a communication connection with the transaction initiator based on the transaction initiator information in the communication request;

[0009] The transaction initiator and the transaction receiver are configured to, in response to receiving a first transaction request sent by the other party, execute a first transaction in their respective blockchain networks to obtain a first execution result. The first transaction request includes first transaction information, which includes the execution status of a transaction flow. The transaction flow includes multiple related transactions obtained by splitting the same cross-chain transaction. A new first transaction is determined based on the order of the transactions in the transaction flow. The first transaction information is updated according to the first execution result and the new first transaction. A new first transaction request is then sent to the other party, which includes the updated first transaction information.

[0010] The transaction initiator sends an initial first transaction request to the transaction receiver based on the order of the transactions in the transaction flow.

[0011] Optionally, the transaction initiator is configured to set a first condition for the new first transaction, generate a first zero-knowledge proof based on the first condition, and add the first condition and the first constraint to the updated first transaction information, wherein the first zero-knowledge proof satisfies the first constraint;

[0012] The transaction recipient is used to execute a new first transaction in its own first blockchain network, obtain a second execution result, save and lock the second execution result in the first blockchain of the first blockchain network; and deploy a first smart contract in the first blockchain network based on the first condition and the first constraint.

[0013] The first smart contract is configured to unlock the second execution result if the received zero-knowledge proof satisfies the first constraint and the second execution result satisfies the received condition associated with the zero-knowledge proof.

[0014] Optionally, the transaction initiator is further configured to, after generating a first zero-knowledge proof based on the first condition, save and lock the first execution result in the second blockchain of the second blockchain network in which it is located, and deploy a second smart contract in the second blockchain network. The second smart contract is configured to unlock the first execution result upon receiving a zero-knowledge proof that satisfies the first constraint.

[0015] The transaction initiator is also used to initiate a first call request when the first smart contract is deployed. The first call request includes the first zero-knowledge proof and the first condition. The first call request is used to call the first smart contract to unlock the second execution result.

[0016] The transaction recipient is further configured to obtain the first zero-knowledge proof in the first call request and initiate a second call request, the second call request including the first zero-knowledge proof, and the second call request being used to call the second smart contract to unlock the first execution result.

[0017] Optionally, the transaction recipient is configured to set a second condition for the new first transaction, generate a second zero-knowledge proof based on the second condition, and add the second condition and the second constraint to the updated first transaction information, wherein the second zero-knowledge proof satisfies the second constraint;

[0018] The transaction initiator is used to execute a new first transaction in its own second blockchain network, obtain a third execution result, save and lock the third execution result in the second blockchain of the second blockchain network; and deploy a third smart contract in the second blockchain network based on the second condition and the second constraint.

[0019] The third smart contract is used to unlock the third execution result if the received zero-knowledge proof satisfies the second constraint and the third execution result satisfies the received conditions associated with the zero-knowledge proof.

[0020] Optionally, the transaction recipient is further configured to, after generating a second zero-knowledge proof based on the second condition, save and lock the first execution result in the first blockchain of the first blockchain network in which it is located, and deploy a fourth smart contract in the first blockchain network, wherein the fourth smart contract is configured to unlock the first execution result upon receiving a zero-knowledge proof that satisfies the second constraint;

[0021] The transaction recipient is also configured to, upon completion of the deployment of the third smart contract, initiate a third call request, the third call request including the second zero-knowledge proof and the second condition, the third call request being used to call the third smart contract to unlock the third execution result;

[0022] The transaction initiator is also used to obtain the second zero-knowledge proof in the third call request and initiate a fourth call request, the fourth call request including the second zero-knowledge proof, and the fourth call request is used to call the fourth smart contract to unlock the first execution result.

[0023] Optionally, the first transaction information may further include a summary of the first transaction, the current block hash value in the blockchain network, and a summary of the second transaction, wherein the second transaction is the preceding transaction of the first transaction in the transaction stream.

[0024] Optionally, the transaction initiator is configured to send query requests to each blockchain node in the first node index, obtain query responses from each blockchain node, and select the blockchain node with the shortest response time as the target blockchain node.

[0025] Optionally, the blockchain node is used to generate a node index of the blockchain node based on the information of the transaction node, wherein the transaction node is a node that has conducted transactions with the blockchain node.

[0026] According to a second aspect of the present disclosure, a blockchain networking method is provided, applied to the blockchain networking system described in any one of the first aspects above, the method comprising:

[0027] The transaction initiator queries the first node index of the transaction initiator based on the transaction recipient information;

[0028] If the transaction initiator does not include the transaction recipient in the first node index, the initiator sends a communication request to the target blockchain node in the first node index. The communication request includes the transaction initiator information and the transaction recipient information.

[0029] Upon receiving the communication request, the target blockchain node queries its own maintained second node index based on the transaction recipient information.

[0030] If the target blockchain node that receives the communication request includes the transaction recipient in the second node index, it will send the communication request to the transaction recipient.

[0031] If the target blockchain node receiving the communication request does not include the transaction recipient in the second node index, a new target blockchain node is determined from the second node index, and the communication request is forwarded to the new target blockchain node.

[0032] Optionally, the method includes:

[0033] In response to receiving the communication request, the transaction recipient establishes a communication connection with the transaction initiator based on the transaction initiator information in the communication request.

[0034] The transaction initiator or the transaction recipient shall perform the following steps:

[0035] In response to receiving a first transaction request from the other party between the transaction initiator and the transaction receiver, the first transaction is executed in its own blockchain network to obtain a first execution result. The first transaction request includes first transaction information, which includes the execution status of the transaction flow. The transaction flow includes multiple related transactions obtained by splitting the same cross-chain transaction.

[0036] The new first transaction is determined based on the order of the transactions in the transaction flow;

[0037] Update the first transaction information based on the first execution result and the new first transaction;

[0038] Send a new first transaction request to the other party, the new first transaction request including the updated first transaction information;

[0039] The transaction initiator sends an initial first transaction request to the transaction receiver based on the order of the transactions in the transaction flow.

[0040] Optionally, it also includes:

[0041] The transaction initiator sets the first condition for the new first transaction;

[0042] The transaction initiator generates a first zero-knowledge proof based on the first condition;

[0043] The transaction initiator adds the first condition and the first constraint to the updated first transaction information, and the first zero-knowledge proof satisfies the first constraint;

[0044] The transaction recipient executes a new first transaction within its own first blockchain network and obtains a second execution result;

[0045] The transaction recipient saves and locks the second execution result in the first blockchain of the first blockchain network;

[0046] The transaction recipient deploys a first smart contract in the first blockchain network based on the first condition and the first constraint.

[0047] The first smart contract is configured to unlock the second execution result if the received zero-knowledge proof satisfies the first constraint and the second execution result satisfies the received condition associated with the zero-knowledge proof.

[0048] Optionally, it includes:

[0049] After generating the first zero-knowledge proof based on the first condition, the transaction initiator saves and locks the first execution result in the second blockchain of the second blockchain network to which it belongs;

[0050] The transaction initiator deploys a second smart contract in the second blockchain network. The second smart contract is used to unlock the first execution result upon receiving a zero-knowledge proof that satisfies the first constraint.

[0051] When the first smart contract is deployed, the transaction initiator initiates a first call request. The first call request includes the first zero-knowledge proof and the first condition. The first call request is used to call the first smart contract to unlock the second execution result.

[0052] The transaction recipient obtains the first zero-knowledge proof from the first invocation request;

[0053] The transaction recipient initiates a second call request, which includes the first zero-knowledge proof and is used to call the second smart contract to unlock the first execution result.

[0054] Optionally, it also includes:

[0055] The transaction recipient sets the second condition for the new first transaction;

[0056] The transaction recipient generates a second zero-knowledge proof based on the second condition;

[0057] The transaction recipient adds the second condition and the second constraint to the updated first transaction information, and the second zero-knowledge proof satisfies the second constraint;

[0058] The transaction initiator executes a new first transaction in its own second blockchain network, resulting in a third execution result.

[0059] The transaction initiator saves and locks the third execution result in the second blockchain of the second blockchain network;

[0060] The transaction initiator deploys a third smart contract in the second blockchain network based on the second condition and the second constraint;

[0061] The third smart contract is used to unlock the third execution result if the received zero-knowledge proof satisfies the second constraint and the third execution result satisfies the received conditions associated with the zero-knowledge proof.

[0062] Optionally, it includes:

[0063] After generating a second zero-knowledge proof based on the second condition, the transaction recipient saves and locks the first execution result in the first blockchain of the first blockchain network to which it belongs;

[0064] The transaction recipient deploys a fourth smart contract in the first blockchain network. The fourth smart contract is used to unlock the first execution result upon receiving a zero-knowledge proof that satisfies the second constraint.

[0065] When the third smart contract is deployed, the transaction recipient initiates a third call request. The third call request includes the second zero-knowledge proof and the second condition. The third call request is used to call the third smart contract to unlock the third execution result.

[0066] The transaction initiator obtains the second zero-knowledge proof in the third invocation request;

[0067] The transaction initiator initiates a fourth call request, which includes the second zero-knowledge proof and is used to call the fourth smart contract to unlock the first execution result.

[0068] Optionally, the first transaction information may further include a summary of the first transaction, the current block hash value in the blockchain network, and a summary of the second transaction, wherein the second transaction is the preceding transaction of the first transaction in the transaction stream.

[0069] Optionally, it includes:

[0070] The transaction initiator sends query requests to each blockchain node in the first node index;

[0071] The transaction initiator obtains the query responses from each of the blockchain nodes and selects the blockchain node with the shortest response time as the target blockchain node.

[0072] Optionally, it also includes:

[0073] The blockchain node generates a node index based on the information of the transaction node, where the transaction node is a node that has conducted transactions with the blockchain node.

[0074] In the above technical solution, each blockchain node in the blockchain network system can maintain a node index, which includes blockchain nodes capable of establishing communication with the blockchain node. Thus, when a blockchain node initiating a transaction performs a transaction, it can query the transaction recipient in its own maintained first node index. If the transaction recipient is found, it can directly conduct the transaction with the recipient. If the transaction recipient is not found in the first node index, the transaction initiator can determine the target blockchain node from the first node index and send a communication request to the target blockchain node. The target blockchain node receiving the communication request can query its own maintained second node index based on the transaction recipient information. If the transaction recipient is found in the second node index, the communication request can be sent to the transaction recipient; if the transaction recipient is not found in the second node index, a new target blockchain node can be determined from the second node index, and the communication request can be forwarded to the new target blockchain node. In this way, the new target blockchain node can continue to query the transaction recipient.

[0075] In other words, a specific blockchain node can be addressed based on the node index maintained by the blockchain node. This addressing method can overcome the limitations of blockchain networks and enable networking between multiple blockchain networks. Furthermore, the above technical solution does not require setting up a relay blockchain network for addressing, thus possessing the advantage of a simple system architecture.

[0076] Other features and advantages of this disclosure will be described in detail in the following detailed description section. Attached Figure Description

[0077] The accompanying drawings are provided to further illustrate the present disclosure and form part of the specification. They are used together with the following detailed description to explain the present disclosure, but do not constitute a limitation thereof. In the drawings:

[0078] Figure 1 This is a schematic diagram of a blockchain networking system shown in an exemplary embodiment of this disclosure.

[0079] Figure 2 This is a flowchart illustrating a blockchain networking method as shown in an exemplary embodiment of this disclosure.

[0080] Figure 3 This is a flowchart illustrating a blockchain networking method as shown in an exemplary embodiment of this disclosure.

[0081] Figure 4 This is a block diagram of an electronic device 400 as shown in an exemplary embodiment of this disclosure. Detailed Implementation

[0082] The specific embodiments of this disclosure will be described in detail below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are for illustration and explanation only and are not intended to limit this disclosure.

[0083] Before introducing the blockchain networking system and method disclosed herein, we will first introduce the application scenarios of this disclosure. To facilitate data flow, cross-chain methods such as hash locking and sidechains / relays can be used to achieve interconnection and interoperability between different blockchain networks in relevant scenarios.

[0084] Hash locking technology originated from the Bitcoin Lightning Network as a technical means of asset exchange between Bitcoin and other cryptocurrencies. With the increasing demand for cross-chain technology, hash locking has been applied to cross-chain scenarios. However, while suitable for asset exchange, hash locking is difficult to apply in other scenarios.

[0085] Cross-chain technology based on sidechain / relay models can verify transaction information on the original chain on the target chain. For example, in relay mode, cross-chain interoperability without relying on third parties can be achieved through a unified scheduling center and relay smart contracts. Cross-chain technology based on relay models has the advantages of flexibility and strong applicability, and is therefore widely used in various cross-chain scenarios.

[0086] It's worth noting that while these cross-chain technologies can meet the needs of single-chain to single-chain cross-chain communication, they struggle to meet the demands of large-scale interconnection between multiple blockchains. For example, in relay mode, when there are many cross-chain participants, the relay blockchain network faces significant load pressure. In this situation, issues such as transaction failures and slow transaction responses may occur, thus affecting the cross-chain process. Furthermore, the setup of a relay blockchain network also makes the cross-chain system architecture more complex, resulting in higher development and maintenance costs.

[0087] To this end, this disclosure provides a blockchain networking system. The blockchain networking system includes multiple blockchain nodes, each of which serves as a node in one or more blockchain networks. Each blockchain node maintains a node index, which includes blockchain nodes capable of establishing communication with that blockchain node.

[0088] As an example, blockchain nodes in the blockchain network system can obtain historical transaction information and extract one or more transaction nodes that have transacted with the blockchain node from the historical transaction information. In this way, a node index of the blockchain node can be generated based on the information of the transaction nodes, which may include, for example, the node address, information about the blockchain network to which it belongs, node identifier, etc. Of course, after constructing the node index, the blockchain node can also maintain the node index. For example, after the blockchain node completes a new transaction, the blockchain node can extract the transaction node's information from the new transaction and update and maintain it in the node index.

[0089] Figure 1 This is a schematic diagram of a blockchain networking system as shown in this disclosure. Figure 1 In the example, the blockchain network system includes blockchain nodes add1 to add12, a total of 12 blockchain nodes. Following the example above, add1 can obtain historical transaction information and extract transaction nodes add2 to add6 that have transacted with the blockchain node from that historical transaction information. Thus, a node index for blockchain node add1 can be generated based on the information of transaction nodes add2 to add6.

[0090] Similarly, other blockchain nodes can also generate node indexes. Figure 1 In the example, the node index of add6 can include add1 and add7; the node index of add7 can include add6 and add8; the node index of add8 can include add7 and add9; and the node index of add9 can include add8, add10, add11, and add12. It should be noted that two blockchain nodes capable of communication can add each other to their own node indexes. For example, in... Figure 1 In the example, add7 can be in the node index of add6, and add6 can be in the node index of add7.

[0091] In some possible implementations, the node index may also be generated according to preset rules. The blockchain networking system can preset the node index for each blockchain node, which is then maintained by each blockchain node. In some implementations, a blockchain node may also add other blockchain nodes from its own blockchain network to its own node index. It should be noted that the node index can be maintained locally on the blockchain node or in a storage space accessible to the blockchain node, such as in the cloud; this disclosure does not impose any restrictions on this.

[0092] Furthermore, blockchain nodes in the aforementioned blockchain network system can either initiate a transaction request as a transaction initiator or receive a transaction request as a transaction receiver. In other words, a blockchain node (such as add2) can act as both a transaction initiator and a transaction receiver.

[0093] Thus, the transaction initiator among the plurality of blockchain nodes is used to query the first node index of the transaction initiator based on the transaction recipient information. If the transaction recipient is not included in the first node index, the transaction initiator sends a communication request to the target blockchain node in the first node index. The communication request includes the transaction initiator information and the transaction recipient information.

[0094] by Figure 1 Taking add1 as the transaction initiator and add11 as the transaction receiver as an example, add1 can query the first node index it maintains based on add11's information (such as name, number, etc.). For example, it can query the first node index based on add11's name to determine whether the first node index includes add11. If add11 is included in the first node index, add1 can obtain add11's node address from the first node index and communicate with add11 through that node address.

[0095] If add11 is not included in the first node index, add1 can send a communication request to the target blockchain node in the first node index. The communication request includes information about the transaction initiator add1 and the transaction recipient add11.

[0096] In some implementation scenarios, add1 can send the communication request to each blockchain node in the first node index. That is, the target blockchain node can include all blockchain nodes in the first node index. In other words, in this case, add1 can send the communication request to add2 through add6.

[0097] Thus, the target blockchain node that receives the communication request queries its own maintained second node index based on the transaction recipient information. If the transaction recipient is included in the second node index, the communication request is sent to the transaction recipient. If the transaction recipient is not included in the second node index, a new target blockchain node is determined from the second node index, and the communication request is forwarded to the new target blockchain node.

[0098] Using the example above, add2 through add6 can query the second node index they maintain. If add11 is included in the second node index, the communication request is sent to add11. If add11 is not included in the second node index, a new target blockchain node can be determined from the second node index, and the communication request is sent to the new target blockchain node.

[0099] Taking add6 as an example, if add11 is not included in the second node index of add6, add6 can forward the communication request to the blockchain node in its node index, namely add7. Similarly, add7 can forward the communication request to add8, and add8 can forward the communication request to add9. add9 can query its own maintained second node index to determine add11 and forward the communication request to add11. In this way, after receiving the communication request, add11 can establish a communication connection with add1 based on the transaction initiator information in the communication request (i.e., add1's information, such as node address).

[0100] Using the above technical solution, a specified blockchain node can be addressed based on the node index maintained by the blockchain node. This addressing method can overcome the limitations of blockchain networks and realize networking between multiple blockchain networks. Furthermore, the above technical solution does not require setting up a relay blockchain network for addressing, thus having the advantage of simple system architecture.

[0101] In some possible implementations, the transaction initiator may also filter the target blockchain nodes from the first node index. For example, the transaction initiator may use this to send query requests to each blockchain node in the first node index.

[0102] The blockchain node that receives the query request can send a query response to the transaction initiator.

[0103] The transaction initiator can obtain the query responses from each of the blockchain nodes and select the blockchain node with the shortest response time as the target blockchain node.

[0104] For example, add1 can send query requests to add2 through add6 and receive query responses from add2 through add6. add1 can then select add6, which has the shortest response time, as the target blockchain node.

[0105] In some implementations, the transaction initiator may also select a preset number of blockchain nodes with shorter response times as the target blockchain nodes. (Continued) Figure 1For example, add1 can send query requests to add2 through add6 and receive query responses from add2 through add6. Add2 and add5 are nodes that do not respond (shown as dashed lines in the diagram). Thus, add1 can use add3, add4, and add6 as the target blockchain nodes.

[0106] The above technical solution can filter target blockchain nodes based on response time. In this way, blockchain nodes with faster response times can be used to address the transaction recipient, thereby improving the system's addressing performance.

[0107] Using the above technical solution, the transaction initiator can send communication requests to the transaction recipient.

[0108] Upon receiving the communication request, the transaction recipient can establish a communication connection with the transaction initiator based on the transaction initiator information in the communication request, thereby conducting the transaction.

[0109] During the transaction process, the transaction initiator and the transaction receiver are configured to, in response to receiving a first transaction request sent by the other party, execute a first transaction in their respective blockchain networks to obtain a first execution result. The first transaction request includes first transaction information, which includes the execution status of a transaction flow. The transaction flow includes multiple related transactions obtained by splitting the same cross-chain transaction. A new first transaction is determined based on the order of the transactions in the transaction flow. The first transaction information is updated according to the first execution result and the new first transaction. A new first transaction request is then sent to the other party, which includes the updated first transaction information.

[0110] The transaction initiator sends an initial first transaction request to the transaction receiver based on the order of the transactions in the transaction flow.

[0111] The following explains the transaction process. Taking a cross-chain transaction as an example of a household registration transfer, the transaction initiator can be a blockchain node in the blockchain network of the original household registration location, and the transaction recipient can be a blockchain node in the blockchain network of the household registration destination location.

[0112] In this way, the transaction initiator can split the household registration transfer transaction into multiple related transactions (such as the transaction initiator providing the target household registration information to the transaction recipient -> the transaction recipient verifying the target household registration information -> the transaction initiator deleting the target household registration in the blockchain of the source household registration location (such as marking the target household registration as invalid) -> the transaction recipient adding the target household registration in the blockchain of the household registration destination), thereby obtaining the transaction flow of the household registration transfer transaction.

[0113] It should be understood that the transactions in the transaction flow are interconnected, and the execution of a subsequent transaction depends on the execution result of the preceding transaction. For example, the action of "the transaction initiator deleting the target household registration in the blockchain of the source household registration location" requires that "the transaction recipient verifying the target household registration information" be successful.

[0114] After obtaining the transaction flow, the transaction initiator can initiate a transaction based on the transaction flow. For example, in some implementations, the transaction initiator can send an initial first transaction request to the transaction recipient according to the transaction order in the transaction flow. The first transaction request includes first transaction information, which includes the execution status of the transaction flow. Here, the execution status of the transaction flow can be a "starting state". The transaction initiator can also save the first transaction information to the second blockchain of its own second blockchain network, thereby recording and documenting the transaction process.

[0115] After receiving the first transaction request, the transaction recipient can execute the first transaction within its own first blockchain network to obtain a first execution result. As an example, the initial first transaction could be to verify the target household registration information provided by the transaction initiator. In this way, the transaction recipient can verify the target household registration information according to the set household registration information verification rules and save the verification result to the first blockchain of the first blockchain network.

[0116] After the first transaction is completed, the transaction recipient can determine a new first transaction based on the transaction flow, such as requesting the transaction initiator to delete the target household registration in the blockchain of the source household registration location. The transaction recipient can also update the first transaction information in the first transaction request based on the first execution result of the first transaction and the new first transaction. For example, the execution status of the transaction flow in the first transaction information can be updated from "starting state" to "in progress state". The transaction recipient can also save the new first transaction information to the first blockchain, thereby providing evidence of the transaction process. The transaction recipient can also send a new first transaction request to the transaction initiator, the new first transaction request including the new first transaction information.

[0117] It should be noted that in some implementation scenarios, the first transaction information may also include other information.

[0118] For example, in one possible implementation, the first transaction information may include the node address of the transaction initiator and the node address of the transaction recipient. In some possible implementations, the first transaction information may include the timeout period of the transaction initiator and the timeout period of the transaction recipient. In some possible implementations, the first transaction information may include a summary of the first transaction, the current block hash value in the blockchain network, and a summary of a second transaction, which is the transaction preceding the first transaction in the transaction stream.

[0119] In this scenario, when sending the initial first transaction, the transaction initiator can obtain the current first block hash value of the second blockchain network and calculate the hash value of the first transaction as its digest. Thus, the transaction initiator can generate first transaction information [transaction initiator's node address A, transaction receiver's node address B, first block hash value C, first transaction digest D (first transaction hash value), second transaction digest E, transaction status F (initial status)]. It should be noted that since this is the initial first transaction, the digest of the second transaction can be left blank.

[0120] Accordingly, when the transaction recipient generates new first transaction information, it can update the aforementioned first transaction information. Specifically, field C is updated to the current block hash value in the first blockchain network, field D is updated to the digest of the new first transaction, field E is updated to the digest of the previous first transaction, and field F is updated to "in progress status".

[0121] It should be noted that in some implementation scenarios, due to the lack of a lookup mechanism, the blockchain network needs to wait for all of the multiple transactions to be completed before generating a block in order to save multiple consecutive transactions to the same block. In this case, when some transactions are not completed, the blockchain network is in a congested state, preventing other transactions from being properly uploaded and saved to the chain.

[0122] The aforementioned technical solution retains information such as the block hash value and the digest of the previous transaction in the transaction stream within the transaction information. This allows for the lookup of the block containing a specific transaction based on the block hash value, and the retrieval of the specific transaction information from that block based on the transaction digest. Similarly, the digest of the previous transaction and the hash value of the block containing the previous transaction can be determined from the first transaction information, thereby obtaining information about the previous transaction.

[0123] In this way, even if transactions in the transaction flow are stored in different locations on the blockchain, they can still be indexed and queried. In other words, using this technical solution, the blockchain network does not need to wait for individual transactions in the transaction flow to be executed. Therefore, this technical solution can effectively prevent transaction congestion.

[0124] The transaction process will still be described. After receiving the first transaction request from the transaction recipient, the transaction initiator can execute the first transaction in the second blockchain network. Using the household registration transfer example above, the transaction initiator can mark the target household registration information as invalid in the second blockchain and update the first transaction information. The method for updating the first transaction information is described in the above embodiments; for the sake of brevity, this disclosure will not elaborate further. The transaction initiator can also determine a new first transaction (requesting the transaction recipient to add the target household registration in the blockchain of the place of household registration relocation) based on the order of transactions in the transaction flow and send a new first transaction request to the transaction recipient.

[0125] After receiving the first transaction request from the transaction initiator, the transaction recipient can execute the first transaction in the first blockchain network, saving the target household registration information to the first blockchain. The transaction recipient can determine from the transaction flow information that the transaction flow has no subsequent transaction steps. Therefore, the transaction recipient can update the first transaction information and update the execution status of the transaction flow to "terminated".

[0126] In other words, the transaction initiator and the transaction recipient can repeat the above steps until the transaction flow is completed.

[0127] It should be noted that in these scenarios, cross-chain transactions are typically used as the transaction dimension, and smart contracts control the process at the business level. For example, in the aforementioned household registration transfer transaction, the transaction initiator can pre-execute its own related operations (such as deleting the target household registration information in the second blockchain) and synchronize the transaction status to the transaction recipient. Then, the transaction recipient synchronizes the transaction based on the received information and the transaction processing strategy (such as verifying the target household registration information and adding the target household registration information to the first blockchain).

[0128] In this scenario, the transaction initiator's execution status cannot be verified by the transaction recipient, nor can the transaction recipient's execution status be verified by the transaction initiator. In other words, the cross-chain transaction is effectively controlled by one party. Furthermore, since the transaction initiator and recipient are unaware of the entire transaction process, data inconsistencies may occur. For example, the transaction initiator might send cross-chain transaction-related fields such as "target household registration information to be verified; request to add the target household registration information to the first blockchain; request the transaction recipient to provide feedback on the result of adding the target household registration information (so that, if the target household registration information is saved to the first blockchain, the target household registration information can be deleted from the second blockchain)."

[0129] Thus, in the event of information loss, the transaction recipient may receive "target household registration information to be verified; request to add the target household registration information to the first blockchain," resulting in the transaction recipient adding the target household registration information to the first blockchain, but the transaction initiator not deleting the target household registration information from the second blockchain, i.e., the target household registration information exists in both locations simultaneously.

[0130] The aforementioned technical solution allows cross-chain transactions to be broken down into multiple related transaction streams. This enables the transaction initiator and receiver to identify anomalies during cross-chain communication (such as a transaction stream not being completed without feedback from the receiver), thus preventing data inconsistencies between them. Furthermore, the transaction initiator and receiver can verify the transaction status, allowing them to jointly confirm the transaction's state and helping to maintain trust between them.

[0131] The following example illustrates the transaction verification method from the perspective of the transaction initiator.

[0132] In one possible implementation, the transaction initiator is configured to set a first condition for the new first transaction, generate a first zero-knowledge proof based on the first condition, and add the first condition and the first constraint to the updated first transaction information, wherein the first zero-knowledge proof satisfies the first constraint.

[0133] Here, the first condition can be set based on application requirements. For example, in a financial scenario, the first transaction could be a request from the transaction initiator to the transaction recipient to transfer funds to the target account, and the first condition could be that the transfer amount is greater than X yuan. In the example of the target household registration transfer mentioned above, the first condition could be, for example, "the target household registration information is added to the first blockchain".

[0134] In this way, the transaction initiator can generate a first zero-knowledge proof based on the first condition.

[0135] As an example, a first zero-knowledge proof can be generated as follows:

[0136] First, set the constraint h(z):

[0137]

[0138] In this way, the proof of the first zero knowledge can be calculated.

[0139]

[0140]

[0141] Where z is obtained based on the first condition transformation, u, w, y, c, r, t, g1, g2 are constants, which can be selected according to application requirements (such as choosing empirical values) during specific implementation, m is the dimension of z, and l is the length of z.

[0142] The first zero-knowledge proof satisfies the first constraint:

[0143] (1) A·g2=B·g1

[0144] (2)

[0145] In this way, the transaction initiator can add the first condition and the first constraint to the updated first transaction information.

[0146] The transaction recipient is used to execute a new first transaction in its own first blockchain network, obtain a second execution result, save and lock the second execution result in the first blockchain; and deploy a first smart contract in the first blockchain network based on the first condition and the first constraint.

[0147] The first smart contract is configured to unlock the second execution result if the received zero-knowledge proof satisfies the first constraint and the second execution result satisfies the received condition associated with the zero-knowledge proof.

[0148] For example, the transaction recipient can save and lock the target household registration information in the first blockchain. The transaction recipient can also deploy a first smart contract, which is used to unlock the locked second execution result if the received zero-knowledge proof satisfies a first constraint and the locked second execution result in the first blockchain satisfies "the target household registration information is added to the first blockchain". The first constraint is:

[0149] (1) A·g2=B·g1

[0150] (2)

[0151] In some implementation scenarios, the transaction initiator is also used to initiate a first call request after the first smart contract has been deployed. The first call request includes the first zero-knowledge proof and the first condition. The first call request is used to call the first smart contract to unlock the second execution result.

[0152] For example, the transaction initiator can provide a locally stored first zero-knowledge proof and the first condition. Upon receiving the first zero-knowledge proof, the first smart contract can verify whether the first zero-knowledge proof satisfies the first constraint and whether the second execution result satisfies the first condition. If the first zero-knowledge proof satisfies the first constraint and the second execution result satisfies the first condition, the first smart contract can unlock the second execution result from the first blockchain.

[0153] In this way, the transaction recipient can provide the transaction initiator with a way to verify the transaction execution status without exposing information in the first blockchain, thereby helping to ensure the security of on-chain information.

[0154] In one possible implementation, the transaction initiator and the transaction recipient can also verify each other's transactions. In this scenario, the transaction initiator is further configured to, after generating a first zero-knowledge proof based on the first condition, save and lock the first execution result in the second blockchain of its own second blockchain network, and deploy a second smart contract in the second blockchain network. The second smart contract is configured to unlock the first execution result upon receiving a zero-knowledge proof that satisfies the first constraint.

[0155] For example, in the aforementioned household registration transfer case, the transaction initiator can perform the operation "delete the target household registration information in the second blockchain" in the second blockchain network, thereby obtaining the first execution result. The transaction initiator can save and lock the first execution result in the second blockchain. The transaction initiator can also construct a second smart contract. The second smart contract is used to unlock the first execution result in the second blockchain upon receiving a zero-knowledge proof that satisfies the first constraint.

[0156] It is worth noting that in some implementation scenarios, the transaction initiator and the transaction recipient may need to jointly perform an operation (such as transferring an amount greater than Y yuan). In this case, the deployed second smart contract can also be used to unlock the first execution result if the received zero-knowledge proof satisfies the first constraint and the first execution result satisfies the received conditions associated with the zero-knowledge proof.

[0157] The transaction initiator is further configured to, upon completion of the deployment of the first smart contract, initiate a first call request, the first call request including the first zero-knowledge proof and the first condition, the first call request being used to invoke the first smart contract to unlock the second execution result.

[0158] As an example, after the first smart contract is deployed, the transaction recipient can send a deployment completion message to the transaction initiator. Continuing with the household registration transfer example above, the transaction initiator can initiate a first call request based on the first zero-knowledge proof and the first condition, thereby unlocking the second execution result and making the "target household registration information" in the first blockchain effective.

[0159] The transaction recipient is further configured to obtain the first zero-knowledge proof in the first call request and initiate a second call request, the second call request including the first zero-knowledge proof, and the second call request being used to call the second smart contract to unlock the first execution result.

[0160] The transaction recipient can obtain the first zero-knowledge proof and the first condition sent by the transaction initiator through the first smart contract. Continuing with the household registration transfer example above, the transaction initiator can initiate a second call request to unlock the first execution result on the second blockchain, thus invalidating the "target household registration information" in the second blockchain.

[0161] By employing the above technical solution, cross-chain transactions can be achieved without relying on third parties. Furthermore, the transaction conditions in this solution can be set based on application requirements, thus ensuring compatibility with various cross-chain scenarios.

[0162] It should be noted that the above embodiments exemplify the transaction verification methods from the perspective of the transaction initiator. However, those skilled in the art should understand that the above transaction verification methods are also applicable to the transaction recipient. When the above transaction verification methods are applied to the transaction recipient, the implementation process should be referred to the description in the above examples. For the sake of brevity, this disclosure will not elaborate further.

[0163] When the above transaction verification method is applied to the transaction recipient, the transaction recipient is used to set a second condition for the new first transaction, generate a second zero-knowledge proof based on the second condition, and add the second condition and the second constraint to the updated first transaction information, wherein the second zero-knowledge proof satisfies the second constraint;

[0164] The transaction initiator is used to execute a new first transaction within its own second blockchain network, obtain a third execution result, and save and lock the third execution result in the second blockchain of the second blockchain network; based on the second condition and the second constraint, it deploys a third smart contract in the second blockchain network.

[0165] The third smart contract is used to unlock the third execution result if the received zero-knowledge proof satisfies the second constraint and the third execution result satisfies the received conditions associated with the zero-knowledge proof.

[0166] In one possible implementation, the transaction recipient is further configured to, after generating a second zero-knowledge proof based on the second condition, save and lock the first execution result in the first blockchain of the first blockchain network in which it is located, and deploy a fourth smart contract in the first blockchain network, wherein the fourth smart contract is configured to unlock the first execution result upon receiving a zero-knowledge proof that satisfies the second constraint.

[0167] The transaction recipient is also configured to, upon completion of the deployment of the third smart contract, initiate a third call request, the third call request including the second zero-knowledge proof and the second condition, the third call request being used to call the third smart contract to unlock the third execution result;

[0168] The transaction initiator is also used to obtain the second zero-knowledge proof in the third call request and initiate a fourth call request, the fourth call request including the second zero-knowledge proof, and the fourth call request is used to call the fourth smart contract to unlock the first execution result.

[0169] Based on the same inventive concept, this disclosure provides a blockchain networking method, which is applied to the blockchain networking system provided in this disclosure. Figure 2 This is a flowchart of a blockchain networking method shown in this disclosure, refer to... Figure 2 The method includes:

[0170] In step S21, the transaction initiator queries the first node index of the transaction initiator based on the transaction recipient information.

[0171] In step S22, if the transaction initiator does not include the transaction recipient in the first node index, it sends a communication request to the target blockchain node in the first node index. The communication request includes transaction initiator information and transaction recipient information.

[0172] In step S23, the target blockchain node that receives the communication request queries the second node index it maintains based on the transaction recipient information.

[0173] In step S24, if the target blockchain node that receives the communication request includes the transaction recipient in the second node index, it will send the communication request to the transaction recipient.

[0174] In step S25, if the target blockchain node that receives the communication request does not include the transaction recipient in the second node index, a new target blockchain node is determined from the second node index, and the communication request is forwarded to the new target blockchain node.

[0175] by Figure 1 Taking add1 as the transaction initiator and add11 as the transaction receiver as an example, add1 can query the first node index it maintains based on add11's information (such as name, number, etc.). For example, it can query the first node index based on add11's name to determine whether the first node index includes add11. If add11 is included in the first node index, add1 can obtain add11's node address from the first node index and communicate with add11 through that node address.

[0176] If add11 is not included in the first node index, add1 can send a communication request to the target blockchain node in the first node index. The communication request includes information about the transaction initiator add1 and the transaction recipient add11.

[0177] In some implementation scenarios, add1 can send the communication request to each blockchain node in the first node index. That is, the target blockchain node can include all blockchain nodes in the first node index. (See reference...) Figure 1 In this case, add1 can send the communication request to add2 through add6.

[0178] Thus, the target blockchain node that receives the communication request queries its own maintained second node index based on the transaction recipient information. If the transaction recipient is included in the second node index, the communication request is sent to the transaction recipient. If the transaction recipient is not included in the second node index, a new target blockchain node is determined from the second node index, and the communication request is forwarded to the new target blockchain node.

[0179] Using the example above, add2 through add6 can query the second node index they maintain. If add11 is included in the second node index, the communication request is sent to add11. If add11 is not included in the second node index, a new target blockchain node can be determined from the second node index, and the communication request is sent to the new target blockchain node.

[0180] Taking add6 as an example, if add11 is not included in the second node index of add6, add6 can forward the communication request to the blockchain node in its node index, namely add7. Similarly, add7 can forward the communication request to add8, and add8 can forward the communication request to add9. add9 can query its own maintained second node index to determine add11 and forward the communication request to add11. In this way, after receiving the communication request, add11 can establish a communication connection with add1 based on the transaction initiator information in the communication request (i.e., add1's information, such as node address).

[0181] The above technical solution maintains node indexes in the blockchain nodes, enabling addressing of specific blockchain nodes based on these indexes. This addressing method overcomes the limitations of blockchain networks, allowing for networking between multiple blockchain networks. Furthermore, this technical solution eliminates the need for a relay blockchain network for addressing, thus offering the advantage of a simple system architecture.

[0182] Figure 3 This is a flowchart of a blockchain networking method shown in this disclosure, refer to... Figure 3 The method is in Figure 2 In addition to this, it also includes:

[0183] In step S36, in response to receiving the communication request, the transaction recipient establishes a communication connection with the transaction initiator based on the transaction initiator information in the communication request.

[0184] In step S37, in response to receiving a first transaction request from the other party, the transaction initiator and the transaction receiver execute the first transaction within their respective blockchain networks and obtain a first execution result. The first transaction request includes first transaction information, which includes the execution status of the transaction flow. The transaction flow includes multiple related transactions obtained by splitting the same cross-chain transaction.

[0185] In step S38, the transaction initiator and the transaction receiver determine a new first transaction based on the order of the transactions in the transaction flow.

[0186] In step S39, the transaction initiator and the transaction recipient update the first transaction information based on the first execution result and the new first transaction.

[0187] In step S310, the transaction initiator and the transaction receiver send a new first transaction request to the other party, which includes the updated first transaction information.

[0188] In this process, the transaction initiator sends an initial first transaction request to the transaction recipient based on the order of the transactions in the transaction flow.

[0189] Optionally, the method further includes:

[0190] The transaction initiator sets the first condition for the new first transaction;

[0191] The transaction initiator generates a first zero-knowledge proof based on the first condition;

[0192] The transaction initiator adds the first condition and the first constraint to the updated first transaction information, and the first zero-knowledge proof satisfies the first constraint;

[0193] The transaction recipient executes a new first transaction within its own first blockchain network and obtains a second execution result;

[0194] The transaction recipient saves and locks the second execution result in the first blockchain of the first blockchain network;

[0195] Based on the first condition and the first constraint, the transaction recipient deploys a first smart contract in the first blockchain network.

[0196] The first smart contract is configured to unlock the second execution result if the received zero-knowledge proof satisfies the first constraint and the second execution result satisfies the received condition associated with the zero-knowledge proof.

[0197] Optionally, the method includes:

[0198] After generating the first zero-knowledge proof based on the first condition, the transaction initiator saves and locks the first execution result in the second blockchain of the second blockchain network to which it belongs;

[0199] The transaction initiator deploys a second smart contract in the second blockchain network. The second smart contract is used to unlock the first execution result upon receiving a zero-knowledge proof that satisfies the first constraint.

[0200] When the first smart contract is deployed, the transaction initiator initiates a first call request. The first call request includes the first zero-knowledge proof and the first condition. The first call request is used to call the first smart contract to unlock the second execution result.

[0201] The transaction recipient obtains the first zero-knowledge proof from the first invocation request;

[0202] The transaction recipient initiates a second call request, which includes the first zero-knowledge proof and is used to call the second smart contract to unlock the first execution result.

[0203] Optionally, the method further includes:

[0204] The transaction recipient sets the second condition for the new first transaction;

[0205] The transaction recipient generates a second zero-knowledge proof based on the second condition;

[0206] The transaction recipient adds the second condition and the second constraint to the updated first transaction information, and the second zero-knowledge proof satisfies the second constraint;

[0207] The transaction initiator executes a new first transaction in its own second blockchain network, resulting in a third execution result.

[0208] The transaction initiator saves and locks the third execution result in the second blockchain of the second blockchain network;

[0209] Based on the second condition and the second constraint, the transaction initiator deploys a third smart contract in the second blockchain network.

[0210] The third smart contract is used to unlock the third execution result if the received zero-knowledge proof satisfies the second constraint and the third execution result satisfies the received conditions associated with the zero-knowledge proof.

[0211] Optionally, the method includes:

[0212] After generating a second zero-knowledge proof based on the second condition, the transaction recipient saves and locks the first execution result in the first blockchain of the first blockchain network to which it belongs;

[0213] The transaction recipient deploys a fourth smart contract in the first blockchain network. The fourth smart contract is used to unlock the first execution result upon receiving a zero-knowledge proof that satisfies the second constraint.

[0214] When the third smart contract is deployed, the transaction recipient initiates a third call request. The third call request includes the second zero-knowledge proof and the second condition. The third call request is used to call the third smart contract to unlock the third execution result.

[0215] The transaction initiator obtains the second zero-knowledge proof in the third invocation request;

[0216] The transaction initiator initiates a fourth call request, which includes the second zero-knowledge proof and is used to call the fourth smart contract to unlock the first execution result.

[0217] Optionally, the first transaction information may further include a summary of the first transaction, the current block hash value in the blockchain network, and a summary of the second transaction, wherein the second transaction is the preceding transaction of the first transaction in the transaction stream.

[0218] Optionally, it includes:

[0219] The transaction initiator sends query requests to each blockchain node in the first node index;

[0220] The transaction initiator obtains the query responses from each of the blockchain nodes and selects the blockchain node with the shortest response time as the target blockchain node.

[0221] Optionally, it also includes:

[0222] The blockchain node generates a node index based on the information of the transaction node, where the transaction node is a node that has conducted transactions with the blockchain node.

[0223] Regarding the method steps in the above embodiments, the specific implementation of each step has been described in detail in the system embodiments related to that step, and will not be elaborated here.

[0224] Figure 4 This is a block diagram illustrating an electronic device 400 according to an exemplary embodiment. Figure 4 As shown, the electronic device 400 may include a processor 401 and a memory 402. The electronic device 400 may also include one or more of a multimedia component 403, an input / output (I / O) interface 404, and a communication component 405.

[0225] The processor 401 controls the overall operation of the electronic device 400 to complete the steps performed by the transaction initiator or receiver in the aforementioned blockchain networking method. The memory 402 stores various types of data to support the operation of the electronic device 400. This data may include, for example, instructions for any application or method operating on the electronic device 400, and application-related data such as transaction data, sent and received messages, images, audio, video, etc. The memory 402 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random Access Memory (SRAM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Erasable Programmable Read-Only Memory (EPROM), Programmable Read-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. Multimedia component 403 may include a screen and an audio component. The screen may be, for example, a touchscreen, and the audio component is used to output and / or input audio signals. For example, the audio component may include a microphone for receiving external audio signals. The received audio signals may be further stored in memory 402 or transmitted via communication component 405. The audio component also includes at least one speaker for outputting audio signals. I / O interface 404 provides an interface between processor 401 and other interface modules, such as a keyboard, mouse, buttons, etc. These buttons may be virtual or physical buttons. Communication component 405 is used for wired or wireless communication between the electronic device 400 and other devices. Wireless communication, such as Wi-Fi, Bluetooth, Near Field Communication (NFC), 2G, 3G, 4G, NB-IoT, eMTC, or other 5G technologies, or combinations thereof, is not limited here. Therefore, the corresponding communication component 405 may include: a Wi-Fi module, a Bluetooth module, an NFC module, etc.

[0226] In an exemplary embodiment, the electronic device 400 may be implemented by one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components to perform the steps executed by the transaction initiator or transaction recipient in the blockchain networking method described above.

[0227] In another exemplary embodiment, a computer-readable storage medium including program instructions is also provided. When executed by a processor, these program instructions implement the steps performed by the transaction initiator or transaction recipient in the aforementioned blockchain networking method. For example, the computer-readable storage medium may be the aforementioned memory 402 including program instructions, which may be executed by the processor 401 of the electronic device 400 to complete the steps performed by the transaction initiator or transaction recipient in the aforementioned blockchain networking method.

[0228] In another exemplary embodiment, a computer program product is also provided, the computer program product comprising a computer program executable by a programmable device, the computer program having a code portion for performing steps performed by the transaction initiator or transaction recipient in the blockchain networking method described above when executed by the programmable device.

[0229] The preferred embodiments of this disclosure have been described in detail above with reference to the accompanying drawings. However, this disclosure is not limited to the specific details of the above embodiments. Within the scope of the technical concept of this disclosure, various simple modifications can be made to the technical solutions of this disclosure, and these simple modifications all fall within the protection scope of this disclosure.

[0230] It should also be noted that the various specific technical features described in the above specific embodiments can be combined in any suitable manner without contradiction. In order to avoid unnecessary repetition, this disclosure will not describe the various possible combinations separately.

[0231] Furthermore, various different embodiments of this disclosure can be combined in any way, as long as they do not violate the spirit of this disclosure, they should also be regarded as the content disclosed in this disclosure.

Claims

1. A blockchain networking system, characterized in that, It includes multiple blockchain nodes, each of which is a node in one or more blockchain networks. Each blockchain node maintains a node index, which includes blockchain nodes that can establish communication with it. The transaction initiator among the plurality of blockchain nodes is used to query the first node index of the transaction initiator based on the transaction recipient information. If the transaction recipient is not included in the first node index, the transaction initiator sends a communication request to the target blockchain node in the first node index. The communication request includes the transaction initiator information and the transaction recipient information. The target blockchain node that receives the communication request is to query the second node index it maintains based on the transaction recipient information. If the transaction recipient is included in the second node index, the communication request is sent to the transaction recipient. If the transaction recipient is not included in the second node index, a new target blockchain node is determined from the second node index, and the communication request is forwarded to the new target blockchain node. The transaction recipient is configured to, in response to receiving the communication request, establish a communication connection with the transaction initiator based on the transaction initiator information in the communication request; The transaction initiator and the transaction receiver are configured to, in response to receiving a first transaction request sent by the other party, execute a first transaction in their respective blockchain networks to obtain a first execution result. The first transaction request includes first transaction information, which includes the execution status of a transaction flow. The transaction flow includes multiple related transactions obtained by splitting the same cross-chain transaction. A new first transaction is determined based on the order of the transactions in the transaction flow. The first transaction information is updated according to the first execution result and the new first transaction. A new first transaction request is then sent to the other party, which includes the updated first transaction information. The transaction initiator sends an initial first transaction request to the transaction receiver based on the order of the transactions in the transaction flow.

2. The blockchain networking system according to claim 1, characterized in that, The transaction initiator is used to set a first condition for the new first transaction, generate a first zero-knowledge proof based on the first condition, and add the first condition and the first constraint to the updated first transaction information, wherein the first zero-knowledge proof satisfies the first constraint. The transaction recipient is used to execute a new first transaction in the first blockchain network where it is located, obtain a second execution result, and save and lock the second execution result in the first blockchain of the first blockchain network. Based on the first condition and the first constraint, deploy the first smart contract in the first blockchain network; The first smart contract is configured to unlock the second execution result if the received zero-knowledge proof satisfies the first constraint and the second execution result satisfies the received condition associated with the zero-knowledge proof.

3. The blockchain networking system according to claim 2, characterized in that, The transaction initiator is further configured to, after generating a first zero-knowledge proof based on the first condition, save and lock the first execution result in the second blockchain of the second blockchain network in which it is located, and deploy a second smart contract in the second blockchain network. The second smart contract is configured to unlock the first execution result upon receiving a zero-knowledge proof that satisfies the first constraint. The transaction initiator is also used to initiate a first call request when the first smart contract is deployed. The first call request includes the first zero-knowledge proof and the first condition. The first call request is used to call the first smart contract to unlock the second execution result. The transaction recipient is further configured to obtain the first zero-knowledge proof in the first call request and initiate a second call request, the second call request including the first zero-knowledge proof, and the second call request being used to call the second smart contract to unlock the first execution result.

4. The blockchain networking system according to claim 1, characterized in that, The transaction recipient is configured to: set a second condition for the new first transaction, generate a second zero-knowledge proof based on the second condition, and add the second condition and the second constraint to the updated first transaction information, wherein the second zero-knowledge proof satisfies the second constraint; The transaction initiator is used to execute a new first transaction in its own second blockchain network, obtain a third execution result, and save and lock the third execution result in the second blockchain of the second blockchain network. Based on the second condition and the second constraint, a third smart contract is deployed in the second blockchain network; The third smart contract is used to unlock the third execution result if the received zero-knowledge proof satisfies the second constraint and the third execution result satisfies the received conditions associated with the zero-knowledge proof.

5. The blockchain networking system according to claim 4, characterized in that, The transaction recipient is further configured to, after generating a second zero-knowledge proof based on the second condition, save and lock the first execution result in the first blockchain of the first blockchain network in which it is located, and deploy a fourth smart contract in the first blockchain network. The fourth smart contract is configured to unlock the first execution result upon receiving a zero-knowledge proof that satisfies the second constraint. The transaction recipient is also configured to, upon completion of the deployment of the third smart contract, initiate a third call request, the third call request including the second zero-knowledge proof and the second condition, the third call request being used to call the third smart contract to unlock the third execution result; The transaction initiator is also used to obtain the second zero-knowledge proof in the third call request and initiate a fourth call request, the fourth call request including the second zero-knowledge proof, and the fourth call request is used to call the fourth smart contract to unlock the first execution result.

6. The blockchain networking system according to any one of claims 1 to 5, characterized in that, The first transaction information also includes a summary of the first transaction, the current block hash value in the blockchain network, and a summary of the second transaction, which is the transaction preceding the first transaction in the transaction stream.

7. The blockchain networking system according to any one of claims 1 to 5, characterized in that, The transaction initiator is used to send query requests to each blockchain node in the first node index, obtain the query responses from each blockchain node, and select the blockchain node with the shortest response time as the target blockchain node.

8. The blockchain networking system according to any one of claims 1 to 5, characterized in that, The blockchain node is used to generate a node index for the blockchain node based on the information of the transaction node, wherein the transaction node is a node that has conducted transactions with the blockchain node.

9. A blockchain networking method, characterized in that, The method, applied to the blockchain networking system according to any one of claims 1 to 8, comprises: The transaction initiator queries the first node index of the transaction initiator based on the transaction recipient information; If the transaction initiator does not include the transaction recipient in the first node index, the initiator sends a communication request to the target blockchain node in the first node index. The communication request includes the transaction initiator information and the transaction recipient information. Upon receiving the communication request, the target blockchain node queries its own maintained second node index based on the transaction recipient information. If the target blockchain node that receives the communication request includes the transaction recipient in the second node index, it will send the communication request to the transaction recipient. If the target blockchain node receiving the communication request does not include the transaction recipient in the second node index, a new target blockchain node is determined from the second node index, and the communication request is forwarded to the new target blockchain node.

Images