Blockchain message propagation

Abstract

A computer-based method for propagating a blockchain message, wherein at least one blockchain node is associated with one or more respective ranges of numbers and one or more respective sets of blockchain nodes, and each respective range of numbers is associated with each respective set of blockchain nodes, and the method is For at least one of several blockchain messages, a numerical value is determined based on each blockchain message, wherein each numerical value of one or more blockchain messages falls within each of one or more ranges. The system comprises making available to each blockchain node belonging to each set of blockchain nodes associated with each of the one or more blockchain transactions, for each range in which each numerical value of one or more blockchain transactions falls, part or all of each blockchain message.

Description

[Technical Field]

[0001] This disclosure relates to a method for propagating blockchain transactions to nodes in a blockchain network. [Background technology]

[0002] The Internet Protocol (IP) suite currently has two competing technical designs, IPv4 and IPv6, corresponding to versions 4 and 6 of IP, for assigning IP addresses and routing data packets between senders and receivers over the Internet. A key difference between the two is that IPv6 includes a range of IP address types such as unicast, anycast, and multicast.

[0003] The most widely adopted type of address is unicast. Unicast allows packets to be sent to a single recipient. This is usually sufficient for most client services and applications. However, two other types of addresses, multicast and anycast, are used for specialized enterprise networks. Anycast allows a single action to send a packet to one recipient out of a set of recipients. It is not available for IPv4 (although it may be implemented with some workarounds), but is inherently supported by IPv6. Multicast allows a single action to send packets to multiple recipients. It is optional in IPv4 (but not widely adopted), but is inherently part of the IPv6 specification.

[0004] IP multicast allows a source host to send IP packets to one or more destination hosts identified by a single group address. The transmitted packets are replicated within the IP network by routers at points where the route branches so that a single packet destined for a specific group must be sent by the source host, resulting in the most efficient delivery of data to multiple recipients. A single link may transmit to one or more multicast groups, and a host may be part of two or more multicast groups. Any host may send packets to a multicast group, regardless of whether it is a member of that group, but only group members will receive those packets.

[0005] IP multicast is designed for applications and services that need to reach many hosts connected to a network simultaneously. Illustrative applications include video conferencing, corporate communications, and the distribution of news, software, and stock information. A source host might support these applications by learning the IP addresses of N destination hosts, establishing N connections with them, and sending N copies of each packet. In contrast, IP multicast is more efficient because the source host must learn a single group address and send a single packet to reach N destination hosts. IP multicast differs from broadcast in that packets are sent not across an entire subnetwork, but rather to a selected group of hosts that may be on different subnetworks and have registered themselves as a group. Another difference is that broadcast only supports one-to-many type communication, while multicast also supports many-to-many type communication. Any IP network that is 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-based and IPv6-based networks support IP multicast, this specification states that the limited address space of IPv4 limits the ability of IPv4 multicast to reach a growing number of internet-connected devices. In addition, the common use of Network Address Translation (NAT) vehicles, which translate public IPv4 addresses to private addresses, makes it extremely difficult, if not impossible, to support several applications that use multicast connectivity. Globally unique IPv6 addresses eliminate the need for NAT boxes and simplify multicast communication between hosts. More specifically, the wider address space of IPv6 reduces the likelihood of separate multicast streams from different sources using the same group address and interfering with each other. IPv6 multicast also more clearly defines domain control, i.e., the ability to prevent multicast leaks outside the managed domain, and makes it easier to allocate and manage multicast groups.

[0007] As shown in Figure 3, the basic format of an IPv6 multicast address includes the following elements. • Prefix: All IPv6 multicast addresses begin with hex (hex) 0xFF to identify them as multicast addresses. • Flags: Indicates how an address was assigned or if it may contain additional information. The Internet Assigned Numbers Authority (IANA) assigns 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 unicast-based IPv6 network prefixes, and the R flag to signal that a rendezvous-point (RP) address is incorporated. • Scope: Restricts the distance a multicast packet can travel. This prevents multicast packets from crossing management network boundaries and traversing links and networks to which they do not belong. • Group ID: Identifies a specific multicast group address (belonging to the host interface).

[0008] Blockchain networks like Bitcoin typically use a distributed network of nodes to generate new blocks containing transactions. These blocks and transactions propagate rapidly across the network using peer-to-peer (P2P) messaging protocols. The protocols employ a "flooding" technique that attempts to forward all new messages to all peers connected to a given node. [Overview of the Initiative] [Problems that the invention aims to solve]

[0009] The peer-to-peer messaging protocols in Bitcoin and several other blockchains ensure that each new block or transaction reaches all other nodes in the network in a timely manner, regardless of the network structure. This is because the protocol guarantees that each node will attempt to forward the new message to all other nodes it is connected to. This is inefficient because it generates a large amount of redundant network traffic.

[0010] In reality, the topology of a blockchain network is the topology of a highly connected graph consisting of only a few essential nodes. In such a network, sometimes called a "small world," or quasi-perfect graph, each node is connected to the vast majority of all other nodes. In its extreme case, the network can become saturated with all nodes connected to one another.

[0011] The high connectivity of a blockchain network introduces significant redundancy, impacting the efficiency of P2P messaging protocols. Consider a 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 may send up to (n-1)·m messages per second, which roughly creates an upper limit of n·(n-1)·m in the instantaneous total network traffic rate. This is significantly larger than the theoretical minimum of n·m messages per second required for the network to function, corresponding to a scenario where all new blocks and transactions are generated by a single node. The ratio of the upper limit to the lower limit is approximately n, which is an order of magnitude difference even when only a handful of nodes are involved in the network.

[0012] Therefore, this interaction between the blockchain network's current P2P messaging protocol and empirical topology results in redundancy of up to (n-2)·n·m = (n-1)·(n·m)-(n·m) messages per second. In practice, this lower bound is unlikely to occur (since not all blocks and transactions tend to originate from a single node), but there will almost always be significant redundancy between the worst-case network traffic upper limit and the theoretical minimum traffic for any given network state. These redundant messages unnecessarily increase the burden on operating blockchain nodes and therefore reduce the overall efficiency of the network.

[0013] Therefore, it is advantageous to reduce the total momentary traffic on the blockchain network by modifying the P2P messaging protocol so that new blocks and transaction messages are not unnecessarily duplicated. [Means for solving the problem]

[0014] According to one aspect disclosed herein, a computer-operated method for propagating blockchain messages is provided, wherein the blockchain network comprises multiple blockchain nodes, at least one blockchain node is associated with one or more respective ranges of numbers and one or more respective sets of blockchain nodes, each respective range of numbers is associated with each respective set of blockchain nodes, and the method is performed by a first blockchain node. For at least one of several blockchain messages, a numerical value is determined based on each blockchain message, wherein each numerical value of one or more blockchain messages falls within each of one or more ranges. The system comprises making available, for each range in which each numerical value of each of the one or more blockchain messages falls, a portion or all of each blockchain message to each blockchain node belonging to each set of blockchain nodes associated with that range.

[0015] According to another aspect disclosed herein, a method is provided, performed by a computer, for retrieving blockchain messages, wherein the blockchain network comprises multiple blockchain nodes, each blockchain node being associated with one or more respective ranges of numbers and one or more respective sets of blockchain nodes, each respective range of numbers being associated with each respective set of blockchain nodes, and the method is performed by a second blockchain node. Joining each network address associated with each range and each set of blockchain nodes, It includes obtaining the first blockchain message sent to each network address.

[0016] According to another aspect disclosed herein, a computer-operated method for propagating blockchain messages is provided, wherein the blockchain network comprises multiple blockchain nodes, each blockchain node being associated with one or more respective ranges of numbers and one or more respective sets of blockchain nodes, each respective range of numbers being associated with each respective set of blockchain nodes, and the method is performed by a first blockchain node. The respective values ​​are determined based on the first blockchain message, If the first numerical value is within one of each range associated with the first blockchain node, making the first blockchain message available to each blockchain node belonging to each set of blockchain nodes associated with each range.

[0017] Embodiments of the present disclosure provide several advantages over existing "flooding" techniques that transfer all messages to all nodes. For example, the embodiments improve the efficiency of the blockchain P2P protocol and reduce redundant or replicated network traffic. The embodiments also enable a hierarchy in the node network based on capabilities, meaning that some nodes can choose to take more of the propagation burden than other nodes.

[0018] Embodiments disclosed herein enable network traffic to be "sharded", i.e., partitioned based on the content of the traffic or the order in which the traffic arrives. In the case of blockchain transactions, the ordering used to partition the traffic may relate to the order in which the transactions appear in blocks and their associated Merkle trees.

[0019] To build resilience when transferring data to multiple parties, overlaps in the segmented traffic may also be created using the described embodiments. These overlaps represent a compromise between redundancy and resilience in data propagation, such that redundancy is still minimized with respect to existing messaging protocols. In effect, a single large message, e.g., a block composed of many transactions, or a large transaction composed of many packets, for example, can be propagated to the recipient more efficiently by using these overlaps when segmenting. This divides the load when propagating traffic among diverse senders, which enhances the resilience of the propagation mechanism to failures of a subset of the senders, as dropped connections or failed packets are mitigated by the overlaps between different traffic segments. In other words, some embodiments create a "virtual" propagation connection between each recipient and diverse senders that is more robust than the connection between each individual sender and recipient in the network. This is similar to a RAID (Redundant Array of Inexpensive Disks) system in a virtualized data storage system.

[0020] A feature of the Bitcoin network according to the Bitcoin white paper is that "new transactions are broadcast to all nodes." Embodiments of the present disclosure achieve this same goal and are thus compatible with the original Bitcoin protocol but minimize redundancy in message propagation.

[0021] To assist in understanding the embodiments of the present disclosure and to show how such embodiments can be implemented, the accompanying drawings are referred to merely by way of example.

Brief Description of the Drawings

[0022] [Figure 1] It is a schematic block diagram of a system for implementing a blockchain. [Figure 2]This diagram schematically illustrates some examples of transactions that can be recorded in a blockchain. [Figure 3] This diagram schematically shows the basic format of an IPv6 multicast address. [Figure 4] This diagram schematically illustrates an exemplary system for propagating a message. [Modes for carrying out the invention]

[0023] 1. Propagation of blockchain messages An exemplary system for carrying out embodiments of the present disclosure is shown in Figure 4. System 400 includes a plurality of blockchain nodes 104. Although only four nodes 104 (nodes 104a to d) are shown, in general, system 400 may include any number of blockchain nodes 104 in the blockchain network 106, for example, all of the blockchain nodes 104. A first blockchain node (for example, "blockchain node A" 104a) is configured to determine whether a blockchain-related message should be propagated to one or more other blockchain nodes 104, and / or to which other nodes 104 the message will be propagated. A message may be one or more blockchain transactions 152, or comprise one or more. In some examples, a message is a single transaction. A message may be a blockchain block 151, or comprise one or more. A message may include an entire block, i.e., a corresponding set of block headers and transactions, or may include only block headers.

[0024] Propagating a message to node 104 may include sending the message directly to node 104. Propagating a message to node 104 may include sending the message to a network address associated with node 104 (for example, an IPv4 or IPv6 address). Propagating a message to node 104 may include sending the message to a network address to which node 104 will join (for example, an IPv6 multicast address). It should be understood that "sending a message to a network address" means sending the message (for example, to a router), and it should be understood here that the message is addressed to a network address.

[0025] The first node 104a receives the first message. The first message may be received from a different node 104 or from user 103. In some examples, the first message may be generated at least partially by the first node 104a. For example, the first message may include a block header generated by the first node 104a based on, for example, a set of enabled transactions available to the first node 104a stored in its memory pool.

[0026] In some embodiments, a first node 104a is associated with a first numerical range. Generally, the first numerical range may begin and end with any number and may be of any size. The first numerical range may 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 numerical range. Each node 104 may be associated with its own numerical range. Some of the numerical ranges may overlap. Some of the numerical ranges may not overlap.

[0027] The first node 104a determines a first numerical value based on a first message. For example, the first node 104a may apply a hash function to the first message and, for example, generate a first numerical value based on the hash result, or determine a first numerical value based on the hash result by selecting one or more digits of the hash result (such as a leading or last digit with non-zero characters). In some examples, the first numerical value is determined based on a part of the first message (e.g., a field). That is, the first message may contain a number on which the first numerical value may be based. In a particular example, the first message may be a transaction, and the first numerical value may be determined based on a transaction identifier, for example, one or more of the first or last digits of the transaction identifier.

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

[0029] As described above, propagating the first message may involve sending the first message to one or more second nodes 104. Alternatively, as shown in Figure 4, propagating the first message may involve sending the first message to a first network address associated with a first numerical range (e.g., "Network Address A"). One or more second nodes 104 may listen to (e.g., join) the first network address for blockchain messages. That is, 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 are joined to the first network address.

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

[0031] In other embodiments, the first node 104a is associated with a first set of blockchain nodes 104 (i.e., one or more nodes 104 other than the first node 104a). Generally, the first set of nodes 104 may include any number of nodes 104, but not all nodes 104. The first set of nodes (a particular node 104 and / or that number of nodes 104) may 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 set of nodes 104. Each node 104 may be associated with its own set of other nodes 104. Some of the sets may overlap. Some of the sets may not overlap.

[0032] Please note that, as used throughout this disclosure, the term “set” should be understood to mean one or more sets.

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

[0034] As described above, propagating the first message may involve sending the first message to one or more second nodes 104. Alternatively, as shown in Figure 4, propagating the first message may involve 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 to (e.g., join) the first network address for blockchain messages. That is, 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 are joined to the first network address.

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

[0036] In other embodiments, the first node 104a is associated with both a first numerical range and a first set of nodes 104. Similar to the embodiments described above, the first node 104a may determine a first numerical value based on a first blockchain message and propagate the first message to the first set of nodes 104 only if the first numerical value falls within the first numerical range.

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

[0038] As in the embodiments described above, each numerical range may begin and end with any number and may be of any size. One or more of the numerical ranges may overlap. One or more of the numerical ranges may not overlap. One or more of the numerical ranges may 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 may determine one or more of the numerical ranges.

[0039] Similarly, as in the embodiments described above, each set of nodes 104 may contain any number of nodes 104, but not all of them. One or more of each set may contain the same number of nodes 104. One or more of each set may contain different numbers of nodes 104. One or more of each set of nodes (a specific number of nodes 104 and / or that number of nodes 104) may be selected by a first node 104a, by a different node 104, or by a third party. In some examples, some (e.g., all) of the nodes 104 of the blockchain network 106 determine one or more of each set of nodes 104.

[0040] For each message acquired (e.g., received or generated) by the first node 104a, the first node 104a determines a numerical value for that message. The first node 104a may determine the numerical values ​​by using one of the techniques described above, for example, by hashing part or all of the message. If each numerical value falls within one of the respective numerical ranges, the first node 104a may propagate the message to the respective sets of nodes 104 linked to the respective numerical ranges.

[0041] In some examples, the first node 104a may propagate each message to each set of nodes linked to each numerical range, provided that each numerical value determined for that message falls within its respective numerical range. In other examples, the first node 104a may propagate only a portion of the messages to each set of nodes. For example, the first node 104a may propagate only 50% of the messages with determined numerical values ​​that fall within a particular numerical range to the associated set of nodes 104. In some examples, each numerical range is associated with a percentage that determines the proportion of messages sent to each set of nodes 104. For example, if a numerical range is associated with 25%, only 25% of the messages with determined numerical values ​​that fall within that range will be sent to each set of nodes 104. One or more numerical ranges may be associated with the same percentage. One or more numerical ranges may be associated with different percentages. In some examples, each numerical range is associated with a different percentage.

[0042] As in the embodiments described above, propagating each message may involve sending each message to one or more second nodes 104 belonging to each set. Alternatively, as shown in Figure 4, propagating each message may involve sending each message to each network address associated with each set of nodes 104. For example, as shown in Figure 4, one message may be sent to network address A, to which nodes 104b and 104c will join, i.e., to which it will listen for messages, while a different message may be sent to network address B, to which nodes 104c and 104d will join. Each second node 104 may listen to (e.g., join) one or more network addresses for blockchain messages.

[0043] 1.1 Specific Examples As described, the embodiment described reduces the total instantaneous traffic on blockchain network 106 by modifying the P2P messaging protocol so that new blocks and transaction messages are not unnecessarily duplicated. Specific examples of the embodiment described are described below. The unifying features of these examples are as follows: All data messages (i.e., blocks, transactions) are sent from source node 104 to the multicast address. Node 104 selectively sends data messages according to policy rules. The node's policy rules determine whether node 104 sends a given message, or to which node 104 a given message is sent, based on the following: (i) The content of the data message, or (ii) A group of nodes currently in the network, or (iii) Both.

[0044] It should be noted that there may be some exceptional messages that can be excluded from this new logic, such as when node 104 itself finds a new block.

[0045] 1.1.1 Exemplary Policy 1 - Content-Based Message Propagation In this example, the P2P protocol is modified so that node 104 is assigned a numerical range to which it is responsible for forwarding messages. Since a numerical value may be derived from each data message received by node 104 (for example, by hashing the message), the P2P protocol automatically chooses to propagate only messages to which that numerical value falls within the node's assigned range.

[0046] The logic for selectively propagating data messages in the new P2P protocol is as follows: 0. Numerical range in Node A

[0047]

number

[0048] It will be assigned. 1. A receives a data message m from another network node or from a user. 2. A finds or calculates the hash h(m) of the message. 3. A parses h(m) as a numerical value within the range 0 ≤ h(m) ≤ k, where k is determined by the hash function h. 4. h(m)∈[v L ,v U In the case of ], multicast IP address IP R Send m to , otherwise do nothing.

[0049] Notes on this protocol variant - When joining the network, range R may be automatically assigned to node 104 (for example, randomly selected). Alternatively, range R may be assigned by a third-party service provider that monitors which node is responsible for which range at a given time. Alternatively, node 104 can communicate collaboratively to assign ranges together in an ongoing and dynamic manner to ensure that the full range is always covered. - There may be overlaps in the ranges covered by different nodes 104. Minimizing overlaps minimizes redundancy in message propagation. - Multicast IP address corresponding to this range R However, any network node 104 may join. If there is no overlap in the range, preferably all nodes 104 will join this address to ensure that they all receive all data messages. If there is overlap, a node 104 that is the source for a given range does not need to join, minimizing redundant traffic. - In this P2P protocol, it is preferable that node 104 joins any range-specific multicast address to which node 104 is also not the source.

[0050] 1.1.2 Protocol Modification Form 2 - Group-Based Propagation In this example, the P2P protocol is modified so that each node 104 is assigned a group of destination nodes to which each node 104 must forward its messages.

[0051] The logic for selectively propagating data messages in the new P2P protocol is as follows: 0. Group of recipient node ranges

[0052]

number

[0053] These are assigned to node A, and they correspond to multicast addresses

[0054]

number

[0055] Share. 1. A receives a data message m from another network node or from a user. 2. A is a multicast address

[0056]

number

[0057] Transfer m to [destination].

[0058] Notes on this protocol variant - This variant form's selectivity affects the selection of which node 104 to forward messages to and which messages not to propagate. - Similar to protocol variant 1, the group assigned to node 104

[0059]

number

[0060] These may be (i) automatically assigned, (ii) assigned by a third party, or (iii) jointly assigned in coordination with the rest of the node network 106. - If a group of at least one node 104 sending a message is assigned to all nodes 104, there is still some redundancy in the traffic, but the redundancy is significantly reduced compared to the worst-case scenario.

[0061] 1.1.3 Protocol Modification Form 3 - Combined Type An alternative form involves modifying the P2P messaging protocol using a combination of variant forms 1 and 2, so that messages (i) may be selectively selected for propagation, and (ii) assuming that messages are selected, messages are propagated only to a selected group of nodes 104.

[0062] For example, a modified version of the P2P protocol may be established that enforces the following set of rules on a given node A. 1. A is in the range [v L ,v U All messages in the group

[0063]

number

[0064] To propagate. 2. A is range

[0065]

number

[0066] 50% of the messages in the group

[0067]

number

[0068] To propagate. 3. A is range

[0069]

number

[0070] 25% of the messages in the group

[0071]

Number

[0072] propagate to. 4....

[0073] Such logic sacrifices a corresponding increase in redundancy, but, critically, allows for increased network integrity and resilience to failures with less redundancy than the current P2P protocol allows. Such a scheme also allows the degree of redundancy to be finely tuned by selecting, as parameters, the size of each range and the size of each group, and by reflecting the diversity in node capabilities on the network at each respective value chosen for these parameters by each node 104.

[0074] 1.1.4 Exceptions There can be exceptions to the above-described P2P logical variant forms, such as new blocks generated by node 104, which should be broadcast widely to the entire network as quickly as possible by that node 104.

[0075] To account for such cases, a message-specific multicast address to which other nodes 104 will subscribe may be created. Each node A i can register the specific address i corresponding to the new block created by A

[0076]

Number

[0077] All nodes A on the network j can

[0078]

Number

[0079] I will be joining A i This exclusively applies to new block messages.

[0080]

number

[0081] This will ensure that the proposed P2P protocol changes do not disadvantage new blocks and do not increase their isolated risks.

[0082] 2. Exemplary System Overview A blockchain refers to a form of distributed data structure in which copies of the blockchain are maintained and widely published on each of several nodes in a decentralized peer-to-peer (P2P) network (hereinafter referred to as the "blockchain network"). A blockchain consists of a chain of blocks of data, each containing one or more transactions. Each transaction, other than so-called "coinbase transactions," points backward to a preceding transaction in a sequence that can span one or more blocks, leading backward to one or more coinbase transactions. Coinbase transactions are explained further below. Transactions submitted to the blockchain network are included in a new block. New blocks are often created by a process called "mining," which involves each of several nodes competing to solve a cryptographic puzzle based on a representation of "proof of work," i.e., a specified set of ordered and validated pending transactions waiting to be included in a new block of the blockchain. It should be noted that blockchains may be pruned on some nodes, and block publication may be achieved simply by publishing the block header.

[0083] Transactions within a blockchain may be used for one or more of the following purposes: carrying digital assets (i.e., several digital tokens), ordering a set of entries in a virtualized ledger or registry, receiving and processing timestamp entries, and / or ordering index pointers in time. Blockchain can also be leveraged to layer additional functionality on top of the blockchain. For example, a blockchain protocol may allow the accumulation of additional user data or indices to data within a transaction. There are no predetermined limits on the maximum amount of data that can be accumulated within a single transaction, and therefore, increasingly complex data can be incorporated. For example, this may be used to store electronic documents, or audio or video data, within the blockchain.

[0084] In the “output-based” model (sometimes called the UTXO-based model), the data structure of a given transaction comprises one or more inputs and one or more outputs. Any consumable output comprises an element specifying the amount of digital asset that can be derived from the evolving sequence of the transaction. A consumable output is sometimes called a UTXO (“unconsumed transaction output”). That output may further comprise a locking script that specifies the conditions for the future redemption of that output. A locking script is a predicate that defines the conditions necessary to activate and transfer a digital token or digital asset. Each input of a transaction (other than a coinbase transaction) comprises a pointer (i.e., a reference) to such an output in a preceding transaction and may further comprise an unlocking script to unlock the locking script of the pointed-to output. Thus, a pair of transactions are taken into consideration and referred to as the first transaction and the second transaction (or “target” transaction). The first transaction comprises at least one output which comprises a locking script that specifies the amount of digital asset and defines one or more conditions for unlocking the output. The second target transaction has at least one input, which includes a pointer to the output of the first transaction and an unlocking script for unlocking the output of the first transaction.

[0085] In such a model, when a second target transaction is sent to the blockchain network to be propagated and recorded within the blockchain, one of the validity criteria applied at each node is that the unlocking script satisfies all one or more conditions specified in the locking script of the first transaction. Another criterion is that the output of the first transaction has not already been redeemed by another valid transaction earlier. Any node that finds a target transaction invalid according to any of these conditions will neither propagate it (as a valid transaction, but in some cases to register an invalid transaction) nor include it in a new block to be recorded in the blockchain.

[0086] An alternative type of transaction model is the account-based model. In this case, each transaction specifies the amount to be transferred not by backward referencing the UTXO of a preceding transaction in a sequence of past transactions, but rather by referencing an absolute account balance. The current state of all accounts is accumulated and constantly updated by nodes separate from the blockchain.

[0087] Figure 1 shows an exemplary system 100 for implementing blockchain 150. System 100 may include a packet-switched network 101, i.e., a wide-area internet, typically such as the internet. The packet-switched network 101 may include a number of blockchain nodes 104 (often called "miners") that are configured to form a peer-to-peer (P2P) network 106 within the packet-switched network 101. Although not shown, the blockchain nodes 104 may be configured as a quasi-complete graph. Thus, each blockchain node 104 is highly connected to other blockchain nodes 104.

[0088] Each blockchain node 104 is equipped with the computer equipment of its peers, and different nodes 104 belong to different peers. Each blockchain node 104 is equipped with one or more processors, such as processing units comprising one or more central processing units (CPUs), accelerator processors, application-specific processors, and / or field-programmable gate arrays (FPGAs), and other equipment such as application-specific integrated circuits (ASICs). Each node also has memory, i.e., computer-readable storage in the form of one or more non-temporary computer-readable media. The memory may comprise one or more memory units employing one or more memory media, such as magnetic media such as hard disks, solid-state drives (SSDs), flash memory, or electronic media such as EEPROMs, and / or optical media such as optical disc drives.

[0089] Blockchain 150 comprises a chain of data blocks 151, with each copy of blockchain 150 maintained in each of the multiple blockchain nodes 104 within the distributed network or blockchain network 106. As mentioned above, maintaining a copy of blockchain 150 does not necessarily mean accumulating blockchain 150 as a whole. Instead, blockchain 150 may be a pruned version of the data, as long as each blockchain node 150 accumulates the block header (described below) of each block 151. Each block 151 in the chain comprises one or more transactions 152, where a transaction refers to a certain type of data structure. The nature of that data structure depends on the type of transaction protocol used as part of the transaction model or transaction scheme. A given blockchain uses one particular transaction protocol throughout.

[0090] Blockchain node 104 may be configured to forward transaction 152 to other blockchain nodes 104, thereby propagating transaction 152 across the entire network 106. Blockchain node 104 may be configured to create block 151, accumulating copies of the same blockchain 150 in their respective memories. Blockchain node 104 may also maintain an ordered set (or “pool”) 154 of transactions 152 waiting to be incorporated into block 151. The ordered pool 154 is often referred to as a “mempool”. This term, as used herein, is not intended to be limited to any particular blockchain, protocol, or model. It refers to an ordered set of transactions that node 104 accepts as valid and that node 104 is obligated not to accept any other transaction attempting to consume the same output.

[0091] In a given current transaction 152j, its (or each) input comprises a pointer to the output of a preceding transaction 152i in the sequence of transactions, specifying that this output will be redeemed or "consumed" within the current transaction 152j. Consumption or redemption does not necessarily imply the transfer of a financial asset, but that is certainly one common application. More generally, consumption can be described as consuming an output, i.e., allocating it to one or more outputs in another transaction forward. Generally, a preceding transaction can be any transaction in an ordered set 154 or any block 151. The preceding transaction 152i does not necessarily need to exist at the time the current transaction 152j is created and sent to network 106, but the preceding transaction 152i must exist and be enabled for the current transaction to be valid. Therefore, "predecessor" as used herein does not necessarily refer to the time of creation or transmission in a temporal sequence, but rather to the predecessor in a logical sequence linked by pointers, and thus does not necessarily rule out the possibility that transactions 152i and 152j may be created or transmitted out of order (see the following explanation of orphan transactions). The predecessor transaction 152i may be equated with the antecedent transaction or the former transaction.

[0092] Due to the resources involved in transaction activation and publication, each of the blockchain nodes 104 typically 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.

[0093] The memory of each blockchain node 104 stores software configured to run on the processing unit of the blockchain node 104 in order to perform one or more of its respective roles and to process transaction 152 in accordance with the blockchain node protocol. It will be understood that any action attributed to blockchain node 104 herein may be performed by software running on the processing unit of each computer device. The node software may be implemented in one or more applications at the application layer, or in lower layers such as the operating system layer, the protocol layer, or any combination thereof.

[0094] Any given blockchain node may be configured to perform one or more of the following operations: validating 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, nodes may specialize in a particular operation. For example, node 104 may focus on transaction validation and propagation, or on block mining. In some examples, blockchain node 104 may perform two or more of these operations in parallel. Any reference to blockchain node 104 may refer to an entity configured to perform at least one of these operations.

[0095] Furthermore, the computer devices 102 of each of the multiple parties 103 acting as consuming users are connected to the network 101. These users may interact with the blockchain network 106 but do not participate in activating transactions or building blocks. Some of these users or agents 103 may act as senders and receivers in transactions. Other users may interact with the blockchain 150 without necessarily acting as senders or receivers. For example, some parties may act as accumulating entities that accumulate copies of the blockchain 150 (for example, by obtaining a copy of the blockchain from a blockchain node 104).

[0096] Some or all of the parties 103 may be connected as part of a different network, for example, as part of a network overlaid on top of the blockchain network 106. Users of the blockchain network (often called “clients”) may be said to be part of the system including the blockchain network 106, but these users are not blockchain nodes 104 as they do not perform the required roles of blockchain nodes. Instead, each party 103 may interact with the blockchain network 106 and thereby utilize the blockchain 150 by connecting to (i.e., communicating with) the blockchain nodes 106. Two parties 103 and their respective devices 102, namely the first party 103a and their respective computer devices 102a, and the second party 103b and their respective computer devices 102b, are shown for illustrative purposes. It will be understood that many more such parties 103 and their respective computer devices 102 may exist and participate in the system 100, but for convenience they are not shown. Each party 103 may be an individual or an organization. For purely illustrative purposes, the first party 103a is referred to as Alice and the second party 103b as Bob in this specification, but it should be understood that this is not limiting, and any reference to Alice or Bob in this specification may be replaced with "the first party" and "the second party," respectively.

[0097] Each computer device 102 of Party 103 comprises a processing unit comprising one or more processors, for example, one or more CPUs, GPUs, other accelerator processors, application-specific processors, and / or FPGAs. Each computer device 102 of Party 103 further comprises memory, i.e., computer-readable storage in the form of one or more non-temporary computer-readable media. This memory may comprise one or more memory units employing one or more memory media, for example, magnetic media such as hard disks, SSDs, flash memory, or electronic media such as EEPROMs, and / or optical media such as optical disc drives. The memory on each computer device 102 of Party 103 stores software comprising at least one instance of a client application 105 configured to run on the processing unit. It will be understood that any action attributed to a given Party 103 herein can be performed using the software running on the processing unit of each computer device 102. Each party 103's computer equipment 102 includes at least one user terminal, such as a desktop or laptop computer, tablet, smartphone, or wearable device such as a smartwatch. A given party 103's computer equipment 102 may also include one or more other networked resources, such as cloud computing resources, accessed via the user terminal.

[0098] The client application 105 may initially be provided to the computer equipment 102 of any given party 103 on one or more suitable computer-readable storage media, for example, by downloading from a server, or on a removable storage device such as a removable SSD, flash memory key, removable EEPROM, removable magnetic disk drive, magnetic floppy disk or tape, optical disk such as a CD or DVD ROM, or removable optical drive.

[0099] The client application 105 has at least a “wallet” function, which has two main functions. One of these is to enable each party 103 to create, authorize (e.g., sign), and send a transaction 152 to one or more Bitcoin nodes 104, which are then propagated across the entire network of blockchain nodes 104, thereby being included in blockchain 150. The other is to report back to each party the amount of digital assets they currently own. In an output-based system, this second function includes matching the amounts specified in the outputs of various transactions 152 distributed across blockchain 150 belonging to the party in question.

[0100] Note: While various client functionalities may be described as being integrated into a given client application 105, this is not necessarily limited. Instead, any client functionality described herein may instead be implemented in a set of two or more separate applications that interface via an API, for example, or one may be plugged into the other. More generally, client functionalities may be implemented in the application layer, or in lower layers such as the operating system, or any combination thereof. The following description will be based on client application 105, but it should be understood that this is not limited.

[0101] Each computer device 102 instance of a client application or software 105 is operably coupled to at least one of the blockchain nodes 104 of the network 106. This enables the wallet function of client 105 to send transaction 152 to the network 106. Client 105 can also contact a blockchain node 104 to query the blockchain 150 for any transaction in which each party 103 is the recipient (or, in embodiments, to actually examine the transactions of other parties in the blockchain 150, since the blockchain 150 is a public facility that provides trust in transactions, partly through its public visibility). The wallet function on each computer device 102 is configured to organize and send transaction 152 according to the transaction protocol. As described above, each blockchain node 104 runs software configured to validate transaction 152 according to the blockchain node protocol and to forward transaction 152 to propagate them across the entire blockchain network 106. Transaction protocols and node protocols correspond to each other; a given transaction protocol is used together with a given node protocol to implement a given transaction model. The same transaction protocol is used for all transactions 152 in blockchain 150. The same node protocol is used by all nodes 104 in network 106.

[0102] An alternative type of transaction protocol, operated by several blockchain networks, is sometimes referred to as an "account-based" protocol as part of the account-based transaction model. In the account-based example, each transaction specifies the amount to be transferred not by retrospectively referencing the UTXO of a preceding transaction in a sequence of past transactions, but rather by referencing an absolute account balance. The current state of all accounts is accumulated and constantly updated by nodes of that network, separate from the blockchain. In such a system, transactions are ordered using the account's running transaction account (also called 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, an optional data field may also be signed by the transaction. This data field may point backward to a previous transaction, for example, if the data field contains a previous transaction ID.

[0103] Several account-based transaction models share some similarities with the output-based transaction models described herein. For example, as mentioned above, the data fields of an account-based transaction may point backward to a previous transaction, which is equivalent to the input of an output-based transaction, referencing the output point of the previous transaction. Thus, both models enable links between transactions. As another example, an account-based transaction includes a “Recipient” field (where the receiving address of the account is specified) and a “Value” field (where the amount of the digital asset may be specified). Together, the Recipient and Value fields are equivalent to the output of an output-based transaction, which may be used to assign the amount of the digital asset to a blockchain address. Similarly, an account-based transaction has a “Signature” field containing a signature for the transaction. The signature is generated using the sender’s private key and confirms that the sender authorizes this transaction. This is equivalent to the input / unlocking script of an output-based transaction, which typically includes a signature for the transaction. Once both types of transactions are submitted to their respective blockchain networks, the signature may be checked to determine whether the transaction is valid and recorded on the blockchain. In an account-based blockchain, a “smart contract” refers to a transaction that includes a script configured to perform one or more actions (for example, sending or “releasing” a digital asset to a recipient address) in response to one or more conditions defined by the smart contract's script being met by one or more inputs (provided by the transaction). A smart contract exists as a transaction on the blockchain and can be invoked (or triggered) by a subsequent transaction.Therefore, in some examples, a smart contract can be considered equivalent to a locking script for an output-based transaction that can be triggered by a subsequent transaction, checking whether one or more conditions defined by the locking script are met by the input of the subsequent transaction.

[0104] 3. UTXO base model Figure 2 shows an exemplary transaction protocol, which is an example of a UTXO-based protocol. A transaction 152 (abbreviated as "Tx") is the fundamental data structure of blockchain 150 (each block 151 contains one or more transactions 152). The following will be described by reference to output-based or "UTXO"-based protocols. However, this does not necessarily limit all possible embodiments. While the exemplary UTXO-based protocol is described with reference to Bitcoin, it should be noted that it can be equally implemented in other exemplary blockchain networks.

[0105] In the UTXO-based model, each transaction ("Tx") 152 comprises a data structure having one or more inputs 202 and one or more outputs 203. Each output 203 may have an unspent transaction output (UTXO) which can be used as a source for the input 202 of another new transaction (if the UTXO has not already been redeemed). The UTXO contains a value that specifies the amount of the digital asset, which represents a set number of tokens on the distributed ledger. The UTXO may also contain, among other information, the transaction ID of the transaction from which the UTXO originated. The transaction data structure may also have a header 201 which may contain an indicator of the size of the input fields 202 and the output fields 203. The header 201 may also contain the ID of the transaction. In embodiments, the transaction ID is a hash of the transaction data (excluding the transaction ID itself) and is stored in the header 201 of the raw transaction 152 submitted to node 104.

[0106] For example, Alice 103a wants to create transaction 152j to transfer a certain amount of the digital asset in question to Bob 103b. In Figure 2, Alice's new transaction 152j is labeled "Tx1". It takes a certain amount of the digital asset locked in Alice in the output 203 of a preceding transaction 152i in the sequence and transfers at least some of it to Bob. The preceding transaction 152i is labeled "Tx0" in Figure 2. Tx0 and Tx1 are merely arbitrary labels. They do not necessarily mean that Tx0 is the first transaction in blockchain 151, or that Tx1 is the next transaction in pool 154. Tx1 could point backward to any preceding (i.e., ancestor) transaction that still has the unspent output 203 locked in Alice.

[0107] In the context of a transaction sequence, the terms “preceding” and “subsequent” as used herein refer to the order of transactions in a sequence, as defined by transaction pointers specified within the transaction (such as which transaction points to which other transactions later). They can be equally replaced with “former” and “successor,” or “ancestor” and “descendant,” “parent” and “child,” or similar terms. This does not necessarily imply the order in which they are created, sent to network 106, or arrive at any given blockchain node 104. However, a subsequent transaction (descendant transaction or “child”) that points to a preceding transaction (ancestor transaction or “parent”) will not be activated until the parent transaction is activated, and unless the parent transaction is activated. A child that arrives at blockchain node 104 before its parent is considered an orphan. Depending on the node protocol and / or node behavior, orphans may be discarded or buffered for a period of time while waiting for their parent.

[0108] One of the one or more outputs 203 of the preceding transaction Tx0 contains a specific UTXO, here labeled UTXO0. Each UTXO contains a value specifying the amount of the digital asset represented by the UTXO, and a locking script that specifies the conditions that must be met by the unlocking script in the subsequent transaction's input 202 in order for the subsequent transaction to be activated and therefore for the UTXO to be successfully redeemed.

[0109] A locking script (also called scriptPubKey) is a snippet of code written in a domain-specific language recognized by the node protocol. A specific example of such a language is called "Script" (uppercase S), used by blockchain networks. The locking script specifies what information is needed to consume transaction output 203, for example, the requirements for Alice's signature. The locking script appears in the output of the transaction. An unlocking script (also called scriptSig) is a snippet of code written in a domain-specific language that provides the information needed to satisfy the locking script criteria. For example, it may include Bob's signature. The unlocking script appears in input 202 of the transaction.

[0110] Therefore, in the illustrated example, UTXO0 in output 203 of Tx0 is signed by Alice Sig P for UTXO0 to be redeemed (more precisely, for subsequent transactions attempting to redeem UTXO0 to be valid). A Locking script that requires [Checksig P A [Equipped with] [Checksig P A ] is the public key P from Alice's public key-private key pair. A The notation (i.e., hash) is included. Input 202 of Tx1 includes a pointer that points backward to Tx1 (by its transaction ID, i.e., TxID0, which in this embodiment is the hash of the entire transaction Tx0). Input 202 of Tx1 includes an index that identifies the UTXO0 in Tx0 to identify it among any other possible outputs of Tx0. Input 202 of Tx1 includes an unlocking script with Alice's cryptographic signature, which is created by Alice applying her private key from a key pair to a default portion of the data (sometimes called a "message" in cryptography). <Sig P A>Furthermore, the data (or "message") that needs to be signed by Alice to provide a valid signature may be defined by a locking script, by the node protocol, or a combination thereof.

[0111] When a new transaction Tx1 arrives at blockchain node 104, the node applies the node protocol. This involves executing the locking script and the unlocking script together to check whether the unlocking script satisfies the conditions specified in the locking script (if this condition may satisfy one or more criteria).

[0112] It should be noted that script code is often expressed in a general way (i.e., without using a strict language). For example, arithmetic codes (opcodes) may be used to represent specific functions. "OP_..." refers to a specific opcode in the Script language. For example, OP_RETURN is a Script language opcode that, when preceded by OP_FALSE at the beginning of a locking script, creates a non-consumable output of a transaction that allows data to be stored within the transaction, thereby immutably recording the data in blockchain 150. For example, the data may consist of documents that are desired to be stored in the blockchain.

[0113] Typically, the input to a transaction is the public key P AThis includes a corresponding digital signature. In embodiments, this is based on ECDSA using the elliptic curve secp256k1. The digital signature signs a specific fragment of data. In some embodiments, for a given transaction, the signature signs some or all of the transaction inputs and some or all of the transaction outputs. The specific portion of the output it signs depends on the SIGHASH flag. The SIGHASH flag is a 4-byte code typically included at the end of the signature to select which outputs are signed (and therefore fixed at the time of signing).

[0114] A locking script is sometimes referred to as a “scriptPubKey,” typically because it contains the public key of the party to which each transaction is locked. An unlocking script is sometimes referred to as a “scriptSig,” typically because it contains the corresponding signature. However, more generally, the requirement that a UTXO be redeemed includes authenticating a signature is not mandatory in all blockchain applications. More generally, a scripting language may be used to define any one or more conditions. Thus, the more general terms “locking script” and “unlocking script” may be preferred.

[0115] 4. Further special notes As the disclosures herein are given, other variations or uses of the techniques disclosed may become apparent to those skilled in the art. The scope of this disclosure is limited solely by the appended claims and not by the embodiments described herein.

[0116] For example, some of the embodiments described above relate to a Bitcoin network 106, a Bitcoin blockchain 150, and a Bitcoin node 104. However, it should be understood that the Bitcoin blockchain is just one specific example of blockchain 150, and the above description may generally apply to any blockchain. That is, the present invention is by no means limited to the Bitcoin blockchain. More generally, any above references to Bitcoin network 106, Bitcoin blockchain 150, and Bitcoin node 104 may be replaced with references to blockchain network 106, blockchain 150, and blockchain node 104, respectively. Blockchains, blockchain networks, and / or blockchain nodes may share some or all of the described characteristics of Bitcoin blockchain 150, Bitcoin network 106, and Bitcoin node 104 as described above.

[0117] In a preferred embodiment of the present invention, the blockchain network 106 is a Bitcoin network, and the Bitcoin node 104 performs at least all of the described functions, including creating, issuing, propagating, and accumulating a block 151 of the blockchain 150. It is not excluded that there may be other network entities (or network elements) that perform only one or some of these functions, rather than all of them. That is, a network entity may perform the function of propagating and / or accumulating blocks without creating and issuing blocks (it should be noted that these entities would not be considered nodes of the preferred Bitcoin network 106).

[0118] In other embodiments of the present invention, the blockchain network 106 does not have to be a Bitcoin network. In these embodiments, it is not excluded that a node may perform at least one or part of, but not all, of the functions of creating, issuing, propagating, and accumulating blocks 151 of blockchain 150. For example, in those other blockchain networks, “node” may be used to refer to a network entity configured to create and issue blocks 151 but not to accumulate those blocks 151 and / or propagate them to other nodes.

[0119] More generally, any reference to the term “Bitcoin node” 104 above may be replaced with the term “network entity” or “network element,” such entities / elements configured to perform some or all of the roles of creating, issuing, propagating, and accumulating blocks. The functionality of such network entities / elements may be implemented in hardware in a similar manner to that described above with reference to blockchain nodes 104.

[0120] Several embodiments have been described regarding blockchain networks implementing a proof-of-work consensus mechanism to secure the underlying blockchain. However, proof-of-work is only one type of consensus mechanism, and generally, embodiments may use any type of preferred consensus mechanism, 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 randomized process to determine which blockchain node 104 will be given the opportunity to generate the next block 151. The node chosen is often called a validator. Blockchain nodes can look up their tokens over a period of time to have the opportunity to become a validator. Generally, the node that locks the largest contribution over the longest period of time has the best opportunity to become the next validator.

[0121] It should be understood that the embodiments described above are merely illustrative. More generally, methods, apparatus, or programs may be provided by any one or more of the following statements.

[0122] Statement 1. A computer-operated method for propagating a blockchain message, wherein the blockchain network comprises multiple blockchain nodes, and at least one blockchain node is associated with one or more respective ranges of numbers and one or more respective sets of blockchain nodes, and each respective range of numbers is associated with each respective set of blockchain nodes, and the method is performed by a first blockchain node. For at least one of several blockchain messages, a numerical value is determined based on that blockchain message, such that the numerical value of one or more blockchain messages falls within the respective range of one or more ranges. The system comprises making available, for each range in which each numerical value of each of the one or more blockchain messages falls, a portion or all of each blockchain message to each blockchain node belonging to each set of blockchain nodes associated with that range.

[0123] Statement 2. The method of Statement 1, wherein each respective scope is associated with each respective percentage, and the making available comprises making each respective percentage of one or more respective blockchain messages available to each blockchain node belonging to each set of blockchain nodes associated with each node.

[0124] Statement 3. The method of Statement 2, but with one or more of the respective percentages being different.

[0125] Statement 4. Any method of statements 1-3, wherein one, part, or all of the respective scopes do not overlap.

[0126] Statement 5. Any method of statements 1-3, where one, part, or all of the respective scopes overlap.

[0127] Statement 6. The method of any statement described above, wherein determining each of the numerical values ​​comprises hashing at least a portion of each blockchain message.

[0128] Statement 7. Any method of statements 1 to 5, wherein determining each numerical value comprises extracting each numerical value, for example, a transaction identifier, from the fields of each blockchain message.

[0129] Statement 8. A method of any of the preceding statements wherein each set of blockchain nodes is associated with its respective network address, and making one or more of each blockchain message available comprises sending the said part or all of each blockchain message to the respective network address associated with each set of blockchain nodes.

[0130] Statement 9. A method performed by a computer for retrieving a blockchain message, wherein the blockchain network comprises multiple blockchain nodes, each blockchain node is associated with one or more respective ranges of numbers and one or more respective sets of blockchain nodes, and each respective range of numbers is associated with each respective set of blockchain nodes, and the method is performed by a second blockchain node. Joining each network address associated with each range and each set of blockchain nodes, It includes obtaining the first blockchain message sent to each network address.

[0131] Joining may involve listening to / monitoring each network address.

[0132] Statement 10. The method of any of the statements described above, wherein one or more sets of blockchain nodes associated with each blockchain node are automatically assigned by the blockchain node.

[0133] Statement 11. One or more sets of blockchain nodes associated with each blockchain node are assigned by a third party using any of the methods described in Statements 1-6.

[0134] Statement 12. In any of the methods described in Statements 1 to 6, one or more sets of blockchain nodes associated with each blockchain node are allocated collectively by multiple of the multiple blockchain nodes.

[0135] Statement 13. A method of statement 8 or statement 9 or any statement subordinate thereto, wherein each network address is a multicast address.

[0136] Statement 14. The method of Statement 13, wherein the multicast address is an IPv6 multicast address.

[0137] Statement 15. Any of the aforementioned statements, wherein each blockchain message comprises part or all of the respective blockchain transaction.

[0138] Statement 16. Any of the aforementioned statements, wherein each blockchain message comprises part or all of the respective blockchain blocks.

[0139] Statement 17. A computer-operated method for propagating a blockchain message, wherein the blockchain network comprises multiple blockchain nodes, each blockchain node is associated with one or more respective ranges of numbers and one or more respective sets of blockchain nodes, and each respective range of numbers is associated with each respective set of blockchain nodes, and the method is performed by a first blockchain node. The respective values ​​are determined based on the first blockchain message, If the first number is within one of the ranges associated with the first blockchain node, the first blockchain message is made available to each blockchain node belonging to each set of blockchain nodes associated with the respective range.

[0140] Statement 18. A computer device comprising a memory having one or more memory units and a processing unit having one or more processing units, wherein the memory stores code configured to be executed on the processing unit, and the code is configured to execute any of the methods in Statements 1 to 17 when it is on the processing unit.

[0141] Statement 19. A computer program that is implemented on computer-readable storage and configured to perform any of the methods described in Statements 1 through 17 when executed on one or more processors.

[0142] Another embodiment disclosed herein may provide a method comprising the actions of a first blockchain node and a second blockchain node. Another embodiment disclosed herein may provide a system comprising computer equipment for the first blockchain node and the second blockchain node. [Explanation of Symbols]

[0143] 100 Systems 101 Packet-switched network 102 Computer equipment 103 Users, Parties, Agents 103a Alice 103b Bob 104 nodes, blockchain nodes, Bitcoin nodes 105 Client applications, software 106 Distributed networks, blockchain networks, node networks, peer-to-peer (P2P) networks 150 Blockchains 151 blocks, blockchain blocks 152 transactions, blockchain transactions 154 ordered sets, ordered pools 201 Header 202 Input, Input Field 203 Output, Output Fields 400 System

Claims

1. A computer-based method for propagating a blockchain message, wherein the blockchain network comprises multiple blockchain nodes, at least one blockchain node is associated with one or more respective ranges of numbers and one or more respective sets of blockchain nodes, each respective range of numbers is associated with each respective set of blockchain nodes, and the method is performed by a first blockchain node. A step of determining a numerical value for at least one of a plurality of blockchain messages based on the respective blockchain message, wherein the respective numerical value of one or more blockchain messages falls within the respective range of one or more respective ranges. A method comprising the step of making available to each blockchain node belonging to each set of blockchain nodes associated with each of the one or more blockchain messages, for each range in which the respective numerical values ​​of each blockchain message are contained.

2. The method according to claim 1, wherein each range is associated with a respective percentage, and the step of making available comprises making the respective percentage of each of the one or more blockchain messages available to each blockchain node belonging to each set of blockchain nodes associated with each of the respective nodes.

3. The method according to claim 2, wherein one or more of the aforementioned percentages are different.

4. The method according to any one of claims 1 to 3, wherein one, part, or all of the respective ranges are non-overlapping ranges.

5. The method according to any one of claims 1 to 3, wherein one, part, or all of the aforementioned ranges are overlapping ranges.

6. The method according to any one of claims 1 to 5, wherein the step of determining each of the aforementioned numerical values ​​comprises the step of hashing at least a portion of each of the aforementioned blockchain messages.

7. The method according to any one of claims 1 to 5, wherein the step of determining each of the aforementioned numerical values ​​comprises the step of extracting each of the aforementioned numerical values ​​from the fields of each of the blockchain messages.

8. The method according to any one of claims 1 to 7, wherein each set of blockchain nodes is associated with a respective network address, and the step of making one or more of each blockchain messages available comprises sending the part or all of each blockchain message to the respective network address associated with each set of blockchain nodes.

9. A computer-based method for retrieving a blockchain message, wherein the blockchain network comprises multiple blockchain nodes, each blockchain node is associated with one or more respective ranges of numbers and one or more respective sets of blockchain nodes, each respective range of numbers is associated with each respective set of blockchain nodes, and the method is performed by a second blockchain node. The steps include joining each network address associated with each range and each set of blockchain nodes, The process includes the step of obtaining a first blockchain message sent to each of the aforementioned network addresses. method.

10. The method according to any one of claims 1 to 9, wherein one or more sets of blockchain nodes associated with each blockchain node are automatically assigned by the blockchain node.

11. The method according to any one of claims 1 to 6, wherein one or more sets of blockchain nodes associated with each blockchain node are assigned by a third party.

12. The method according to any one of claims 1 to 6, wherein one or more sets of blockchain nodes associated with each blockchain node are allocated collectively by multiple of the plurality of blockchain nodes.

13. The method according to any one of the dependent claims of claim 8 or 9, wherein each of the aforementioned network addresses is a multicast address.

14. The method according to claim 13, wherein the multicast address is an IPv6 multicast address.

15. The method according to any one of claims 9 to 14, wherein all or part of each of the aforementioned blockchain messages comprises each of the aforementioned blockchain transactions.

16. The method according to any one of claims 9 to 15, wherein all or part of each of the aforementioned blockchain messages comprises each respective blockchain block.

17. A computer-based method for propagating a blockchain message, wherein the blockchain network comprises multiple blockchain nodes, each blockchain node is associated with one or more respective ranges of numbers and one or more respective sets of blockchain nodes, each respective range of numbers is associated with each respective set of blockchain nodes, and the method is performed by a first blockchain node. The first step is to determine each numerical value based on the blockchain message, A method comprising the step of making the first blockchain message available to each blockchain node belonging to each set of blockchain nodes associated with the respective range, if the first numerical value is in one of the respective ranges associated with the first blockchain node.

18. Computer equipment, A memory comprising one or more memory units, A computer device comprising a processing unit having one or more processing units, wherein the memory stores code configured to be executed on the processing unit, and the memory is configured to perform the method according to any one of claims 1 to 17 when the code is on the processing unit.

19. A computer program, which is implemented on computer-readable storage and configured to perform the method described in any one of claims 1 to 17 when executed on one or more processors.

Images