Blockchain message propagation

Abstract

1. A computer-implemented method for propagating blockchain messages, wherein a blockchain network comprises a plurality of blockchain nodes, each blockchain node being associated with a respective set of blockchain nodes, the method being performed by a first blockchain node; Making the first blockchain message available to each blockchain node belonging to a respective set of blockchain nodes associated with the first blockchain node, each set of blockchain nodes including some but not all of the plurality of blockchain nodes.

Description

[Technical Field]

[0001] The present disclosure relates to a method for propagating blockchain transactions to nodes of 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, respectively, of IP for assigning IP addresses and routing packets of data between senders and receivers over the Internet. The main difference between the two is that IPv6 comes with a wide range of IP address types, including unicast, anycast, and multicast.

[0003] The most widely adopted address type is unicast. Unicast allows a packet to be sent to a single receiver. This is usually sufficient for most client services and applications. However, two other types of addresses, multicast and anycast, are used for specialized corporate networks. Anycast allows a packet to be sent to one receiver out of a set of receivers in a single operation. This is not available in IPv4 (though it can be implemented with some workarounds), but is natively supported by IPv6. Multicast allows a packet to be sent to multiple receivers in a single operation. It is optional in IPv4 (and not widely adopted), but is natively 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 in the IP network by routers at the points where the paths diverge, so that a single packet destined for a particular group need be sent by the source host, resulting in the most efficient delivery of data to multiple receivers. A single link may transmit to one or more multicast groups, and a host may be part of multiple multicast groups. Any host, whether or not it is a member of the multicast group, can send packets to a group, but only group members receive the packets.

[0005] IP multicast is designed for applications and services that require the same data to reach many networked hosts simultaneously. Example applications include videoconferencing, corporate communications, and distribution of news, software, and stock quotes. A source host can support these applications by learning the IP addresses of N destination hosts, establishing N connections with those hosts, 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 the N destination hosts. IP multicast differs from broadcast in that packets are not sent to an entire subnetwork, but are sent to a selected group of hosts that may be in different subnetworks and be registered with the group. Another difference is that broadcast supports only one-to-many type of communication, while multicast also supports many-to-many type of communication. Any IP network that involves reducing network resource overhead for one-to-many or many-to-many data or multimedia applications with multiple receivers can benefit from multicast.

[0006] While both IPv4 and IPv6-based networks support IP multicast, this document notes that IPv4's limited address space limits the ability of IPv4 multicast to reach the growing number of Internet-connected devices. Furthermore, the common use of Network Address Translation (NAT) vehicles that convert public IPv4 addresses into private addresses makes it very difficult, if not impossible, to support some applications that use multicast connectivity. Globally unique IPv6 addresses eliminate the need for NAT boxes and simplify multicast communication between hosts. In particular, IPv6's relatively large address space reduces the likelihood that separate multicast streams from different sources will use the same group address and interfere. IPv6 multicast also more clearly defines domain control, the ability to prevent multicast leakage outside of administrative regions, 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 start with hexadecimal 0xFF to identify them as multicast addresses. Flags: Indicates how the address was allocated or whether it may contain additional information. The Internet Assigned Numbers Authority (IANA) has assigned sets of permanently assigned multicast addresses to 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 embedded. Scope: Limits the distance that multicast packets can travel. This prevents multicast packets from crossing administrative network boundaries and from traversing links and networks to which they do not belong. · Group ID: Identifies a specific multicast group address (belonging to a host interface).

[0008] Blockchain networks such as Bitcoin generally use a decentralized network of nodes to create new blocks containing transactions. These blocks and transactions are rapidly propagated throughout the network using a peer-to-peer (P2P) messaging protocol. The protocol uses a "flooding" technique that attempts to forward all new messages to all peers connected to a given node. Summary of the Invention [Problem to be solved by the invention]

[0009] The P2P messaging protocol in Bitcoin and some other blockchains ensures 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 ensures that each node attempts to forward new messages to all other nodes to which it is connected. This is inefficient because it generates a large amount of redundant network traffic.

[0010] In fact, the topology of a blockchain network is that of a highly connected graph consisting of only a few top nodes. In such networks, sometimes called "small-world" or nearly complete graphs, each node is connected to a majority of all other nodes. At the limit, the network can become saturated, with every node connected to every other node.

[0011] The high connectivity of a blockchain network introduces significant redundancy, which impacts the efficiency of P2P messaging protocols. Consider a connectivity-saturated snapshot of a blockchain network consisting of n nodes and producing blocks and transactions at an aggregate rate of m per second. The nature of P2P protocols means that each node can send at most (n-1) m messages per second, which creates an upper bound on the instantaneous aggregate 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, which corresponds to a scenario in which all new blocks and transactions are created by just one node. The ratio of the upper and lower bounds is approximately n, an order of magnitude difference even when the network contains only a handful of nodes.

[0012] This interaction between current P2P messaging protocols and the empirical topology of blockchain networks therefore creates a redundancy of up to (n-2)·n·m = (n-1)·(n·m)-(n·m) messages per second. In practice, while the lower bound is unlikely to occur (since not all blocks and transactions tend to originate from a single node), there is almost always significant redundancy between the upper worst-case network traffic and the theoretical minimum 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 would be advantageous to reduce the total instantaneous traffic in a blockchain network by modifying the P2P messaging protocol so that new block and transaction messages are not unnecessarily duplicated. [Means for solving the problem]

[0014] According to one aspect disclosed herein, a computer-implemented method for propagating a blockchain message is provided, wherein a blockchain network comprises a plurality of blockchain nodes, each blockchain node being associated with a respective set of blockchain nodes, the method being performed by a first blockchain node; Making the first blockchain message available to each blockchain node belonging to a respective set of blockchain nodes associated with the first blockchain node, each set of blockchain nodes including some but not all of the plurality of blockchain nodes.

[0015] According to one aspect disclosed herein, there is provided a computer-implemented method for obtaining a blockchain message, wherein a blockchain network comprises a plurality of blockchain nodes, the method being performed by a second blockchain node: subscribing to respective network addresses associated with a respective set of blockchain nodes; and obtaining a first blockchain message sent to each network address.

[0016] Embodiments of the present disclosure offer several advantages over existing "flooding" approaches that forward all messages to all nodes. For example, embodiments improve the efficiency of blockchain P2P protocols and reduce redundant or repeated network traffic. Embodiments also allow for hierarchy in node networks based on capabilities, meaning that some nodes may choose to shoulder more of the propagation burden than others.

[0017] The embodiments disclosed herein allow network traffic to be "shared," or 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 transactions appear in blocks and their associated Merkle trees.

[0018] Overlaps in segmented traffic may also be introduced using the described embodiments to build resilience when forwarding data to many parties. These overlaps represent a compromise between redundancy and resilience in data propagation, whereby redundancy is still minimized relative to existing messaging protocols. In effect, a single large message, e.g., a block of many transactions, or a large transaction, e.g., many packets, can be more efficiently propagated to the receiver by using these overlaps in the segmentation. This divides the load of propagating traffic among multiple senders, thereby increasing the resilience of the propagation mechanism to failures of a subset of senders, since connection disruptions or packet failures are mitigated by the overlaps between different traffic segments. In other words, some embodiments create "virtual" propagation connections between each receiver and multiple senders that are more robust than each individual sender-receiver connection in the network. This is similar to a RAID (Redundant Array of Inexpensive Disks) system in a virtualized data storage system.

[0019] A feature of the Bitcoin network, as stated in the Bitcoin white paper, is that "new transactions are broadcast to all nodes." Embodiments of the present disclosure achieve this same goal and are therefore compatible with the original Bitcoin protocol, but with minimal redundancy in message propagation.

[0020] To assist in understanding 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: [Brief explanation of the drawings]

[0021] [Figure 1] FIG. 1 is a schematic block diagram of a system for implementing a blockchain. [Figure 2] FIG. 1 illustrates schematically some examples of transactions that may be recorded on a blockchain. [Figure 3] 1 is a diagram illustrating a basic format of an IPv6 multicast address. [Figure 4] FIG. 1 illustrates a schematic diagram of an exemplary system for propagating messages. DETAILED DESCRIPTION OF THE INVENTION

[0022] 1. Blockchain message propagation An exemplary system for implementing embodiments of the present disclosure is shown in FIG. 4. The system 400 includes multiple blockchain nodes 104. While only four nodes 104 are shown (nodes 104a-d), in general, the system 400 may include any number, e.g., all, of the blockchain nodes 104 in the 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 nodes 104 the message should be propagated. 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 the entire block, i.e., the block header and corresponding transaction set, or only the block header.

[0023] Propagating a message to a node 104 may include sending the message directly to the node 104. Propagating a message to a node 104 may include sending the message to a network address (e.g., an IPv4 or IPv6 address) associated with the node 104. Propagating a message to a node 104 may include sending the message to a network address (e.g., an IPv6 multicast address) to which the node 104 is subscribed. It will be appreciated that "sending a message to a network address" may be interpreted to mean sending a message (e.g., to a router) where the message is addressed to a network address.

[0024] The first node 104a obtains a first message. The first message may be received from a different node 104 or from the user 103. In some examples, the first message may be generated, at least in part, by the first node 104a. For example, the first message may include a block header generated by the first node 104a based on a set of validating transactions available to the first node 104a, e.g., stored in its mempool.

[0025] In some embodiments, a first node 104a is associated with a first number range. In general, the first number range may start and end at any number and be of any size. The first number range may be chosen by the first node 104a, by a different node 104, or by a third party. In some examples, some (e.g., all) nodes 104 in the blockchain network 106 determine the first number range. Each node 104 may be associated with a unique number range. Some of the number ranges may overlap. Some of the number ranges may not overlap.

[0026] The first node 104a may determine 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, e.g., by generating the first number based on the hash result or by selecting one or more digits of the hash result (such as the first non-zero digit or the last 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 particular 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 or last digits of the transaction identifier.

[0027] If the first number determined based on the first message is within a 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 one or more second nodes 104. That is, the first node 104a forwards the first message only if the first number is within the number range assigned to the first node 104a.

[0028] As described above, propagating the first message may involve sending the first message to one or more second nodes 104. Alternatively, as shown in FIG. 4, propagating the first message may involve sending the first message to a first network address associated with the first number range (e.g., “Network Address A”). One or more second nodes 104 may listen to (e.g., subscribe to) 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 a message sent to the first network address may be forwarded to nodes 104 that are subscribed to the first network address.

[0029] Each number range may be associated with a respective network address. Each node 104 may determine the number based on the message it receives and only need to propagate the message if the number is within the range assigned to that node. Here, propagating 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.

[0030] 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 every node 104. The first set of nodes (particular nodes 104 and / or some nodes 104) may be chosen by the first node 104a, by different nodes 104, or by a third party. In some examples, some (e.g., all) nodes 104 in the blockchain network 106 determine the first set of nodes 104. Each node 104 may be associated with a unique set of other nodes 104. Some of the sets may overlap. Some of the sets may not overlap.

[0031] It should be noted that as used throughout this disclosure, the term "set" may be construed to mean one or more.

[0032] 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 nodes 104 that do 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.

[0033] As described above, propagating the first message may involve sending the first message to one or more second nodes 104. Alternatively, as shown in FIG. 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., subscribe to) 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 a message sent to the first network address may be forwarded to nodes 104 that are subscribed to the first network address.

[0034] Each set of nodes 104 may be associated with a respective network address. Each node 104 need only propagate messages to the set of nodes 104 assigned to that node 104, where propagating 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.

[0035] In other embodiments, the first node 104a is associated with both the first number range and the first set of nodes 104. Similar to the embodiment described above, the first node 104a may 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.

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

[0037] As in the above-described embodiments, each respective number range may start and end at any number and be of any size. One or more of the respective number ranges may overlap. One or more of the respective number ranges may not overlap. One or more of the respective number ranges may be chosen 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 respective number ranges.

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

[0039] For each message that the first node 104a obtains (e.g., receives or generates), the first node 104a determines a respective number for that message. The first node 104a may determine the respective numbers using any of the techniques described above, for example, by hashing a portion of all of the messages. If the respective numbers are within one of the respective number ranges, the first node 104a may propagate the respective message to a respective set of nodes 104 linked to the respective number range.

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

[0041] As in the above-described embodiment, propagating each message may involve sending each message to one or more second nodes 104 belonging to each set. Alternatively, as shown in FIG. 4, propagating each message may involve sending each message to a respective network address associated with each set of nodes 104. For example, as shown in FIG. 4, a message may be sent to network address A to which nodes 104b and 104c are subscribed, i.e., listening for or without messages, and a different message may be sent to network address B to which nodes 104c and 104d are subscribed. Each second node 104 may listen for (e.g., subscribe to) one or more network addresses for blockchain messages.

[0042] 1.1 Specific examples As discussed, the described embodiments reduce the total instantaneous traffic in the blockchain network 106 by modifying the P2P messaging protocol so that new block and transaction messages are not unnecessarily duplicated. Specific examples of the described embodiments are now discussed. The following features summarize these examples: Every data message (i.e., block, transaction) is sent from the source node 104 to a multicast address. Nodes 104 selectively send data messages depending on policy rules. A node's policy rules determine whether a node 104 sends a given message or to which node 104 a given message is sent and are based on: (i) the content of the data message; or (ii) a group of nodes currently in the network, or ○(iii) Both.

[0043] Note that when a node 104 itself discovers a new block, there may be some exceptional messages that may be excluded from this new logic.

[0044] 1.1.1 Example Policy 1 - Content-Based Message Propagation In this example, the P2P protocol is modified so that nodes 104 are assigned a range of numeric values ​​that they are responsible for forwarding messages to. Because 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 propagate only messages whose numeric values ​​are within the node's assigned range.

[0045] The logic for selectively propagating data messages in the new P2P protocol is as follows. 0. Node A is a numeric range

number

[0046] Notes about this protocol variant: The range R may be self-assigned (e.g., chosen randomly) to a node 104 when it joins the network. Alternatively, it may be assigned by a third-party service provider that monitors which nodes are responsible for which ranges at a given time. Alternatively, the nodes 104 may communicate cooperatively to assign ranges together, continuously and dynamically, to ensure that the entire range is always covered. There may be overlap in the ranges covered by different nodes 104. Minimizing overlap minimizes redundancy in message propagation. - This range IP R The multicast IP address corresponding to may be subscribed to by any network node 104. If there is no overlap in the ranges, preferably all nodes 104 will subscribe to this address to ensure that all receive all data messages. If there is overlap, nodes 104 that are sources for a given range do not need to subscribe, minimizing redundant traffic. In this P2P protocol, a node 104 preferably subscribes to any scope-specific multicast address for which the node 104 is not a source.

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

[0048] The logic for selectively propagating data messages in the new P2P protocol is as follows. 0. Node A is in the receiving node range.

number

number

number

[0049] Notes about this protocol variant: Selectivity in this variant affects the choice of which nodes 104 to forward messages to and which messages not to propagate. - As in protocol variant 1, the group assigned to node 104

number

[0050] 1.1.3 Protocol Variant 3 - Combination An alternative is to modify the P2P messaging protocol using a combination of variants 1 and 2 so that messages (i) may be selectively selected for propagation and (ii) if selected, are propagated only to a selected group of nodes 104.

[0051] For example, for a given node A, it is possible to establish a modified version of the P2P protocol that implements the following set of rules: 1.A is in the range [v L ,v U] to group all messages in

number

number

number

[0052] Such logic increases network consistency and resilience to failures at the expense of a corresponding increase in redundancy, the very low redundancy that current P2P protocols allow. Such an approach also fine-tunes the degree of redundancy by selecting the size of each range and the size of each group as parameters, and by reflecting the diversity in node capabilities on the network in the respective values ​​chosen for these parameters by each node 104.

[0053] 1.1.4 Exception There may be exceptions to the P2P logic variants listed above, such as new blocks generated by a node 104 that should be widely broadcast throughout the network by that node 104 as quickly as possible.

[0054] To account for such cases, a message-specific multicast address can be created to which other nodes 104 subscribe. i But, A i The specific address corresponding to the new block to be created by

number

number

number

[0055] 2. Example System Overview A blockchain refers to a form of distributed data structure in which a copy of the blockchain is maintained and publicly published at each of multiple nodes in a distributed peer-to-peer (P2P) network (hereinafter referred to as the "blockchain network"). A blockchain includes a chain of blocks of data, each containing one or more transactions. Each transaction, other than so-called "coinbase transactions," points back to a previous transaction in a sequence that may span one or more blocks, leading back to one or more coinbase transactions. Coinbase transactions are discussed further below. Transactions submitted to a blockchain network are included in new blocks. New blocks are created by a process often called "mining," which involves multiple nodes each competing to perform "proof of work," i.e., solving a cryptographic puzzle based on a representation of a defined set of ordered, validated, pending transactions awaiting inclusion in a new block of the blockchain. Note that a blockchain may be pruned at some nodes, and block publication can be accomplished through the publication of a few block headers.

[0056] Transactions in a blockchain may be used for one or more of the following purposes: to convey digital assets (i.e., numbers of digital tokens), to order a set of entries in a virtualized ledger or registry, to receive and process timestamp entries, and / or to order index pointers chronologically. Blockchains can also be leveraged to layer additional functionality on top of the blockchain. For example, blockchain protocols allow for the storage of additional user data or indexes to data in transactions. There is no pre-specified limit on the maximum amount of data that can be stored within a single transaction, and therefore increasingly more complex data can be incorporated. For example, this may be used to store electronic documents, or audio or video data in the blockchain.

[0057] In an “output-based” model (sometimes called a UTXO-based model), the data structure of a given transaction includes one or more inputs and one or more outputs. Every spendable output includes an element specifying the amount of a digital asset derivable from the transaction's procedural sequence. A spendable output is sometimes called a UTXO (unspent transaction output). This output may further include a locking script that specifies the conditions for the output's future redemption. A locking script is a predicate that defines the conditions required to activate and transfer a digital token or asset. Each input of a transaction (other than a coinbase transaction) includes a pointer (i.e., a reference) to such output in a prior transaction and may further include an unlocking script to unlock the locking script of the pointed-to output. Thus, consider a pair of transactions, referred to as the first and second transactions (or “target” transactions). The first transaction includes at least one output that specifies the amount of a digital asset and includes a locking script that defines one or more conditions for unlocking the output. The second, target transaction includes at least one input that includes a pointer to the output of the first transaction and an unlock script for unlocking the output of the first transaction.

[0058] In such a model, when the second, target transaction is sent to the blockchain network to be propagated and recorded on the blockchain, one of the validity criteria applied at each node is that the unlocking script meets all of one or more conditions defined in the locking script of the first transaction. Another is that the output of the first transaction has not yet 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 potentially to mark it as an invalid transaction) or include it in a new block to be recorded on the blockchain.

[0059] An alternative type of transaction model is the account-based model, where each transaction defines the amount to be transferred not by referencing the UTXO of a previous transaction in a sequence of past transactions, but rather by reference to an absolute account balance. The current state of all accounts is stored and frequently updated by nodes separate from the blockchain.

[0060] 1 illustrates an exemplary system 100 for implementing a blockchain 150. The system 100 may comprise a packet-switched network 101, typically a wide-area internetwork such as the Internet. The packet-switched network 101 comprises a plurality of blockchain nodes 104 (often referred to as "miners") that may be arranged to form a peer-to-peer (P2P) network 106 within the packet-switched network 101. Although not shown, the blockchain nodes 104 may be arranged as a nearly complete graph. Each blockchain node 104 is therefore highly connected to other blockchain nodes 104.

[0061] Each blockchain node 104 comprises a peer's computing equipment, with various of the nodes 104 belonging to different peers. Each blockchain node 104 comprises one or more processors, e.g., processing units comprising one or more central processing units (CPUs), accelerator processors, application-specific processors, and / or field-programmable gate arrays (FPGAs), as well as other devices such as application-specific integrated circuits (ASICs). Each node also comprises memory, i.e., computer-readable storage, in the form of one or more non-transitory computer-readable media. The memory may comprise one or more memory units utilizing one or more memory media, e.g., magnetic media such as hard disks, electronic media such as solid-state drives (SSDs), flash memory, or EEPROMs, and / or optical media such as optical disk drives.

[0062] A blockchain 150 includes a chain of blocks of data 151, with a respective copy of the blockchain 150 maintained at each of multiple blockchain nodes 104 in a distributed or blockchain network 106. As mentioned above, maintaining a copy of the blockchain 150 does not necessarily mean storing the entire blockchain 150. Instead, the blockchain 150 can be pruned so long as each blockchain node 150 stores the block header (discussed later) of each block 151. Each block 151 in the chain includes one or more transactions 152, where a transaction in this context refers to a certain data structure. The nature of the data structure depends on the type of transaction protocol used as part of the transaction model or scheme. A given blockchain consistently uses one particular transaction protocol.

[0063] A blockchain node 104 may be configured to forward transactions 152 to other blockchain nodes 104, thereby propagating the transactions 152 through the network 106. Blockchain nodes 104 may be configured to create blocks 151 and store respective copies of the same blockchain 150 in their respective memories. Blockchain nodes 104 may also maintain an ordered set (or "pool") 154 of transactions 152 waiting to be incorporated into a block 151. The ordered pool 154 is often referred to as a "mempool." This term herein is not intended to be limited to any particular blockchain, protocol, or model. It refers to an ordered set of transactions that the node 104 has accepted as valid and that the node 104 is obligated not to accept any other transactions that attempt to spend the same output.

[0064] For a given current transaction 152j, the (or each) input contains a pointer that references the output of a previous transaction 152i in the sequence of transactions, specifying that this output must be redeemed or "spent" in the current transaction 152j. Spending or redemption does not necessarily imply the transfer of a financial asset, although that is certainly one common application. More generally, spending may be described as consuming an output or allocating it to one or more outputs in another, forward transaction. In general, a previous transaction may be any transaction in the ordered set 154 or any block 151. While a previous transaction 152i does not necessarily need to exist when a current transaction 152j is created or sent to the network 106, a previous transaction 152i must exist and be valid for the current transaction to be valid. Thus, "predecessor" herein refers to a predecessor in a logical sequence, linked by a pointer, not necessarily to a time of creation or delivery in a time sequence, and thus does not necessarily preclude transactions 152i, 152j from being created or delivered out of order (see the discussion below regarding orphan transactions). A predecessor transaction 152i may also be referred to as an ancestor or predecessor transaction.

[0065] Due to the resources involved in transaction validation and publishing, at least each of the blockchain nodes 104 will typically take the form of a server comprising one or more physical server units, or even an entire data center, although in principle any given blockchain node 104 may also take the form of a user terminal or a group of user terminals networked with each other.

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

[0067] 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 enforcing agreement (e.g., proof of work) / mining. In some examples, each type of operation is performed by a different node 104. That is, a node may specialize in a particular operation. For example, a node 104 may focus on transaction validation and propagation or on block mining. In some examples, a blockchain node 104 may perform more than one of these operations in parallel. Any reference to a blockchain node 104 may refer to an entity configured to perform at least one of these operations.

[0068] Also connected to the network 101 are computing devices 102 for each of a number of parties 103 in the role of consuming users. These users may interact with the blockchain network 106 but do not participate in validating transactions or constructing 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 storage entities that store a copy of the blockchain 150 (e.g., have obtained a copy of the blockchain from a blockchain node 104).

[0069] Some or all of the parties 103 may be connected as part of a different network, for example, a network overlaid on the blockchain network 106. Users of the blockchain network (often called “clients”) may be said to be part of a system that includes the blockchain network 106, but these users are not blockchain nodes 104 because they do not perform the roles required of blockchain nodes. Instead, each party 103 may use the blockchain 150 by interacting with the blockchain network 106 and, by doing so, connecting to (i.e., communicating with) a blockchain node 106. Two parties 103 and their respective devices 102 are shown for illustrative purposes: a first party 103a and its respective computer device 102a, and a second party 103b and its respective computer device 102b. It will be understood that more such parties 103 and their respective computer devices 102 may be present and participating in the system 100, but for convenience, they are not shown. Each party 103 may be an individual or an organization. Purely by way of example, first party 103a is referred to herein as Alice and second party 103b is referred to as Bob, but it will be appreciated that this is not limiting and any reference herein to Alice or Bob may be replaced with "first party" and "second party," respectively.

[0070] The computing equipment 102 of each party 103 includes a respective processing unit comprising one or more processors, e.g., one or more CPUs, GPUs, other accelerator processors, special-purpose processors, and / or FPGAs. The computing equipment 102 of each party 103 further includes memory, i.e., computer-readable storage, in the form of one or more non-transitory computer-readable media. This memory may include one or more memory units utilizing one or more memory media, e.g., magnetic media such as hard disks, electronic media such as SSDs, flash memory, or EEPROMs, and / or optical media such as optical disk drives. The memory on the computing equipment 102 of each party 103 stores software including a respective instance of at least one client application 105 arranged to run on the processing unit. It will be understood that any action attributed to a given party 103 herein may be implemented using software running on the processing unit of the respective computing equipment 102. The computing equipment 102 of each party 103 includes at least one user terminal, e.g., a desktop or laptop computer, a tablet, a smartphone, or a wearable device such as a smartwatch. The computing equipment 102 of a given party 103 may also include one or more other network-connected resources, such as cloud computing resources accessed via a user terminal.

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

[0072] The client application 105 includes at least a "wallet" function. This has two main functionalities. One of these is to allow each party 103 to create, authorize (e.g., sign), and send transactions 152 to one or more Bitcoin nodes 104, which are then propagated throughout the network of blockchain nodes 104 and thereby included in the blockchain 150. The other function is to report back to each party on the amount of digital assets it currently owns. In an output-based system, this second functionality involves reconciling the amounts defined in the outputs of the various 152 transactions scattered throughout the blockchain 150 that belong to the party in question.

[0073] Note: Although various client functionalities may be described as being integrated into a given, not necessarily limiting, client application 105, any client functionality described herein may instead be implemented in a series of two or more separate applications that interface, for example, by an API or one that is a plug-in to the other. More generally, client functionality may be implemented in the application layer or a lower layer, such as an operating system, or any combination thereof. While the following is described with respect to client application 105, it will be appreciated that this is not limiting.

[0074] An instance of a client application or software 105 on each computing device 102 is operably coupled to at least one of the blockchain nodes 104 of the network 106. This enables a wallet function on 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 (or indeed, to examine other parties' transactions in the blockchain 150, since in some embodiments, the blockchain 150 is a public facility that grants trust to transactions, in part due to public recognition) for any transactions in which the respective party 103 is a recipient. The wallet function on each computing device 102 is configured to formulate and send transactions 152 according to a transaction protocol. As noted above, each blockchain node 104 runs software configured to validate transactions 152 according to the blockchain node protocol and to forward transactions 152 for propagation through the blockchain network 106. The transaction protocol and the node protocol correspond to each other, and a given transaction protocol is synchronized with a given node protocol, and together they implement a given transaction model. The same transaction protocol is used for all transactions 152 in the blockchain 150. The same node protocol is used by all nodes 104 in the network 106.

[0075] An alternative type of transaction protocol operated by some blockchain networks may be called an "account-based" protocol, as part of the account-based transaction model. In the account-based case, each transaction does not define the amount to be transferred by referencing the UTXO of a previous transaction in a sequence of past transactions, but rather by reference to an absolute account balance. The current state of all accounts is stored and frequently updated by the network's nodes, separate from the blockchain. In such a system, transactions are ordered using a running transaction tally of the account (also called a "position" or "nonce"). This value is signed by the sender as part of its cryptographic signature and hashed as part of the transaction reference calculation. Additionally, an optional data field may also be signed with the transaction. This data field may point back to a previous transaction, for example, if a previous transaction ID is included in the data field.

[0076] Some account-based transaction models share some similarities with the output-based transaction model described herein. For example, as described above, data fields in an account-based transaction may point back to a previous transaction, which is equivalent to an input in an output-based transaction referencing an outpoint, a previous transaction. Thus, both models allow for linking 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 a digital asset may be specified). The recipient and value fields together are equivalent to an output in an output-based transaction, which can be used to assign the amount of a digital asset to a blockchain address. Similarly, an account-based transaction has a "signature" field that contains a signature for the transaction. The signature is generated using the sender's private key and verifies that the sender authorized the transaction. This is equivalent to the input / unlock script of an output-based transaction, which generally includes a signature for the transaction. 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. In an account-based blockchain, a "smart contract" refers to a transaction that includes a script configured to perform one or more actions (e.g., send or "release" digital assets to a receiving address) in response to one or more inputs (provided by a transaction) that meet one or more conditions defined by the smart contact's script. Smart contracts exist as transactions in the blockchain and can be invoked (or triggered) by subsequent transactions.Thus, in some examples, a smart contract may be considered equivalent to a locking script for an output-based transaction, which can be triggered by a subsequent transaction and checks whether one or more conditions defined by the locking script are met by the inputs of the subsequent transaction.

[0077] 3. UTXO-based model Figure 2 illustrates an exemplary transaction protocol. This is an example of a UTXO-based protocol. A transaction 152 (abbreviated as "Tx") is a fundamental data structure of a blockchain 150 (each block 151 contains one or more transactions 152). The following is described with reference to an output-based or "UTXO"-based protocol, although this is not limiting for all possible embodiments. Note that the exemplary UTXO-based protocol is described with reference to Bitcoin, but may be similarly implemented on other exemplary blockchain networks.

[0078] In a 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 for input 202 of another new transaction (if the UTXO has not yet been redeemed). A UTXO includes a value that specifies an amount of a digital asset, which represents a set number of tokens in a distributed ledger. A UTXO may also include, among other information, the transaction ID of the transaction from which the UTXO originated. The transaction data structure may also include a header 201, which may include indicators of the sizes of the input fields 202 and output fields 203. The header 201 may also include the transaction's ID. In some 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 the node 104.

[0079] For example, Alice 103a wishes to create transaction 152j that transfers a certain amount of the digital asset in question to Bob 103b. In FIG. 2, Alice's new transaction 152j is labeled "Tx1." It takes a certain amount of the digital asset locked to Alice in the output 203 of the previous transaction 152i in the sequence and transfers at least a portion of it to Bob. The previous transaction 152i is labeled "Tx0" in FIG. 2. Tx0 and Tx1 are simply arbitrary labels. They do not necessarily imply that Tx0 is the first transaction in the blockchain 151 or that Tx1 is the immediate next transaction in the pool 154. Tx1 may point back to any previous (i.e., ancestor) transaction that still has unspent output 203 locked to Alice.

[0080] The terms “predecessor” and “successor,” as used herein in the context of a sequence of transactions, refer to the order of transactions in the sequence (e.g., which transaction points back to which other transaction), as defined by the transaction pointers specified in the transaction. These may be equivalently replaced with “predecessor” and “successor,” or “ancestor” and “descendant,” “parent” and “child,” etc. They do not necessarily imply the order in which they are created, sent to the network 106, or arrive at any given blockchain node 104. Nevertheless, a subsequent transaction (descendant transaction or “child”) that points to a predecessor transaction (ancestor transaction or “parent”) will not be validated until and unless the parent transaction is validated. A child that arrives at the blockchain node 104 before its parent is considered an orphan. Orphans may be discarded or buffered for a period of time to wait for their parent, depending on the node protocol and / or node behavior.

[0081] One of the one or more outputs 203 of the preceding transaction Tx0 includes a particular UTXO, here labeled UTXO 0. Each UTXO includes a value that specifies the amount of the digital asset represented by the UTXO and a locking script that defines the conditions that must be met by the unlocking script in the input 202 of the subsequent transaction for the subsequent transaction to be valid, and therefore for the redemption of the UTXO to be successful.

[0082] A 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 such a language is called "Script" (capital S) used by blockchain networks. A locking script specifies what information is needed to spend the transaction output 203, for example, Alice's signature is needed. The locking script appears in the transaction's output. An unlocking script (also known as scriptSig) is a piece of code written in a domain-specific language that provides the information needed to satisfy the locking script criteria. For example, the script might include Bob's signature. The unlocking script appears in the transaction's input 202.

[0083] Thus, in the illustrated example, UTXO0 in Tx0's output 203 must have Alice's signature Sig P in order for UTXO0 to be redeemed (or, more precisely, for subsequent transactions attempting to redeem UTXO0 to be valid). A Locking script [Checksig P A ]. [Checksig P A ] is the public key P from Alice's public-private key pair. A , a representation (i.e., a hash) of Tx1's transaction ID. Tx1's input 202 includes a pointer that points back to Tx1 (e.g., using its transaction ID, i.e., TxID0, which in some embodiments is a hash of all transaction Tx0). Tx1's input 202 includes an index that identifies UTXO0 within Tx0, among any other possible outputs of Tx0. Tx1's input 202 includes an unlock script created by Alice that applies Alice's private key from a key pair to a predefined portion of data (sometimes called a "message" in cryptography), including Alice's cryptographic signature. <Sig P AThe data (or "message") that needs to be signed by Alice to give a valid signature may be defined by the locking script, or by the node protocol, or a combination of these.

[0084] When new transaction Tx1 arrives at 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 meets the conditions defined in the locking script (which may include one or more criteria).

[0085] Note that script code is often expressed generally (i.e., without using a precise language). For example, an operation code (opcode) may be used to represent a particular function. "OP_..." refers to a particular opcode in a scripting language. As an example, OP_RETURN is an opcode in a scripting language that, when preceded by OP_FALSE at the beginning of a locking script, stores data within the transaction, thereby creating an unspendable output of the transaction that can still be recorded on the blockchain 150. For example, the data may include a document that is desired to be stored on the blockchain.

[0086] In general, the input for a transaction is a public key P A In some embodiments, this is based on ECDSA using the elliptic curve secp256k1. The digital signature signs one specific piece of data. In some embodiments, for a given transaction, the signature signs some of the transaction inputs and some or all of the transaction outputs. The specific parts of the outputs it signs depend on the SIGHASH flag, which is typically a four-byte code included at the end of the signature (and therefore determined at the time of signing) that selects which outputs are signed.

[0087] A locking script is sometimes referred to as a "scriptPubKey" in reference to the fact that it generally includes the public key of the party whose respective transaction is locked. An unlocking script is sometimes referred to as a "scriptSig" in reference to the fact that it provides the corresponding signature. However, more generally, it is not essential in all applications of blockchain 150 that the condition for a UTXO to be redeemed include authenticating the signature. More generally, a scripting language may also be used to define any condition or conditions. Therefore, the more general terms "locking script" and "unlocking script" may be preferred.

[0088] 4. Further findings Given the disclosure herein, other variations or use cases of the disclosed techniques may become apparent to those of ordinary skill in the art. The scope of the present disclosure is limited only by the appended claims, and not by the described embodiments.

[0089] For example, some embodiments above are described with reference to the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin nodes 104. However, it will be appreciated that the Bitcoin blockchain is one specific example of a blockchain 150, and the above description may apply generally to any blockchain. That is, the present invention is not limited to the Bitcoin blockchain in any way. More generally, any references above to the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin nodes 104 may be replaced with reference to the blockchain network 106, the blockchain 150, and the blockchain nodes 104, respectively. The blockchains, blockchain networks, and / or blockchain nodes may share some or all of the described properties of the Bitcoin blockchain 150, the Bitcoin network 106, and the Bitcoin nodes 104, as described above.

[0090] In a preferred embodiment of the present invention, the blockchain network 106 is the Bitcoin network, and the Bitcoin nodes 104 perform all of the described functions of at least creating, publishing, propagating, and storing blocks 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, but not all, of these functions. That is, network entities may perform the functions of creating blocks and propagating and / or storing blocks without publishing them (recall that these entities are not considered to be nodes of the preferred Bitcoin network 106).

[0091] In other embodiments of the present invention, the 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 the blockchain 150. For example, on these other blockchain networks, a "node" may be used to refer to a network entity that is configured to create and publish blocks 151 but not store and / or propagate those blocks 151 to other nodes.

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

[0093] Some embodiments have been described with respect to blockchain networks that implement a proof-of-work agreement mechanism to secure the underlying blockchain. However, proof-of-work is just one type of agreement mechanism, and in general, embodiments may use any type of appropriate agreement mechanism, such as proof-of-stake, delegated proof-of-stake, proof-of-capacity, or age proof. As a specific example, proof-of-stake uses a randomization process to determine which blockchain node 104 is given the opportunity to produce the next block 151. The selected node is often called the validator. Blockchain nodes can lock up their tokens for a certain period of time to have the opportunity to become the validator. In general, the node that locks up the greatest stake for the longest period of time has the best chance of becoming the next validator.

[0094] It will be appreciated that the above embodiments have been described for illustrative purposes only. More generally, there may be provided a method, apparatus or program according to any one or more of the following statements:

[0095] STATEMENT 1. A computer-implemented method for propagating blockchain messages, wherein a blockchain network comprises a plurality of blockchain nodes, each blockchain node being associated with a respective set of blockchain nodes, the method being performed by a first blockchain node; 1. A method comprising: making a first blockchain message available to each blockchain node belonging to a respective set of blockchain nodes associated with the first blockchain node, the respective set of blockchain nodes including some but not all of the plurality of blockchain nodes.

[0096] The method includes not making the first blockchain message available to blockchain nodes belonging to a respective set of blockchain nodes that are not associated with the first blockchain node.

[0097] Statement 2. The method of statement 1, wherein each respective set of blockchain nodes is associated with a respective network address, and wherein the step of making the first blockchain message available to each blockchain node belonging to the respective set of blockchain nodes associated with the first blockchain node includes the step of sending the first blockchain message to the respective network address associated with the respective set of blockchain nodes.

[0098] Statement 3. A computer-implemented method for obtaining a blockchain message, wherein the blockchain network comprises a plurality of blockchain nodes, the method being performed by a second blockchain node; subscribing to respective network addresses associated with a respective set of blockchain nodes; and obtaining a first blockchain message sent to each network address.

[0099] The subscribing step may include listening / monitoring the respective network address.

[0100] Statement 4. The method of any one of statements 1 to 3, wherein each set of blockchain nodes associated with each blockchain node is self-assigned by the blockchain node.

[0101] Statement 5. The method of any one of statements 1 to 4, wherein each set of blockchain nodes associated with each blockchain node is assigned by a third party.

[0102] Statement 6. The method of any one of statements 1 to 5, wherein each set of blockchain nodes associated with each blockchain node is collectively assigned by more than one of the plurality of blockchain nodes.

[0103] Statement 7. The method of statement 2 or statement 3, or any statement dependent thereon, wherein each network address is a multicast address.

[0104] Statement 8. The method of statement 7, wherein the multicast address is an IPv6 multicast address.

[0105] Statement 9. The method of any one of statements 1 to 8, wherein the first blockchain message includes a blockchain transaction.

[0106] Statement 10. The method of any one of statements 1 to 9, wherein the first blockchain message includes a blockchain block.

[0107] Statement 11. a memory comprising one or more memory units; 11. A computing device comprising: a processing unit having one or more processing units; and a memory storing code arranged to run on the processing unit, the code configured, when on the processing unit, to perform a method according to any one of statements 1 to 10.

[0108] Statement 12. A computer program product embodied on computer-readable storage and configured, when run on one or more processors, to perform the method of any of statements 1 to 10.

[0109] According to another aspect disclosed herein, a method may be provided that includes actions of a first blockchain node and a second blockchain node. According to another aspect disclosed herein, a system may be provided that includes computer devices of a first blockchain node and a second blockchain node. [Explanation of symbols]

[0110] 100 systems 101 Packet Switched Networks, Networks 102 Computer equipment and devices 104 Blockchain Nodes, Nodes, Source Nodes, Bitcoin Nodes 106 Blockchain Network, Peer-to-Peer (P2P) Network, Network 150 Blockchain 400 System

Claims

1. 1. A computer-implemented method for propagating blockchain messages, wherein a blockchain network comprises a plurality of blockchain nodes, each blockchain node being associated with a respective set of blockchain nodes, the method being performed by a first blockchain node; making a first blockchain message available to each blockchain node belonging to a respective set of blockchain nodes associated with the first blockchain node, the respective set of blockchain nodes including some but not all of the plurality of blockchain nodes.

2. 2. The method of claim 1, wherein each respective set of blockchain nodes is associated with a respective network address, and wherein making the first blockchain message available to each blockchain node belonging to the respective set of blockchain nodes associated with the first blockchain node comprises sending the first blockchain message to the respective network address associated with the respective set of blockchain nodes.

3. 1. A computer-implemented method for obtaining a blockchain message, wherein a blockchain network comprises a plurality of blockchain nodes, the method being performed by a second blockchain node; subscribing to respective network addresses associated with a respective set of blockchain nodes; and obtaining a first blockchain message sent to the respective network address.

4. 4. The method of claim 1, wherein the respective set of blockchain nodes associated with each blockchain node is self-assigned by the blockchain node.

5. The method of claim 1 , wherein each set of blockchain nodes associated with each blockchain node is assigned by a third party.

6. 6. The method of claim 1, wherein each set of blockchain nodes associated with each blockchain node is collectively assigned by more than one of the plurality of blockchain nodes.

7. 4. A method according to claim 2 or claim 3 or any claim dependent thereon, wherein each said network address is a multicast address.

8. The method of claim 7 , wherein the multicast address is an IPv6 multicast address.

9. 9. The method of claim 1, wherein the first blockchain message comprises a blockchain transaction.

10. 10. The method of claim 1, wherein the first blockchain message comprises a blockchain block.

11. a memory comprising one or more memory units; 11. A computing device comprising: a processing device having one or more processing units; and the memory storing code arranged to run on the processing device, the code configured, when on the processing device, to perform the method of any one of claims 1 to 10.

12. 11. A computer program embodied on a computer readable storage and configured to, when run on one or more processors, perform the method of any one of claims 1 to 10.

Images