A transaction synchronization method based on a blockchain network and related equipment

Abstract

Embodiments of the present application provide a transaction synchronization method based on a blockchain network and related equipment, the blockchain network comprising a core subnetwork and a witness subnetwork, the transaction synchronization method being executed by a target service node in the witness subnetwork; the transaction synchronization method comprises: when transactions stored in the witness subnetwork fall behind transactions stored in the core subnetwork, determining indication information for indicating a transaction falling behind degree of the target service node; based on the indication information of the target service node and indication information of other service nodes in the witness subnetwork, negotiating a relay order of each service node in the witness subnetwork when relaying to synchronize transactions; in the process of relaying to synchronize transactions, if it is detected that the relay order of the target service node arrives, then falling behind transactions of the target service node are synchronized from a relay node of the target service node. By using the embodiments of the present application, the transaction synchronization pressure of consensus nodes in the core subnetwork can be effectively alleviated.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a transaction synchronization method based on a blockchain network, a transaction synchronization device based on a blockchain network, a computer device, a computer-readable storage medium, and a computer program product. Background Technology

[0002] With the rapid development of computer technology, blockchain networks have received widespread attention. More and more users are leveraging blockchain networks to execute transactions and store them through the blockchain itself, ensuring secure and reliable transaction execution. A blockchain network can include business nodes and consensus nodes. Each business node synchronizes transactions with the consensus node. When the transactions stored on a business node lag significantly behind those stored on the consensus node, the consensus node needs to synchronize the lagging transactions from each business node, placing immense pressure on the consensus node's transaction synchronization capabilities. Summary of the Invention

[0003] This application provides a transaction synchronization method and related equipment for a basic blockchain network, which can effectively alleviate the transaction synchronization pressure on consensus nodes in the core sub-network.

[0004] On one hand, this application provides a transaction synchronization method based on a blockchain network. The blockchain network includes a core sub-network and a witness sub-network. The core sub-network includes one or more consensus nodes, and the witness sub-network includes one or more business nodes. The transaction synchronization method is executed by the target business node in the witness sub-network. The transaction synchronization method is as follows:

[0005] When a transaction stored in the witness subnetwork lags behind a transaction stored in the core subnetwork, an indication information is determined to indicate the degree of lag in the transaction of the target business node. The degree of lag reflects the difference between the transactions stored in the business node and the transactions stored in the consensus node in the core subnetwork.

[0006] Based on the indication information of the target business node and the indication information of other business nodes in the witness subnetwork, negotiate the relay order of each business node in the witness subnetwork when relaying synchronous transactions.

[0007] During the relay synchronization of transactions, if the relay order of the target business node is detected to have arrived, the lagging transactions of the target business node are synchronized from the relay node of the target business node. Lagging transactions refer to transactions that are not stored in the corresponding business node but are stored in the relay node of the corresponding business node.

[0008] Specifically, when the target business node is in the first position in the relay order, the relay node is a consensus node; when the target business node is not in the first position in the relay order, the relay node is a business node.

[0009] Accordingly, this application provides a transaction synchronization device based on a blockchain network. The blockchain network includes a core sub-network and a witness sub-network. The core sub-network includes one or more consensus nodes, and the witness sub-network includes one or more business nodes. The transaction synchronization device is set in a target business node in the witness sub-network. The transaction synchronization device includes:

[0010] The determining unit is used to determine indication information to indicate the degree of lag of transactions in the target business node when the transactions stored in the witness subnetwork lag behind the transactions stored in the core subnetwork. The degree of lag is used to reflect the difference between the transactions stored in the business node and the transactions stored in the consensus node in the core subnetwork.

[0011] The processing unit is used to negotiate the relay order of each business node in the witness subnetwork during the relay synchronization transaction based on the indication information of the target business node and the indication information of other business nodes in the witness subnetwork.

[0012] The processing unit is also used to synchronize the lagging transactions of the target business node from the relay node of the target business node if the relay order of the target business node is detected during the relay synchronization process. The lagging transactions refer to transactions that are not stored in the corresponding business node but are stored in the relay node of the corresponding business node.

[0013] Specifically, when the target business node is in the first position in the relay order, the relay node is a consensus node; when the target business node is not in the first position in the relay order, the relay node is a business node.

[0014] In one implementation, the processing unit, when negotiating the relay order of various business nodes in the witness subnetwork during relay synchronization transactions based on the indication information of the target business node and the indication information of other business nodes in the witness subnetwork, specifically performs the following steps:

[0015] The node identifiers of each business node are sorted according to the degree of transaction lag, from low to high, based on the indication information of each business node in the witness subnetwork.

[0016] The relay order of each business node during the relay synchronization transaction is determined based on the sorting results. The relay order of any business node is positively correlated with the position of the node identifier of any business node in the sorting results.

[0017] In one implementation, the processing unit, when negotiating the relay order of various business nodes in the witness subnetwork during relay synchronization transactions based on the indication information of the target business node and the indication information of other business nodes in the witness subnetwork, specifically performs the following steps:

[0018] Based on the indication information of the target business node and the indication information of other business nodes in the witness subnetwork, negotiation of a common synchronization node is carried out in the witness subnetwork; a common synchronization node refers to a business node that needs to synchronize transactions from the consensus node in the core subnetwork and provides synchronization services for the remaining business nodes in the witness subnetwork.

[0019] Based on the negotiation results of the public synchronization node, the relay order of each business node in the relay synchronization transaction is determined respectively; among them, when any business node is the negotiated public synchronization node, the relay order of any business node is first, and when any business node is not the negotiated public synchronization node, the relay order of any business node is not first.

[0020] In one implementation, after synchronizing the lagging transactions of the target business node from the relay node of the target business node, the processing unit is further configured to perform the following steps:

[0021] If there is a reference business node in the witness subnetwork, the reference business node is a business node that uses the target business node as a relay node, then the reference business node is notified to synchronize the transaction.

[0022] When a transaction synchronization request is received from a reference service node, the lagging transactions of the reference service node are determined based on the transactions currently stored in the target service node and the transactions currently stored in the reference service node.

[0023] The lagging transactions of the reference service node are sent to the reference service node so that the reference service node can update the currently stored transactions based on the received lagging transactions.

[0024] In one implementation, the determining unit, when determining the indication information for indicating the transaction lag level of the target business node, specifically performs the following steps:

[0025] Obtain the first number of transactions stored in the consensus nodes of the core sub-network, and determine the second number of transactions stored in the target business node;

[0026] Calculate the difference between the first transaction count and the second transaction count to obtain the number of lagging transactions for the target business node;

[0027] Based on the number of lagging transactions of the target business node, determine the indication information used to indicate the degree of transaction lag of the target business node.

[0028] In one implementation, the processing unit is further configured to perform the following steps:

[0029] If the number of lagging transactions of the target business node is equal to the target number, then the target business node will not participate in the relay synchronization transaction.

[0030] If the number of lagging transactions of the target business node is greater than the target number, then the step of determining the indication information used to indicate the degree of transaction lag of the target business node is triggered based on the number of lagging transactions of the target business node.

[0031] In one implementation, when the determining unit determines indication information to indicate the degree of transaction lag of the target business node based on the number of lagging transactions of the target business node, it specifically performs the following steps:

[0032] Obtain the number of lagging transactions of other business nodes in the witness subnetwork, and determine the difference in the number of lagging transactions between any two business nodes in the witness subnetwork based on the number of lagging transactions of other business nodes and the number of lagging transactions of the target business node.

[0033] Based on the difference in the number of lagging transactions between any two business nodes in the witness subnetwork, detect the requirement to disturb the number of lagging transactions of the target business node.

[0034] If a requirement for the number of lagging transactions that disturbs the target business node is detected, a random factor for the target business node is generated.

[0035] Based on the random factor of the target business node, the number of lagging transactions of the target business node is perturbed, and the perturbation result is used as an indication of the degree of transaction lag of the target business node.

[0036] In one implementation, when the determining unit determines indication information to indicate the degree of transaction lag of the target business node based on the number of lagging transactions of the target business node, it is also used to perform the following steps:

[0037] If no demand for a number of lagging transactions that would disturb the target business node is detected, then the number of lagging transactions of the target business node will be used as an indication of the degree of transaction lag of the target business node.

[0038] In one implementation, the determining unit, when detecting the requirement for the number of lagging transactions to disturb the target business node based on the difference in the number of lagging transactions between any two business nodes in the witness sub-network, specifically performs the following steps:

[0039] The system checks whether the difference in the number of lagging transactions between any two service nodes in the witness subnetwork is less than a difference threshold; if it is less, it determines that a requirement for detecting the number of lagging transactions that are disturbing the target service node has been detected; if it is not less, it determines that a requirement for detecting the number of lagging transactions that are disturbing the target service node has not been detected; or...

[0040] The system detects whether there exists a difference in the number of lagging transactions between at least two business nodes in the witness subnetwork that is less than a difference threshold. If such a difference exists, the system determines whether a requirement has been detected for the number of lagging transactions that are disturbing the target business node. If no such difference exists, the system determines whether a requirement has been detected for the number of lagging transactions that are disturbing the target business node.

[0041] In one implementation, the determining unit, when perturbing the number of lagging transactions of the target business node based on the random factor of the target business node, specifically performs the following steps:

[0042] Calculate the product between the random factor of the target business node and the number of lagging transactions of the target business node;

[0043] The perturbation result is the product of the random factor of the target business node and the number of lagging transactions of the target business node.

[0044] In one implementation, when determining the unit to generate the random factor for the target service node, the following steps are specifically performed:

[0045] Obtain the random range corresponding to the target business node, and ensure that the random ranges corresponding to each business node in the witness sub-network are the same.

[0046] Generate random factors that fall within the random range.

[0047] In one implementation, determining the unit also serves to perform the following steps:

[0048] When the witness subnetwork malfunctions, obtain the number of lagging transactions of the target business node and the number of lagging transactions of other business nodes in the witness subnetwork; the witness subnetwork malfunction includes any of the following: a failure in the data center where the witness subnetwork is deployed, and a failure in the external communication network of the witness subnetwork;

[0049] When the number of lagging transactions of each business node in the witness subnetwork meets the lagging condition, it is determined that the transactions stored in the witness subnetwork are lagging behind the transactions stored in the core subnetwork.

[0050] When the number of lagging transactions of each business node in the witness subnetwork does not meet the lagging condition, it is determined that the transactions stored in the witness subnetwork are not lagging behind the transactions stored in the core subnetwork.

[0051] The lagging condition refers to the situation where at least one business node in the witness sub-network has a lagging transaction count greater than the lagging quantity threshold.

[0052] In one implementation, when the transactions stored in the witness subnetwork are not behind the transactions stored in the core subnetwork, each business node in the witness subnetwork connects to the consensus node in the core subnetwork, and each business node synchronizes transactions from the core subnetwork.

[0053] Accordingly, this application provides a computer device, wherein the blockchain network includes a core sub-network and a witness sub-network, the core sub-network includes one or more consensus nodes, the witness sub-network includes one or more business nodes, and the computer device is a target business node in the witness sub-network; the computer device includes a processor and a computer-readable storage medium, wherein:

[0054] A processor is adapted to implement a computer program; a computer-readable storage medium stores the computer program, which is adapted to be loaded by the processor and executed by the aforementioned blockchain-based transaction synchronization method.

[0055] Accordingly, embodiments of this application provide a computer-readable storage medium storing a computer program. When the computer program is read and executed by the processor of a computer device, the computer device performs the aforementioned transaction synchronization method based on a blockchain network.

[0056] Accordingly, embodiments of this application provide a computer program product or computer program, which includes computer instructions stored in a computer-readable storage medium. The processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the aforementioned blockchain-based transaction synchronization method.

[0057] In this embodiment, the blockchain network may include a core subnetwork and a witness subnetwork. When transactions stored in the witness subnetwork lag behind those stored in the core subnetwork, the target business node in the witness subnetwork can determine indication information to indicate the degree of lag in its transactions. Based on the indication information of the target business node and the indication information of other business nodes in the witness subnetwork, the relay order of each business node in the witness subnetwork during transaction synchronization is negotiated. During the relay synchronization process, if the relay order of the target business node is detected to have arrived, the target business node can synchronize its lagging transactions from its relay nodes. Wherein, when the target business node's relay order is first, the relay node of the target business node is a node in the core subnetwork... A consensus node is established where, when the target business node's relay order is not first, the relay node is a business node within the witness subnetwork. Therefore, when transactions stored in the witness subnetwork lag behind those stored in the core subnetwork, the relay order of transactions among the business nodes in the witness subnetwork is negotiated. Only the business node with the first relay order in the witness subnetwork needs to synchronize the lagging transactions from the consensus node in the core subnetwork. Business nodes with a non-first relay order in the witness subnetwork synchronize the lagging transactions from the business nodes in the witness subnetwork. The transaction synchronization pressure on the consensus nodes in the core subnetwork is distributed among the business nodes in the witness subnetwork, effectively alleviating the transaction synchronization pressure on the consensus nodes in the core subnetwork. Attached Figure Description

[0058] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0059] Figure 1 This is a schematic diagram of the architecture of a single-layer blockchain network provided in an embodiment of this application;

[0060] Figure 2 This is a schematic diagram of a blockchain structure provided in an embodiment of this application;

[0061] Figure 3 This is a schematic diagram of a block generation process provided in an embodiment of this application;

[0062] Figure 4a This is a schematic diagram of the architecture of a two-layer blockchain network provided in an embodiment of this application;

[0063] Figure 4bThis is a schematic diagram of another two-layer blockchain network architecture provided in the embodiments of this application;

[0064] Figure 5 This is a flowchart illustrating a transaction synchronization method based on a blockchain network provided in an embodiment of this application;

[0065] Figure 6 This is a schematic diagram of a multi-active form of a witness subnetwork provided in an embodiment of this application;

[0066] Figure 7a This is a schematic diagram of a witness sub-network relay synchronous transaction provided in an embodiment of this application;

[0067] Figure 7b This is a schematic diagram of another witness sub-network relay synchronous transaction provided in an embodiment of this application;

[0068] Figure 8 This is a flowchart illustrating another transaction synchronization method based on a blockchain network provided in an embodiment of this application;

[0069] Figure 9 This is a schematic diagram of a transaction synchronization method for a witness subnetwork provided in an embodiment of this application;

[0070] Figure 10 This is a schematic diagram of the structure of a transaction synchronization device based on a blockchain network provided in an embodiment of this application;

[0071] Figure 11 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

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

[0073] Traditional blockchain networks, or P2P (Peer-to-Peer) networks, are peer-to-peer connections. The nodes in these connections are called peers. P2P networks are based on a specific network protocol that eliminates the need for a central node to maintain network state. Each node maintains the overall network state and its connections with neighboring nodes through broadcast interactions. A P2P network is a single-layer blockchain network, which can be understood as... Figure 1The data sharing system 10 shown is a system for data sharing between nodes. This system may include multiple nodes 101, which can refer to clients, terminals, or servers within the system. Each node 101 receives input information during normal operation and maintains shared data within the system based on this information. To ensure interoperability within the system, information connections exist between nodes, allowing for information transmission. For example, when any node in the system receives input information, other nodes obtain this information according to a consensus algorithm and store it as part of the shared data, ensuring consistency across all nodes. Each node in the system has a corresponding node identifier, and can also store the node identifiers of other nodes. This allows for the broadcasting of generated blocks to other nodes based on their identifiers. Each node maintains a node identifier list as shown in Table 1, storing the node name and identifier accordingly. The node identifier can be an IP (Internet Protocol) address or any other information that can be used to identify the node. Table 1 uses IP addresses as an example only:

[0074] Table 1

[0075] Node Name Node identifier Node 1 117.114.151.174 Node 2 117.116.189.145 … … Node N 119.123.789.258

[0076] Each node in the data-sharing system stores the same blockchain. A blockchain consists of multiple blocks, as shown in [reference needed]. Figure 2 The blockchain structure shown consists of multiple blocks. The genesis block includes a block header and a block body. The block header stores input information feature values, version number, timestamp, and difficulty value, while the block body stores the input information. The next block after the genesis block takes the genesis block as its parent block. The next block also includes a block header and a block body. The block header stores the input information feature values ​​of the current block, the block header feature values ​​of the parent block, version number, timestamp, and difficulty value, and so on. This ensures that the block data stored in each block is related to the block data stored in the parent block, guaranteeing the security of the input information in the blocks.

[0077] When generating the individual blocks in the blockchain, see [link / reference]. Figure 3The block generation process shown involves the following steps: When a node in the blockchain receives input information, it verifies the input information, stores it in a memory pool, and updates its hash tree used to record the input information. Then, it updates the timestamp to the time the input information was received and attempts to calculate the feature value multiple times using different random numbers, ensuring that the calculated feature value satisfies the following formula:

[0078] SHA256(SHA256(version+prev_hash+merkle_root+ntime+nbits+x)) <TARGET

[0079] Among them, SHA256 (Secure Hash Algorithm) is the feature value algorithm used to calculate the feature value; version (version number) is the version information of the relevant block protocol in the blockchain; prev_hash is the block header feature value of the parent block of the current block; merkle_root is the feature value of the input information; ntime is the update time of the update timestamp; nbits is the current difficulty, which is a fixed value for a period of time and is determined again after exceeding the fixed time period; x is a random number; TARGET is the feature value threshold, which can be determined based on nbits.

[0080] Thus, when a random number satisfying the above formula is calculated, the information can be stored accordingly, generating a block header and a block body to obtain the current block. Subsequently, the node where the blockchain resides sends the newly generated block to other nodes in its data sharing system based on the node identifiers of other nodes in the data sharing system. The other nodes then verify the newly generated block and add it to their stored blockchain after verification.

[0081] However, the aforementioned single-layer blockchain network has some problems in practical application scenarios. Due to considerations of node utilization in a single-layer blockchain network, not all nodes need to be deployed as transaction execution nodes, and not all nodes have sufficient resources and necessity to participate in blockchain consensus. Regarding transaction security in a single-layer blockchain network, when confidential transactions are involved, these transactions are shared within the network, making it difficult to store transactions confidentially and securely. A transaction can be understood as a computer science transaction, including operations that need to be submitted to the blockchain network for execution and the corresponding execution results. Given the conventional use of the term "transaction" in blockchain technology, this application follows this convention. To address the problems of single-layer blockchain networks, this application proposes a two-layer blockchain network. The transaction synchronization scheme proposed in this application is also based on a two-layer blockchain network. The network architecture of the two-layer blockchain network is described below:

[0082] The network architecture of a two-layer blockchain network is as follows: Figure 4a As shown, the two-layer blockchain network 40 may include a core sub-network 401 and a witness sub-network 402. The core sub-network may include one or more consensus nodes, which can run the blockchain consensus protocol for consensus-based ledger recording on the blockchain. The consensus nodes store the complete transactions of the two-layer blockchain network. The witness subnetwork can include one or more business nodes (also known as SPVs (Simplified Payment Verification) nodes). These business nodes primarily execute business transactions, do not participate in accounting consensus, and synchronize transactions from the core subnetwork via identity authentication (specifically, synchronizing all block header data and some authorized visible block data). Typically, the core subnetwork and the witness subnetwork reside in different network environments. The witness subnetwork is generally in a public network, while the core subnetwork is typically in a private network. Furthermore, because the core subnetwork is in a relatively secure private network, the consensus mechanisms inherently ensure security for mutual access between consensus nodes, eliminating the need for additional identity management and network control. In contrast, the witness subnetwork is in a public network, and its business nodes may be accessed by other unidentified network terminals. Therefore, the access of the witness subnetwork and other potential nodes to the core subnetwork requires strict control.

[0083] In more detail, the network architecture of a two-layer blockchain network can be further subdivided; see [link to relevant documentation]. Figure 4bThe illustrated two-layer blockchain network architecture includes a core subnetwork 401 that may include a routing proxy layer 4011 and a consensus layer 4012. The routing proxy layer 4011 may include one or more routing proxy nodes, and the consensus layer 4012 may include one or more consensus nodes. The routing proxy layer can be used to isolate the consensus layer and the witness subnetwork within the core subnetwork. Communication data between the consensus layer and the witness subnetwork in the core subnetwork requires forwarding by the routing proxy nodes in the routing proxy network.

[0084] In this application, any consensus node or business node can be a terminal or a server. The terminal mentioned in this embodiment can be a smartphone, tablet, laptop, desktop computer, smartwatch, in-vehicle terminal, smart voice interaction device, or smart home appliance, but is not limited to these. The server mentioned in this embodiment can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN (Content Delivery Network), and big data and artificial intelligence platforms.

[0085] It is understood that the two-layer blockchain network described in the embodiments of this application is for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and does not constitute a limitation on the technical solutions provided in the embodiments of this application. As those skilled in the art will know, with the evolution of blockchain network architecture and the emergence of new business scenarios, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems.

[0086] Based on the aforementioned two-layer blockchain network, this application proposes a transaction synchronization scheme based on a blockchain network (i.e., a two-layer blockchain network). In this scheme, when a transaction stored in the witness sub-network lags behind a transaction stored in the core sub-network, each business node in the witness sub-network can negotiate the relay order for synchronizing transactions. For a business node in the witness sub-network that is first in the relay order, it can synchronize its lagging transactions from the consensus nodes in the core sub-network. For any business node in the witness sub-network that is not first in the relay order, it can determine its relay node from the witness sub-network and synchronize its lagging transactions from that relay node. Compared to a scheme where each business node in the witness sub-network synchronizes its lagging transactions from the consensus nodes in the core sub-network, the transaction synchronization scheme provided in this application can reasonably distribute the transaction synchronization pressure of the consensus nodes in the core sub-network to the witness sub-network, effectively alleviating the transaction synchronization pressure on the consensus nodes in the core sub-network.

[0087] based on Figure 4a and Figure 4b The two-layer blockchain network shown below, combined with... Figures 5-9 The transaction synchronization scheme provided in the embodiments of this application will be described in more detail.

[0088] This application provides a transaction synchronization method based on a blockchain network. This method primarily involves each business node in a witness subnetwork negotiating the relay order of transaction synchronization. This blockchain-based transaction synchronization method can be executed by a target business node in the witness subnetwork, which can be any business node within the witness subnetwork. For example... Figure 5 As shown, the transaction synchronization method based on the blockchain network includes the following steps S501-S503:

[0089] S501, when a transaction stored in the witness sub-network lags behind a transaction stored in the core sub-network, determine indication information to indicate the degree of lag in the transaction of the target business node.

[0090] A blockchain network (i.e., the two-layer blockchain network mentioned above) may include a core sub-network and a witness sub-network. The core sub-network may include one or more consensus nodes, and the witness sub-network may include one or more business nodes. The consensus nodes in the core sub-network store complete transactions in the blockchain network. In one implementation, when a transaction stored in the witness sub-network lags behind a transaction stored in the core sub-network, the witness sub-network can enter a relay order negotiation phase. During the relay order negotiation phase, each business node in the witness sub-network can negotiate the relay order for synchronizing transactions. The negotiated relay order determines the order in which each business node synchronizes transactions, so that when each business node reaches its respective relay order, it can synchronize its lagging transactions from its respective relay node. Lagging transactions refer to transactions that are not stored in the corresponding business node but are stored in the relay node of the corresponding business node.

[0091] For a target service node in the witness subnetwork, when the transactions stored in the witness subnetwork lag behind the transactions stored in the core subnetwork, the target service node can determine indication information to indicate the degree of lag in its transactions. The degree of lag can be used to reflect the difference between the transactions stored by the service node and the transactions stored by the consensus node in the core subnetwork. In other words, the degree of lag in the target service node's transactions can be used to reflect the difference between the transactions stored by the target service node and the transactions stored by the consensus node in the core subnetwork. The indication information of the target service node can be used to negotiate the relay order when performing relay synchronization transactions in the witness subnetwork. That is, when the transactions stored in the witness subnetwork lag behind the transactions stored in the core subnetwork, steps S501-S503 provided in the embodiments of this application can be executed.

[0092] It is worth noting that before the witness subnetwork enters the relay order negotiation phase, it can also hold a vote on whether to enter the relay order negotiation phase. When the vote passes, the witness subnetwork is confirmed to be ready to proceed to the relay order negotiation phase. Specifically, passing the vote means that the number of business nodes in the witness subnetwork agreeing to enter the relay order negotiation phase is greater than or equal to a voting threshold. This threshold can be the total number of business nodes in the witness subnetwork, or it can be the product of the total number of business nodes and a target ratio (e.g., 2 / 3 or 4 / 5). In other words, when transactions stored in the witness subnetwork lag behind those stored in the core subnetwork, the witness subnetwork's entry into the relay order negotiation phase is agreed upon by all or some of its business nodes. This ensures that the entry of each business node into the relay order negotiation phase is recognized by the witness subnetwork.

[0093] In another implementation, when the transactions stored in the witness subnetwork are not behind those stored in the core subnetwork, each business node in the witness subnetwork is in a multi-active state. This multi-active state can be understood as follows: each business node in the witness subnetwork is independently available (i.e., each business node can provide services independently), each business node is connected to the consensus node in the core subnetwork, each business node synchronizes transactions from the core subnetwork, and any two business nodes in the witness subnetwork maintain a full-connection heartbeat (i.e., maintain an uninterrupted connection between any two business nodes in the witness subnetwork), allowing them to communicate with each other. Each business node can maintain a list of other surviving business nodes in the witness subnetwork. The list of surviving nodes maintained by any business node includes the node identifiers of other surviving business nodes in the witness subnetwork besides the current business node. A surviving business node is a business node that can be used normally and independently. An example of the multi-active state of the witness subnetwork can be found here. Figure 6 , Figure 6 The witness subnetwork shown includes three business nodes: business node 1, business node 2, and business node 3. Each of the three business nodes connects to the consensus node in the core subnetwork through the core subnetwork entry point. Each of the three business nodes synchronizes transactions from the consensus node in the core consensus network, and a full-connection heartbeat is maintained between any two of the three business nodes (for example, a full-connection heartbeat is maintained between business node 1 and business node 2, between business node 2 and business node 3, and between business node 1 and business node 3).

[0094] It should be noted that whether transactions stored in the witness sub-network lag behind those stored in the core sub-network can be determined when the witness sub-network experiences an anomaly by checking whether the number of lagging transactions at each business node in the witness sub-network meets the lag condition. Specifically, an anomaly in the witness sub-network can include any of the following: a failure in the data center where the witness sub-network is deployed, or a failure in the external communication network of the witness sub-network. In other words, when either the data center or the external communication network of the witness sub-network fails, it can be determined that the witness sub-network is anomaly. Both failures can prevent the witness sub-network from synchronizing transactions with the consensus nodes in the core sub-network, resulting in transaction lag. When the witness sub-network is anomaly, the number of lagging transactions at the target business node and the number of lagging transactions at other business nodes in the witness sub-network (i.e., those other than the target business node) can be obtained. The number of lagging transactions for each business node is defined as follows: the number of lagging transactions for the target business node is the difference between the number of transactions stored in the core subnetwork and the number of transactions stored in the target business node; the number of lagging transactions for other business nodes is the difference between the number of transactions stored in the core subnetwork and the number of transactions stored in other business nodes. When the number of lagging transactions for each business node in the witness subnetwork meets the lagging condition, it can be determined that the transactions stored in the witness subnetwork are lagging behind the transactions stored in the core subnetwork. When the number of lagging transactions for each business node in the witness subnetwork does not meet the lagging condition, it can be determined that the transactions stored in the witness subnetwork are not lagging behind the transactions stored in the core subnetwork.

[0095] The "lagging condition" refers to the following: at least one business node in the witness sub-network has a lagging transaction count greater than the lagging transaction count threshold. In other words, if at least one business node in the witness sub-network has a lagging transaction count greater than the lagging transaction count threshold (e.g., 100,000), it can be determined that the transactions stored in the witness sub-network are lagging behind the transactions stored in the core sub-network. If the lagging transaction count of each business node in the witness sub-network is not greater than the lagging transaction count threshold, it can be determined that the transactions stored in the witness sub-network are not lagging behind the transactions stored in the core sub-network. This can be understood as follows: when the transactions stored in the witness sub-network lag significantly behind those stored in the core sub-network (i.e., the number of lagging transactions at business nodes in the witness sub-network exceeds the lag threshold), the witness sub-network enters the relay order negotiation phase. When the transactions stored in the witness sub-network are not lagging behind those stored in the core sub-network (including transactions stored in the witness sub-network being synchronized with those stored in the core sub-network (i.e., the number of lagging transactions at each business node in the witness sub-network is 0), or the transactions stored in the witness sub-network lag slightly behind those stored in the core sub-network (i.e., the number of lagging transactions at each business node in the witness sub-network does not exceed the lag threshold), the witness sub-network maintains a multi-active state.

[0096] S502, based on the indication information of the target business node and the indication information of other business nodes in the witness sub-network, negotiate the relay order of each business node in the witness sub-network when relaying synchronous transactions.

[0097] After determining the indication information of the target business node, the indication information of other business nodes in the witness subnetwork can be obtained. This indication information indicates the degree of transaction lag of other business nodes, which reflects the difference between the transactions stored by other business nodes and those stored by the consensus nodes in the core subnetwork. Based on its own indication information and that of other business nodes, the target business node can negotiate the relay order of transactions among the various business nodes in the witness subnetwork. The process of negotiating the relay order of transactions among the various business nodes in the witness subnetwork can include any of the following:

[0098] The first method involves the target business node negotiating the relay order of transactions during the relay synchronization process based on its own indications and those of other business nodes in the witness subnetwork. This process may include: sorting the node identifiers of each business node according to their transaction lag levels, from lowest to highest, based on the lag levels indicated by their respective indications; and determining the relay order of each business node during the relay synchronization process based on the sorting results. The relay order of any business node is positively correlated with the position of its node identifier in the sorting results. In other words, the node identifier of a business node with a lower transaction lag level precedes the node identifier of a business node with a higher transaction lag level, and therefore, the relay order of a business node with a lower transaction lag level precedes that of a business node with a higher transaction lag level.

[0099] For example, the indication information of a business node can be a numerical value indicating the degree of transaction lag of the business node. The smaller the value, the lower the degree of transaction lag, and the larger the value, the higher the degree of transaction lag. The witness sub-network includes business node 1, business node 2, and business node 3. The indication information of business node 1 is the value 523, the indication information of business node 2 is the value 6543, and the indication information of business node 3 is the value 8831. According to the order of transaction lag from high to low, that is, according to the order of the numerical value indicating the degree of transaction lag from small to large, the node identifiers of each business node in the witness sub-network are sorted according to the value of their respective transaction lag. The relay order of business node 1, business node 2, and business node 3 in relaying synchronous transactions is determined by the sorting result as follows: business node 1 is the first (i.e., first position), business node 2 is the second position, and business node 3 is the third position.

[0100] The second method involves the target business node negotiating the relay order of various business nodes in the witness subnetwork during relay synchronization transactions based on the target business node's indication information and the indication information of other business nodes in the witness subnetwork. This process may include: negotiating a common synchronization node in the witness subnetwork based on the target business node's indication information and the indication information of other business nodes in the witness subnetwork. A common synchronization node refers to a business node that needs to synchronize transactions from the consensus nodes in the core subnetwork and provides synchronization services to the remaining business nodes in the witness subnetwork; then, based on the negotiation results of the common synchronization node, determining the relay order of each business node during relay synchronization transactions; wherein, when any business node is a negotiated common synchronization node, that business node has the first relay order, and when any business node is not a negotiated common synchronization node, that business node has a non-first relay order.

[0101] The process of negotiating a common synchronization node in the witness subnetwork, based on the indication information of the target business node and the indication information of other business nodes in the witness subnetwork, may include: determining the number of common synchronization nodes (the number of common synchronization nodes can be one or more); sorting the node identifiers of each business node according to the transaction lag degree indicated by the indication information of each business node in the witness subnetwork, in order from low to high transaction lag degree; and determining the business node corresponding to the node identifier ranked first in the sorting result as the common synchronization node; that is, one or more business nodes with a lower transaction lag degree in the witness subnetwork can be determined as common synchronization nodes.

[0102] For example, the indication information of a business node can be a numerical value indicating the degree of transaction lag. The smaller the value, the lower the degree of transaction lag; the larger the value, the higher the degree of transaction lag. The witness subnetwork includes business node 1, business node 2, and business node 3. The indication information of business node 1 is 523, that of business node 2 is 6543, and that of business node 3 is 8831. A common synchronization node needs to be determined from the witness subnetwork. Based on the transaction lag degree from high to low (i.e., according to the numerical value indicating the transaction lag degree from small to large), the node identifiers of each business node in the witness subnetwork are sorted according to their respective transaction lag degree values. The business node 1 corresponding to the first node identifier in the sorting result is determined as the common synchronization node. The relay order of business nodes 1, 2, and 3 when synchronizing transactions is: business node 1 is the first, business node 2 is the second, and business node 3 is the second.

[0103] S503: During the relay synchronization of transactions, if the relay order of the target business node is detected to have arrived, the lagging transactions of the target business node are synchronized from the relay node of the target business node.

[0104] After negotiating the relay order of each business node in the witness subnetwork during the relay synchronization transaction, if the relay order of the target business node is detected to have arrived during the relay synchronization transaction process, the lagging transactions of the target business node are synchronized from the relay nodes of the target business node; lagging transactions refer to transactions that are not stored in the corresponding business node but are stored in the relay nodes of the corresponding business node, that is, lagging transactions of the target business node refer to transactions that are not stored in the target business node but are stored in the relay nodes of the target business node.

[0105] Specifically, after the relay node of the target service node has synchronized the lagging transactions, the relay node of the target service node can send a transaction synchronization notification to the target service node. When the target service node receives the transaction synchronization notification sent by the relay node, it can determine that the relay order of the target service node has arrived. In this case, the target service node can send a transaction synchronization request to the relay node. When the relay node of the target service node receives the transaction synchronization request sent by the target service node, it can determine the lagging transactions of the target service node based on the transactions currently stored in the target service node and the transactions currently stored in the relay node, and then send the lagging transactions of the target service node to the target service node. The target service node can receive the lagging transactions of the target service node sent by the relay node and update the transactions currently stored in the target service node based on the lagging transactions, thereby synchronizing the transactions stored in the target service node with the transactions stored in the consensus nodes in the core sub-network. More specifically, the transaction synchronization request sent by the target service node may include the transaction hash of the transactions already stored by the target service node; the relay node of the target service node can determine the transactions currently stored by the target service node based on the transaction hash of the transactions already stored by the target service node included in the transaction synchronization request sent by the target service node, and determine the lagging transactions of the target service node based on the transactions currently stored by the target service node and the transactions currently stored by the relay node of the target service node.

[0106] After synchronizing the lagging transactions of the target business node from the relay node of the target business node, if a reference business node exists in the witness subnetwork (the reference business node is the business node that uses the target business node as a relay node), the reference business node can be notified to synchronize transactions. When a transaction synchronization request is received from the reference business node, the lagging transactions of the reference business node can be determined based on the transactions currently stored in the target business node and the transactions currently stored in the reference business node. The lagging transactions can then be sent to the reference business node so that it can update its currently stored transactions based on the received lagging transactions, thereby synchronizing the transactions stored in the reference business node with those stored in the consensus nodes in the core subnetwork. More specifically, the transaction synchronization request sent by the reference business node can carry the transaction hashes of the transactions already stored by the reference business node. The target business node can determine the transactions currently stored by the reference business node based on the transaction hashes of the transactions already stored by the reference business node, and then determine the lagging transactions of the reference business node based on the transactions currently stored by the reference business node and the transactions currently stored by the target business node.

[0107] Specifically, when the target business node is in the first position of the relay order, the relay node of the target business node is a consensus node; when the target business node is not in the first position of the relay order, the relay node of the target business node is a business node; more specifically, when the target business node is not in the first position of the relay order, the relay node of the target business node is the business node corresponding to the adjacent relay order that is in the relay order preceding the target business node.

[0108] In the first scenario described above, the relay node for the first business node in the relay order is a consensus node in the core subnetwork; that is, the business node with the first relay order synchronizes the lagging transactions from the consensus nodes in the core subnetwork. The relay node for a business node that is not the first in the relay order is the adjacent business node whose relay order precedes that of the business node with the non-first relay order. Figure 7a Taking the relay synchronization process shown as an example, the witness subnetwork includes business node 1, business node 2, and business node 3. Business node 1 is the first in the relay order (i.e., the first position), so the relay node for business node 1 is the consensus node in the core subnetwork. Business node 1 synchronizes its lagging transactions from the consensus node in the core subnetwork. Business node 2 is the second in the relay order, so the relay node for business node 2 is the business node with the first in the relay order (i.e., business node 1). After business node 1 synchronizes its lagging transactions from the consensus node in the core subnetwork, business node 2 synchronizes its lagging transactions from business node 1. Business node 3 is the third in the relay order, so the relay node for business node 3 is the business node with the second in the relay order (i.e., business node 2). After business node 2 synchronizes its lagging transactions from business node 1, business node 3 synchronizes its lagging transactions from business node 2. In this way, the transaction synchronization pressure of the core subnetwork is reasonably distributed among the various business nodes in the witness subnetwork. This effectively alleviates the transaction synchronization pressure on the consensus nodes in the core subnetwork. Furthermore, the business nodes that synchronize lagging transactions from the consensus nodes in the core subnetwork are the business nodes with the lowest degree of transaction lag in the witness subnetwork, synchronizing the fewest lagging transactions from the consensus nodes in the core subnetwork. This further alleviates the transaction synchronization pressure on the consensus nodes in the core subnetwork. In addition, except for the business node at the end of the relay order in the witness subnetwork, the other business nodes play the dual role of transaction receiver and transaction sender when synchronizing transactions. This ensures that the transaction synchronization pressure among the various business nodes in the witness subnetwork is balanced, thereby achieving load balancing among the various business nodes in the witness subnetwork.

[0109] In the second scenario described above, the public synchronization node takes the lead, and its successor node is a consensus node in the core subnetwork. In other words, the public synchronization node synchronizes its lagging transactions from the consensus nodes in the core subnetwork. However, the remaining business nodes in the witness subnetwork, excluding the public synchronization node, do not take the lead. All remaining business nodes take the lead from the public synchronization node, meaning they all synchronize their lagging transactions from the public synchronization node. Figure 7b Taking the relay synchronization process shown as an example, the witness subnetwork includes business node 1, business node 2, and business node 3. Business node 1 is the first in the relay order, so business node 1 is the common synchronization node. The relay node of business node 1 is the consensus node in the core subnetwork. Business node 1 synchronizes its lagging transactions from the consensus node in the core subnetwork. Business node 2 and business node 3 are the second in the relay order. The relay nodes of business node 2 and business node 3 are both business nodes that are the first in the relay order (i.e., business node 1). After business node 1 synchronizes its lagging transactions from the consensus node in the core subnetwork, business node 2 synchronizes its lagging transactions from business node 1, and business node 3 synchronizes its lagging transactions from business node 1. In this way, the transaction synchronization pressure of the core subnetwork is reasonably distributed to the various public synchronization nodes in the witness subnetwork. This can effectively alleviate the transaction synchronization pressure of the consensus nodes in the core subnetwork. Furthermore, the public synchronization nodes that synchronize lagging transactions from the consensus nodes in the core subnetwork are one or more business nodes in the witness subnetwork with a relatively low degree of transaction lag. The number of lagging transactions synchronized from the consensus nodes in the core subnetwork is small, which can further alleviate the transaction synchronization pressure of the consensus nodes in the core subnetwork.

[0110] It should be noted that after the relay synchronization transaction ends, that is, after each business node in the witness subnetwork synchronizes its lagging transactions from its respective relay node, the transactions stored in the witness subnetwork are synchronized with the transactions stored in the core subnetwork. In other words, the transactions stored in the witness subnetwork are not lagging behind the transactions stored in the core subnetwork, and the business nodes in the witness subnetwork revert from the relay synchronization transaction mode to a multi-active mode. As mentioned above, the business nodes synchronize block header data and some authorized visible block data. Specifically, the lagging transactions synchronized by any business node from its relay node can refer to: the block header data of the lagging transaction in the block containing the lagging transaction and the block data of the authorized visible transaction in the block containing the lagging transaction.

[0111] In this embodiment, by negotiating the relay order of each business node in the witness subnetwork during the relay synchronization of transactions, when any business node in the witness subnetwork is in the first position, its relay node becomes the consensus node in the core subnetwork. When any business node in the witness subnetwork is not in the first position, its relay node becomes another business node in the witness subnetwork. This can distribute the transaction synchronization pressure of the consensus nodes in the core subnetwork to the witness subnetwork, effectively alleviating the transaction synchronization pressure of the consensus nodes in the core subnetwork. Furthermore, the business nodes in the witness subnetwork that lag behind in synchronizing transactions from the consensus nodes in the core subnetwork are the business nodes with the least transaction activity in the witness subnetwork, or one or more business nodes with relatively low transaction activity, which can further alleviate the transaction synchronization pressure of the consensus nodes in the core subnetwork.

[0112] This application provides a transaction synchronization method based on a blockchain network. This method primarily describes determining the content of the instruction information used for negotiation by each business node in the witness subnetwork. This transaction synchronization method can be executed by a target business node in the witness subnetwork, and the target business node can be any business node in the witness subnetwork. For example... Figure 8 As shown, the transaction synchronization method includes the following steps S801-S805:

[0113] S801, when the transactions stored in the witness sub-network lag behind the transactions stored in the core sub-network, obtain the first number of transactions stored in the consensus nodes in the core sub-network, and determine the second number of transactions stored in the target business node.

[0114] S802, calculate the difference between the first transaction count and the second transaction count to obtain the number of lagging transactions for the target business node.

[0115] In steps S801-S802, when the transactions stored in the witness sub-network lag behind the transactions stored in the core sub-network, each business node in the witness sub-network can determine indication information to indicate the degree of lag of its own transactions. The indication information of each business node can be determined based on the number of lag transactions of each business node.

[0116] For a target business node in the witness subnetwork, the target business node can obtain the first number of transactions stored in the consensus node in the core subnetwork, and determine the second number of transactions stored in the target business node. Then, it can calculate the difference between the first number of transactions and the second number of transactions to obtain the lagging number of transactions of the target business node. The lagging number of transactions of the target business node is equal to the difference between the first number of transactions stored in the consensus node in the core subnetwork and the second number of transactions stored in the target business node.

[0117] If the number of lagging transactions of the target service node is equal to the target number (for example, the target number can be 0), then it can be determined that the target service node will not participate in the relay synchronization transaction. The target service node's non-participation in the relay synchronization transaction can be understood as: the target service node maintains a direct connection with the core sub-network, directly synchronizing transactions from the core sub-network, and does not participate in the negotiation of the relay order. If the number of lagging transactions of the target service node is greater than the target number, then based on the number of lagging transactions of the target service node, indication information for indicating the degree of transaction lag of the target service node can be determined. That is, steps S802-S805 in this embodiment can be executed to participate in the negotiation of the relay order. In other words, service nodes in the witness sub-network with a number of lagging transactions equal to the target number do not participate in the relay synchronization transaction, while service nodes in the witness sub-network with a number of lagging transactions greater than the target number participate in the relay synchronization transaction. Figure 9 As shown, the witness subnetwork includes business node 1, business node 2, business node 3, and business node 4. Business node 4 has zero lagging transactions, so it does not participate in the relay synchronization transaction and maintains a direct connection with the core subnetwork. Business nodes 1, 2, and 3 all have more than zero lagging transactions and negotiate the relay order. In this way, business nodes with zero lagging transactions in the witness subnetwork do not participate in the relay synchronization transaction, which reduces the time for relay order negotiation in the witness subnetwork, thereby improving the overall transaction synchronization efficiency of the witness subnetwork.

[0118] S803, based on the number of lagging transactions of the target business node, determine indication information to indicate the degree of transaction lag of the target business node.

[0119] After obtaining the number of lagging transactions for the target business node, indication information for indicating the degree of transaction lag of the target business node can be determined based on this number. The process of determining this indication information based on the number of lagging transactions for the target business node may include: obtaining the number of lagging transactions for other business nodes in the witness subnetwork, and determining the difference in the number of lagging transactions between any two business nodes in the witness subnetwork based on the difference in the number of lagging transactions between the other business nodes and the target business node; then, detecting the need to disturb the number of lagging transactions for the target business node based on the difference in the number of lagging transactions between any two business nodes in the witness subnetwork; if a need to disturb the number of lagging transactions for the target business node is detected, a random factor for the target business node can be generated, and the number of lagging transactions for the target business node can be perturbed based on the random factor, with the perturbation result used as the indication information for indicating the degree of transaction lag of the target business node; if no need to disturb the number of lagging transactions for the target business node is detected, the number of lagging transactions for the target business node can be directly used as the indication information for indicating the degree of transaction lag of the target business node.

[0120] The process of detecting the number of lagging transactions that disturbs the target business node may include: detecting whether the difference in the number of lagging transactions between any two business nodes in the witness sub-network is less than a difference threshold; if it is less than (i.e., the difference in the number of lagging transactions between any two business nodes in the witness sub-network is less than the difference threshold), then it can be determined that the number of lagging transactions that disturbs the target business node has been detected; if it is not less than (i.e., there are at least two business nodes in the witness sub-network whose number of lagging transactions is not less than the number threshold), then it can be determined that the number of lagging transactions that disturbs the target business node has not been detected.

[0121] Alternatively, the process of detecting the number of lagging transactions that disturbs the target business node may include: detecting whether there is a difference in the number of lagging transactions between at least two business nodes in the witness subnetwork that is less than a difference threshold; if so (i.e., there are two business nodes in the witness subnetwork whose number of lagging transactions is less than the difference threshold), then it can be determined that the number of lagging transactions that disturbs the target business node has been detected; if not so (i.e., the difference in the number of lagging transactions between any two business nodes in the witness subnetwork is not less than the difference threshold), then it can be determined that the number of lagging transactions that disturbs the target business node has not been detected.

[0122] It should be noted that this explanation uses the requirement of detecting the number of lagging transactions that disturbs the target business node and the requirement of not detecting the number of lagging transactions that disturbs the target business node as examples. In actual transaction synchronization scenarios, each business node in the witness sub-network can detect whether the difference in the number of lagging transactions between any two business nodes in the witness sub-network is less than the difference threshold. If it is less, then each business node in the witness sub-network can determine that it has detected the requirement of disturbing its own number of lagging transactions; if it is not less, then each business node in the witness sub-network can determine that it has not detected the requirement of disturbing its own number of lagging transactions. For example, the witness sub-network includes business node 1, business node 2, and business node 3. The number of lagging transactions of business node 1 is 1000, the number of lagging transactions of business node 2 is 1000, and the number of lagging transactions of business node 3 is 1000. Through calculation, it can be seen that the difference in the number of lagging transactions between any two business nodes among business node 1, business node 2, and business node 3 is less than the difference threshold 2. Therefore, business node 1 can determine that it has detected the requirement of disturbing its own number of lagging transactions. Business nodes 2 and 3 are the same as business node 1. For example, the witness subnetwork includes business node 1, business node 2, and business node 3. The number of lagging transactions for business node 1 is 1000, the number of lagging transactions for business node 2 is 1001, and the number of lagging transactions for business node 3 is 1006. Calculation shows that the difference between the number of lagging transactions for business node 1 and the number of lagging transactions for business node 3 is greater than the difference threshold 2. Therefore, business node 1 can be determined that no demand for lagging transactions that disturbs business node 1 has been detected. Business nodes 2 and 3 are the same as business node 1.

[0123] Similarly, each business node in the witness sub-network can detect whether there exists a difference in the number of lagging transactions between at least two business nodes that is less than a difference threshold. If such a difference exists, each business node in the witness sub-network can determine that a requirement has been detected that disturbs its own number of lagging transactions. If no such requirement exists, each business node in the witness sub-network can determine that a requirement has not been detected that disturbs its own number of lagging transactions. For example, the witness sub-network includes business node 1, business node 2, and business node 3. Business node 1 has a lagging transaction count of 1000, business node 2 has a lagging transaction count of 1001, and business node 3 has a lagging transaction count of 1006. Calculations show that the difference between the number of lagging transactions of business node 1 and the number of lagging transactions of business node 2 is less than a difference threshold of 2. Therefore, business node 1 can determine that a requirement has been detected that disturbs its own number of lagging transactions. Business nodes 2 and 3 are the same as business node 1. For example, the witness subnetwork includes business node 1, business node 2, and business node 3. The number of lagging transactions for business node 1 is 1000, the number of lagging transactions for business node 2 is 1003, and the number of lagging transactions for business node 3 is 1006. It can be calculated that the difference in the number of lagging transactions between any two business nodes among business node 1, business node 2, and business node 3 is not less than the difference threshold 2. Therefore, business node 1 can be determined that no demand for lagging transactions that disturbs business node 1 has been detected. Business nodes 2 and 3 are the same as business node 1.

[0124] If each business node in the witness subnetwork determines that it has detected a demand that would disturb its own lagging transaction count, each business node can generate its own random factor, perturb its own lagging transaction count according to its random factor, and use the perturbation result as an indication of its own transaction lag level. If each business node in the witness subnetwork determines that it has not detected a demand that would disturb its own lagging transaction count, each business node can directly use its own lagging transaction count as an indication of its own transaction lag level.

[0125] Taking a target business node in the witness sub-network as an example, when a requirement to disturb the number of lagging transactions of the target business node is detected, a random factor for the target business node is generated. This can include: obtaining the random range corresponding to the target business node. The random range corresponding to each business node in the witness sub-network is the same. For example, the random number range corresponding to each business node in the witness sub-network is (0.7, 1.3). Then, a random factor belonging to the random range can be generated. For example, a random number generation function (such as the rand function) or a random number generation algorithm can be used to generate a random factor belonging to the random range. Based on the random factor of the target business node, the number of lagging transactions of the target business node is disturbed. This can include: calculating the product between the random factor of the target business node and the number of lagging transactions of the target business node, and using the product between the random factor of the target business node and the number of lagging transactions of the target business node as the disturbance result. That is, the product between the random factor of the target business node and the number of lagging transactions of the target business node is used as an indication of the degree of transaction lag of the target business node. For example, the witness subnetwork includes business node 1, business node 2, and business node 3. The number of lagging transactions for business node 1 is 1000, the number of lagging transactions for business node 2 is 1000, and the number of lagging transactions for business node 3 is 1000. Through calculation, it is determined that business node 1, business node 2, and business node 3 all detect the need to disturb their respective lagging transaction numbers. Further, business node 1 can generate a random factor of 0.75 within the random range (0.7, 1.3) using the rand function, and the disturbance result of business node 1, i.e., the indication information of business node 1, is 750. Business node 2 can generate a random factor of 0.93 within the random range (0.7, 1.3) using the rand function, and the disturbance result of business node 2, i.e., the indication information of business node 2, is 930. Business node 3 can generate a random factor of 1.25 within the random range (0.7, 1.3) using the rand function, and the disturbance result of business node 3, i.e., the indication information of business node 3, is 1250.

[0126] As described in step S803 above, when the difference in the number of lagging transactions among the various business nodes in the witness subnetwork is not significant, directly using the number of lagging transactions of a business node as an indication of its transaction lag level would not allow for the sorting of node identifiers based on the size of the lagging transaction counts, nor would it allow for determining the relay order of business nodes during transaction synchronization based on the sorting results. Furthermore, it would be impossible to determine the common synchronization node in the witness subnetwork based on the size of the lagging transaction counts. For example... When the data center deploying the witness subnetwork fails, all business nodes in the witness subnetwork experience lagging transactions, and the number of lagging transactions is usually the same for each node. This makes it impossible to determine the relay order of transactions during synchronization by sorting, or to identify the common synchronization node in the witness subnetwork. Therefore, in such cases, a random factor can be introduced to perturb the number of lagging transactions for each business node, and the perturbation result can be used as an indicator of the degree of lag for each business node. The purpose of the perturbation is to increase the difference in the number of lagging transactions among the business nodes in the witness subnetwork. However, when the difference in the number of lagging transactions among the business nodes in the witness subnetwork is large, the relay order of transactions during synchronization can be determined by sorting according to the size relationship of the lagging transaction numbers, or the common synchronization node in the witness subnetwork can be identified by sorting. In this case, it is not necessary to introduce a random factor; the number of lagging transactions for each business node can be directly used as the indicator of the degree of lag for each business node.

[0127] S804, based on the indication information of the target business node and the indication information of other business nodes in the witness sub-network, negotiate the relay order of each business node in the witness sub-network when relaying synchronous transactions.

[0128] The execution process of step S804 in this embodiment is the same as described above. Figure 5 The execution process of step S502 in the illustrated embodiment is the same, and can be found in the above description. Figure 5 The description of step S502 in the illustrated embodiment will not be repeated here.

[0129] S805, during the relay synchronization of transactions, if the relay order of the target business node is detected to have arrived, then the lagging transactions of the target business node are synchronized from the relay node of the target business node.

[0130] The execution process of step S805 in this embodiment is the same as described above. Figure 5The execution process of step S503 in the illustrated embodiment is the same; please refer to the above for details. Figure 5 The description of step S503 in the illustrated embodiment will not be repeated here.

[0131] In this embodiment, when the number of lagging transactions among the various business nodes in the witness subnetwork differs significantly, the number of lagging transactions for each business node can be directly used as an indication of the degree of lag. This allows for a rapid ranking and determination of the relay order of the business nodes in the witness subnetwork during synchronized transactions based on the size relationship of their lagging transaction counts. Conversely, when the number of lagging transactions among the various business nodes in the witness subnetwork differs slightly, a random factor can be introduced to perturb the number of lagging transactions. The perturbation result for each business node is then used as an indication of its degree of lag. The purpose of the perturbation is to amplify the difference in the number of lagging transactions among the various business nodes in the witness subnetwork. This allows for a rapid ranking and determination of the relay order of the business nodes in the witness subnetwork during synchronized transactions based on the size relationship of their perturbed lagging transaction counts.

[0132] The methods of the embodiments of this application have been described in detail above. In order to facilitate better implementation of the above solutions of the embodiments of this application, the apparatus of the embodiments of this application is provided below.

[0133] Please see Figure 10 , Figure 10 This is a schematic diagram of a transaction synchronization device based on a blockchain network provided in an embodiment of this application. The transaction synchronization device can be installed in the computer equipment provided in the embodiment of this application, and the computer equipment can be the target business node mentioned in the above method embodiment. Figure 10 The transaction synchronization device shown can be a computer program (including program code) running on a computer device, which can be used to execute... Figure 5 or Figure 8 Some or all of the steps in the method embodiments shown. Please refer to [link / reference]. Figure 10 The transaction synchronization device may include the following units:

[0134] The determining unit 1001 is used to determine indication information to indicate the degree of lag of transactions of the target business node when the transactions stored in the witness sub-network lag behind the transactions stored in the core sub-network. The degree of lag of transactions is used to reflect the difference between the transactions stored in the business node and the transactions stored in the consensus node in the core sub-network.

[0135] The processing unit 1002 is used to negotiate the relay order of each business node in the witness subnetwork during relay synchronization transactions based on the indication information of the target business node and the indication information of other business nodes in the witness subnetwork.

[0136] The processing unit 1002 is also used to synchronize the lagging transactions of the target business node from the relay node of the target business node if the relay order of the target business node is detected during the relay synchronization process. The lagging transactions refer to transactions that are not stored in the corresponding business node but are stored in the relay node of the corresponding business node.

[0137] Specifically, when the target business node is in the first position in the relay order, the relay node is a consensus node; when the target business node is not in the first position in the relay order, the relay node is a business node.

[0138] In one implementation, the processing unit 1002, when negotiating the relay order of various business nodes in the witness subnetwork during relay synchronization transactions based on the indication information of the target business node and the indication information of other business nodes in the witness subnetwork, specifically performs the following steps:

[0139] The node identifiers of each business node are sorted according to the degree of transaction lag, from low to high, based on the indication information of each business node in the witness subnetwork.

[0140] The relay order of each business node during the relay synchronization transaction is determined based on the sorting results. The relay order of any business node is positively correlated with the position of the node identifier of any business node in the sorting results.

[0141] In one implementation, the processing unit 1002, when negotiating the relay order of various business nodes in the witness subnetwork during relay synchronization transactions based on the indication information of the target business node and the indication information of other business nodes in the witness subnetwork, specifically performs the following steps:

[0142] Based on the indication information of the target business node and the indication information of other business nodes in the witness subnetwork, negotiation of a common synchronization node is carried out in the witness subnetwork; a common synchronization node refers to a business node that needs to synchronize transactions from the consensus node in the core subnetwork and provides synchronization services for the remaining business nodes in the witness subnetwork.

[0143] Based on the negotiation results of the public synchronization node, the relay order of each business node in the relay synchronization transaction is determined respectively; among them, when any business node is the negotiated public synchronization node, the relay order of any business node is first, and when any business node is not the negotiated public synchronization node, the relay order of any business node is not first.

[0144] In one implementation, after synchronizing the lagging transactions of the target business node from the relay node of the target business node, the processing unit 1002 is further configured to perform the following steps:

[0145] If there is a reference business node in the witness subnetwork, the reference business node is a business node that uses the target business node as a relay node, then the reference business node is notified to synchronize the transaction.

[0146] When a transaction synchronization request is received from a reference service node, the lagging transactions of the reference service node are determined based on the transactions currently stored in the target service node and the transactions currently stored in the reference service node.

[0147] The lagging transactions of the reference service node are sent to the reference service node so that the reference service node can update the currently stored transactions based on the received lagging transactions.

[0148] In one implementation, when determining the indication information for indicating the transaction lag level of the target business node, the determining unit 1001 specifically performs the following steps:

[0149] Obtain the first number of transactions stored in the consensus nodes of the core sub-network, and determine the second number of transactions stored in the target business node;

[0150] Calculate the difference between the first transaction count and the second transaction count to obtain the number of lagging transactions for the target business node;

[0151] Based on the number of lagging transactions of the target business node, determine the indication information used to indicate the degree of transaction lag of the target business node.

[0152] In one implementation, the processing unit 1002 is further configured to perform the following steps:

[0153] If the number of lagging transactions of the target business node is equal to the target number, then the target business node will not participate in the relay synchronization transaction.

[0154] If the number of lagging transactions of the target business node is greater than the target number, then the step of determining the indication information used to indicate the degree of transaction lag of the target business node is triggered based on the number of lagging transactions of the target business node.

[0155] In one implementation, when determining indication information to indicate the degree of transaction lag of a target business node based on the number of lagging transactions of that target business node, the determining unit 1001 specifically performs the following steps:

[0156] Obtain the number of lagging transactions of other business nodes in the witness subnetwork, and determine the difference in the number of lagging transactions between any two business nodes in the witness subnetwork based on the number of lagging transactions of other business nodes and the number of lagging transactions of the target business node.

[0157] Based on the difference in the number of lagging transactions between any two business nodes in the witness subnetwork, detect the requirement to disturb the number of lagging transactions of the target business node.

[0158] If a requirement for the number of lagging transactions that disturbs the target business node is detected, a random factor for the target business node is generated.

[0159] Based on the random factor of the target business node, the number of lagging transactions of the target business node is perturbed, and the perturbation result is used as an indication of the degree of transaction lag of the target business node.

[0160] In one implementation, when determining indication information for indicating the degree of transaction lag of a target business node based on the number of lagging transactions of the target business node, the determining unit 1001 is further configured to perform the following steps:

[0161] If no demand for a number of lagging transactions that would disturb the target business node is detected, then the number of lagging transactions of the target business node will be used as an indication of the degree of transaction lag of the target business node.

[0162] In one implementation, the determining unit 1001, when detecting the requirement for the number of lagging transactions of the target business node to disturb it based on the difference in the number of lagging transactions between any two business nodes in the witness sub-network, specifically performs the following steps:

[0163] The system checks whether the difference in the number of lagging transactions between any two service nodes in the witness subnetwork is less than a difference threshold; if it is less, it determines that a requirement for detecting the number of lagging transactions that are disturbing the target service node has been detected; if it is not less, it determines that a requirement for detecting the number of lagging transactions that are disturbing the target service node has not been detected; or...

[0164] The system detects whether there exists a difference in the number of lagging transactions between at least two business nodes in the witness subnetwork that is less than a difference threshold. If such a difference exists, the system determines whether a requirement has been detected for the number of lagging transactions that are disturbing the target business node. If no such difference exists, the system determines whether a requirement has been detected for the number of lagging transactions that are disturbing the target business node.

[0165] In one implementation, when determining the number of lagging transactions of the target business node based on the random factor of the target business node, the determining unit 1001 specifically performs the following steps:

[0166] Calculate the product between the random factor of the target business node and the number of lagging transactions of the target business node;

[0167] The perturbation result is the product of the random factor of the target business node and the number of lagging transactions of the target business node.

[0168] In one implementation, when determining the unit 1001, it is used to generate the random factor for the target service node, specifically performs the following steps:

[0169] Obtain the random range corresponding to the target business node, and ensure that the random ranges corresponding to each business node in the witness sub-network are the same.

[0170] Generate random factors that fall within the random range.

[0171] In one implementation, the determining unit 1001 is also used to perform the following steps:

[0172] When the witness subnetwork malfunctions, obtain the number of lagging transactions of the target business node and the number of lagging transactions of other business nodes in the witness subnetwork; the witness subnetwork malfunction includes any of the following: a failure in the data center where the witness subnetwork is deployed, and a failure in the external communication network of the witness subnetwork;

[0173] When the number of lagging transactions of each business node in the witness subnetwork meets the lagging condition, it is determined that the transactions stored in the witness subnetwork are lagging behind the transactions stored in the core subnetwork.

[0174] When the number of lagging transactions of each business node in the witness subnetwork does not meet the lagging condition, it is determined that the transactions stored in the witness subnetwork are not lagging behind the transactions stored in the core subnetwork.

[0175] The lagging condition refers to the situation where at least one business node in the witness sub-network has a lagging transaction count greater than the lagging quantity threshold.

[0176] In one implementation, when the transactions stored in the witness subnetwork are not behind the transactions stored in the core subnetwork, each business node in the witness subnetwork connects to the consensus node in the core subnetwork, and each business node synchronizes transactions from the core subnetwork.

[0177] According to one embodiment of this application, Figure 5 or Figure 8 The method steps involved in the method shown can be derived from... Figure 10 This is performed by the individual units within the transaction synchronization device shown. For example, Figure 5 Step S501 shown can be performed by Figure 10 The determining unit 1001 shown is executed. Figure 5Steps S502-S503 shown can be derived from... Figure 10 The processing unit 1002 shown executes this. For example, Figure 8 Steps S801-S803 shown can be derived from... Figure 10 The determining unit 1001 shown is executed. Figure 8 Steps S804-S805 shown can be derived from... Figure 10 The processing unit 1002 shown is executed.

[0178] According to another embodiment of this application, Figure 10 The various units in the transaction synchronization device shown can be individually or entirely merged into one or more other units, or some of the units can be further divided into multiple functionally smaller units. This achieves the same operation without affecting the technical effects of the embodiments of this application. The above units are based on logical function division. In practical applications, the function of one unit can also be implemented by multiple units, or the function of multiple units can be implemented by one unit. In other embodiments of this application, the transaction synchronization device may also include other units. In practical applications, these functions can also be implemented with the assistance of other units, and can be implemented collaboratively by multiple units.

[0179] According to another embodiment of this application, the following can be achieved by running on a general-purpose computing device, such as a computer, which includes processing elements and storage elements such as a central processing unit (CPU), random access memory (RAM), and read-only memory (ROM), a device capable of performing operations such as... Figure 5 or Figure 8 The computer program (including program code) for each step involved in the corresponding method shown, to construct such... Figure 10 The transaction synchronization apparatus shown herein, and the transaction synchronization method based on a blockchain network for implementing embodiments of this application, are described. The computer program may be recorded on, for example, a computer-readable storage medium, loaded onto the aforementioned computing device via the computer-readable storage medium, and run therein.

[0180] In this embodiment, the blockchain network may include a core subnetwork and a witness subnetwork. When transactions stored in the witness subnetwork lag behind those stored in the core subnetwork, the target business node in the witness subnetwork can determine indication information to indicate the degree of lag in its transactions. Based on the indication information of the target business node and the indication information of other business nodes in the witness subnetwork, the relay order of each business node in the witness subnetwork during transaction synchronization is negotiated. During the relay synchronization process, if the relay order of the target business node is detected to have arrived, the target business node can synchronize its lagging transactions from its relay nodes. Wherein, when the target business node's relay order is first, the relay node of the target business node is a node in the core subnetwork... A consensus node is established where, when the target business node's relay order is not first, the relay node is a business node within the witness subnetwork. Therefore, when transactions stored in the witness subnetwork lag behind those stored in the core subnetwork, the relay order of transactions among the business nodes in the witness subnetwork is negotiated. Only the business node with the first relay order in the witness subnetwork needs to synchronize the lagging transactions from the consensus node in the core subnetwork. Business nodes with a non-first relay order in the witness subnetwork synchronize the lagging transactions from the business nodes in the witness subnetwork. The transaction synchronization pressure on the consensus nodes in the core subnetwork is distributed among the business nodes in the witness subnetwork, effectively alleviating the transaction synchronization pressure on the consensus nodes in the core subnetwork.

[0181] Based on the above methods and apparatus embodiments, this application provides a computer device, which can be the aforementioned target service node. Please refer to... Figure 11 , Figure 11 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Figure 11 The computer device shown includes at least a processor 1101, an input interface 1102, an output interface 1103, and a computer-readable storage medium 1104. The processor 1101, input interface 1102, output interface 1103, and computer-readable storage medium 1104 can be connected via a bus or other means.

[0182] Input interface 1102 can be used to obtain indication information from other business nodes in the witness subnetwork, as well as the number of lagging transactions of other business nodes in the witness subnetwork, and to receive lagging transactions of the target business node sent by the relay node of the target business node. Output interface 1103 can be used to send the lagging transactions of the reference business node to the reference business node (i.e., the business node in the witness subnetwork that uses the target business node as a relay node).

[0183] The computer-readable storage medium 1104 can be stored in the memory of a computer device. The computer-readable storage medium 1104 is used to store computer programs, which include computer instructions. The processor 1101 is used to execute the program instructions stored in the computer-readable storage medium 1104. The processor 1101 (or CPU (Central Processing Unit)) is the computing and control core of the computer device. It is adapted to implement one or more computer instructions, specifically to load and execute one or more computer instructions to achieve corresponding method flows or corresponding functions.

[0184] This application also provides a computer-readable storage medium (Memory), which is a memory device in a computer device used to store programs and data. It is understood that the computer-readable storage medium here can include both built-in storage media in the computer device and extended storage media supported by the computer device. The computer-readable storage medium provides storage space that stores the operating system of the computer device. Furthermore, the storage space also stores one or more computer instructions suitable for loading and execution by a processor. These computer instructions can be one or more computer programs (including program code). It should be noted that the computer-readable storage medium here can be high-speed RAM or non-volatile memory, such as at least one disk storage device; optionally, it can also be at least one computer-readable storage medium located remotely from the aforementioned processor.

[0185] In some embodiments, the processor 1101 may load and execute one or more computer instructions stored in the computer-readable storage medium 1104 to implement the aforementioned related... Figure 5 or Figure 8 The corresponding steps of the transaction synchronization method based on a blockchain network are shown. In specific implementation, the computer instructions in the computer-readable storage medium 1104 are loaded by the processor 1101 and executed as follows:

[0186] When a transaction stored in the witness subnetwork lags behind a transaction stored in the core subnetwork, an indication information is determined to indicate the degree of lag in the transaction of the target business node. The degree of lag reflects the difference between the transactions stored in the business node and the transactions stored in the consensus node in the core subnetwork.

[0187] Based on the indication information of the target business node and the indication information of other business nodes in the witness subnetwork, negotiate the relay order of each business node in the witness subnetwork when relaying synchronous transactions.

[0188] During the relay synchronization of transactions, if the relay order of the target business node is detected to have arrived, the lagging transactions of the target business node are synchronized from the relay node of the target business node. Lagging transactions refer to transactions that are not stored in the corresponding business node but are stored in the relay node of the corresponding business node.

[0189] Specifically, when the target business node is in the first position in the relay order, the relay node is a consensus node; when the target business node is not in the first position in the relay order, the relay node is a business node.

[0190] In one implementation, the computer instructions in the computer-readable storage medium 1104 are loaded and executed by the processor 1101 based on the indication information of the target business node and the indication information of other business nodes in the witness subnetwork. When negotiating the relay order of each business node in the witness subnetwork during the relay synchronization transaction, the instructions are specifically used to perform the following steps:

[0191] The node identifiers of each business node are sorted according to the degree of transaction lag, from low to high, based on the indication information of each business node in the witness subnetwork.

[0192] The relay order of each business node during the relay synchronization transaction is determined based on the sorting results. The relay order of any business node is positively correlated with the position of the node identifier of any business node in the sorting results.

[0193] In one implementation, the computer instructions in the computer-readable storage medium 1104 are loaded and executed by the processor 1101 based on the indication information of the target business node and the indication information of other business nodes in the witness subnetwork. When negotiating the relay order of each business node in the witness subnetwork during the relay synchronization transaction, the instructions are specifically used to perform the following steps:

[0194] Based on the indication information of the target business node and the indication information of other business nodes in the witness subnetwork, negotiation of a common synchronization node is carried out in the witness subnetwork; a common synchronization node refers to a business node that needs to synchronize transactions from the consensus node in the core subnetwork and provides synchronization services for the remaining business nodes in the witness subnetwork.

[0195] Based on the negotiation results of the public synchronization node, the relay order of each business node in the relay synchronization transaction is determined respectively; among them, when any business node is the negotiated public synchronization node, the relay order of any business node is first, and when any business node is not the negotiated public synchronization node, the relay order of any business node is not first.

[0196] In one implementation, after the computer instructions in the computer-readable storage medium 1104 are loaded and executed by the processor 1101 to synchronize the lagging transactions of the target service node from the relay node of the target service node, they are further used to perform the following steps:

[0197] If there is a reference business node in the witness subnetwork, the reference business node is a business node that uses the target business node as a relay node, then the reference business node is notified to synchronize the transaction.

[0198] When a transaction synchronization request is received from a reference service node, the lagging transactions of the reference service node are determined based on the transactions currently stored in the target service node and the transactions currently stored in the reference service node.

[0199] The lagging transactions of the reference service node are sent to the reference service node so that the reference service node can update the currently stored transactions based on the received lagging transactions.

[0200] In one implementation, when the computer instructions in the computer-readable storage medium 1104 are loaded and executed by the processor 1101 to determine indication information for indicating the degree of transaction lag of the target service node, they are specifically used to perform the following steps:

[0201] Obtain the first number of transactions stored in the consensus nodes of the core sub-network, and determine the second number of transactions stored in the target business node;

[0202] Calculate the difference between the first transaction count and the second transaction count to obtain the number of lagging transactions for the target business node;

[0203] Based on the number of lagging transactions of the target business node, determine the indication information used to indicate the degree of transaction lag of the target business node.

[0204] In one implementation, the computer instructions in the computer-readable storage medium 1104 are loaded by the processor 1101 and are also used to perform the following steps:

[0205] If the number of lagging transactions of the target business node is equal to the target number, then the target business node will not participate in the relay synchronization transaction.

[0206] If the number of lagging transactions of the target business node is greater than the target number, then the step of determining the indication information used to indicate the degree of transaction lag of the target business node is triggered based on the number of lagging transactions of the target business node.

[0207] In one implementation, when the computer instructions in the computer-readable storage medium 1104 are loaded and executed by the processor 1101 to determine indication information for indicating the degree of transaction lag of the target service node based on the number of lagging transactions of the target service node, the instructions specifically perform the following steps:

[0208] Obtain the number of lagging transactions of other business nodes in the witness subnetwork, and determine the difference in the number of lagging transactions between any two business nodes in the witness subnetwork based on the number of lagging transactions of other business nodes and the number of lagging transactions of the target business node.

[0209] Based on the difference in the number of lagging transactions between any two business nodes in the witness subnetwork, detect the requirement to disturb the number of lagging transactions of the target business node.

[0210] If a requirement for the number of lagging transactions that disturbs the target business node is detected, a random factor for the target business node is generated.

[0211] Based on the random factor of the target business node, the number of lagging transactions of the target business node is perturbed, and the perturbation result is used as an indication of the degree of transaction lag of the target business node.

[0212] In one implementation, when the computer instructions in the computer-readable storage medium 1104 are loaded and executed by the processor 1101 to determine indication information for indicating the degree of transaction lag of the target service node based on the number of lagging transactions of the target service node, they are also used to perform the following steps:

[0213] If no demand for a number of lagging transactions that would disturb the target business node is detected, then the number of lagging transactions of the target business node will be used as an indication of the degree of transaction lag of the target business node.

[0214] In one implementation, when the computer instructions in the computer-readable storage medium 1104 are loaded and executed by the processor 1101 to detect the requirement for the number of lagging transactions of the target business node based on the difference in the number of lagging transactions between any two business nodes in the witness subnetwork, the instructions are specifically used to perform the following steps:

[0215] The system checks whether the difference in the number of lagging transactions between any two service nodes in the witness subnetwork is less than a difference threshold; if it is less, it determines that a requirement for detecting the number of lagging transactions that are disturbing the target service node has been detected; if it is not less, it determines that a requirement for detecting the number of lagging transactions that are disturbing the target service node has not been detected; or...

[0216] The system detects whether there exists a difference in the number of lagging transactions between at least two business nodes in the witness subnetwork that is less than a difference threshold. If such a difference exists, the system determines whether a requirement has been detected for the number of lagging transactions that are disturbing the target business node. If no such difference exists, the system determines whether a requirement has been detected for the number of lagging transactions that are disturbing the target business node.

[0217] In one implementation, when the computer instructions in the computer-readable storage medium 1104 are loaded and executed by the processor 1101 to perturb the number of lagging transactions of the target business node according to the random factor of the target business node, they are specifically used to perform the following steps:

[0218] Calculate the product between the random factor of the target business node and the number of lagging transactions of the target business node;

[0219] The perturbation result is the product of the random factor of the target business node and the number of lagging transactions of the target business node.

[0220] In one implementation, when the computer instructions in the computer-readable storage medium 1104 are loaded and executed by the processor 1101 to generate the random factor for the target service node, they are specifically used to perform the following steps:

[0221] Obtain the random range corresponding to the target business node, and ensure that the random ranges corresponding to each business node in the witness sub-network are the same.

[0222] Generate random factors that fall within the random range.

[0223] In one implementation, the computer instructions in the computer-readable storage medium 1104 are loaded by the processor 1101 and are also used to perform the following steps:

[0224] When the witness subnetwork malfunctions, obtain the number of lagging transactions of the target business node and the number of lagging transactions of other business nodes in the witness subnetwork; the witness subnetwork malfunction includes any of the following: a failure in the data center where the witness subnetwork is deployed, and a failure in the external communication network of the witness subnetwork;

[0225] When the number of lagging transactions of each business node in the witness subnetwork meets the lagging condition, it is determined that the transactions stored in the witness subnetwork are lagging behind the transactions stored in the core subnetwork.

[0226] When the number of lagging transactions of each business node in the witness subnetwork does not meet the lagging condition, it is determined that the transactions stored in the witness subnetwork are not lagging behind the transactions stored in the core subnetwork.

[0227] The lagging condition refers to the situation where at least one business node in the witness sub-network has a lagging transaction count greater than the lagging quantity threshold.

[0228] In one implementation, when the transactions stored in the witness subnetwork are not behind the transactions stored in the core subnetwork, each business node in the witness subnetwork connects to the consensus node in the core subnetwork, and each business node synchronizes transactions from the core subnetwork.

[0229] In this embodiment, the blockchain network may include a core subnetwork and a witness subnetwork. When transactions stored in the witness subnetwork lag behind those stored in the core subnetwork, the target business node in the witness subnetwork can determine indication information to indicate the degree of lag in its transactions. Based on the indication information of the target business node and the indication information of other business nodes in the witness subnetwork, the relay order of each business node in the witness subnetwork during transaction synchronization is negotiated. During the relay synchronization process, if the relay order of the target business node is detected to have arrived, the target business node can synchronize its lagging transactions from its relay nodes. Wherein, when the target business node's relay order is first, the relay node of the target business node is a node in the core subnetwork... A consensus node is established where, when the target business node's relay order is not first, the relay node is a business node within the witness subnetwork. Therefore, when transactions stored in the witness subnetwork lag behind those stored in the core subnetwork, the relay order of transactions among the business nodes in the witness subnetwork is negotiated. Only the business node with the first relay order in the witness subnetwork needs to synchronize the lagging transactions from the consensus node in the core subnetwork. Business nodes with a non-first relay order in the witness subnetwork synchronize the lagging transactions from the business nodes in the witness subnetwork. The transaction synchronization pressure on the consensus nodes in the core subnetwork is distributed among the business nodes in the witness subnetwork, effectively alleviating the transaction synchronization pressure on the consensus nodes in the core subnetwork.

[0230] According to one aspect of this application, a computer program product or computer program is provided, comprising computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the blockchain-based transaction synchronization method provided in the various alternative embodiments described above.

[0231] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A transaction synchronization method based on a blockchain network, characterized in that, The blockchain network includes a core subnetwork and a witness subnetwork. The core subnetwork includes one or more consensus nodes, and the witness subnetwork includes one or more business nodes. The method is executed by a target business node in the witness subnetwork, and the method includes: When the transactions stored in the witness subnetwork lag behind the transactions stored in the core subnetwork, indication information is determined to indicate the degree of lag of the transactions of the target business node. The degree of lag reflects the difference between the transactions stored in the business node and the transactions stored in the consensus node in the core subnetwork. Based on the indication information of the target business node and the indication information of other business nodes in the witness sub-network, negotiate the relay order of each business node in the witness sub-network when relaying synchronous transactions; During the relay synchronization of transactions, if the relay order of the target business node is detected to arrive, the lagging transactions of the target business node are synchronized from the relay node of the target business node. Lagging transactions refer to transactions that are not stored in the corresponding business node but are stored in the relay node of the corresponding business node. Specifically, when the target business node is in the first position in the relay order, the relay node is a consensus node; when the target business node is not in the first position in the relay order, the relay node is a business node.

2. The method as described in claim 1, characterized in that, The process of negotiating the relay order of business nodes in the witness sub-network during relay synchronization transactions, based on the indication information of the target business node and the indication information of other business nodes in the witness sub-network, includes: The node identifiers of each business node are sorted according to the degree of transaction lag, from low to high, based on the indication information of each business node in the witness sub-network. The relay order of each business node in the relay synchronization transaction is determined according to the sorting results. The relay order of any business node is positively correlated with the position of the node identifier of any business node in the sorting results.

3. The method as described in claim 1, characterized in that, The process of negotiating the relay order of business nodes in the witness sub-network during relay synchronization transactions, based on the indication information of the target business node and the indication information of other business nodes in the witness sub-network, includes: Based on the indication information of the target business node and the indication information of other business nodes in the witness sub-network, negotiation of a common synchronization node is carried out in the witness sub-network; the common synchronization node refers to a business node that needs to synchronize transactions from the consensus node in the core sub-network and provides synchronization services for the remaining business nodes in the witness sub-network. Based on the negotiation results of the public synchronization node, the relay order of each business node in the relay synchronization transaction is determined respectively; wherein, when any business node is a negotiated public synchronization node, the relay order of any business node is first, and when any business node is not a negotiated public synchronization node, the relay order of any business node is not first.

4. The method as described in claim 1, characterized in that, After synchronizing the lagging transactions of the target business node from the relay node of the target business node, the method further includes: If there is a reference business node in the witness sub-network, the reference business node refers to the business node that uses the target business node as a relay node, then the reference business node is notified to synchronize the transaction. When a transaction synchronization request is received from the reference service node, the lagging transactions of the reference service node are determined based on the transactions currently stored in the target service node and the transactions currently stored in the reference service node. The lagging transactions of the reference service node are sent to the reference service node so that the reference service node updates the currently stored transactions based on the received lagging transactions.

5. The method according to any one of claims 1-4, characterized in that, The indication information used to determine the transaction lag level of the target business node includes: Obtain the first number of transactions stored in the consensus nodes of the core sub-network, and determine the second number of transactions stored in the target business node; Calculate the difference between the first number of transactions and the second number of transactions to obtain the number of lagging transactions of the target business node; Based on the number of lagging transactions of the target business node, determine indication information to indicate the degree of transaction lag of the target business node.

6. The method as described in claim 5, characterized in that, The method further includes: If the number of lagging transactions of the target business node is equal to the target number, then the target business node is determined not to participate in the relay synchronization transaction; If the number of lagging transactions of the target business node is greater than the target number, then the step of determining indication information to indicate the degree of transaction lag of the target business node based on the number of lagging transactions of the target business node is triggered.

7. The method as described in claim 5, characterized in that, The step of determining indication information to indicate the degree of transaction lag of the target business node based on the number of lagging transactions of the target business node includes: Obtain the number of lagging transactions of other business nodes in the witness sub-network, and determine the difference in the number of lagging transactions between any two business nodes in the witness sub-network based on the number of lagging transactions of the other business nodes and the number of lagging transactions of the target business node; Based on the difference in the number of lagging transactions between any two business nodes in the witness sub-network, detect the need to disturb the number of lagging transactions of the target business node; If a requirement for the number of lagging transactions that disturbs the target business node is detected, a random factor for the target business node is generated; Based on the random factor of the target business node, the number of lagging transactions of the target business node is perturbed, and the perturbation result is used as an indication of the degree of transaction lag of the target business node.

8. The method as described in claim 7, characterized in that, The step of determining indication information to indicate the degree of transaction lag of the target business node based on the number of lagging transactions of the target business node further includes: If no requirement is detected to disrupt the number of lagging transactions of the target service node, then the number of lagging transactions of the target service node will be used as an indication of the degree of transaction lag of the target service node.

9. The method as described in claim 7, characterized in that, The requirement to detect the number of lagging transactions that disturbs the target business node based on the difference in the number of lagging transactions between any two business nodes in the witness sub-network includes: The system checks whether the difference in the number of lagging transactions between any two service nodes in the witness sub-network is less than a difference threshold; if it is less, it determines that a requirement to disturb the target service node's number of lagging transactions has been detected; if it is not less, it determines that no requirement to disturb the target service node's number of lagging transactions has been detected; or... The system detects whether there exists a difference in the number of lagging transactions between at least two business nodes in the witness sub-network that is less than a difference threshold. If such a difference exists, it determines that a requirement to detect the number of lagging transactions that disturbs the target business node has been detected. If no such requirement exists, it determines that a requirement to detect the number of lagging transactions that disturbs the target business node has not been detected.

10. The method as described in claim 7, characterized in that, The step of perturbing the number of lagging transactions of the target business node based on the random factor of the target business node includes: Calculate the product between the random factor of the target business node and the number of lagging transactions of the target business node; The perturbation result is the product of the random factor of the target business node and the number of lagging transactions of the target business node.

11. The method as described in claim 7, characterized in that, The random factor for generating the target service node includes: Obtain the random range corresponding to the target business node, wherein the random range corresponding to each business node in the witness sub-network is the same; Generate random factors that belong to the aforementioned random range.

12. The method as described in claim 1, characterized in that, The method further includes: When the witness subnetwork malfunctions, the number of lagging transactions of the target business node and the number of lagging transactions of other business nodes in the witness subnetwork are obtained; the malfunction of the witness subnetwork includes any of the following: a failure in the data center where the witness subnetwork is deployed, and a failure in the external communication network of the witness subnetwork; When the number of lagging transactions of each business node in the witness sub-network meets the lagging condition, it is determined that the transactions stored in the witness sub-network are lagging behind the transactions stored in the core sub-network. When the number of lagging transactions of each business node in the witness sub-network does not meet the lagging condition, it is determined that the transactions stored in the witness sub-network are not lagging behind the transactions stored in the core sub-network. The lagging condition refers to the situation where at least one business node in the witness sub-network has a lagging transaction count greater than the lagging count threshold.

13. The method as described in claim 12, characterized in that, When the transactions stored in the witness sub-network are not behind the transactions stored in the core sub-network, each business node in the witness sub-network is connected to the consensus node in the core sub-network, and each business node synchronizes transactions from the core sub-network.

14. A transaction synchronization device based on a blockchain network, characterized in that, The blockchain network includes a core sub-network and a witness sub-network. The core sub-network includes one or more consensus nodes, and the witness sub-network includes one or more business nodes. The transaction synchronization device is set in the target business node in the witness sub-network. The transaction synchronization device includes: The determining unit is used to determine indication information to indicate the degree of lag of the transactions of the target business node when the transactions stored in the witness sub-network lag behind the transactions stored in the core sub-network. The degree of lag reflects the difference between the transactions stored in the business node and the transactions stored in the consensus node in the core sub-network. The processing unit is used to negotiate the relay order of each business node in the witness subnetwork during relay synchronization transactions based on the indication information of the target business node and the indication information of other business nodes in the witness subnetwork. The processing unit is also used to synchronize the lagging transactions of the target business node from the relay node of the target business node if the relay order of the target business node is detected to arrive during the relay synchronization process. The lagging transactions refer to transactions that are not stored in the corresponding business node but are stored in the relay node of the corresponding business node. Specifically, when the target business node is in the first position in the relay order, the relay node is a consensus node; when the target business node is not in the first position in the relay order, the relay node is a business node.

15. A computer device, characterized in that, The blockchain network includes a core sub-network and a witness sub-network. The core sub-network includes one or more consensus nodes, and the witness sub-network includes one or more business nodes. The computer device is the target business node in the witness sub-network. The computer device includes: A processor is a tool for implementing computer programs. A computer-readable storage medium storing a computer program adapted to be loaded by the processor and executed as described in any one of claims 1-13.

16. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program adapted to be loaded by a processor and executed as described in any one of claims 1-13.

17. A computer program product, characterized in that, The computer program product includes computer instructions that, when executed by a processor, implement the transaction synchronization method based on a blockchain network as described in any one of claims 1-13.

Images