Propagating blockchain messages

Abstract

A computer-implemented method of disseminating a blockchain message, where a blockchain network comprises a plurality of blockchain nodes, where each blockchain node is associated with a respective range of numbers, where the method is performed by a first blockchain node and comprises: determining a first number based on a first blockchain message; and if the first number is within the respective range associated with the first blockchain node, providing the first blockchain message to one or more second blockchain nodes.

Description

Technical Field

[0001] The present disclosure relates to a method of propagating blockchain transactions to nodes of a blockchain network. Background Art

[0002] The Internet Protocol (IP) suite currently has two competing technology designs: IPv4 and IPv6, which correspond to versions 4 and 6 of IP, respectively, and are used to assign IP addresses and route packets between senders and receivers across the internet. A key difference between the two is that IPv6 supports a range of IP address types, such as unicast, anycast, and multicast.

[0003] The most widely adopted address type is unicast. Unicast allows packets to be delivered to a single recipient. This is generally sufficient for most client services and applications. However, professional enterprise networks also use two other types of addresses: multicast and anycast. Anycast allows a packet to be delivered to one recipient in a set of recipients with a single operation. Anycast is not available for IPv4 (though it can be implemented with some workarounds), while IPv6 supports anycast natively. Multicast allows packets to be delivered to multiple recipients with a single operation. Multicast is optional in IPv4 (and not widely adopted), while multicast itself is part of the IPv6 specification.

[0004] IP multicast enables a source host to transmit IP packets to one or more destination hosts identified by a single group address. Transmitted packets are replicated by routers at path divergence points within the IP network, so that a single packet destined for a particular group must be sent by the source host, resulting in the most efficient delivery of data to multiple recipients. A link can transmit to one or more multicast groups, and a host can be part of multiple multicast groups. Any host, regardless of membership in a multicast group, can send packets to it, but only group members receive them.

[0005] IP multicast is designed for applications and services in which the same data needs to reach many hosts connected to the network simultaneously. Example applications include video conferencing, enterprise communications, and the distribution of news, software, and stock quotes. A source host can support these applications by learning the IP addresses of destination hosts, establishing connections with them, and transmitting a copy of each packet. In contrast, IP multicast is more efficient because the source host must learn a single group address and transmit a single packet to reach the destination host. IP multicast differs from broadcast in that packets are not sent to the entire subnet but to a select group of hosts, which can be located on different subnets and have automatically registered to join the group. Another difference is that while broadcast only supports one-to-many communication, multicast also supports many-to-many communication. Any IP network concerned with reducing network resource overhead for one-to-many or many-to-many data or multimedia applications with multiple recipients can benefit from multicast.

[0006] While both IPv4- and IPv6-based networks support IP multicast, the limited address space of IPv4 limits the ability of IPv4 multicast to reach the growing number of Internet-connected devices in this context. Furthermore, the common use of Network Address Translation (NAT) tools, which translate public IPv4 addresses into private addresses, makes it difficult or even impossible to support certain applications that use multicast connections. Globally unique IPv6 addresses eliminate the need for NAT devices and simplify multicast communication between hosts. Specifically, the larger address space of IPv6 reduces the possibility that separate multicast streams from different sources will use the same group address and interfere with each other. IPv6 multicast also more clearly defines domain control, that is, the ability to prevent multicast from leaking outside an administrative area, and makes it easier to assign and manage multicast groups.

[0007] like Figure 3 As shown in Figure 1, the basic format of an IPv6 multicast address consists of the following elements:

[0008] Prefix: All IPv6 multicast addresses begin with hexadecimal 0xFF to identify them as multicast addresses.

[0009] Flags: Indicate how the address was assigned or whether it may contain other information. The Internet Assigned Numbers Authority (IANA) has assigned a set of permanently assigned multicast addresses for specific functions. Other flags include: the T flag, for temporarily assigned addresses; the P flag, for addresses derived from a unicast-based IPv6 network prefix; and the R flag, which indicates that a Rendezvous Point (RP) address is embedded.

[0010] Range: Limits the distance that multicast packets can travel. This prevents multicast packets from crossing administrative network boundaries and traversing links and networks to which they do not belong.

[0011] Group ID: Identifies a specific multicast group address (belonging to a host interface).

[0012] Blockchain networks like Bitcoin typically use a distributed network of nodes to produce new blocks containing transactions. These blocks and transactions are rapidly propagated throughout the network using a peer-to-peer (P2P) messaging protocol. This protocol uses a "flooding" method, attempting to forward all new messages to all peers connected to a given node. Summary of the Invention

[0013] The peer-to-peer messaging protocol in Bitcoin and some other blockchains ensures that every new block or transaction reaches every other node in the network in a timely manner, regardless of the network's structure. This is because the protocol ensures that every node attempts to forward new messages to every other node it is connected to. This is inefficient because it generates a lot of redundant network traffic.

[0014] In reality, the topology of a blockchain network is a highly connected graph consisting of a few important nodes. In such networks, sometimes called "small-world" or near-complete graphs, every node is connected to most of all other nodes. In extreme cases, the network can become saturated, with all nodes connected to each other.

[0015] The high connectivity of the blockchain network affects the efficiency of the P2P message transmission protocol because it introduces significant redundancy. Consider a connectivity-saturated snapshot of a blockchain network consisting of n nodes generating blocks and transactions at a total rate of m per second. The nature of the P2P protocol means that each node can send at most (n-1)·m messages per second, which puts an upper bound on the instantaneous total network traffic rate of approximately n·(n-1)·m. This is significantly higher than the theoretical minimum of n·m messages per second required for the network to function properly, corresponding to the case where all new blocks and transactions are initiated by only one node. The ratio of the upper and lower bounds is ~n, an order of magnitude difference even with only a small number of nodes in the network.

[0016] Therefore, this interaction between current P2P messaging protocols and the empirical topology of blockchain networks creates redundancy of up to (n-2)·n·m = (n-1)·(n·m)-(n·m) messages per second. In practice, the lower bound is unlikely to occur (because not all blocks and transactions tend to originate from a single node), but for any given network state, there will almost always be significant redundancy between the upper worst-case network traffic and the theoretical minimum traffic. These redundant messages unnecessarily burden operating blockchain nodes, thereby reducing the overall efficiency of the network.

[0017] Therefore, by modifying the P2P messaging protocol so that new blocks and transactions are not repeated unnecessarily, it will help reduce the total instantaneous traffic on the blockchain network.

[0018] According to one aspect disclosed herein, there is provided a computer-implemented method of propagating a blockchain message, wherein a blockchain network includes a plurality of blockchain nodes, wherein each blockchain node is associated with a respective number range, wherein the method is performed by a first blockchain node and comprises:

[0019] determining a first number based on the first blockchain message; and

[0020] If the first number is within the corresponding range associated with the first blockchain node, the first blockchain message is provided to one or more second blockchain nodes.

[0021] According to another aspect disclosed herein, there is provided a computer-implemented method of obtaining a blockchain message, wherein a blockchain network includes a plurality of blockchain nodes, wherein each blockchain node is associated with a respective number range, wherein the method is performed by a second blockchain node and comprises:

[0022] subscribing to a corresponding network address associated with a corresponding number range; and

[0023] Obtain a first blockchain message sent to the corresponding network address.

[0024] Compared to existing "flooding" approaches that forward all messages to all nodes, embodiments of the present disclosure offer several advantages. For example, they improve the efficiency of blockchain P2P protocols and reduce redundant or duplicate network traffic. Embodiments also allow for a hierarchical structure within the node network based on capabilities, meaning some nodes can choose to shoulder more of the propagation burden than others.

[0025] According to the Bitcoin white paper, a feature of the Bitcoin network is that “new transactions are broadcast to all nodes.” The embodiments of the present disclosure achieve the same goal and are therefore compatible with the original Bitcoin protocol, but minimize redundancy in message propagation.

[0026] Embodiments disclosed herein allow for "sharding" or partitioning of network traffic based on its content or the order in which it arrives. In the case of blockchain transactions, the ordering used to partition the traffic may be related to the order in which the transactions appear in a block and its associated Merkle tree.

[0027] The described embodiments can also be used to create overlaps in partitioned traffic to build in resilience when transmitting data to multiple parties. These overlaps represent a tradeoff between redundancy and resilience in data propagation, so that redundancy is still minimized relative to existing message transmission protocols. In fact, by using these overlaps in partitions, a single large message (such as a block consisting of many transactions, or such as a large transaction consisting of many packets) can be propagated to receivers more efficiently. This distributes the load of propagation traffic across multiple senders, thereby increasing the resilience of the propagation mechanism to failures of a subset of the senders, as the overlaps between different traffic partitions will mitigate connection interruptions or packet losses. In other words, some embodiments create a "virtual" propagation connection between each receiver and multiple senders that is more robust than each individual sender-receiver connection in the network. This is similar to RAID (Redundant Array of Inexpensive Disks) in virtualized data storage systems. BRIEF DESCRIPTION OF THE DRAWINGS

[0028] To facilitate an understanding of the embodiments of the present disclosure and to show how such embodiments may be carried into effect, reference will now be made, by way of example only, to the accompanying drawings, in which:

[0029] Figure 1 is a schematic block diagram of a system for implementing a blockchain;

[0030] Figure 2 Some examples of transactions that may be recorded in a blockchain are schematically shown;

[0031] Figure 3 Schematically shows the basic format of an IPv6 multicast address; and

[0032] Figure 4 An exemplary system for propagating messages is schematically illustrated. DETAILED DESCRIPTION

[0033] 1. Spread blockchain news

[0034] exist Figure 4, an exemplary system for implementing embodiments of the present disclosure is shown in FIG. System 400 includes multiple blockchain nodes 104. Although only four nodes 104 (nodes 104a through 104d) are shown, system 400 may generally include any number (e.g., all) of the blockchain nodes 104 of a blockchain network 106. A first blockchain node (e.g., "blockchain node A" 104a) is configured to determine whether to propagate a blockchain-related message to one or more other blockchain nodes 104 and / or to which other node(s) 104 to propagate the message. The message may be or include one or more blockchain transactions 152. In some examples, the message is a single transaction. The message may be or include a blockchain block 151. The message may include an entire block, i.e., a block header and a corresponding set of transactions, or may include only a block header.

[0035] Propagating the message to the node 104 may include sending the message directly to the node 104. Propagating the message to the node 104 may include sending the message to a network address (e.g., an IPv4 or IPv6 address) associated with the node 104. Propagating the message to the node 104 may include sending the message to a network address (e.g., an IPv6 multicast address) to which the node 104 subscribes. It should be understood that "sending a message to a network address" may be considered to refer to sending a message (e.g., to a router) where the message is addressed to the network address.

[0036] First node 104a obtains a first message. The first message can be received from a different node 104 or from user 103. In some examples, the first message can be generated at least in part by first node 104a. For example, the first message can include a block header generated by first node 104a based on a set of verified transactions provided to first node 104a (e.g., stored in its memory pool).

[0037] In some embodiments, the first node 104a is associated with a first number range. Generally, the first number range can begin and end with any number and can be of any size. The first number range can be selected by the first node 104a, by a different node 104, or by a third party. In some examples, several (e.g., all) nodes 104 of the blockchain network 106 determine the first number range. Each node 104 can be associated with its own number range. Some of these number ranges may or may not overlap.

[0038] The first node 104a determines the first number based on the first message. For example, the first node 104a may apply a hash function to the first message and determine the first number based on the hash result, for example, by generating the first number based on the hash result, or selecting one or more digits of the hash result (e.g., a leading non-zero digit or a final digit). In some examples, the first number is determined based on a portion (e.g., a field) of the first message. That is, the first message may include a number on which the first number may be based. As a specific example, the first message may be a transaction, and the first number may be determined based on a transaction identifier (e.g., one or more of the first digit or the last digit of the transaction identifier).

[0039] If the first number determined based on the first message is within the first number range, the first node 104 propagates the first message to one or more second nodes 104 (e.g., "blockchain node B" 104v and "blockchain node C" 104c). Conversely, if the first number is not within the first number range, the first node 104a does not propagate the first message to the one or more second nodes 104. In other words, the first node 104a forwards the first message only if the first number is within the number range assigned to the first node 104a.

[0040] As described above, propagating the first message may include sending the first message to one or more second nodes 104. Alternatively, Figure 4 As shown, propagating the first message may include sending the first message to a first network address associated with a first number range (e.g., "network address A"). One or more second nodes 104 may listen (e.g., subscribe) to the first network address for blockchain messages. In other words, one or more second nodes 104 may choose to monitor the first network address for messages, or messages sent to the first network address may be forwarded to nodes 104 that subscribe to the first network address.

[0041] Each number range may be associated with a corresponding network address. Each node 104 may determine a number based on the message it receives and propagate the message only if the number is within the range assigned to the node. Here, propagation means sending the message to the appropriate network address. Figure 4 As shown, a given node 104 can subscribe to multiple network addresses. Similarly, multiple nodes 104 can subscribe to the same network address. For example, the network address can be an (IPv6) multicast address.

[0042] In other embodiments, first node 104a is associated with a first set of blockchain nodes 104 (i.e., one or more nodes 104 other than first node 104a). Generally, the first set of nodes 104 may include any number of nodes 104, but not every node 104. The first set of nodes (the specific nodes 104 and / or the number of nodes 104) may be selected by first node 104a, by different nodes 104, or by a third party. In some examples, several (e.g., all) nodes 104 of blockchain network 106 determine the first set of nodes 104. Each node 104 may be associated with its own set of other nodes 104. Some of these sets may or may not overlap.

[0043] It should be noted that, as used throughout this disclosure, the term "set" may be considered to refer to one or more.

[0044] The first node 104a is configured to propagate the first message to each node 104 in the first set of nodes 104. The first node 104a does not propagate the first message to nodes 104 that are not part of the first set of nodes 104. That is, the first node 104a only forwards the first message to one or more second nodes 104 assigned to the first node 104a.

[0045] As described above, propagating the first message may include sending the first message to one or more second nodes 104. Alternatively, Figure 4 As shown, propagating the first message may include sending the first message to a first network address (e.g., "network address B") associated with a first set of nodes 104. One or more second nodes 104 may listen (e.g., subscribe) to the first network address for blockchain messages. In other words, one or more second nodes 104 may choose to monitor the first network address for messages, or messages sent to the first network address may be forwarded to nodes 104 that subscribe to the first network address.

[0046] Each set of nodes 104 may be associated with a corresponding network address. Each node 104 may propagate a message only to the set of nodes 104 assigned to that node 104. Here, propagation means sending the message to the appropriate network address. Figure 4 As shown, a given node 104 can subscribe to multiple network addresses. Similarly, multiple nodes 104 can subscribe to the same network address. For example, the network address can be an (IPv6) multicast address.

[0047] In other embodiments, the first node 104a is associated with a first number range and a first set of nodes 104. Similar to the above embodiment, the first node 104a can determine the first number based on the first blockchain message and propagate the first message to the first set of nodes 104 only if the first number is within the first number range.

[0048] In some embodiments, the first node 104a is associated with multiple number ranges and multiple sets of nodes. For example, the first node 104a can be associated with a first number range that is linked to (i.e., associated with) a first set of nodes 104, a second number range that is linked to a second set of nodes 104, a third set of nodes 104 that is linked to a third set of nodes 104, and so on. In general, the first node 104a can be associated with any number of corresponding number ranges and corresponding sets of nodes 104.

[0049] As in the above embodiment, each corresponding number range can start and end with any number and can have any size. One or more corresponding number ranges in the corresponding number ranges may or may not overlap. One or more corresponding number ranges in the corresponding number ranges may be selected by the first node 104a, or by a different node 104, or by a third party. In some examples, several (e.g., all) nodes 104 of the blockchain network 106 may determine one or more corresponding number ranges in the corresponding number ranges.

[0050] Similarly, as in the above embodiment, each corresponding set of nodes 104 can include any number of nodes 104, but does not include every node 104. One or more of the corresponding sets can include the same number of nodes 104, or a different number of nodes 104. One or more of the corresponding sets of nodes (specific nodes 104 and / or the number of nodes 104) can be selected by the first node 104a, a different node 104, or a third party. In some examples, several (e.g., all) nodes 104 of the blockchain network 106 determine one or more of the corresponding sets of nodes 104.

[0051] For each message acquired (e.g., received or generated) by the first node 104a, the first node 104a determines the corresponding number for the message. The first node 104a may determine the corresponding number using any of the techniques described above (e.g., by hashing part or all of the message). If the corresponding number is within a corresponding number range, the first node 104a may propagate the corresponding message to the corresponding set of nodes 104 linked to the corresponding number range.

[0052] In some examples, if the corresponding number determined for each message is within a corresponding number range, first node 104a may propagate the message to the corresponding set of nodes linked to the corresponding number range. In other examples, first node 104a may propagate only some of the messages to the corresponding set of nodes. For example, first node 104a may propagate only 50% of the messages with determined numbers within a particular number range to the associated set of nodes 104. In some examples, each number range is associated with a corresponding percentage, which indicates the proportion of messages sent to the corresponding set of nodes 104. For example, if a number range is associated with 25%, only 25% of the messages with determined numbers within that number range are sent to the corresponding set of nodes 104. One or more corresponding number ranges may be associated with the same percentage or different percentages. In some examples, each corresponding number range is associated with a different percentage.

[0053] As in the above embodiment, propagating the corresponding message may include sending the corresponding message to one or more second nodes 104 belonging to the corresponding set. Figure 4 As shown, propagating the corresponding message may include sending the corresponding message to the corresponding network address associated with the corresponding set of nodes 104. Figure 4 As shown, a message may be sent to a network address A to which nodes 104b and 104c subscribe (i.e., listen for messages), while a different message may be sent to a network address B to which nodes 104c and 104d subscribe. Each second node 104 may listen (e.g., subscribe) to one or more network addresses for blockchain messages.

[0054] 1.1 Specific Examples

[0055] As described above, the described embodiments reduce the total instantaneous traffic in the blockchain network 106 by modifying the P2P message transmission protocol so that new block and transaction messages are not unnecessarily repeated. Specific examples of the described embodiments are now discussed. The features that unify these examples are as follows:

[0056] • Every data message (i.e., block, transaction) is sent from a source node 104 to a multicast address.

[0057] A node 104 will selectively send data messages based on policy rules. The node's policy rules determine whether a node 104 sends a given message, or to which nodes 104 a given message is sent, based on:

[0058] o(i) the content of the data message; or

[0059] o(ii) each group of nodes in the current network; or

[0060] o(iii)both of the above.

[0061] It should be noted that there may be some exception messages, such as when the node 104 discovers a new block itself, which may be exempted from following this new logic.

[0062] 1.1.1 Example Strategy 1—Content-Based Message Dissemination

[0063] In this example, the P2P protocol is modified so that node 104 is assigned a range of numbers within which it is responsible for forwarding messages. Since the number can be derived from each data message received by node 104 (e.g., by hashing the message), the P2P protocol automatically chooses to only propagate messages whose number values ​​are within the node's assigned range.

[0064] The logic of selectively propagating data messages in the new P2P protocol is as follows:

[0065] 0. Assign a number range to node A

[0066] 1. A receives a data message m from another network node or user.

[0067] 2.A looks up or calculates the hash h(m) of the message.

[0068] 3. A resolves h(m) into a number in the range 0≤h(m)≤k, where k is determined according to the hash function h.

[0069] 4. If h(m)∈[v L ,v U ], then m is sent to the multicast IP address IP R , otherwise no action is performed.

[0070] Notes on this protocol variant:

[0071] Range R can be assigned to a node 104 automatically (e.g., randomly) when the node joins the network. Alternatively, it can be assigned by a third-party service provider that monitors which nodes are responsible for which ranges at a given time. Alternatively, nodes 104 can continuously and dynamically communicate with each other to jointly assign ranges to ensure that the entire range is always covered.

[0072] There may be overlap in the ranges covered by different nodes 104. Minimizing overlap will minimize redundancy in message propagation.

[0073] -with the IP range RThe corresponding multicast IP address can be subscribed to by any network node 104. If there is no overlap in the ranges, then preferably all nodes 104 subscribe to the address to ensure that they will all receive all data messages. If there is an overlap, then the node 104 that is the source of a given range will not need to subscribe, thereby minimizing redundant traffic.

[0074] - In this P2P protocol, preferably, node 104 subscribes to each scope-specific multicast address, for which node 104 is not the source.

[0075] 1.1.2 Protocol Variant 2—Group-Based Propagation

[0076] In this example, the P2P protocol is modified so that each node 104 is assigned a set of nodes to which it must forward messages.

[0077] The logic of selectively propagating data messages in the new P2P protocol is as follows:

[0078] 0. Assign a set of receiver node ranges to node A The group of receiver nodes shares the corresponding multicast address

[0079] 1. A receives a data message m from another network node or user.

[0080] 2.A forwards m to the multicast address

[0081] Notes on this protocol variant:

[0082] - Selectivity in this variant affects the choice of which nodes 104 to forward messages to, rather than which messages to propagate.

[0083] - Similar to protocol variant 1, the group assigned to node 104 The allocation may be (i) self-allocated, (ii) allocated by a third party, or (iii) co-allocated in coordination with the rest of the node network 106 .

[0084] If all nodes 104 are assigned a set of at least one node 104 to which to send messages, there is still some redundancy in the traffic, but it is significantly reduced compared to the worst case.

[0085] 1.1.3 Protocol Variant 3—Combination

[0086] An alternative is to use a combination of Variant 1 and Variant 2 to modify the P2P message transmission protocol so that messages can be (i) selectively selected for propagation; and (ii) propagated only to a select set of nodes 104, assuming they are selected.

[0087] For example, a modified version of the P2P protocol can be established for a given node A that implements the following set of rules:

[0088] 1.A will range [v L ,v U All messages within ] are propagated to the group

[0089] 2.A will range [v′ L ,v′ U ] 50% of the messages spread to the group

[0090] 3.A will range [v″ L ,v″ U ] 25% of the messages spread to the group

[0091] 4.……

[0092] This type of logic can improve network consistency and resilience to failures at the expense of increased redundancy, but crucially, its level of redundancy remains far below the level tolerated by current P2P protocols. This scheme can also fine-tune the level of redundancy by selecting the size of each range and the size of each group as parameters, and by having each node 104 select values ​​for these parameters that reflect the diversity of node capabilities on the network.

[0093] 1.1.4 Exceptions

[0094] There may be exceptions to the P2P logic variants proposed above, such as a new block generated by a node 104, which should be widely broadcasted by the node 104 to the entire network as quickly as possible.

[0095] To address this situation, a message-specific multicast address can be created for other nodes 104 to subscribe to. i Can register with A i The specific address corresponding to the newly created block All nodes A on the network j Will subscribe And A i Will specifically Send a new block message. This ensures that the new block is not disadvantaged by the proposed P2P protocol changes and does not increase the risk of becoming orphaned.

[0096] 2. Exemplary System Overview

[0097] A blockchain is a distributed data structure in which a copy of the blockchain is maintained at each of multiple nodes in a distributed peer-to-peer (P2P) network (hereinafter referred to as a "blockchain network") and is widely disclosed. A blockchain consists of a series of data blocks, each of which includes one or more transactions. With the exception of so-called "coinbase transactions," each transaction points back to a previous transaction in a sequence that can span one or more blocks, back to one or more coinbase transactions. Coinbase transactions are discussed further below. Transactions submitted to the blockchain network are included in new blocks. The process of creating a new block, often referred to as "mining," involves each of multiple nodes competing to perform "proof of work," i.e., solving a cryptographic puzzle based on a defined, ordered, and verified set of pending transactions waiting to be included in the new block of the blockchain. It should be noted that the blockchain can be pruned at some nodes, and that blocks can be published by publishing only the block header.

[0098] Transactions in a blockchain can be used for one or more of the following purposes: transferring digital assets (i.e., a certain number of digital tokens); sorting a set of entries in a virtualized ledger or registry; receiving and processing timestamped entries; and / or chronologically sorting index pointers. Blockchains can also be used to implement additional layered functionality. For example, blockchain protocols may allow for the storage of additional user data or data indexes within transactions. There is no pre-specified limit on the maximum amount of data that can be stored in a single transaction, allowing for the incorporation of increasingly complex data. This can be used, for example, to store electronic documents, audio, or video data within a blockchain.

[0099] In the "output-based" model (sometimes referred to as the UTXO-based model), the data structure of a given transaction includes one or more inputs and one or more outputs. Any spendable output includes an element specifying an amount of a digital asset, which can be derived from the ongoing sequence of transactions. Spendable outputs are sometimes referred to as UTXOs ("unspent transaction outputs"). Outputs may also include a locking script, which specifies the conditions for future redemption of the output. A locking script is a predicate that defines the conditions necessary to verify and transfer a digital token or asset. Each input in a transaction (except for the coinbase transaction) includes a pointer (i.e., a reference) to that output in a previous transaction and may also include an unlocking script that unlocks the locking script pointing to the output. Consider a pair of transactions, referred to as a first transaction and a second transaction (or "target" transaction). The first transaction includes at least one output specifying an amount of a digital asset and a locking script defining one or more conditions for unlocking that output. The second (target) transaction includes at least one input, which includes a pointer to an output of the first transaction, and an unlocking script that unlocks the output of the first transaction.

[0100] In this model, when the second (target) transaction is sent to the blockchain network for propagation and recording in the blockchain, one of the validity conditions applied at each node will be that the unlocking script satisfies all of the one or more conditions defined in the locking script of the first transaction. Another condition will be that the output of the first transaction has not been redeemed by another earlier valid transaction. Any node that finds the target transaction invalid according to any of these conditions will not propagate the transaction (as a valid transaction, but may register it as an invalid transaction) and will not include it in the new block to be recorded in the blockchain.

[0101] Another transaction model is the account-based model. In this case, each transaction defines the amount transferred not by reference to the UTXO of previous transactions in the past transaction sequence, but rather by reference to absolute account balances. The current state of all accounts is stored independently in the blockchain by nodes and is continuously updated.

[0102] Figure 1 An exemplary system 100 for implementing a blockchain 150 is shown. System 100 may include a packet-switched network 101, typically a wide-area network such as the Internet. Packet-switched network 101 includes a plurality of blockchain nodes 104 (often referred to as "miners"), which may be arranged to form a peer-to-peer (P2P) network 106 within packet-switched network 101. Although not shown, blockchain nodes 104 may be arranged as a near-complete graph. Thus, each blockchain node 104 is highly connected to other blockchain nodes 104.

[0103] Each blockchain node 104 includes a peer computer device, with different nodes 104 belonging to different peers. Each blockchain node 104 includes a processing device, which includes one or more processors, such as one or more central processing units (CPUs), accelerator processors, special-purpose processors, and / or field-programmable gate arrays (FPGAs), as well as other devices, such as application-specific integrated circuits (ASICs). Each node also includes memory, i.e., computer-readable memory in the form of non-transitory computer-readable media. The memory may include one or more memory units, which use one or more storage media, such as magnetic media such as hard drives, electronic media such as solid-state drives (SSDs), flash memory, or electrically erasable programmable read-only memory (EEPROM), and / or optical media such as optical disk drives.

[0104] A blockchain 150 comprises a series of data blocks 151, with a respective copy of the blockchain 150 maintained at each of the plurality of blockchain nodes 104 in a distributed or blockchain network 106. As discussed above, maintaining a copy of the blockchain 150 does not necessarily mean storing the entire blockchain 150. Rather, the blockchain 150 can be pruned as long as each blockchain node 150 stores the block header (discussed below) for each block 151. Each block 151 in the blockchain includes one or more transactions 152, where a transaction in this context refers to a data structure. The nature of the data structure will depend on the type of transaction protocol used as part of the transaction model or scheme. A given blockchain utilizes a specific transaction protocol throughout.

[0105] Blockchain nodes 104 can be configured to forward transactions 152 to other blockchain nodes 104, thereby propagating transactions 152 throughout the network 106. Blockchain nodes 104 can be configured to create blocks 151 and store corresponding copies of the same blockchain 150 in their respective memories. Blockchain nodes 104 can also maintain an ordered set (or "pool") 154 of transactions 152 awaiting incorporation into blocks 151. Ordered pool 154 is often referred to as a "memory pool." As used herein, this term is not intended to be limited to any particular blockchain, protocol, or model. The term refers to a set of ordered transactions that a node 104 has accepted as valid and for which it is mandatory that the node 104 not accept any other transaction that attempts to spend the same output.

[0106] In a given current transaction 152j, an input (or each input) includes a pointer that references an output from a previous transaction 152i in the transaction sequence, specifying that the output is to be redeemed or "spent" in the current transaction 152j. Spending or redeeming does not necessarily imply transferring a financial asset, although this is certainly a common application. More generally, spending can be described as consuming an output or allocating it to one or more outputs in another subsequent transaction. In general, the previous transaction can be any transaction in the ordered set 154 or any block 151. While the existence and verification of the previous transaction 152i are required for the current transaction to be valid, the previous transaction 152i does not need to exist at the time the current transaction 152j is created or even sent to the network 106. Therefore, in this context, "previous" refers to the predecessor in the logical sequence linked by the pointer, not necessarily the creation or sending time in the temporal sequence, and thus does not necessarily preclude the creation or sending of transactions 152i, 152j out of order (see the discussion of orphan transactions below). The previous transaction 152i can also be referred to as a predecessor or predecessor transaction.

[0107] Due to the resources involved in transaction verification and publication, typically at least each blockchain node 104 takes the form of a server comprising one or more physical server units, or even an entire data center. However, in principle, any given blockchain node 104 may take the form of a user terminal or a group of user terminals networked together.

[0108] The memory of each blockchain node 104 stores software configured to run on the processing device of the blockchain node 104 to perform its corresponding role and process transactions 152 according to the blockchain node protocol. It should be understood that any action attributed to the blockchain node 104 herein can be performed by software running on the processing device of the corresponding computer device. The node software can be implemented in one or more applications at the application layer or at a lower layer such as an operating system layer or a protocol layer, or any combination of these layers.

[0109] Any given blockchain node can be configured to perform one or more of the following operations: verifying transactions, storing transactions, propagating transactions to other peers, and performing consensus (e.g., proof-of-work) / mining operations. In some examples, each type of operation is performed by a different node 104. That is, a node can be specialized for a particular operation. For example, a node 104 can focus on transaction verification and propagation, or it can focus on block mining. In some examples, a blockchain node 104 can perform more than one of these operations in parallel. Any reference to a blockchain node 104 can refer to an entity configured to perform at least one of these operations.

[0110] Each of the multiple parties 103 acting as consuming users also has its computer device 102 connected to the network 101. These users can interact with the blockchain network 106 but do not participate in verifying transactions or constructing blocks. Some of these users or agents 103 can act as senders and receivers in transactions. Other users can interact with the blockchain 150 without necessarily acting as senders or receivers. For example, some parties may act as storage entities that store a copy of the blockchain 150 (e.g., having obtained a copy of the blockchain from the blockchain node 104).

[0111] Some or all of the parties 103 may be connected as part of a different network, such as a network overlaid on blockchain network 106. Users of the blockchain network (often referred to as "clients") may be referred to as being part of the system comprising blockchain network 106; however, these users are not blockchain nodes 104 because they do not perform the roles required of a blockchain node. Instead, each party 103 may interact with blockchain network 106, thereby utilizing blockchain 150 by connecting to (i.e., communicating with) blockchain node 106. For illustrative purposes, two parties 103 and their corresponding devices 102 are shown: a first party 103a and its corresponding computer device 102a, and a second party 103b and its corresponding computer device 102b. It should be understood that more such parties 103 and their corresponding computer devices 102 may exist and participate in system 100, but for convenience, they are not illustrated. Each party 103 may be an individual or an organization. For illustrative purposes only, the first party 103a is referred to herein as Alice and the second party 103b is referred to as Bob, but it should be understood that this is not limited to Alice or Bob, and any references to Alice or Bob herein may be replaced with "first party" and "second party", respectively.

[0112] The computer device 102 of each party 103 includes a corresponding processing device, which includes one or more processors, such as one or more CPUs, graphics processing units (GPUs), other accelerator processors, application-specific processors, and / or FPGAs. The computer device 102 of each party 103 also includes memory, i.e., computer-readable memory in the form of non-transitory computer-readable media. The memory may include one or more memory units, which use one or more storage media, such as magnetic media such as a hard drive, electronic media such as an SSD, flash memory, or EEPROM, and / or optical media such as an optical drive. The memory on the computer device 102 of each party 103 stores software, which includes a corresponding instance of at least one client application 105 configured to run on the processing device. It should be understood that any action attributed to a given party 103 herein may be performed by software running on the processing device of the corresponding computer device 102. The computer device 102 of each party 103 includes at least one user terminal, such as a desktop or laptop computer, a tablet computer, a smartphone, or a wearable device such as a smartwatch. The computer device 102 of a given party 103 may also include one or more other network resources, such as cloud computing resources accessed through a user terminal.

[0113] The client application 105 may be initially provided to the computer device 102 of any given party 103 via, for example, a suitable computer-readable storage medium downloaded from a server, or via a removable storage device such as a removable SSD, flash memory key, removable EEPROM, removable disk drive, floppy disk or tape, an optical disk such as a CD or DVD ROM, or a removable optical drive.

[0114] Client application 105 includes at least a "wallet" function. This has two primary functions. One is to enable counterparty 103 to create, authorize (e.g., sign), and send transactions 152 to one or more Bitcoin nodes 104, which are then propagated across the network of blockchain nodes 104 and included in blockchain 150. The other function is to report to the counterparty the amount of digital assets they currently hold. In an output-based system, this second function involves collating the amounts defined in the outputs of various transactions 152 belonging to the relevant parties, which are dispersed across blockchain 150.

[0115] Note: While various client functions may be described as being integrated into a given client application 105, this is not necessarily limiting. Rather, any client function described herein may be implemented in a suite consisting of two or more distinct applications, for example, interfacing via an API or one application as a plug-in to another. More generally, the client functions may be implemented at the application layer or at a lower layer such as an operating system, or at any combination of these layers. The following description will be based on the client application 105, but it should be understood that this is not limiting.

[0116] An instance of a client application or software 105 on each computer device 102 is operatively coupled to at least one of the blockchain nodes 104 of the network 106. This enables the wallet functionality of the client 105 to send transactions 152 to the network 106. The client 105 can also contact the blockchain node 104 to query the blockchain 150 for any transactions to which the corresponding party 103 is a recipient (or indeed, to examine other parties' transactions in the blockchain 150, since, in embodiments, the blockchain 150 is a public utility that provides trust in transactions, in part, through its public visibility). The wallet functionality on each computer device 102 is configured to formulate and send transactions 152 according to a transaction protocol. As described above, each blockchain node 104 runs software configured to verify transactions 152 according to the blockchain node protocol and forward transactions 152 for propagation within the blockchain network 106. The transaction protocol and the node protocol correspond to each other, and a given transaction protocol and a given node protocol together implement a given transaction model. The same transaction protocol is used for all transactions 152 in the blockchain 150. All nodes 104 in the network 106 use the same node protocol.

[0117] As part of the account-based transaction model, another type of transaction protocol operated by some blockchain networks can be called an "account-based" protocol. In the account-based scenario, each transaction defines the amount transferred not by reference to the UTXO of a previous transaction in the past sequence of transactions, but rather by reference to absolute account balances. The current state of all accounts is stored independently in the blockchain by the network's nodes and continuously updated. In this type of system, transactions are ordered using an account's running transaction record (also known as a "position" or "nonce"). This value is signed by the sender as part of their cryptographic signature and hashed as part of the transaction reference calculation. In addition, optional data fields can be signed in transactions. For example, if the data field contains the ID of a previous transaction, the data field can point to the previous transaction.

[0118] Some account-based transaction models share some similarities with the output-based transaction model described herein. For example, as described above, the data field of an account-based transaction can point to a previous transaction, which is equivalent to the input of an output-based transaction referencing the output of a previous transaction. Therefore, both models support linking between transactions. For another example, an account-based transaction contains a "recipient" field (which specifies the receiving address of an account) and a "value" field (which can specify an amount of a digital asset). The recipient and value fields together are equivalent to the output of an output-based transaction, which can be used to allocate an amount of a digital asset to a blockchain address. Similarly, an account-based transaction has a "signature" field, which includes the transaction's signature. This signature is generated using the sender's private key and confirms that the sender has authorized the transaction. This is equivalent to the input / unlocking script of an output-based transaction, which typically includes the transaction's signature. When both types of transactions are submitted to their respective blockchain networks, the signature is checked to determine whether the transaction is valid and can be recorded on the blockchain. On an account-based blockchain, a "smart contract" refers to a transaction containing a script that is configured to perform one or more actions (e.g., sending or "releasing" a digital asset to a recipient address) in response to one or more inputs (provided by the transaction) that satisfy one or more conditions defined by the smart contract's script. A smart contract exists as a transaction on the blockchain and can be called (or triggered) by subsequent transactions. Therefore, in some examples, a smart contract can be considered equivalent to a locking script for an output-based transaction (which can be triggered by a subsequent transaction) that checks whether the input of the subsequent transaction satisfies one or more conditions defined by the locking script.

[0119] 3. UTXO-based model

[0120] Figure 2 An exemplary transaction protocol is shown. This is an example of a UTXO-based protocol. A transaction 152 ("Tx") is the fundamental data structure of a blockchain 150 (each block 151 includes one or more transactions 152). The following description will refer to an output-based or "UTXO-based" protocol. However, this is not intended to limit all possible implementations. It should be noted that while the exemplary UTXO-based protocol is described with reference to Bitcoin, it can also be implemented on other exemplary blockchain networks.

[0121] In the UTXO-based model, each transaction ("Tx") 152 includes a data structure that includes one or more inputs 202 and one or more outputs 203. Each output 203 may include an unspent transaction output (UTXO), which can be used as a source of input 202 for another new transaction (if the UTXO has not yet been redeemed). The UTXO includes a value that specifies the amount of a digital asset. This represents a set of tokens on the distributed ledger. The UTXO may also include the transaction ID of the transaction from which it originated, as well as other information. The transaction data structure may also include a header 201, which may include an indicator of the size of the input field 202 and the output field 203. The header 201 may also include an ID for the transaction. In an embodiment, the transaction ID is a hash of the transaction data (excluding the transaction ID itself) and is stored in the header 201 of the original transaction 152 submitted to the node 104.

[0122] Let's say Alice 103a wishes to create a transaction 152j that transfers the relevant amount of digital assets to Bob 103b. Figure 2 In , Alice's new transaction 152j is labeled "Tx1". This new transaction takes the amount of digital assets locked to Alice in output 203 of the previous transaction 152i in the sequence and transfers at least part of such amount to Bob. Figure 2 In the example, the previous transaction 152i is labeled "Tx0". Tx0 and Tx1 are just arbitrary labels that do not necessarily mean that Tx0 refers to the first transaction in the blockchain 151 and Tx1 refers to a subsequent transaction in the pool 154. Tx1 can point to any previous (i.e., predecessor) transaction that still has unspent outputs 203 locked to Alice.

[0123] As used herein in the context of transaction sequences, the terms "previous" and "successor" refer to the order of transactions in the sequence defined by the transaction pointers specified within them (which transaction points to which other transaction, and so on). They could equally well be replaced with "predecessor" and "successor," "ancestor" and "descendant," or "parent" and "child," among others. This does not necessarily refer to the order in which they were created, sent to the network 106, or arrived at any given blockchain node 104. However, subsequent transactions (descendant transactions or "children") that point to a previous transaction (ancestor transaction or "parent") will not be valid unless the parent transaction is valid. Children that arrive at a blockchain node 104 before their parents are considered orphaned. Depending on the node's protocol and / or behavior, they may be discarded or buffered for a period of time, waiting for their parents.

[0124] One of the one or more outputs 203 of the previous transaction Tx0 includes a specific UTXO, labeled UTXO0. Each UTXO includes a value specifying the amount of digital assets represented by the UTXO and a locking script that defines the conditions that the unlocking script in the input 202 of the subsequent transaction must meet in order for the subsequent transaction to be valid and thus successfully redeem the UTXO.

[0125] The locking script (also known as scriptPubKey) is a piece of code written in a domain-specific language recognized by the node protocol. A specific example of this language is called a "Script" (with a capital S), which can be used by the blockchain network. The locking script specifies the information required to spend transaction output 203, such as the requirement for Alice's signature. The locking script appears in the transaction output. The unlocking script (also known as scriptSig) is a piece of code written in a domain-specific language that provides the information required to meet the locking script criteria. For example, it can contain Bob's signature. The unlocking script appears in the transaction input 202.

[0126] Thus in the example shown, UTXO0 in output 203 of Tx0 includes a locking script [Checksig P A ], the locking script requires Alice’s signature Sig P A , in order to redeem UTXO0 (strictly speaking, to make subsequent transactions that attempt to redeem UTXO0 valid). [Checksig P A ] contains Alice's public key P from her public-private key pair A The input 202 of Tx1 includes a pointer to Tx1 (e.g., through its transaction ID (TxID0), which in this embodiment is the hash value of the entire transaction Tx0). The input 202 of Tx1 includes an index that identifies UTXO0 in Tx0 to identify it among any other possible outputs of Tx0. The input 202 of Tx1 further includes an unlocking script <Sig P A The unlocking script includes Alice's cryptographic signature, which she creates by applying the private key from her key pair to a predetermined portion of data (sometimes called a "message" in cryptography). The data (or "message") that Alice needs to sign to provide a valid signature can be defined by the locking script, the node protocol, or a combination thereof.

[0127] When a new transaction Tx1 arrives at a blockchain node 104, the node applies the node protocol, which involves running the locking script and the unlocking script together to check whether the unlocking script satisfies the conditions defined in the locking script (where the conditions may include one or more criteria).

[0128] It should be noted that script code is typically represented schematically (i.e., using a non-precise language). For example, an opcode (opcode) may be used to represent a specific function. "OP_..." refers to a specific opcode in the scripting language. For example, OP_RETURN is a scripting language opcode that, when preceded by OP_FALSE at the beginning of a locking script, creates an unspendable output of the transaction. This output can store data within the transaction, thereby immutably recording the data on blockchain 150. For example, the data may include a file to be stored on the blockchain.

[0129] Typically, transaction inputs contain a digital signature corresponding to the public key PA. In one embodiment, this is based on ECDSA using the elliptic curve secp256k1. The digital signature signs a specific piece of data. In one embodiment, for a given transaction, the signature will sign some transaction inputs and some or all transaction outputs. The specific portion of the output that is signed depends on the SIGHASH flag. The SIGHASH flag is typically a 4-byte code included at the end of the signature that selects the output to be signed (and is therefore fixed at the time of signing).

[0130] The locking script is sometimes referred to as "scriptPubKey," meaning it typically includes the public key of the party to whom the corresponding transaction is locked. The unlocking script is sometimes referred to as "scriptSig," meaning it typically provides the corresponding signature. However, more generally, in all applications of blockchain 150, the conditions for UTXO redemption do not necessarily require signature verification. More generally, the scripting language can be used to define any one or more conditions. Therefore, the more general terms "locking script" and "unlocking script" may be preferred.

[0131] 4. Further comments

[0132] Other variations or uses of the disclosed technology may become apparent to those skilled in the art once given the disclosure herein.The scope of the present disclosure is not limited by the described embodiments but only by the claims that follow.

[0133] For example, some of the embodiments above have been described with respect to the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin node 104. However, it should be understood that the Bitcoin blockchain is a specific example of a blockchain 150, and the above description can generally be applied to any blockchain. That is, the present invention is in no way limited to the Bitcoin blockchain. More generally, any references above to the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin node 104 can be replaced with references to the blockchain network 106, the blockchain 150, and the blockchain node 104, respectively. Blockchains, blockchain networks, and / or blockchain nodes may share some or all of the characteristics described above for the Bitcoin blockchain 150, the Bitcoin network 106, and the Bitcoin node 104.

[0134] In a preferred embodiment of the present invention, blockchain network 106 is a Bitcoin network, and Bitcoin nodes 104 perform at least all of the aforementioned functions of creating, publishing, propagating, and storing blocks 151 of blockchain 150. It is not excluded that there may be other network entities (or network elements) that perform only one or some, but not all, of these functions. In other words, a network entity may perform the functions of propagating and / or storing blocks without creating and publishing blocks (keeping in mind that these entities are not considered nodes of the preferred Bitcoin network 106).

[0135] In other embodiments of the present invention, blockchain network 106 may not be the Bitcoin network. In these embodiments, it is not excluded that a node may perform at least one or some, but not all, of the functions of creating, publishing, propagating, and storing blocks 151 of blockchain 150. For example, on these other blockchain networks, "node" may be used to refer to a network entity that is configured to create and publish blocks 151 but does not store and / or propagate these blocks 151 to other nodes.

[0136] Even more generally, any reference above to the term "Bitcoin node" 104 may be replaced with the term "network entity" or "network element," where such entity / element is configured to perform some or all of the roles of creating, publishing, propagating, and storing blocks. The functionality of such a network entity / element may be implemented in hardware in the same manner as described above with reference to blockchain node 104.

[0137] Some embodiments have been described in terms of a blockchain network that implements a proof-of-work consensus mechanism to secure the underlying blockchain. However, proof-of-work is only one type of consensus mechanism, and in general embodiments, any suitable consensus mechanism may be used, such as proof-of-stake, delegated proof-of-stake, proof-of-capacity, or proof-of-elapsed time. As a specific example, proof-of-stake uses a randomization process to determine which blockchain node 104 has the opportunity to produce the next block 151. The selected node is often referred to as a validator. Blockchain nodes can lock their tokens for a period of time in order to have the opportunity to become a validator. Generally, the node that locks the largest stake for the longest period of time is most likely to become the next validator.

[0138] It should be understood that the above embodiments are described by way of example only. More generally speaking, a method, apparatus or program may be provided according to any one or more of the following statements.

[0139] Statement 1. A computer-implemented method of propagating a blockchain message, wherein a blockchain network comprises a plurality of blockchain nodes, wherein each blockchain node is associated with a respective number range, wherein the method is performed by a first blockchain node and comprises:

[0140] determining a first number based on the first blockchain message; and

[0141] If the first number is within the corresponding range associated with the first blockchain node, the first blockchain message is provided to one or more second blockchain nodes.

[0142] The method includes not providing the first blockchain message to one or more second blockchain nodes if the first number is not within the corresponding range associated with the first blockchain node.

[0143] Statement 2. The method of statement 1, wherein determining the first number comprises: hashing at least a portion of the first blockchain message.

[0144] Statement 3. The method of statement 1, wherein determining the first number comprises extracting the first number from a field of the first blockchain message, such as a transaction identifier.

[0145] Statement 4. A method according to any of the preceding statements, wherein each corresponding range is associated with a corresponding network address, and wherein providing the first blockchain message to the one or more second blockchain nodes includes: sending the first blockchain message to the corresponding network address associated with the corresponding range.

[0146] Statement 5. A computer-implemented method of obtaining a blockchain message, wherein a blockchain network comprises a plurality of blockchain nodes, wherein each blockchain node is associated with a respective number range, wherein the method is performed by a second blockchain node and comprises:

[0147] subscribing to a corresponding network address associated with a corresponding number range; and obtaining a first blockchain message sent to the corresponding network address.

[0148] Subscribing may include listening / monitoring the corresponding network address.

[0149] Statement 6. A method according to any of the preceding statements, wherein the corresponding number range associated with each blockchain node is assigned by the blockchain node itself.

[0150] Statement 7. The method of any one of statements 1 to 6, wherein the respective number range associated with each blockchain node is assigned by a third party.

[0151] Statement 8. A method according to any one of statements 1 to 6, wherein the corresponding number range associated with each blockchain node is jointly allocated by multiple blockchain nodes in the multiple blockchain nodes.

[0152] Statement 9. The method of statement 4 or 5 or any statement dependent thereon, wherein the corresponding network address is a multicast address.

[0153] Statement 10. The method of statement 9, wherein the multicast address is an IPv6 multicast address.

[0154] Statement 11. The method of any preceding statement, wherein the first blockchain message comprises a blockchain transaction.

[0155] Statement 12. A method according to any of the preceding statements, wherein the first blockchain message includes a blockchain block.

[0156] Statement 13. A computer device, comprising:

[0157] a memory comprising one or more memory cells; and

[0158] A processing device comprising one or more processing units, wherein the memory stores code arranged to be run on the processing device, the code being configured to perform a method according to any one of statements 1 to 12 when run on the processing device.

[0159] Clause 14. A computer program embodied on a computer-readable storage and configured to, when executed on one or more processors, perform the method of any one of clauses 1 to 12.

[0160] According to another aspect of the disclosure, a method may be provided, the method comprising actions of the first blockchain node and the second blockchain node. According to another aspect of the disclosure, a system may be provided, the system comprising computer devices of the first blockchain node and the second blockchain node.

Claims

1. A computer-implemented method of propagating a blockchain message, wherein a blockchain network comprises a plurality of blockchain nodes, wherein each blockchain node is associated with a respective number range, wherein the method is performed by a first blockchain node and comprises: determining a first number based on the first blockchain message; as well as If the first number is within the corresponding range associated with the first blockchain node, the first blockchain message is provided to one or more second blockchain nodes.

2. The method according to claim 1, wherein determining the first number comprises: Hash at least a portion of the first blockchain message.

3. The method according to claim 1, wherein determining the first number comprises: The first number is extracted from a field of the first blockchain message.

4. The method of any preceding claim, wherein each respective range is associated with a respective network address, and wherein providing the first blockchain message to the one or more second blockchain nodes comprises: The first blockchain message is sent to the respective network address associated with the respective scope.

5. The method of any preceding claim, wherein each blockchain node is associated with a respective set of blockchain nodes, and wherein providing the first blockchain message to the one or more second blockchain nodes comprises: The first blockchain message is provided to the set of corresponding blockchain nodes.

6. A computer-implemented method of obtaining a blockchain message, wherein a blockchain network comprises a plurality of blockchain nodes, wherein each blockchain node is associated with a respective number range, wherein the method is performed by a second blockchain node and comprises: subscribing to a corresponding network address associated with a corresponding number range; as well as Obtain a first blockchain message sent to the corresponding network address.

7. A method according to any preceding claim, wherein the corresponding number range associated with each blockchain node is assigned by the blockchain node itself.

8. The method according to any one of claims 1 to 7, wherein the respective number range associated with each blockchain node is allocated by a third party.

9. The method according to any one of claims 1 to 7, wherein the corresponding number range associated with each blockchain node is jointly allocated by multiple blockchain nodes among the multiple blockchain nodes.

10. The method according to claim 4 or 6 or any claim dependent therefrom, wherein the corresponding network address is a multicast address. The method according to claim 10 , wherein the multicast address is an IPv6 multicast address.

12. The method of any preceding claim, wherein the first blockchain message comprises a blockchain transaction.

13. A method according to any preceding claim, wherein the first blockchain message comprises a blockchain block.

14. A method according to any preceding claim, wherein one or more numbers in the respective number ranges are different.

15. A computer device, comprising: a memory, the memory comprising one or more memory units; as well as A processing device comprising one or more processing units, wherein the memory stores code configured to be run on the processing device, the code being configured to perform the method according to any one of claims 1 to 14 when run on the processing device.

16. A computer program embodied on a computer readable memory and configured to, when run on one or more processors, perform the method according to any one of claims 1 to 14.

Images