CN115174572B

CN115174572B - Data multicasting method in blockchain, blockchain node and storage medium

Info

Publication number: CN115174572B
Application number: CN202210760113.6A
Authority: CN
Inventors: 石杰
Original assignee: Ant Blockchain Technology Shanghai Co Ltd
Current assignee: Ant Blockchain Technology Shanghai Co Ltd
Priority date: 2022-06-30
Filing date: 2022-06-30
Publication date: 2024-01-05
Anticipated expiration: 2042-06-30
Also published as: CN115174572A

Abstract

A method of multicasting data and a blockchain node in a blockchain system, the method performed by a first node in the blockchain system, the blockchain system further including a second node and a third node, the method comprising: acquiring a first connection path between a first node and a second node, wherein the first connection path is used for sending first data to the second node; acquiring a second connection path between the first node and the third node, wherein the second connection path is used for sending first data to the third node; and when the node after the first node in the first connection path is determined to be a fourth node in the blockchain system and the node after the first node in the second connection path is determined to be the fourth node, sending a first message to the fourth node, wherein the first message comprises the first data and a target node identifier, and the target node identifier comprises an identifier of a second node and an identifier of a third node.

Description

Data multicasting method in blockchain, blockchain node and storage medium

Technical Field

The embodiment of the specification belongs to the technical field of block chains, and particularly relates to a data multicasting method in a block chain and a block chain node.

Background

Blockchain (Blockchain) is a new application mode of computer technologies such as distributed data storage, point-to-point transmission, consensus mechanisms, encryption algorithms, and the like. In the block chain system, the data blocks are combined into a chain data structure in a sequential connection mode according to the time sequence, and the distributed account book which is not tamperable and counterfeit and is ensured in a cryptographic mode is formed. Because the blockchain has the characteristics of decentralization, non-tamperability of information, autonomy and the like, the blockchain is also receiving more and more attention and application.

Disclosure of Invention

The invention aims to provide a data multicast method in a block chain, which improves the data distribution efficiency by aggregating messages in the same path.

A first aspect of the present disclosure provides a method for multicasting data in a blockchain, performed by a first node, including:

acquiring a first connection path between the first node and a second node, wherein the first connection path is used for sending first data to the second node;

acquiring a second connection path between the first node and a third node, wherein the second connection path is used for sending the first data to the third node;

And when the node after the first node in the first connection path is determined to be a fourth node, and the node after the first node in the second connection path is determined to be the fourth node, sending a first message to the fourth node, wherein the first message comprises the first data and a target node identifier, and the target node identifier comprises an identifier of the second node and an identifier of the third node.

A second aspect of the present specification provides a first node in a blockchain system, comprising:

an obtaining unit, configured to obtain a first connection path between the first node and a second node in a blockchain system, where the first connection path is used to send first data to the second node; acquiring a second connection path between the first node and a third node in the blockchain system, wherein the second connection path is used for sending the first data to the third node;

a sending unit, configured to send a first message to a fourth node in the blockchain system when it is determined that a node in the first connection path after the first node is the fourth node and a node in the second connection path after the first node is the fourth node, where the first message includes the first data and a target node identifier, and the target node identifier includes an identifier of the second node and an identifier of the third node.

A third aspect of the present description provides a computer-readable storage medium having stored thereon a computer program which, when executed in a computer, causes the computer to perform the method of the first aspect.

A fourth aspect of the present specification provides a blockchain node comprising a memory having executable code stored therein and a processor that when executing the executable code implements the method of the first aspect.

According to the data multicast scheme in the embodiment of the specification, redundant data in the data multicast process is avoided and the data distribution efficiency is improved by carrying out message aggregation in the same path in a plurality of connection paths in the data multicast.

Drawings

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

FIG. 1 illustrates a block chain architecture diagram in one embodiment;

FIG. 2 is a schematic diagram of a consensus process in a PBFT consensus algorithm;

FIG. 3 is a flow chart of a block link point grouping method in an embodiment of the present disclosure;

FIG. 4 is a schematic diagram of connections between nodes in a blockchain;

fig. 5 is a schematic diagram of message multicasting in an embodiment of the present specification;

fig. 6 is a flowchart of a data multicasting method in an embodiment of the present disclosure;

fig. 7 is a block chain system architecture diagram of a first node in an embodiment of the present disclosure.

Detailed Description

In order to make the technical solutions in the present specification better understood by those skilled in the art, the technical solutions in the embodiments of the present specification will be clearly and completely described below with reference to the drawings in the embodiments of the present specification, and it is obvious that the described embodiments are only some embodiments of the present specification, not all embodiments. All other embodiments, which can be made by one of ordinary skill in the art without undue burden from the present disclosure, are intended to be within the scope of the present disclosure.

FIG. 1 illustrates a block chain architecture diagram in one embodiment. In the blockchain architecture diagram shown in fig. 1, the blockchain 100 includes N nodes, and nodes 1-8 are schematically shown in fig. 1. The connections between nodes schematically represent P2P (Peer to Peer) connections, which may be TCP connections or the like, for example, for transmitting data between nodes. The nodes may store a full amount of ledgers, i.e., the state of all blocks and all accounts. Wherein each node in the blockchain may generate the same state in the blockchain by performing the same transaction, each node in the blockchain may store the same state database.

Transactions in the blockchain domain may refer to task units that execute in the blockchain and are recorded in the blockchain. The transaction typically includes a send field (From), a receive field (To), and a Data field (Data). Where the transaction is a transfer transaction, the From field indicates an account address From which the transaction was initiated (i.e., a transfer task To another account was initiated), the To field indicates an account address From which the transaction was received (i.e., a transfer was received), and the Data field includes the transfer amount. In the case of a transaction calling a smart contract in a blockchain, the From field represents the account address From which the transaction originated, the To field represents the account address of the contract that the transaction called, and the Data field includes Data, such as the name of the function in the calling contract, and the incoming parameters To the function, for retrieving the code of the function From the blockchain and executing the code of the function when the transaction is executed.

Blockchain technology differs from one of the decentralized features of conventional technology in that accounting is performed on individual nodes, otherwise known as distributed accounting, rather than conventional centralized accounting. The blockchain system is to be a hard-to-break, public, untampered, decentralised, honest and trusted system for data records, and needs to be secure, clear and irreversible for distributed data records in as short a time as possible. In different types of blockchain networks, in order to keep account books consistent among the nodes of each record account book, a consensus algorithm is generally adopted to ensure that the above-mentioned consensus mechanism is adopted. For example, a block granularity consensus mechanism may be implemented between blockchain nodes, such as after a node (e.g., a unique node) generates a block, if the generated block is approved by other nodes, the other nodes record the same block. For another example, a transaction granularity consensus mechanism may be implemented between blockchain nodes, for example, after a node (e.g., a unique node) obtains a blockchain transaction, if the blockchain transaction is approved by other nodes, each node approving the blockchain transaction may respectively add the blockchain transaction to its own maintained latest block, and finally, each node may be ensured to generate the same latest block. The consensus mechanism is a mechanism that the blockchain node achieves the consensus of the whole network about the blockinformation (or blockdata), and can ensure that the latest block is accurately added to the blockchain. The consensus mechanisms of the current mainstream include: proof of Work (POW), proof of equity (POS), proof of commission (Delegated Proof of Stake, DPOS), practical bayer fault tolerance (Practical Byzantine Fault Tolerance, PBFT) algorithms, and the like. Among the various consensus algorithms, the success of consensus on a consensus proposal is determined, typically after a preset number of nodes agree on the data to be consensus (i.e., the consensus proposal). Specifically, in the PBFT algorithm, f malicious nodes can be tolerated for N.gtoreq.3f+1 consensus nodes, that is, when 2f+1 nodes in the N consensus nodes agree, success of the consensus can be determined.

Fig. 2 is a schematic diagram of a consensus process in a PBFT consensus algorithm. As shown in fig. 2, according to the PBFT consensus algorithm, the consensus process can be divided into four phases of Request, preparation and Commit. Assuming that a blockchain includes four consensus nodes of node n 1-node n4, wherein node n1 is, for example, a master node, and node n 2-node n4 is, for example, a slave node, f=1 malicious nodes can be tolerated in node n 1-node n4 according to the PBFT algorithm. Specifically, during the request phase, a user of the blockchain may send a request, for example in the form of a blockchain transaction, to node n1 through his user device. In the preliminary stage, the node n1 may package a plurality of transactions into a consensus proposal after receiving the plurality of transactions from one or more user devices, and send the consensus proposal and a signature of the consensus proposal by the node n1 to other consensus nodes (i.e. nodes n 2-n 4) for generating blocks, where the consensus proposal may include information such as a transaction body of the plurality of transactions and a submitting sequence of the plurality of transactions. In the preparation phase, each slave node may sign the consensus proposal and send it to the other individual nodes. Assuming node n4 is a malicious node, nodes n1, n2, and n3, after each receiving the signatures of 2 f=2 other consensus nodes for the consensus proposal, may determine that the preparation phase is complete, and may enter the commit phase. For example, as shown in fig. 2, after receiving the signatures of node n2 and node n3, node n1 verifies that both the signatures of node n2 and node n3 are correct signatures of the consensus proposal, and then determines that the preparation phase is complete, and node n2 determines that the preparation phase is complete after receiving the signature of node n3 and the signature of preparation phase node n1 and verifying passed. In the submitting stage, each consensus node performs signature of the submitting stage on the consensus proposal and sends the signature to other consensus nodes, and each consensus node can determine that the submitting stage is completed and the consensus is successful after receiving the signatures of the submitting stages of 2 f=2 other consensus nodes. For example, the node n1 may determine that the commit phase is completed after receiving the signatures of the commit phases of the node n2 and the node n3 and verifying, so that the node n1 may perform executing the plurality of transactions according to the consensus proposal, generate and store a block (e.g., block B1) including the plurality of transactions, update the world state according to the execution results of the plurality of transactions, and return the execution results of the plurality of transactions to the user device. Similarly, after determining that the commit phase is complete, nodes n2 and n3 execute the plurality of transactions, generate and store block B1, and update the world state based on the execution results of the plurality of transactions. Through the above process, the storage consistency of the node n1, the node n2 and the node n3 is realized. That is, the nodes n 1-n 4 can still realize successful consensus of the consensus proposal in the presence of a malicious node, and complete execution of the block.

There are many scenarios in blockchains where data broadcasting is required, for example, a blockchain node needs to broadcast a received transaction into the blockchain after receiving the transaction. Alternatively, in the consensus scenario shown in fig. 2, each node needs to broadcast a consensus proposal to other nodes during the consensus process.

In addition, for blockchain systems built from large-scale nodes, a small number of nodes may be selected from the large-scale nodes as consensus nodes that participate in performing a consensus mechanism. The consensus nodes with relatively small number participate in executing the consensus mechanism to agree on the consensus proposal, and the consensus proposal which is agreed on can be distributed to other non-consensus nodes which are not selected as the consensus nodes in the large-scale nodes by the consensus nodes, so that the consensus efficiency of the blockchain system can be improved. After the consensus proposal is agreed by the multiple consensus nodes through the process shown in fig. 2, each consensus node may broadcast the consensus proposal acquired by itself to other non-consensus nodes in the blockchain, that is, each consensus node becomes a data source in the blockchain and broadcasts data to the non-consensus nodes.

Wherein the data broadcast includes an operation that one node transmits the same data to a plurality of nodes, which may also be referred to as data multicast.

In one related art, data broadcasting is performed by clustering a plurality of nodes in a blockchain according to access delay information between the respective nodes and according to the clustering result.

Fig. 3 is a flowchart of a block link point grouping method in an embodiment of the present disclosure. Wherein in fig. 3, the nodes in the blockchain are divided into a plurality of node groups by clustering the nodes by the computing device according to access latency information between the nodes. Here, the computing device may be a server, or may be a node in a blockchain, and fig. 3 schematically illustrates the node 1 in fig. 1 as the computing device. In addition, node 2 shown in FIG. 3 is an example, and other nodes in the blockchain may implement similar method flows as node 2.

As shown in fig. 3, first, in step S301, the node 2 generates local access latency information.

Each node in the blockchain may generate access latency information between the node and other nodes, thereby generating local access latency information. Specifically, taking node 2 as an example, node 2 may first obtain a node list. For example, a node list of all nodes included in a blockchain is stored in a contract state of a particular contract in the blockchain. The node list includes, for example, an identification of each node and connection information of each node, where the connection information includes, for example, information of an IP address, a port, and the like. Node 2 may retrieve the list of nodes by invoking the query interface of the contract.

Node 2 may then establish connections with other various nodes in the blockchain based on the list of nodes. In the case where the node 2 cannot establish a direct connection with another node (hereinafter referred to as a target node), it is possible to find the shortest path with the target node, the number of nodes in the shortest path being the smallest, among the nodes on the connection, and connect to the target node through the shortest path.

After node 2 establishes a connection (direct or indirect connection, such as a short connection) with other nodes in the blockchain as described above, node 2 transmits a lightweight packet to each of the other nodes, respectively, and records transmission times corresponding to the respective other nodes. Each other node returns an Acknowledgement (ACK) for the heartbeat packet immediately after receiving the heartbeat packet. After receiving the ACK from the other nodes, the node 2 records the reception time of the ACK received from each other node. Then, access delays corresponding to the respective other nodes may be calculated according to the transmission time and the reception time corresponding to the respective other nodes.

For example, for the node 3, the node 2 records the transmission time T1 of the heartbeat packet to the node 3, records the reception time T2 of the ACK received after the ACK is received from the node 3, and then can calculate the access delay rtt=t2-T1 with the node 3. Wherein node 3 may be directly connected to node 2 or may be indirectly connected to node 2 through other nodes. In one embodiment, node 2 may send heartbeat packets to node 3 multiple times to obtain multiple access delays RTT1, RTT2, RTT3, … RTTn, and node 2 may calculate an average of the multiple access delays as an average access delay with node 3.

The node 2 can acquire access delay information of other nodes in the blockchain by repeating the detection process with each node, so that local access delay information can be generated. The local access delay information is, for example, a local routing table, where access delay information between the node 2 and each other node in the blockchain is included, and the access delay information is, for example, an access delay, or an average access delay, etc.

In step S303, node 2 transmits the local access latency information to the computing device.

Taking the computing device as node 1 as an example, node 2 may send the generated local access latency information to node 1. In one embodiment, node 2 may cause each node in the blockchain to store the local access latency information into the contract state of the contract by executing a transaction that invokes the contract by sending the transaction into the blockchain. The node 1 may obtain the local access latency information by receiving the transaction. Other nodes in the blockchain may also query the local access latency information by sending a transaction invoking the contract.

In step S305, the computing device generates global access latency information.

Specifically, after the node 1 obtains the local access delay information of each of all the nodes in the blockchain, the node may aggregate a plurality of local access delay information, thereby generating global access delay information. Wherein the local access delay information of the node A comprises the access delay RTT between the node A and the node B _A-B The local access delay information of the node B comprises the access delay RTT between the node B and the node A _B-A Can take RTT _A-B And RTT (round trip time) _B-A The larger value between them acts as access delay between node a and node B.

In step S307, the computing device clusters a plurality of nodes in the blockchain according to the global access latency information.

Node 1 may cluster nodes by a variety of known clustering algorithms.

In one embodiment, node 1 may first perform coarse clustering of multiple nodes by the Canopy algorithm to determine the K value for clustering.

Specifically, node 1 sets set S1, and all nodes in the blockchain are initially included in set S1. Node 1 may preset two access latency thresholds T3 and T4, where T3> T4. Node 1 then selects one node P from set S1 as a class C1, and selects another node Q, and determines whether the time delay between node Q and class C1 is less than or equal to time T3. Here the delay between node Q and class C1 is the delay between node Q and node P. If so, the node Q is also added to class C1, and it is determined whether the time delay between the node Q and the node P is less than or equal to T4, if so, the node Q is deleted in the source S1. If the delay between node Q and node P is greater than time T3, then node Q is taken as a new class. When a plurality of nodes are included in the class C1, the time delay between the node and the class may be calculated in various ways, for example, an average value of the time delays of the node and the plurality of nodes included in the class may be calculated as the time delay between the node and the class.

Thereafter, the next node in the set S1 may be selected to repeat the above process, and finally, the plurality of nodes in the set S1 may be divided into K classes, so that the K value used in clustering may be obtained. And the K value of the clustering algorithm is determined by coarsely clustering the plurality of nodes based on global access delay information based on a canopy algorithm, so that the accuracy of subsequent clustering of the plurality of nodes is improved. It will be appreciated that the K values for clustering are not limited to being determined by the canopy algorithm in the embodiments of the present description, and may be manually specified empirically by business personnel, for example.

After determining the K value, node 1 may cluster multiple nodes in the blockchain, for example, by a K-means algorithm.

Specifically, node 1 first randomly determines K nodes among a plurality of nodes in the blockchain as initial center points of K clusters. Then, the node 1 may allocate other nodes in the blockchain to the cluster where the nearest center point is located according to the global access latency information, where the nearest refers to that the access latency is the shortest. After node 1 allocates all other nodes in the blockchain into K clusters as described above, node 1 may recalculate the center point of each cluster. Specifically, for example, for the cluster Cr1, the node 1 may calculate, according to the global routing table, statistical information of multiple delays between each node in the cluster Cr1 and other nodes in the cluster Cr1, where the statistical information may be, for example, a sum, a mean, a variance, a mean square error, and the like of the multiple delays. Taking the average value as an example, the node 1 may redetermine the node with the smallest average value of the time delays in the cluster Cr1 as a new center point, where the new center point has the smallest average value of a plurality of time delays with other nodes in the cluster Cr1, that is, is equivalent to being located at the center of the cluster Cr 1.

If the calculated position of the center point is the same as the original center point, the clustering process can be ended, otherwise, the center points of all clusters are updated, and the clustering process is repeated. Node 1 may determine the final clustering result, i.e., K clusters, by iterating the clustering process multiple times, with low access latency between nodes included in each cluster.

In step S309, the computing device transmits the clustering result to node 2.

The clustering result includes, for example, the information of the K clusters described above, including the node identification included in each cluster.

In step S311, the node 2 performs data broadcasting according to the clustering result.

After receiving the clustering result, the node 2 may make a connection (e.g., a connection such as a TCP connection or the like) with another node according to the clustering result, and perform data broadcasting through the connection. FIG. 4 is a schematic diagram of connections between nodes in a blockchain. Taking node 2 as an example, as shown in fig. 4, node 2 may establish a connection with most of the nodes in the cluster in which it is located, the nodes with which node 2 establishes a connection being indicated in light grey boxes in fig. 4. It will be appreciated that the node 2 may establish a connection with as many other nodes as possible in the cluster Cr1 to improve the data broadcasting efficiency in the cluster Cr1, and in some specific scenarios, for example, the node 2 may not establish a direct connection with a certain node in the cluster Cr1 due to a network connection number limitation, and the node 2 may still establish an indirect connection with the node that cannot be directly connected through other nodes. Meanwhile, the node 2 may randomly select a small number (e.g., 1 or 2) of nodes in other clusters to establish connection, for example, the node 2 may connect with the nodes 5 and 6 in the cluster Cr 2. Other nodes in the blockchain all establish connections with other nodes in the same manner as node 2, e.g., node 3 in cluster Cr1 may establish connections with a large portion of the other nodes in cluster Cr1 (not shown in fig. 4), while node 3 may establish connections with a small number of nodes randomly determined in the other clusters, e.g., node 3 may establish connections with node 5 in cluster Cr2 (not shown in fig. 4), and node 4 may establish connections with node 7 in cluster Cr2 (not shown in fig. 4). By establishing the connection between nodes as described above, the efficiency of data broadcasting within a cluster is ensured, while ensuring that a network path can be reached between any two nodes in the blockchain full network.

After the connection is established as described above, assuming that node 2 is a consensus node, node 2 becomes a data source node in cluster Cr1 after completing consensus with other consensus nodes, node 2 may send the consensus proposal to other individual nodes in cluster Cr1 through the connection shown in fig. 4, so that other individual nodes in cluster Cr1 may perform transactions based on the consensus proposal, generating a new block.

Assuming that there is no consensus node in cluster Cr2 and cluster Cr3 in the K clusters, node 2 may send a consensus proposal to either of cluster Cr2 and cluster Cr3 via an established connection between each node in the blockchain such that node becomes the data source node in cluster Cr 2. Fig. 5 is a schematic diagram of message multicasting by the node 2 to the node 5 in the cluster Cr2 and the node 8 in the cluster Cr3 in the embodiment of the present specification. In the related art, when the node 2 performs the multicast, it generally determines a connection path r1 to the node 5 and a path r2 to the node 8, and then transmits data (e.g., a consensus proposal) to the node 5 via the path r1, and transmits the same data (e.g., the consensus proposal) to the node 8 via the path r 2. As shown in fig. 5, when the path r1 and the path r2 include the segment of connection of "node 2-node 3" which is coincident, the node 2 needs to repeatedly send the same data to the node 3, so that the efficiency is low because redundant data is sent in the data multicast.

The embodiment of the specification provides a data multicast method, which reduces redundant data and improves data multicast efficiency by aggregating messages on the same path.

Fig. 6 is a flowchart of a data multicasting method in an embodiment of the present disclosure.

As shown in fig. 6, in step S601, the node 2 determines a connection path r1 to the node 5 and a connection path r2 to the node 8.

The data multicasting method in the embodiment of the present specification will be described hereinafter with reference to an example shown in fig. 5. It will be appreciated that the data multicasting in the embodiment of the present specification is not limited to occur between clusters, but may also occur within a cluster, for example, the node 2 in the cluster Cr1 performs data multicasting to other multiple nodes in the cluster Cr1, and the method shown in fig. 6 may be used in this scenario as well.

With reference to the above description, when node 2 needs to multicast the same data (e.g., consensus proposal D1) to node 5 and node 8, node 2 first determines connection path r1 to node 5 and connection path r2 to node 8.

The node 2 may serve as a data source node to multicast the same data to the node 5 and the node 8, or the node 2 may also serve as an intermediate node in the data broadcast process, for example, the node 2 receives a request from the node 1 to send the data D1 to the node 5, and the node 4 receives a request to send the data D1 to the node 8.

As described above, each node in the blockchain may establish a connection with other nodes in the manner shown in fig. 4, so that node 2 may determine connection path r1 and connection path r2 in the connection between the established nodes.

Specifically, the node 2 may determine, as the connection path r1, a path having the shortest access delay between the node 2 and the node 5 in the established connection between the nodes, and determine, as the connection path r2, a path having the shortest access delay between the node 2 and the node 8 in the established connection between the nodes.

In one embodiment, the node 2 may determine a connection path (i.e., a fastest connection path) with the shortest access delay between nodes based on a known algorithm (e.g., dijkstra algorithm) based on the access delay information between nodes in the global routing table obtained above.

In another embodiment, each node of the blockchain has stored therein a local routing table, and node 2 may send a query request to a target node (e.g., node 5) to a plurality of nodes of the neighboring connection of node 2. When the plurality of neighboring nodes includes the target node, the target node returns an access delay between node 2 and the target node in the local routing table to node 2. When the adjacent node is not the target node, the adjacent node acquires the access delay between the adjacent node and the node 2, the fastest path between the adjacent node and the target node and the access delay, and returns the sum of the two access delays and the corresponding connection path to the node 2. The node 2 may determine the fastest connection path between the node 2 and the target node based on the access delay returned by each neighboring node and the corresponding connection path.

In step S603, the node 2 determines whether the path r1 and the next node of the node 2 in the path r2 coincide.

If node 2 determines that path r1 and the next node of node 2 in path r2 do not coincide, node 2 will generate two messages that respectively send data D1 to the next node in path r1 and path r 2.

Referring to fig. 5, assuming that the path r1 is "node 2→node 3→node 5", the path r2 is "node 2→node 3→node 8", and the next node of the path r1 and the node 2 in the path r2 is node 3, that is, the next node of the path r1 and the node 2 in the path r2 coincides, the node 2 performs step S605 in fig. 6.

In step S605, the node 2 generates a message m1, and the target nodes of the message m1 are the node 5 and the node 8.

After determining that the path r1 coincides with the next node in the path r2, the node 2 generates a single message m1, where the message m1 includes a message header and data D1 to be sent, where the message header includes a target node field of the message, where the target node field is an indefinite length field, and is used for a target node set including the message, where "node 5, node 8". That is, the node 2 does not need to generate one message with respect to the nodes 5 and 8, respectively, but rather aggregates the data transmission instructions (or requests) to the nodes 5 and 8 into one message, thereby avoiding transmitting the same data to the next node (i.e., the node 3) a plurality of times. It will be appreciated that if node 2 multicasts a further plurality of nodes and the next node in the fastest connection path to that further plurality of nodes is node 3, the identity of that further plurality of nodes may be included in the message header of message m 1.

In step S607, node 2 transmits a message m1 to node 3.

As shown in fig. 5, node 2 sends message m1 to node 3 over an established connection with node 3.

In step S609, the node 3 determines a connection path r3 to the node 5, a connection path r4 to the node 8.

After receiving message m1, node 3 obtains the set of target nodes from the header of message m1, and determines that the target nodes of the message include node 5 and node 8. Thus, similarly to the node 2, the node 3 determines a connection path r3 between the node 3 and the node 5, and a connection path r4 between the node 3 and the node 8, among the connections that have been established. The connection path r3 may be the fastest connection path between the nodes 3 and 5, and the connection path r4 may be the fastest connection path between the nodes 3 and 8.

In step S611, the node 3 determines whether the path r3 and the next node of the node 3 in the path r4 coincide.

If node 3 determines that the next node of node 3 in path r3 and path r4 is coincident, node 3 may send message m1 directly to that next node.

If the node 3 determines that the next node of the node 3 in the path r3 and the path r4 is not coincident, as shown in fig. 5, assuming that the path r3 is "node 3→node 5" and the path r4 is "node 3→node 8", that is, the next node of the node 3 in the path r3 and the path r4 is not coincident, the node 3 performs step S613 in fig. 6.

In step S613, the node 3 generates a message m2 and a message m3 from the message m1, wherein the target nodes of the message m2 and the message m3 are the node 5 and the node 8, respectively.

In case node 3 determines that the next node of node 3 in path r3 and path r4 does not coincide, it is necessary to split message m1 into two separate messages to send data D1 to different nodes, respectively. Specifically, the node 3 generates a message m2 and a message m3 from the message m1, respectively. Wherein the message m2 includes data D1, and the message header of the message m2 indicates that the target node of the message m2 is node 5. The message m3 includes data D1, and the message header of the message m3 indicates that the destination node of the message m3 is node 8.

In step S615, node 3 sends message m2 to the next node of node 3 in path r 3.

In the example shown in fig. 5, the next node to node 3 in path r3 is node 5, the target node, and thus node 3 may send this message m2 to node 5. It will be appreciated that in the case where the next node (e.g. node 7) to node 3 in path r3 is not the target node, that node 7, after receiving message m2, still determines the connection path between that node 7 and the target node and sends a message according to that connection path. Specifically, when the node 7 receives a message for transmitting the data D1 to another target node, it may determine, similarly to the node 2, whether or not the next node in the connection paths corresponding to the two messages coincides, and if so, may aggregate the two messages into one message and transmit the one message to the next node.

In step S617, node 3 sends a message m3 to the next node of node 3 in path r 4.

This step may refer to the description of step S615 above, and will not be described here again.

The solution in the embodiment of the present specification is described above by taking the multicast from node 2 to node 5 and node 8 as an example. It will be understood that the node 2 is not limited to multicast to two nodes of the node 5 and the node 8, but may multicast to more nodes, the aggregation process in multicast of the node to more nodes may refer to the process described in steps S601-S605, and the splitting process of the node to aggregate the messages of multiple target nodes may refer to the process described in steps S609-S613, which will not be repeated here.

In addition, although it is shown in fig. 6 that the node 2 transmits an aggregate message and the node 3 splits the message, in practice, when the node 2 receives a message for aggregating a plurality of target nodes from other nodes, as in the node 3, it is determined whether or not the next nodes in the paths to the plurality of target nodes overlap, and if the nodes do not overlap, it is necessary to split the message.

Fig. 7 is an architecture diagram of a first node in a blockchain system for performing a method performed by each node as shown in fig. 3 or 6 in an embodiment of the present disclosure, the first node includes:

An obtaining unit 71, configured to obtain a first connection path between the first node and a second node in a blockchain system, where the first connection path is used to send first data to the second node; acquiring a second connection path between the first node and a third node in the blockchain system, wherein the second connection path is used for sending the first data to the third node;

a sending unit 72, configured to send a first message to a fourth node in the blockchain system when it is determined that a node in the first connection path after the first node is the fourth node, and that a node in the second connection path after the first node is the fourth node, where the first message includes the first data and a target node identifier, and the target node identifier includes an identifier of the second node and an identifier of the third node.

In one embodiment, the first node further comprises:

a receiving unit configured to receive the first message from a fifth node in the blockchain system before acquiring the first connection path;

a generating unit, configured to, after acquiring the second connection path, generate, based on the first message, a second message and a third message when it is determined that a node in the first connection path after the first node is a sixth node in the blockchain system and a node in the second connection path after the first node is a seventh node in the blockchain system, where the second message includes identification of the first data and the second node, and the third message includes identification of the first data and the third node;

The sending unit 72 is further configured to send the second message to the sixth node and send the third message to the seventh node.

In an embodiment, the generating unit is further configured to: and generating the first message when the node after the first node in the first connection path is determined to be a fourth node and the node after the first node in the second connection path is determined to be the fourth node.

In one embodiment, the first node further comprises: and the determining unit is used for determining the first connection path in the plurality of connection paths according to access delays of the plurality of connection paths between the first node and the second node.

In one embodiment, the determining unit is specifically configured to: and acquiring global access delay information, wherein the global access delay information comprises access delay among all nodes in a blockchain, and determining the first connection path in the paths according to the global access delay information.

In one embodiment, the first node further comprises: and the storage unit is used for storing the determined first connection path.

In an embodiment, the determining unit is further configured to: and when the access delay change between the first node and the second node through the first connection path is determined, the connection path with the shortest access delay between the first node and the second node is redetermined.

In one embodiment, the acquisition unit is further configured to: acquiring connection relations of a plurality of nodes in a blockchain, wherein the connection relations are established based on grouping information of the plurality of nodes, and the grouping information is determined based on access time delay among the plurality of nodes;

the determining unit is further configured to determine the plurality of connection paths according to the connection relationship.

In one embodiment, the grouping information includes information of a first cluster and a second cluster, the first node belongs to the first cluster, the second node belongs to the second cluster, and the connection relationship includes a first connection between a plurality of nodes in the first cluster, and a second connection between a predetermined number of nodes in the first cluster and the second cluster.

The present description also provides a computer-readable storage medium having stored thereon a computer program which, when executed in a computer, causes the computer to perform the method as shown in fig. 3 or 6.

Embodiments of the present disclosure also provide a blockchain node, including a memory having executable code stored therein and a processor, which when executing the executable code, implements the method as shown in fig. 3 or 6.

According to the data broadcasting scheme in the embodiment of the specification, a plurality of data blocks are obtained according to data, and are distributed to a plurality of nodes in a cluster to be respectively broadcasted, so that the throughput of data broadcasting and the efficiency of data distribution are improved.

In the 90 s of the 20 th century, improvements to one technology could clearly be distinguished as improvements in hardware (e.g., improvements to circuit structures such as diodes, transistors, switches, etc.) or software (improvements to the process flow). However, with the development of technology, many improvements of the current method flows can be regarded as direct improvements of hardware circuit structures. Designers almost always obtain corresponding hardware circuit structures by programming improved method flows into hardware circuits. Therefore, an improvement of a method flow cannot be said to be realized by a hardware entity module. For example, a programmable logic device (Programmable Logic Device, PLD) (e.g., field programmable gate array (Field Programmable Gate Array, FPGA)) is an integrated circuit whose logic function is determined by the programming of the device by a user. A designer programs to "integrate" a digital system onto a PLD without requiring the chip manufacturer to design and fabricate application-specific integrated circuit chips. Moreover, nowadays, instead of manually manufacturing integrated circuit chips, such programming is mostly implemented by using "logic compiler" software, which is similar to the software compiler used in program development and writing, and the original code before the compiling is also written in a specific programming language, which is called hardware description language (Hardware Description Language, HDL), but not just one of the hdds, but a plurality of kinds, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), lava, lola, myHDL, PALASM, RHDL (Ruby Hardware Description Language), etc., VHDL (Very-High-Speed Integrated Circuit Hardware Description Language) and Verilog are currently most commonly used. It will also be apparent to those skilled in the art that a hardware circuit implementing the logic method flow can be readily obtained by merely slightly programming the method flow into an integrated circuit using several of the hardware description languages described above.

The controller may be implemented in any suitable manner, for example, the controller may take the form of, for example, a microprocessor or processor and a computer readable medium storing computer readable program code (e.g., software or firmware) executable by the (micro) processor, logic gates, switches, application specific integrated circuits (Application Specific Integrated Circuit, ASIC), programmable logic controllers, and embedded microcontrollers, examples of which include, but are not limited to, the following microcontrollers: ARC 625D, atmel AT91SAM, microchip PIC18F26K20, and Silicone Labs C8051F320, the memory controller may also be implemented as part of the control logic of the memory. Those skilled in the art will also appreciate that, in addition to implementing the controller in a pure computer readable program code, it is well possible to implement the same functionality by logically programming the method steps such that the controller is in the form of logic gates, switches, application specific integrated circuits, programmable logic controllers, embedded microcontrollers, etc. Such a controller may thus be regarded as a kind of hardware component, and means for performing various functions included therein may also be regarded as structures within the hardware component. Or even means for achieving the various functions may be regarded as either software modules implementing the methods or structures within hardware components.

The system, apparatus, module or unit set forth in the above embodiments may be implemented in particular by a computer chip or entity, or by a product having a certain function. One typical implementation device is a server system. Of course, the present application does not exclude that as future computer technology evolves, the computer implementing the functions of the above-described embodiments may be, for example, a personal computer, a laptop computer, a car-mounted human-computer interaction device, a cellular telephone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.

Although one or more embodiments of the present description provide method operational steps as described in the embodiments or flowcharts, more or fewer operational steps may be included based on conventional or non-inventive means. The order of steps recited in the embodiments is merely one way of performing the order of steps and does not represent a unique order of execution. When implemented in an actual device or end product, the instructions may be executed sequentially or in parallel (e.g., in a parallel processor or multi-threaded processing environment, or even in a distributed data processing environment) as illustrated by the embodiments or by the figures. The terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, it is not excluded that additional identical or equivalent elements may be present in a process, method, article, or apparatus that comprises a described element. For example, if first, second, etc. words are used to indicate a name, but not any particular order.

For convenience of description, the above devices are described as being functionally divided into various modules, respectively. Of course, when one or more of the present description is implemented, the functions of each module may be implemented in the same piece or pieces of software and/or hardware, or a module that implements the same function may be implemented by a plurality of sub-modules or a combination of sub-units, or the like. The above-described apparatus embodiments are merely illustrative, for example, the division of the units is merely a logical function division, and there may be additional divisions when actually implemented, for example, multiple units or components may be combined or integrated into another system, or some features may be omitted or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed with each other may be an indirect coupling or communication connection via some interfaces, devices or units, which may be in electrical, mechanical or other form.

The present invention is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the invention. It will be understood that each flow and/or block of the flowchart illustrations and/or block diagrams, and combinations of flows and/or blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

In one typical configuration, a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.

The memory may include volatile memory in a computer-readable medium, random Access Memory (RAM) and/or nonvolatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of computer-readable media.

Computer readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of storage media for a computer include, but are not limited to, phase change memory (PRAM), static Random Access Memory (SRAM), dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), read Only Memory (ROM), electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, read only compact disc read only memory (CD-ROM), digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage, graphene storage or other magnetic storage devices, or any other non-transmission medium, which can be used to store information that can be accessed by a computing device. Computer-readable media, as defined herein, does not include transitory computer-readable media (transmission media), such as modulated data signals and carrier waves.

One skilled in the relevant art will recognize that one or more embodiments of the present description may be provided as a method, system, or computer program product. Accordingly, one or more embodiments of the present description may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Moreover, one or more embodiments of the present description can take the form of a computer program product on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) having computer-usable program code embodied therein.

One or more embodiments of the present specification may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. One or more embodiments of the present specification may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.

In this specification, each embodiment is described in a progressive manner, and identical and similar parts of each embodiment are all referred to each other, and each embodiment mainly describes differences from other embodiments. In particular, for system embodiments, since they are substantially similar to method embodiments, the description is relatively simple, as relevant to see a section of the description of method embodiments. In the description of the present specification, a description referring to terms "one embodiment," "some embodiments," "examples," "specific examples," or "some examples," etc., means that a particular feature, structure, material, or characteristic described in connection with the embodiment or example is included in at least one embodiment or example of the present specification. In this specification, schematic representations of the above terms are not necessarily directed to the same embodiment or example. Furthermore, the particular features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples. Furthermore, the different embodiments or examples described in this specification and the features of the different embodiments or examples may be combined and combined by those skilled in the art without contradiction.

The foregoing is merely an example of one or more embodiments of the present specification and is not intended to limit the one or more embodiments of the present specification. Various modifications and alterations to one or more embodiments of this description will be apparent to those skilled in the art. Any modification, equivalent replacement, improvement, or the like, which is within the spirit and principles of the present specification, should be included in the scope of the claims.

Claims

1. A method of multicasting data in a blockchain system, performed by a first node in the blockchain system, the blockchain system further including a second node and a third node, the method comprising:

acquiring connection relations of a plurality of nodes in a blockchain, wherein the connection relations are established based on grouping information of the plurality of nodes, and the grouping information is determined based on access time delay among the plurality of nodes;

determining a plurality of connection paths between the first node and the second node according to the connection relation;

determining a first connection path among a plurality of connection paths according to access delays of the plurality of connection paths between the first node and the second node;

acquiring a first connection path between the first node and the second node, wherein the first connection path is used for sending first data to the second node;

Acquiring a second connection path between the first node and the third node, wherein the second connection path is used for sending the first data to the third node;

and when the node after the first node in the first connection path is determined to be a fourth node in the blockchain system and the node after the first node in the second connection path is determined to be the fourth node, sending a first message to the fourth node, wherein the first message comprises the first data and a target node identifier, and the target node identifier comprises an identifier of the second node and an identifier of the third node.

2. The method of claim 1, the method further comprising:

receiving the first message from a fifth node in the blockchain system prior to acquiring the first connection path;

after the second connection path is acquired, when the node after the first node in the first connection path is determined to be a sixth node in the blockchain system and the node after the first node in the second connection path is determined to be a seventh node in the blockchain system, generating a second message and a third message based on the first message, wherein the second message comprises the first data and the identification of the second node, and the third message comprises the first data and the identification of the third node;

And sending the second message to the sixth node and sending the third message to the seventh node.

3. The method of claim 1, further comprising: and generating the first message when the node after the first node in the first connection path is determined to be a fourth node and the node after the first node in the second connection path is determined to be the fourth node.

4. The method of claim 1, the determining the first connection path among the plurality of paths comprising: and acquiring global access delay information, wherein the global access delay information comprises access delay among all nodes in a blockchain, and determining the first connection path in the paths according to the global access delay information.

5. The method of claim 4, further comprising: storing the determined first connection path.

6. The method of claim 4 or 5, further comprising: and when the access delay change between the first node and the second node through the first connection path is determined, the connection path with the shortest access delay between the first node and the second node is redetermined.

7. The method of claim 1, the grouping information comprising information of a first cluster to which the first node belongs and a second cluster to which the second node belongs, the connection relationship comprising a first connection between a plurality of nodes in the first cluster, a second connection between a node in the first cluster and a preset number of nodes in the second cluster.

8. A first node in a blockchain system, comprising:

the acquisition unit is used for: acquiring connection relations of a plurality of nodes in a blockchain, wherein the connection relations are established based on grouping information of the plurality of nodes, and the grouping information is determined based on access time delay among the plurality of nodes;

the determining unit is used for determining a plurality of connection paths between the first node and the second node according to the connection relation;

the determining unit is further configured to determine a first connection path among the multiple connection paths according to access delays of the multiple connection paths between the first node and the second node;

the acquiring unit is further configured to acquire a first connection path between the first node and a second node in the blockchain system, where the first connection path is used to send first data to the second node; acquiring a second connection path between the first node and a third node in the blockchain system, wherein the second connection path is used for sending the first data to the third node;

9. A computer readable storage medium having stored thereon a computer program which, when executed in a computer, causes the computer to perform the method of any of claims 1-7.

10. A blockchain node comprising a memory having executable code stored therein and a processor that, when executing the executable code, implements the method of any of claims 1-7.