Data broadcasting method of block chain system in weak network environment and block chain system

Abstract

The embodiment of the invention relates to a data broadcasting method of a block chain system in a weak network environment and the block chain system, and the method comprises the steps: carrying out the consensus of transaction data in a transaction buffer queue through a consensus node when a consensus block-out condition is satisfied, generating a new block, and writing the new block into a distributed account book of the consensus node; broadcasting new block information to the first connection node, wherein the new block information comprises block metadata information and a transaction hash value corresponding to the transaction data; the first connection node obtains transaction data matched with the transaction hash value in the new block information from a transaction cache queue of the first connection node; verifying the obtained transaction data based on the block metadata information, packaging the transaction data passing the verification into a new block, and writing the new block into a distributed account book of the first connection node; namely, the consensus node does not contain complete transaction data when broadcasting the new block information, but only broadcasts the transaction hash value, so that the volume of broadcast data is reduced, and the method is suitable for a weak network environment.

Description

Technical Field

[0001] The present invention relates to the field of blockchain technology, and in particular to a data broadcasting method and a blockchain system of a blockchain system in a weak network environment. Background Art

[0002] Blockchain is an innovative data storage and processing technology. Its essence is to achieve data storage, verification and consensus through a distributed network, ensuring that the data cannot be tampered with and is transparent and trustworthy.

[0003] Since the blockchain technology was proposed, it has undergone multiple iterations and optimizations in data broadcasting and consensus mechanisms. However, whether it is the traditional blockchain system or Ethereum, its data broadcasting solution is still centered on full network transmission, and fails to fully solve the efficiency problem in weak network environments. Summary of the invention

[0004] The present invention provides a data broadcasting method and a blockchain system of a blockchain system in a weak network environment, so as to solve the technical problem of data broadcasting communication efficiency of the blockchain system in a weak network environment.

[0005] In a first aspect, the present invention provides a data broadcasting method of a blockchain system in a weak network environment, which is applied to a blockchain system, wherein the blockchain system includes multiple nodes, the multiple nodes include a consensus node and a first connection node connected to the consensus node, and each node is provided with a transaction cache queue for storing transaction data; the method includes: under the consensus block condition, the consensus node generates a new block by consensus on the transaction data in the transaction cache queue of the consensus node, and writes the new block into the distributed ledger of the consensus node; the consensus node broadcasts the new block information to the first connection node, and the new block information includes block metadata information and a transaction hash value corresponding to the transaction data; the first connection node receives the new block information, and obtains transaction data matching the transaction hash value in the new block information from the transaction cache queue of the first connection node; the first connection node verifies the acquired transaction data based on the block metadata information, and packages the verified transaction data into a new block and writes it into the distributed ledger of the first connection node.

[0006] In some embodiments, the consensus node broadcasts the new block information to the first connection node, including: the consensus node broadcasts the new block information to the first connection node using a non-relay one-time broadcast method; wherein, the non-relay one-time broadcast method means that after the broadcast node broadcasts the broadcast information to the connection node, the connection node no longer performs relay broadcasting.

[0007] In some embodiments, the method further comprises: dividing the other nodes in the plurality of nodes except the consensus node into i-layer nodes according to the connection relationship between each node and the consensus node, , when i=1, it corresponds to the first connection node, and the i+1th layer node is connected to the i-th layer node; starting from i=1, iteratively execute the following steps: the i+1th layer node periodically queries the block metadata information of the i-th layer node; when the block metadata information of the i+1th layer node is inconsistent with the block metadata information of the i-th layer node, the i+1th layer node obtains a new block from the i-th layer node.

[0008] In some embodiments, the data structure of the new block information includes first blockchain layer data, first TCP protocol layer data, and first IP protocol layer data, and the first blockchain layer data includes block metadata information and a transaction hash value corresponding to the transaction data.

[0009] In some embodiments, the multiple nodes include a transaction node and a second connection node connected to the transaction node. Then, before the consensus node reaches consensus on the transaction data in the transaction cache queue of the consensus node, it also includes: the transaction node stores the transaction data to be broadcast in the transaction cache queue corresponding to the transaction node, and broadcasts the transaction data to the second connection node using a relay-free one-time broadcast method; the second connection node stores the received transaction data in the transaction cache queue corresponding to the second connection node; wherein the relay-free one-time broadcast method means that after the broadcast node broadcasts the broadcast information to the connection node, the connection node no longer performs relay broadcasting.

[0010] In some embodiments, the transaction node stores the transaction data to be broadcast in the transaction cache queue corresponding to the transaction node, including: the transaction node receives the transaction data sent by the user client signature, verifies the validity of the transaction data, and stores the verified transaction data in the transaction cache queue corresponding to the transaction node; the second connection node stores the received transaction data in the transaction cache queue corresponding to the second connection node, including: the second connection node receives the transaction data broadcast by the transaction node, verifies the validity of the transaction data, and stores the verified transaction data in the transaction cache queue corresponding to the second connection node.

[0011] In some embodiments, the method further comprises: dividing the nodes other than the transaction node among the plurality of nodes into j-layer nodes according to the connection relationship between each node and the transaction node, , when j=1, it corresponds to the second connection node, and the j-th layer node is connected to the j+1-th layer node; starting from j=1, iteratively execute the following steps until the consensus node receives the transaction data: when the consensus block conditions are met and the transaction data received by the j-th layer node is not packaged into a new block, send the transaction data to the j+1-th layer node.

[0012] In some embodiments, the data structure of the transaction data includes business layer data, second blockchain layer data, second TCP protocol layer data, and second IP protocol layer data, the business layer data includes the content of the transaction data, and the second blockchain layer data includes the transaction hash value of the transaction data and the signature information of the user client.

[0013] In a second aspect, an embodiment of the present invention provides a blockchain system, comprising multiple nodes, wherein the multiple nodes include a consensus node and a first connection node connected to the consensus node, each node being provided with a transaction cache queue for storing transaction data; when the consensus block condition is met, the consensus node is used to generate a new block by consensus on the transaction data in the transaction cache queue of the consensus node, and write the new block into the distributed ledger of the consensus node; the consensus node is used to broadcast the new block information to the first connection node, wherein the new block information includes block metadata information and a transaction hash value corresponding to the transaction data; the first connection node is used to receive the new block information, and obtain transaction data matching the transaction hash value in the new block information from the transaction cache queue of the first connection node; the first connection node is used to verify the obtained transaction data based on the block metadata information, and package the verified transaction data into a new block and write it into the distributed ledger of the first connection node.

[0014] In some embodiments, the multiple nodes include a transaction node and a second connection node connected to the transaction node; the transaction node is used to store the transaction data to be broadcast in a transaction cache queue corresponding to the transaction node, and broadcast the transaction data to the second connection node using a relay-free one-time broadcast method; the second connection node is used to store the received transaction data in a transaction cache queue corresponding to the second connection node; wherein the relay-free one-time broadcast method means that after the broadcast node broadcasts the broadcast information to the connection node, the connection node no longer performs relay broadcasting.

[0015] The data broadcasting method and blockchain system of the blockchain system in a weak network environment provided by the embodiment of the present invention optimize the broadcast data of the consensus node, that is, the consensus node no longer includes complete transaction data when broadcasting new block information, but only broadcasts the transaction hash value. After other nodes receive the new block information, they can obtain the corresponding transaction data from their own transaction cache queue according to these transaction hash values, and then write these data into their own account books. This optimization measure greatly reduces the volume of broadcast data and optimizes the network adaptability of the broadcast solution. It is particularly suitable for application scenarios under low bandwidth conditions and realizes the optimization of overall communication volume. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the invention and, together with the description, serve to explain the principles of the invention.

[0017] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0018] Figure 1 A flowchart of a data broadcasting method of a blockchain system in a weak network environment provided by an embodiment of the present invention; Figure 2 A schematic diagram of a data structure of new block information provided by an embodiment of the present invention; Figure 3 A flowchart of another data broadcasting method of a blockchain system in a weak network environment provided by an embodiment of the present invention; Figure 4 A schematic diagram of a data structure of transaction data provided by an embodiment of the present invention; Figure 5 A schematic diagram of the architecture of a blockchain system provided by an embodiment of the present invention; Figure 6 for Figure 5 The flowchart of the data broadcasting method of the blockchain system in a weak network environment is shown. DETAILED DESCRIPTION

[0019] In order to make the purpose, technical solution and advantages of the embodiments of the present invention clearer, the technical solution in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0020] Blockchain is an innovative data storage and processing technology. Its essence is to achieve data storage, verification and consensus through a distributed network, ensuring that data cannot be tampered with and is transparent and reliable. In the blockchain system, nodes are the basis for the operation of the system and undertake multiple tasks such as data storage, broadcasting, verification and consensus. Understanding the role and function of blockchain nodes is crucial to optimizing network communication efficiency and improving broadcast methods in weak network environments.

[0021] Consensus nodes are usually authoritative nodes of blockchain networks, and their performance and stability have a direct impact on the operating efficiency and security of the network. However, due to the need to process a large number of transactions and participate in frequent consensus calculations, the communication requirements of consensus nodes are higher than those of ordinary nodes. This also makes it easy for consensus nodes to become performance bottlenecks in weak network environments. Synchronous nodes do not participate in block generation or consensus voting, so their computing burden is lighter, and their main tasks are focused on data synchronization and broadcasting. The operating goal of the synchronization node is to provide data redundancy and reading convenience for the entire network, rather than a decisive function. In summary, the consensus node is the core of the network operation, with a large amount of data processing and frequent interactions, while the synchronization node is an auxiliary role of the network, mainly passively receiving data. This role differentiation determines that optimizing the communication requirements of the consensus node is the key to improving the overall performance of the blockchain network.

[0022] The communication efficiency of the blockchain network directly affects the overall performance of the system. Especially in a weak network environment, the traditional broadcast mechanism may face the following problems. The first is high communication volume: the whole network broadcast requires a large number of data packets to be transmitted between nodes, which puts great pressure on bandwidth; the second is repeated data transmission: most of the data packets received by the nodes may be redundant, resulting in a waste of bandwidth resources; the third is delay accumulation: the frequent interactions between consensus nodes are susceptible to network delays, thereby reducing the efficiency of block generation.

[0023] Since the blockchain technology was proposed, it has undergone multiple iterations and optimizations in data broadcasting and consensus mechanisms. However, whether it is the traditional blockchain system or Ethereum, its data broadcasting solution is still centered on full network transmission, and fails to fully solve the efficiency problem in weak network environments.

[0024] Taking the traditional blockchain system as an example, it is a typical decentralized blockchain system, and its data dissemination method is mainly based on full network broadcast. In the traditional blockchain system, all nodes cooperate equally, and the distribution of transactions and the dissemination of blocks are realized through a peer-to-peer network.

[0025] Transaction broadcast: Nodes in traditional blockchain systems forward received transactions to other nodes connected to them. This broadcast method is based on the principle of "Gossip", that is, through multiple forwardings by neighboring nodes, the transaction is propagated throughout the network. Transaction data includes the input, output and signature information of the transaction, and the average size of a complete data packet is about 250 bytes.

[0026] Block broadcast: After generating a new block, the miner node in the traditional blockchain system broadcasts the block to the entire network. Other nodes verify the block after receiving it. If the block is legal, it will continue to forward it to other nodes. Block data includes block header and block body. The block header contains information such as hash value and timestamp, and the block body contains a list of transactions.

[0027] Although the existing data broadcasting technology of traditional blockchain systems and Ethereum has proven its effectiveness in decentralized networks, these solutions still have obvious shortcomings in weak network environments. The following will systematically explain the shortcomings of traditional blockchain system technical solutions from multiple perspectives.

[0028] Traditional blockchain systems use a "full network broadcast + relay" transmission method. Even if the size of a single transaction is small (250 bytes on average), the amount of broadcast data increases dramatically when the transaction frequency is high. Each transaction may be relayed multiple times by multiple nodes during the broadcast process, and a large number of duplicate data packets greatly wastes network bandwidth. Block broadcasting consumes even more bandwidth. The block body of the traditional blockchain system contains all transaction data, and the amount of data in a single block is usually as high as 1MB. When the block frequency is 10 minutes, all nodes in the entire network need to receive and verify this large amount of data in a short period of time.

[0029] The redundancy problem inherent in full-network broadcasting is a key pain point of existing blockchain technology. When nodes propagate data, they often cannot avoid repeatedly forwarding data that has been received by other nodes. Both traditional blockchain systems and Ethereum rely on the "Gossip" protocol for transaction propagation. Although this method can ensure the propagation coverage of transactions, in the case of random paths between nodes, transaction data is likely to be repeatedly transmitted by multiple nodes, generating a large number of redundant data packets. When broadcasting block data across the entire network, nodes need to repeatedly verify and forward all transactions in the block body. This redundancy problem is particularly serious in scenarios with high-frequency block generation (such as Ethereum's average of one block every 12 seconds).

[0030] The existing broadcast technology solutions of traditional blockchain systems and Ethereum have not been optimized for weak network environments, which is mainly manifested in the following aspects: the design of full-network broadcast lacks flexibility, the propagation paths between nodes are random, and the data transmission strategy cannot be dynamically adjusted according to actual network conditions (such as bandwidth and latency); the data structure is too complex, especially Ethereum's transactions and block data contain a lot of additional information, which makes the size of the data packet difficult to compress, further increasing the communication pressure in weak network environments.

[0031] In response to the above technical problems, the technical concept of the present invention is: by optimizing the data in the consensus broadcast, that is, the new block message broadcast by the consensus node only contains the transaction hash rather than the complete transaction content, thereby greatly reducing the volume and frequency of the broadcast data; and by optimizing the transaction broadcast method, that is, adopting a one-time broadcast method without relays, the repeated propagation of redundant data is avoided.

[0032] Figure 1 A flowchart of a data broadcast method of a blockchain system in a weak network environment provided by an embodiment of the present invention is applied to a blockchain system, wherein the blockchain system includes multiple nodes, the multiple nodes include a consensus node and a first connection node connected to the consensus node, and each node is provided with a transaction cache queue for storing transaction data. Figure 1 As shown, the method includes: Step S101: When the consensus block generation condition is met, the consensus node generates a new block by consensus on the transaction data in the transaction cache queue of the consensus node, and writes the new block into the distributed ledger of the consensus node.

[0033] Specifically, when the conditions for consensus block generation are met, such as a specified time interval, the consensus node in the blockchain system obtains all transaction data from its own transaction cache queue, executes the transaction, generates a new block based on the results of all transaction operations, and writes the new block to the consensus node's own ledger.

[0034] Step S102: The consensus node broadcasts the new block information to the first connection node, where the new block information includes the block metadata information and the transaction hash value corresponding to the transaction data.

[0035] Specifically, a network module is set on the consensus node, and the consensus node sends the new block information to the network module for broadcasting. The network module traverses all nodes connected to the consensus node (ie, the first connected node) and sends the new block information to each connected node.

[0036] It should be emphasized that the new block information in this embodiment only includes block metadata information (such as block height, block hash value) and transaction hash values ​​corresponding to transaction data, and does not include complete transaction content. The transaction hash values ​​corresponding to all transaction data are presented in the form of a transaction hash list.

[0037] Step S103: The first connection node receives the new block information, and obtains transaction data matching the transaction hash value in the new block information from the transaction cache queue of the first connection node.

[0038] Specifically, the first connection node receives new block information from the blockchain network, and queries matching transaction data from its own transaction cache queue according to the transaction hash list in the new block information.

[0039] Step S104: The first connection node verifies the acquired transaction data based on the block metadata information, and packages the verified transaction data into a new block and writes it into the distributed ledger of the first connection node.

[0040] Specifically, the first connection node executes the transaction data, based on the result of the transaction operation, and compares the block metadata information (block height, block hash value) in the new block information to confirm the validity of the new block, packages the transaction data into a new block, and writes it into its own account book.

[0041] In some embodiments, the step S102 includes: the consensus node broadcasts the new block information to the first connection node using a non-relay one-time broadcast method; wherein, the non-relay one-time broadcast method means that after the broadcast node broadcasts the broadcast information to the connection node, the connection node no longer performs relay broadcasting.

[0042] Specifically, the consensus node broadcasts the new block information to the first connected node, and the first connected node no longer relays and broadcasts the new block information it receives. In other words, the consensus node adopts a directional propagation mechanism, which significantly reduces the overall data load of the network through a targeted propagation path.

[0043] In some embodiments, the method further comprises: dividing the other nodes in the plurality of nodes except the consensus node into i-layer nodes according to the connection relationship between each node and the consensus node, , when i=1, it corresponds to the first connection node, and the i+1th layer node is connected to the i-th layer node; starting from i=1, iteratively execute the following steps: the i+1th layer node periodically queries the block metadata information of the i-th layer node; when the block metadata information of the i+1th layer node is inconsistent with the block metadata information of the i-th layer node, the i+1th layer node obtains a new block from the i-th layer node.

[0044] Specifically, when a block is broadcasted, nodes other than the consensus node can be divided into i-layer nodes according to the connection relationship between each node and the consensus node. , when i=1, the first-layer node corresponds to the first connection node connected to the consensus node. When i>1, it means the second-layer node, the third-layer node..., and the latter-layer node is connected to the previous-layer node, such as the P2P network connection mode. When the consensus node broadcasts new block information, the first-layer node receives the new block information and no longer relays the broadcast; the second-layer node determines whether the blockchain ledger data is outdated by regularly requesting or querying the block height on the first-layer node. If so, it will request the corresponding new block from the first-layer node. The new block contains block metadata information, transaction hash value and specific transaction data; similarly, the third-layer node will also determine whether the blockchain ledger data is outdated by regularly requesting or querying the block height on the second-layer node. If so, it will request the corresponding new block from the second-layer node, and so on, until all nodes in the blockchain system are synchronized to the latest block data.

[0045] That is to say, in the process of block broadcasting in this embodiment, the consensus node will broadcast the generated new block information to the first-layer node (i.e., the first connection node). After receiving the new block information, the first-layer node will obtain the transaction data from its own transaction cache queue and package it into a new block. However, the first-layer node will no longer relay the broadcast. Instead, the subsequent-layer nodes will check the data synchronization status by periodically querying the block height of the previous-layer node. If it is found to be lagging behind, it will request to obtain new block data, and so on, until all nodes have synchronized the latest block data.

[0046] In some embodiments, the data structure of the new block information includes first blockchain layer data, first TCP protocol layer data, and first IP protocol layer data, and the first blockchain layer data includes block metadata information and a transaction hash value corresponding to the transaction data.

[0047] like Figure 2 A schematic diagram of a data structure of new block information provided by an embodiment of the present invention, such as Figure 2 As shown, after consensus is completed, the blockchain data packet broadcast by the block is divided into blockchain layer data, TCP protocol layer data, and IP protocol layer data. The IP protocol layer uses IPv4 as a calculation reference. The blockchain layer data consists of the blockchain block header and the transaction hash list. The blockchain block header corresponds to the block metadata information (also known as the block header object data), and the transaction hash list corresponds to the transaction hash value of the transaction data. The encoding rule is Varint encoding, which is a flexible encoding length rather than a fixed encoding length. Taking the int64 type as an example, the space occupied ranges from 1 byte to 10 bytes. The smaller the value, the smaller the occupancy. The specific space occupancy is as follows: header (object type), 144 bytes = object data + object data byte length information + key = (33+33+33+33+3+5)+1+1; hash (bytes type), 32 bytes = 33 bytes = encoded data + key = 32 + 1; preview_hash (bytes type), 33 bytes = encoded data + key = 32 + 1; account_tree_hash (bytes type), 33 bytes = encoded data + key = 32 + 1; validators_hash (bytes type), 33 bytes = encoded data + key = 32 + 1; seq (int64 type), 4 bytes = encoded data + key = 3 + 1; timestamp (int64 type), 6 bytes = encoded data + key = 5 + 1; tx_hash_list (bytes array type), 642 bytes = array data + array data byte length information + key = (640) + 1 + 1.

[0048] The data broadcasting method of the blockchain system in a weak network environment provided in this embodiment optimizes the broadcast data of the consensus node, that is, the consensus node no longer includes complete transaction data when broadcasting new block information, but only broadcasts the transaction hash value. After other nodes receive the new block information, they can obtain the corresponding transaction data from their own transaction cache queue according to these transaction hash values, and then write these data into their own account books. This optimization measure greatly reduces the volume and frequency of broadcast data, optimizes the network adaptability of the broadcast scheme, is particularly suitable for application scenarios under low bandwidth conditions, and realizes the optimization of the overall communication volume; it also realizes the effective dissemination and synchronization of blockchain data by nodes in the entire network through a layered block broadcast mechanism.

[0049] Based on the above embodiments, Figure 3 A flowchart of another method for broadcasting data in a weak network environment of a blockchain system provided by an embodiment of the present invention, wherein the multiple nodes include a transaction node and a second connection node connected to the transaction node. Figure 3 As shown, before step S101, the following steps are also included: Step S301: The transaction node stores the transaction data to be broadcast in the transaction cache queue corresponding to the transaction node, and broadcasts the transaction data to the second connection node in a one-time broadcast mode without relay.

[0050] Step S302: The second connection node stores the received transaction data in a transaction cache queue corresponding to the second connection node.

[0051] The non-relay one-time broadcast mode means that after the broadcast node broadcasts the broadcast information to the connected node, the connected node no longer performs relay broadcasting.

[0052] Specifically, in the Figure 1 Before the block broadcast shown, the transaction broadcast is performed first. The transaction node caches the transaction data to be broadcasted in its own transaction cache queue. The network module in the transaction node will traverse the nodes connected to the transaction node (i.e., the second connection node), and then the transaction node broadcasts the transaction data to the second connection node. After the second connection node receives the transaction data, it also caches the transaction data in the node's own transaction cache queue, and the second connection node will not relay the transaction data. The transaction broadcast is only once.

[0053] In some embodiments, the transaction node in step S301 stores the transaction data to be broadcast in the transaction cache queue corresponding to the transaction node, including: the transaction node receives the transaction data signed and sent by the user client, verifies the validity of the transaction data, and stores the verified transaction data in the transaction cache queue corresponding to the transaction node; the step S302 includes: the second connection node receives the transaction data broadcast by the transaction node, verifies the validity of the transaction data, and stores the verified transaction data in the transaction cache queue corresponding to the second connection node.

[0054] Specifically, the user assembles the blockchain transaction and signs it according to the on-chain business rules, and sends the transaction to the transaction node in the blockchain system. After receiving the transaction data, the transaction node verifies the validity of the transaction data, including the validity of the transaction structure and the validity of the signature. After the verification, the transaction data is cached in the transaction node's own transaction cache queue and broadcasted. The second connection node receives the transaction data from the blockchain system, and each second connection node verifies the validity of the transaction data in its respective module, and caches the verified transaction data in the transaction cache queue of its respective node.

[0055] In some embodiments, the method further comprises: dividing the other nodes except the transaction node among the plurality of nodes into j-layer nodes according to the connection relationship between each node and the transaction node, , when j=1, it corresponds to the second connection node, and the j+1th layer node is connected to the jth layer node; starting from j=1, iteratively execute the following steps until the consensus node receives the transaction data: when the consensus block conditions are met and the transaction data received by the jth layer node is not packaged into a new block, send the transaction data to the j+1th layer node.

[0056] Specifically, when a transaction is broadcast, other nodes except the transaction node can be divided into j-layer nodes according to the connection relationship between each node and the transaction node. , when j=1, the first-layer node corresponds to the second connection node connected to the transaction node. When j>1, it means the second-layer node, the third-layer node..., and the latter-layer node is connected to the previous-layer node, such as the P2P network connection method. When the transaction node broadcasts the transaction data, the first-layer node receives the transaction data and no longer relays the broadcast; the first-layer node will determine whether the transaction data has timed out and has not been packaged. If so, the first-layer node will broadcast the transaction data to the connected second-layer node; if it is still not packaged, the second-layer node will broadcast the transaction data to the connected third-layer node, and so on, until the consensus node receives the transaction data and packages it.

[0057] That is to say, in the transaction broadcast process of this embodiment, the transaction node broadcasts the transaction data to the first-layer node. The first-layer node no longer relays the broadcast, but determines whether the transaction data has timed out and has not been packaged. If so, the transaction data will be broadcast to the next layer of nodes until it is broadcast to the consensus node.

[0058] In some embodiments, the data structure of the transaction data includes business layer data, second blockchain layer data, second TCP protocol layer data, and second IP protocol layer data, the business layer data includes the content of the transaction data, and the second blockchain layer data includes the transaction hash value of the transaction data and the signature information of the user client.

[0059] Figure 4 A data structure diagram of transaction data provided by an embodiment of the present invention, such as Figure 4 As shown in the figure, the blockchain transaction data packets for on-chain operations are divided into business layer data, blockchain layer data, TCP protocol layer data, and IP protocol layer data. The IP protocol layer uses IPv4 as a calculation reference, the business layer data corresponds to the business message, that is, the complete transaction data content, and the blockchain layer data corresponds to the blockchain transaction header. The blockchain transaction header structure consists of a transaction hash value (also known as transaction object data) and user signature list data. The encoding rule is Varint encoding, which is a flexible encoding length rather than a fixed encoding length. Taking the int64 type as an example, the space occupied ranges from 1 byte to 10 bytes. The smaller the value, the smaller the occupancy. The specific space occupancy is as follows: transaction (object type), 97 bytes = object data + object data byte length information + key = (39+5+3+3+45)+1+1; source_address (string type), 39 bytes = string data + string length information + key = 37 + 1 + 1; fee_limit (int64 type), 5 bytes = encoded data + key = 4 + 1; gas_price (int64 type), 3 bytes = encoded data + key = 2 + 1; nonce (int64 type), 3 bytes = encoded data + key = 2 + 1; operations (object array type), 45 bytes = array data + array data byte length information + key = (2 + 41) + 1 + 1; type, 2 bytes = encoded data + key = 1 + 1; invoke_contract(object type), 41 bytes = object data + object data byte length information + key = (39) + 1 + 1; dest_address (string type), 39 bytes = string data + string length information + key = 37+1+1; input (string type), 0 bytes, related to the specific business data message; signatures (object array type), 68 bytes = array data + array data byte length information + key = (66) + 1 + 1; sign_data (bytes type), 66 bytes = binary data + binary length information + key = 64+1+1.

[0060] It should be noted that the sum of the transaction object data and the signature list data is 165 bytes, so the data size attached to the business data by the blockchain layer is 165 bytes.

[0061] On the basis of the foregoing embodiments, by optimizing the transaction broadcasting method, that is, when broadcasting transaction data, the transaction node only needs to broadcast the data once to the connected nodes without relaying the broadcast. This one-time and efficient broadcasting method avoids the repeated propagation of redundant data, reduces communication costs, and improves communication efficiency. It also achieves more efficient propagation of transaction data and ensures that transactions can be packaged and confirmed in a timely manner through a layered transaction broadcasting mechanism.

[0062] Figure 5 A schematic diagram of the architecture of a blockchain system provided by an embodiment of the present invention, Figure 6 for Figure 5 The flowchart of the data broadcasting method of the blockchain system in a weak network environment is shown in FIG. Figure 5 and Figure 6 The embodiments of the present invention are described by way of example: First, if Figure 5 As shown, the blockchain system includes nodes 1-4, wherein node 1 is used as a transaction node and is connected to nodes 2, 3, and 4, and node 4 is used as a single consensus node and is connected to nodes 1, 2, and 3.

[0063] Then, the symbolic expressions involved in this embodiment are explained: TX: stands for transaction, the smallest unit of state change in the distributed ledger; BLK: represents a block, which contains a transaction list, which can be empty or contain multiple transactions.

[0064] Finally, it should be noted that the embodiment of the present invention is specifically designed for limited bandwidth scenarios in weak network environments, including two main parts: "transaction broadcast" and "block broadcast", which reduce redundant communications to improve the processing efficiency and performance of distributed ledgers. This process involves transaction cache queues, consensus processing modules, and user roles. The specific process is as follows: Step 10. The user assembles transaction TX1 according to the on-chain business and sends transaction TX1 to node 1.

[0065] Specifically, the user assembles the transaction parameters according to the on-chain business call rules, and signs the transaction to form transaction TX1, and broadcasts the transaction request through the wallet client.

[0066] Step 20: Node 1 receives and processes transaction TX1. Node 1 broadcasts transaction TX1. Other nodes receive broadcast transaction TX1 and do not continue broadcasting.

[0067] Specifically, first, node 1 receives transaction TX1 sent by the client through the interface, verifies the validity of transaction TX1, including the validity of the transaction structure and the validity of the signature, and adds the verified transaction TX1 to the transaction cache queue of node 1; then, node 1 sends transaction TX1 to the network module of node 1 for broadcasting, and the network module of node 1 traverses all connected nodes (i.e., node 2, node 3, and node 4) and sends transaction TX1 to each connected node; node 2, node 3, and node 4 receive transaction TX1 from the blockchain network, verify the validity of transaction TX1 in their respective modules, and add the verified transaction TX1 to the transaction cache queue of their respective nodes, such as Figure 5 The solid line in the figure represents the one-time broadcasting method without relay in this embodiment. Figure 5 The solid line + dotted line in the figure represent the traditional broadcasting method.

[0068] Step S30, node 4 reaches consensus on block BLK1 and broadcasts block BLK1.

[0069] Specifically, after certain conditions are met, such as a time interval, a single consensus node 4 starts the consensus process, completes the consensus process within a single node, and writes the new block content after the consensus is completed into the ledger, that is, obtains all transactions from the transaction cache queue in node 4, which is transaction TX1 at this time; executes transaction TX1, and generates a new block BLK1 based on the results of all transaction operations, including block height, block hash, transaction hash list, etc.; writes the new block BLK1 into node 4's own ledger; then node 4 sends block BLK1 to node 4's network module for broadcasting, and node 4's network module traverses all connected nodes (i.e., nodes 1, 2, and 3) and sends block BLK1 to each connected node.

[0070] Step S40: After receiving the new block message, other nodes obtain the complete transaction content from the transaction cache queue, verify the validity of the new block, and write it into their respective storage after the verification is completed, completing the new block write operation.

[0071] Specifically, the processes of nodes 1, 2, and 3 are consistent. Taking node 3 as an example, to confirm the validity of the block: node 3 receives block BLK1 from the blockchain network; according to the transaction hash list in BLK1, it queries transaction TX1 from the transaction cache queue; executes transaction TX1, and based on the result of the transaction operation, compares the block BLK1 information, including block height, block hash, etc., to confirm the validity of block BLK1; writes the new block BLK1 into node 3's own ledger.

[0072] In summary, in the transaction broadcast process, the user first assembles transaction TX1 according to the on-chain business. Then, the user sends transaction TX1 to node 1 of the blockchain system. Node 1 receives and verifies the validity of transaction TX1, and puts it into the node's own transaction cache queue after verification. Then, node 1 broadcasts transaction TX1 to other connected nodes in the distributed network: node 2, node 3, and node 4. After receiving transaction TX1 broadcast by node 1, nodes 2, 3, and 4 verify its validity and put it into their respective transaction cache queues. In this process, transaction TX1 has a copy of the data on all nodes, and all interactions of on-chain transactions follow a similar process until the next block data consensus.

[0073] It should be noted that if the blockchain system also includes node 0, node 0 is only connected to node 1. Assuming that a blockchain transaction TX2 is sent to node 0, transaction TX2 will only be broadcast to node 1, and node 1 will not relay the broadcast transaction TX2 to node 4 of the consensus block, which will cause transaction TX2 to fail to be packaged into the block ledger. In this case, node 1 will determine whether transaction TX2 has timed out and not been packaged. For example, the block height when node 1 receives transaction TX2 is 10. If the timeout block height is 2, when node 1 receives block height 12, it finds that transaction TX2 has not been packaged. Node 1 will broadcast transaction TX2 to the connected nodes once. If it is still not packaged, transaction TX2 will be broadcast once every 2 blocks. In this way, transaction TX2 is passed to the consensus node layer by layer until it is packaged into the block ledger.

[0074] In the block broadcast process, node 4 is a single consensus node. When the block consensus conditions are met, such as a specific time interval, node 4 performs consensus block generation internally, saving consensus communication overhead and completing the write operation of the new block. Node 4 broadcasts the new block to nodes 1, 2, and 3. The new block only contains the transaction hash, not the complete transaction content. After receiving the new block message, nodes 1, 2, and 3 obtain the transaction content from the transaction queue according to the transaction hash in the new block, execute the transaction to verify the validity of the new block, and then write it into the new block data. In this process, nodes 1, 2, and 3 no longer relay the block to ensure the efficiency of data transmission and the effective use of network resources.

[0075] It is also necessary to explain that if the blockchain system also includes node 0, node 0 is only connected to node 1, and the block information BLK1 generated by the consensus of node 4 is only broadcast to node 1, and will not be relayed by node 1 to node 0. Node 0 determines whether the blockchain ledger data is behind by regularly requesting or querying the block height on node 1. If the ledger data is found to be behind, it will request the corresponding block information BLK1 and the specific content of the transaction TX1 involved from node 1. The deeper P2P network connection is similar. With the consensus node as the center, the first-layer P2P connection will receive the broadcast message of the consensus node, and the second-layer P2P connection needs to request data on demand after exchanging information with the first layer. And so on. The third layer depends on the second layer, and the fourth layer depends on the third layer, until all nodes of the blockchain system are synchronized to the latest block data.

[0076] In order to further illustrate that this embodiment is applicable to a weak network environment, an example calculation of the communication bandwidth required for this embodiment is now performed: Transaction broadcast communication calculation: Number of nodes in the blockchain network: 16; Average block interval: 5 seconds; Single transaction size: 512 bytes - 40 bytes protocol = 347 bytes; Number of block transactions: 16 / 5 seconds; Single node transaction broadcast communication rate: 512 bytes X 15 nodes X 1.05 packet loss rate X 8 ÷ 5 seconds X 2 times = 25,804.8bps; Consensus broadcast communication calculation: The consensus process is completed within a single node and does not involve communication and computing Block information broadcast packet size: 696 bytes; The consensus node transmission rate is: 696 bytes X 15 nodes X 1.05 packet loss rate X 8 ÷ 5 seconds = 17,539.2bps; The receiving communication rate of other nodes is: 696 bytes X 1.05 packet loss rate X 8 ÷ 5 seconds = 1,169.28bps; The total consensus node communication rate is: 25,804.8 + 17,539.2 = 43,344bps ≈ 43kbps; The total communication rate of other nodes is: 25,804.8 + 1,169.28 = 26,974.08bps ≈ 27kbps; After calculation, the bandwidth requirement on the node is 43kbps for the consensus node and 27kbps for other nodes. It can be seen that this embodiment can achieve efficient data broadcast communication in a weak network environment. In addition, there is a large difference in communication rate between different node roles. The main reason is that the block verification node needs to broadcast block information to its directly connected P2P node once after completing the consensus block.

[0077] In summary, this embodiment has the following beneficial effects: 1. Significantly reduce bandwidth requirements: By optimizing the broadcast method, the total amount of data broadcasted across the entire network is reduced. Transaction broadcasts use a one-time broadcast without relays, and consensus broadcasts only contain transaction hashes, which greatly reduces the size of data packets and adapts to low-bandwidth environments.

[0078] 2. Eliminate data redundancy: Eliminate repeated data transmission between nodes, adopt a streamlined mechanism to transmit transaction and consensus data, and send relevant data only when necessary to avoid wasting network resources.

[0079] 3. Reduced communication burden on consensus nodes: The consensus process is handled within the node, and only the new block data after the consensus is completed is propagated. The consensus node does not need to process the multi-stage confirmation data in the consensus process, which reduces the amount of data and verification calculation requirements, and improves stability in weak network environments.

[0080] 4. Improve network communication efficiency: optimize overall communication volume and transmission paths, reduce invalid transmission, balance the load between nodes, and improve the scalability and stability of the blockchain network.

[0081] The embodiment of the present invention also provides a blockchain system. The blockchain system includes multiple nodes, the multiple nodes include a consensus node and a first connection node connected to the consensus node, and each node is provided with a transaction cache queue for storing transaction data; The consensus node is used to generate a new block by consensus on the transaction data in the transaction cache queue of the consensus node when the consensus block conditions are met, and write the new block into the distributed ledger of the consensus node; The consensus node is used to broadcast new block information to the first connection node, where the new block information includes block metadata information and a transaction hash value corresponding to the transaction data; The first connection node is used to receive the new block information, and obtain transaction data matching the transaction hash value in the new block information from the transaction cache queue of the first connection node; The first connection node is used to verify the acquired transaction data based on the block metadata information, and package the verified transaction data into a new block and write it into the distributed ledger of the first connection node.

[0082] In some embodiments, the consensus node is specifically used to: broadcast the new block information to the first connection node in a one-time broadcast mode without relay; The non-relay one-time broadcast mode means that after the broadcast node broadcasts the broadcast information to the connected node, the connected node no longer performs relay broadcasting.

[0083] In some embodiments, the blockchain system is used to divide the nodes other than the consensus node among the multiple nodes into i-layer nodes according to the connection relationship between each node and the consensus node, , when i=1, it corresponds to the first connection node, and the i+1th layer node is connected to the ith layer node; Starting from i=1, iterate and perform the following steps: The i+1th layer node periodically queries the block metadata information of the ith layer node; When the block metadata information of the i+1th layer node is inconsistent with the block metadata information of the i-th layer node, the i+1th layer node obtains the new block from the i-th layer node.

[0084] In some embodiments, the data structure of the new block information includes first blockchain layer data, first TCP protocol layer data, and first IP protocol layer data, and the first blockchain layer data includes block metadata information and a transaction hash value corresponding to the transaction data.

[0085] In some embodiments, the plurality of nodes include a transaction node and a second connection node connected to the transaction node. The transaction node is used to store the transaction data to be broadcasted in the transaction cache queue corresponding to the transaction node, and broadcast the transaction data to the second connection node in a one-time broadcast mode without relay; The second connection node is used to store the received transaction data in a transaction cache queue corresponding to the second connection node; The non-relay one-time broadcast mode means that after the broadcast node broadcasts the broadcast information to the connected node, the connected node no longer performs relay broadcasting.

[0086] In some embodiments, the transaction node is specifically used to: receive transaction data signed and sent by the user client, verify the validity of the transaction data, and store the verified transaction data in the transaction cache queue corresponding to the transaction node; The second connection node is specifically used to: receive the transaction data broadcast by the transaction node, verify the validity of the transaction data, and store the verified transaction data in the transaction cache queue corresponding to the second connection node.

[0087] In some embodiments, the blockchain system is used to divide the nodes other than the transaction nodes among the multiple nodes into j-layer nodes according to the connection relationship between each node and the transaction node, , when j=1, it corresponds to the second connection node, and the j-th layer node is connected to the j+1-th layer node; Starting from j=1, iterate and execute the following steps until the consensus node receives the transaction data: When the consensus block conditions are met and the transaction data received by the j-th layer node has not been packaged into a new block, the transaction data is sent to the j+1-th layer node.

[0088] In some embodiments, the data structure of the transaction data includes business layer data, second blockchain layer data, second TCP protocol layer data, and second IP protocol layer data, the business layer data includes the content of the transaction data, and the second blockchain layer data includes the transaction hash value of the transaction data and the signature information of the user client.

[0089] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working process of the blockchain system described above and the corresponding beneficial effects can refer to the corresponding process in the aforementioned method example, and will not be repeated here.

[0090] The embodiment of the present invention provides another data broadcasting method of a blockchain system in a weak network environment, which is applied to a consensus node in the blockchain system as described in the above embodiment, and the method includes: When the consensus block conditions are met, a new block is generated by consensus on the transaction data in the transaction cache queue of the consensus node, and the new block is written into the distributed ledger of the consensus node; The new block information is broadcasted to the first connection node, wherein the new block information includes block metadata information and a transaction hash value corresponding to the transaction data.

[0091] In some embodiments, broadcasting the new block information to the first connection node includes: broadcasting the new block information to the first connection node in a non-relay one-time broadcast manner; The non-relay one-time broadcast mode means that after the broadcast node broadcasts the broadcast information to the connected node, the connected node no longer performs relay broadcasting.

[0092] Technical personnel in the relevant field can clearly understand that, for the convenience and conciseness of description, the specific working process and corresponding beneficial effects of the data broadcasting method of the blockchain system in a weak network environment described above can refer to the corresponding process in the aforementioned method example, and will not be repeated here.

[0093] The embodiment of the present invention provides another data broadcasting method of a blockchain system in a weak network environment, which is applied to the first connection node in the blockchain system in the above-mentioned embodiment, and the method includes: Receive new block information broadcast by the consensus node, and obtain transaction data matching the transaction hash value in the new block information from the transaction cache queue of the first connection node; Verify the acquired transaction data based on the block metadata information, and package the verified transaction data into a new block and write it into the distributed ledger of the first connection node Technical personnel in the relevant field can clearly understand that, for the convenience and conciseness of description, the specific working process and corresponding beneficial effects of the data broadcasting method of the blockchain system in a weak network environment described above can refer to the corresponding process in the aforementioned method example, and will not be repeated here.

[0094] The embodiment of the present invention provides another data broadcasting method of a blockchain system in a weak network environment, which is applied to a transaction node in the blockchain system in the above-mentioned embodiment. The method includes: The transaction data to be broadcast is stored in the transaction cache queue corresponding to the transaction node, and the transaction data is broadcast to the second connection node in a non-relay one-time broadcast mode, so that the second connection node stores the received transaction data in the transaction cache queue corresponding to the second connection node; The non-relay one-time broadcast mode means that after the broadcast node broadcasts the broadcast information to the connected node, the connected node no longer performs relay broadcasting.

[0095] In some embodiments, storing the transaction data to be broadcast in the transaction cache queue corresponding to the transaction node includes: Receive the transaction data signed by the user client, verify the validity of the transaction data, and store the verified transaction data in the transaction cache queue corresponding to the transaction node.

[0096] Technical personnel in the relevant field can clearly understand that, for the convenience and conciseness of description, the specific working process and corresponding beneficial effects of the data broadcasting method of the blockchain system in a weak network environment described above can refer to the corresponding process in the aforementioned method example, and will not be repeated here.

[0097] The embodiment of the present invention provides another data broadcasting method of a blockchain system in a weak network environment, which is applied to the second connection node in the blockchain system in the above-mentioned embodiment, and the method includes: storing the received transaction data in a transaction cache queue corresponding to the second connection node, wherein the transaction data is broadcasted to the second connection node by the transaction node in a one-time broadcast manner without relays; The non-relay one-time broadcast mode means that after the broadcast node broadcasts the broadcast information to the connected node, the connected node no longer performs relay broadcasting.

[0098] In some embodiments, storing the received transaction data in the transaction cache queue corresponding to the second connection node includes: the second connection node receives the transaction data broadcast by the transaction node, verifies the validity of the transaction data, and stores the verified transaction data in the transaction cache queue corresponding to the second connection node.

[0099] Technical personnel in the relevant field can clearly understand that, for the convenience and conciseness of description, the specific working process and corresponding beneficial effects of the data broadcasting method of the blockchain system in a weak network environment described above can refer to the corresponding process in the aforementioned method example, and will not be repeated here.

[0100] It should be noted that, in this article, relational terms such as "first" and "second" are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, the elements defined by the sentence "comprise a ..." do not exclude the existence of other identical elements in the process, method, article or device including the elements.

[0101] The foregoing is merely a specific embodiment of the present invention, which enables those skilled in the art to understand or implement the present invention. Various modifications to these embodiments will be apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present invention. Therefore, the present invention will not be limited to the embodiments shown herein, but rather to the widest scope consistent with the principles and novel features claimed herein.

Claims

1. A data broadcasting method of a blockchain system in a weak network environment, characterized in that: Applied to a blockchain system, the blockchain system includes a plurality of nodes, the plurality of nodes include a consensus node and a first connection node connected to the consensus node, each node is provided with a transaction cache queue for storing transaction data; the method includes: When the consensus block conditions are met, the consensus node generates a new block by consensus on the transaction data in the transaction cache queue of the consensus node, and writes the new block into the distributed ledger of the consensus node; The consensus node broadcasts the new block information to the first connection node, wherein the new block information includes the block metadata information and the transaction hash value corresponding to the transaction data; The first connection node receives the new block information, and obtains transaction data matching the transaction hash value in the new block information from the transaction cache queue of the first connection node; The first connection node verifies the acquired transaction data based on the block metadata information, and packages the verified transaction data into a new block and writes it into the distributed ledger of the first connection node.

2. The method according to claim 1, characterized in that The consensus node broadcasts the new block information to the first connection node, including: The consensus node broadcasts the new block information to the first connected node using a one-time broadcast method without relays; The non-relay one-time broadcast mode means that after the broadcast node broadcasts the broadcast information to the connected node, the connected node no longer performs relay broadcasting.

3. The method according to claim 2, characterized in that The method further comprises: According to the connection relationship between each node and the consensus node, the nodes other than the consensus node in the multiple nodes are divided into i-layer nodes. , when i=1, it corresponds to the first connection node, and the i+1th layer node is connected to the ith layer node; Starting from i=1, iterate and perform the following steps: The i+1th layer node periodically queries the block metadata information of the ith layer node; When the block metadata information of the i+1th layer node is inconsistent with the block metadata information of the i-th layer node, the i+1th layer node obtains the new block from the i-th layer node.

4. The method according to any one of claims 1 to 3, characterized in that: The data structure of the new block information includes first blockchain layer data, first TCP protocol layer data and first IP protocol layer data, and the first blockchain layer data includes block metadata information and a transaction hash value corresponding to the transaction data.

5. The method according to claim 1, characterized in that The multiple nodes include a transaction node and a second connection node connected to the transaction node, and before the consensus node reaches consensus on the transaction data in the transaction cache queue of the consensus node, the consensus node also includes: The transaction node stores the transaction data to be broadcast in the transaction cache queue corresponding to the transaction node, and broadcasts the transaction data to the second connection node in a one-time broadcast mode without relays; The second connection node stores the received transaction data in a transaction cache queue corresponding to the second connection node; The non-relay one-time broadcast mode means that after the broadcast node broadcasts the broadcast information to the connected node, the connected node no longer performs relay broadcasting.

6. The method according to claim 5, characterized in that The transaction node stores the transaction data to be broadcast in the transaction cache queue corresponding to the transaction node, including: The transaction node receives the transaction data signed by the user client, verifies the validity of the transaction data, and stores the verified transaction data in the transaction cache queue corresponding to the transaction node; The second connection node stores the received transaction data in a transaction cache queue corresponding to the second connection node, including: The second connection node receives the transaction data broadcasted by the transaction node, verifies the validity of the transaction data, and stores the verified transaction data in a transaction cache queue corresponding to the second connection node.

7. The method according to claim 5, characterized in that The method further comprises: According to the connection relationship between each node and the transaction node, the nodes other than the transaction nodes in the multiple nodes are divided into j-layer nodes. , when j=1, it corresponds to the second connection node, and the j-th layer node is connected to the j+1-th layer node; Starting from j=1, iterate and execute the following steps until the consensus node receives the transaction data: When the consensus block conditions are met and the transaction data received by the j-th layer node has not been packaged into a new block, the transaction data is sent to the j+1-th layer node.

8. The method according to any one of claims 5 to 7, characterized in that: The data structure of the transaction data includes business layer data, second blockchain layer data, second TCP protocol layer data and second IP protocol layer data, the business layer data includes the content of the transaction data, and the second blockchain layer data includes the transaction hash value of the transaction data and the signature information of the user client.

9. A blockchain system, characterized in that: The method comprises a plurality of nodes, wherein the plurality of nodes comprises a consensus node and a first connection node connected to the consensus node, and each node is provided with a transaction cache queue for storing transaction data; When the consensus block generation conditions are met, the consensus node is used to generate a new block by consensus on the transaction data in the transaction cache queue of the consensus node, and write the new block into the distributed ledger of the consensus node; The consensus node is used to broadcast new block information to the first connection node, where the new block information includes block metadata information and a transaction hash value corresponding to the transaction data; The first connection node is used to receive the new block information, and obtain transaction data matching the transaction hash value in the new block information from the transaction cache queue of the first connection node; The first connection node is used to verify the acquired transaction data based on the block metadata information, and package the verified transaction data into a new block and write it into the distributed ledger of the first connection node.

10. The blockchain system according to claim 9, characterized in that: The plurality of nodes include a transaction node and a second connection node connected to the transaction node; The transaction node is used to store the transaction data to be broadcasted in the transaction cache queue corresponding to the transaction node, and broadcast the transaction data to the second connection node in a one-time broadcast mode without relay; The second connection node is used to store the received transaction data in a transaction cache queue corresponding to the second connection node; The non-relay one-time broadcast mode means that after the broadcast node broadcasts the broadcast information to the connected node, the connected node no longer performs relay broadcasting.

Images