Method and system for improving blockchain network communication

Abstract

A computer-implemented data distribution method is disclosed. The method includes transmitting a portion of data from a transmit resource on a network to one or more groups of receive resources, each group of the one or more groups being associated with a respective multicast address. Preferably, the data part comprises block chain related data. Also disclosed is a computer device comprising: a memory comprising one or more memory cells; and a processing device comprising one or more processing units, in which the memory stores code set to run on the processing device, the code configured to perform the method when running on the processing device. A computer program included on a computer readable memory and configured to perform the method when running on one or more processors is also disclosed.

Description

Technical Field

[0001] Embodiments disclosed herein relate to improvements in transmitting data over a computer-implemented network. Embodiments are particularly applicable, but not limited to, transmitting blockchain-related data between parties wishing to receive, process, and / or store such data. Background Art

[0002] Devices on the Internet are assigned unique identifiers (addresses) that allow other devices to identify and locate these devices on the network. When the initial IP protocol was built, it was expected that the number of IP addresses that could be generated from a 32-bit address block would be sufficient to uniquely identify all devices that would be connected to the Internet. However, when the initial IP protocol was designed, it was not expected that the Internet would have such great private and commercial appeal, nor was it expected that a large number of various devices would attempt to connect to the Internet. Therefore, as personal computing and mobile computing technology developed over time, the 4.3 billion addresses that IPv4 could provide were clearly not enough.

[0003] While the threat of IPv4 address exhaustion has led to some creative approaches to mitigate a limited set of IPv4 addresses (e.g., Classless Inter-Domain Routing (CIPR), Unnumbered Interfaces, and Network Address Translation), these measures are not sufficient to address the problem. The advent of the Internet of Things (IoT) further exacerbates the limitations of IPv4 in both the short and long term.

[0004] Due to these challenges, IPv6 was proposed as a replacement for the IPv4 address standard. The core of IPv6 is the use of 128-bit addresses, which can theoretically generate 3.4×10 38 addresses. While several ranges of the key space are pre-designated for specific purposes, the remaining address space is large enough to meet the current and future needs of every resource connected to the Internet with its own unique IPv6 address. Although the most obvious benefit of IPv6 is a larger address space, IPv6 is expected to provide several other benefits, including IPv6 methods for multicast and anycast.

[0005] Multicast enables the transmission of packets to multiple destinations in a single send operation, which is native to the base specification of IPv6. For IPv6, packets are sent to a multicast group address; then, the packets are sent to the members of the group. On the other hand, IPv6 anycast transmission enables a source resource to send a packet to a group address, but only one receiver in the group (topologically closest to the sender) will receive the transmitted data.

[0006] Compared with other packet transmission / broadcasting methods such as unicast and broadcast, the group subscription model of multicast and its combination in the IPv6 protocol improves the transmission efficiency of data packets in the Internet and reduces network congestion. Unicast is a one-to-one connection in which data packets are sent from one IP address to another IP address. Broadcast is a one-to-all transmission in which data packets are sent to all addresses / nodes in the network. Therefore, the use of multicast in IPv6 can provide a more efficient and scalable solution for transmitting data over the Internet.

[0007] In addition to the Internet, the need to efficiently transmit data is critical to other networks as well. For example, scalability is a significant technical challenge for many distributed ledgers because they use a limited maximum block size (e.g., Bitcoin’s 1MB block limit). Because such protocols require more, smaller blocks to be propagated through the network, the network becomes congested and slows down. Transactions take longer to mine and confirm. Network performance degrades and system functionality suffers, rendering the Bitcoin ledger unusable with applications that require fast processing power.

[0008] On the other hand, the Bitcoin SV protocol allows for larger blocks (currently 4GB and moving towards TB blocks). The technical challenge is how to distribute these larger blocks across the nodes in the ledger's node network in a fast, secure and efficient manner. Therefore, for blockchain-related applications, there is a need to provide improved blockchain networks, more efficient technical solutions in terms of time, processing resources and network performance.

[0009] Now a solution has been devised that at least addresses these and other technical issues.

[0010] the term

[0011] As is known in the art, the term "node" may refer to a basic unit of a data structure (in computer science), or a connection point in a communication network (network / telecommunications), an entity in a mesh network, or a computing resource running a blockchain protocol implementation, such as a miner on the Bitcoin network. In addition to this, a device or system in a network may also be referred to as a "host" or a "peer", depending on the context. Therefore, for purposes of this disclosure, confusion may arise between the various terms because certain embodiments may cover or intersect various technical fields.

[0012] Therefore, to avoid confusion and for the sake of clarity, the umbrella term "network resources", "processing resources", "computer-based resources", or simply "resources" will be used to include "nodes", "peers", or "hosts", or any device / system on the network. Here, the term "node" is preferred because it generally means (but not necessarily limited to) nodes on a blockchain network, such as miners.

[0013] In addition, for convenience, the Bitcoin protocol / network / ledger may be cited here because it is the most widely known of such technologies. However, the present disclosure is not limited to use with Bitcoin, and other ledger-based protocols / networks are also within the scope of the present disclosure. For example, blockchain protocols, networks, and implementations that include proof-of-stake mechanisms or utilize account-based rather than UTXO-based models are all within the scope of the present disclosure. It should also be noted that "Bitcoin" is not limited to any specific Bitcoin-related protocol, and any protocol or implementation that is derived from, different from, or deviates from the original Bitcoin protocol is intended to be within the scope of the present disclosure. Public, private, or permissioned blockchains are also within the scope of the present disclosure.

[0014] The term "blockchain-related data" as used herein includes, but is not limited to, any data used, transmitted, received, stored or otherwise processed in connection with or in order to implement operations, functions or services performed in connection with a blockchain protocol or a blockchain-based application. Summary of the invention

[0015] Embodiments of the present disclosure provide a solution for transmitting data via a computer-based network. Preferably:

[0016] ● the solution includes the use of IPv6; and / or

[0017] ● the data is blockchain-related data, but is not limited to being used only for blockchain and blockchain-related data; and / or

[0018] ●The network is a distributed network, such as a ledger (blockchain) network or any peer-to-peer (P2P) network.

[0019] In an exemplary embodiment of the present disclosure, computer-based resources can be associated to form one or more multicast groups, each group having its own corresponding multicast address. The multicast group address is a logical collective identifier of the resources in the group so that they can all receive data packets from a sending node via multicast communication. In some embodiments, the address is an IPv6 multicast address, and the data is sent and received via the Internet.

[0020] In a particularly advantageous example, the present disclosure can be used to send data from a sending resource to a multicast group of receiving resources, and the data relates to at least a portion of a blockchain block and / or a blockchain transaction. In such an example, the sending resource only needs to send the data once to all intended recipients to receive a copy, rather than sending it multiple times to each individual recipient in a unicast manner.

[0021] In one or more embodiments, the receiving resource group may form an overlay network. The overlay network may be an overlay layer relative to a blockchain network associated with a given blockchain protocol. The blockchain network may include full blockchain nodes, each of which runs a client according to the protocol and performs at least one of the following according to and as specified by the blockchain protocol: mining, verification, consensus, and blockchain maintenance functions. In some embodiments, a full node may include a memory pool for storing transactions before they are written to a blockchain ledger, as described below and as known in the art. Additionally or alternatively, the full blockchain node may be substantially as described below and with reference to Figures 1 to 4 As blockchain node 104. In one or more embodiments, one, some or all of the receiving resources are not full nodes on the blockchain network. In one or more embodiments disclosed herein, one, some or all of the receiving resources can be used to perform a subset of the protocol-specified functions run by the full blockchain node.

[0022] The receiving resources in each group may be of various types, forms, configurations or purposes, and the sending resources may be members of the group or external to the group.This disclosure is not intended to limit the type or nature of the data sent, or the purpose for which the data is sent.

[0023] However, in one or more embodiments, one, some, or all of the sending nodes and / or receiving nodes in the group may be full nodes on the blockchain network or nodes on the overlay network, and the data may include data related to unconfirmed transactions that have been verified but not yet written to the blockchain ledger. In such embodiments, systems and methods for implementing a memory pool may be provided, the memory pool being in or associated with a blockchain network or an overlay network that interacts with the blockchain network.

[0024] Advantageous applications of the present disclosure may include at least the ability to send data to a group of computing resources that provide distributed and / or parallelized blockchain-related functions. For example, such functions may be mining functions, on-chain search functions, verification functions, etc. At least one of the technical objectives of the present disclosure may be to enhance the scalability of a blockchain network and / or the scalability of an overlay network that acts as an overlay layer on top of a (underlying) blockchain network. The underlying blockchain network may be as described herein and with reference to Figures 1 to 4 A peer-to-peer (P2P) network 106. According to an embodiment of the present disclosure, at least one or part of the provided technical improvements may not only involve propagating transactions faster or more efficiently when the transactions pass through the traditional (underlying) blockchain network, but also involve improving the throughput of transactions or blocks or parts thereof.

[0025] refer to Figure 5 , three resource 501 groups are shown. Multicast group "a" 502a contains five resources 501, multicast group "b" 502b contains four resources, and multicast group "c" 502c contains three resources. It should be understood that the number of resources 501 in each multicast group is irrelevant to the present invention. For example, the first group may have ten resources 501, the second group may have one resource 501, and the third group may have one hundred resources 501. As explained herein, a multicast group 502 is a group of resources that can be accessed via a single multicast address. A resource 501 that sends any type of data to another resource may be referred to as a sending resource herein, and the recipient of the data may be referred to as a receiving resource.

[0026] Figure 5 Each of the three resource multicast groups in communication with each other is shown. The communication may include sending one or more data packets in a transmission. The data may be blockchain-related data, but not necessarily. The transmission may include data related to a request for data from one or more recipients. Alternatively, the transmission may simply provide data to the recipient and may not include a request for a response. The present disclosure is not limited to the nature, form, or type of action performed by the one or more recipients upon receiving the data from the sending resource. The transmission may be performed using multicast and / or anycast.

[0027] When multicast is used, resources of a multicast group (e.g., group 502a) may send data to the same group 502a and / or another multicast group (e.g., 502b) in the form of a single transmission to a single multicast address corresponding to or associated with the multicast group 502a / 502b. In this way, only one transmission is sent, and only (but not all) resources that are members of the receiving multicast group receive the data.

[0028] When using anycast, a resource 501 of a multicast group (e.g., group 502a) can transmit data by sending data to the same group 502a or another multicast group (e.g., 502b) in the form of a single transmission to a single anycast address corresponding to or associated with multicast group 502b. The one or more packets are routed to the resource 501 of multicast group 502b that is determined to be topologically closest to the sending resource. The receiving resource can then forward the data to one or more other resources of multicast group "b", or to any one or more other resources in one or more other groups, or even to any other resource that does not belong to any group. In this way, only one data transmission is sent to a single recipient within a particular group, but the data can then be propagated among other members of the group via multicast transmission. This is advantageous in the case where only one member or a subset of members of the multicast group needs to receive the transmission in order to provide the data to the entire group. Similarly, the resources of a multicast group can send or receive data using multicast or anycast.

[0029] When multicast is used, resources of a multicast group (e.g., group "b") may transmit data (e.g., data requested in response to such a request) by transmitting the data to multicast group "a" in the form of a single data transmission to a single multicast address corresponding to multicast group "a". In this way, only one data transmission instance is required, and only member resources of multicast group "a" receive the data. In this embodiment, the transmitting resources may be referred to as "transmitting resources", and member resources of multicast group "a" may be referred to as "receiving resources".

[0030] When using anycast, resources of a multicast group (e.g., group "b") can send data (e.g., data requested in response to a received request) by sending the data to multicast group "a" in the form of a single data transmission to a single anycast address corresponding to multicast group "a". The data is routed to the resources of multicast group "a", which are determined to be the resources that are topologically closest to sending the data. The receiving resources can then forward the data to other resources of multicast group "a". In this way, only one data transmission instance is required for the data to reach multicast group "a", and only member resources of multicast group "a" receive the data, which addresses the possibility that only a subset of the multicast group needs the data.

[0031] In an embodiment that includes sending data, multiple resources of a multicast group may each send a portion of the data. In one embodiment, each of the multiple resources may send a hash of the data and / or a hash of a corresponding portion of the data. The hash may be sent instead of the data itself or in addition to the data itself. This distribution helps reduce congestion in the network.

[0032] In an embodiment, one or more resources in the multicast group may be: resources in a blockchain network, computing resources associated with or controlled by a financial institution; a merchant; and / or a digital wallet.

[0033] In additional or alternative embodiments, the request may include a request for a communication or alert related to a blockchain-related event or activity. In one embodiment, the data sent includes a communication or alert related to a blockchain-related event or activity. The communication or the alert may involve a double spend or double spend attempt in the blockchain network.

[0034] In an embodiment, the requested and / or sent data includes: blockchain-related data, such as a blockchain transaction or a portion thereof; at least a portion of a blockchain block; at least a portion of a blockchain transaction script; at least a portion of a Merkle path or a Merkle proof; and / or data used or associated with a consensus mechanism of a blockchain network.

[0035] In one embodiment, the resources of the multicast group communicate with one or more other multicast groups via an Internet Protocol (IP) multicast address. In one embodiment, the resources of the multicast group communicate with one or more other multicast groups via an IPv4 multicast address. In one embodiment, the resources of the multicast group communicate with one or more other multicast groups via an IPv6 multicast address. In one embodiment, resources and / or resource groups may be separated from each other so that they communicate via the Internet.

[0036] In one embodiment, each of the multicast groups includes one or more receiving resources. In one embodiment, each receiving resource in a given receiving resource group is used to receive data sent to the multicast address of the given receiving resource group.

[0037] In one embodiment, a resource subscribes to receive a group of resources. In one embodiment, the resource subscribes by sending a signal to the network.

[0038] In one embodiment, the resource leaves the receiving resource group. In one embodiment, the resource leaves the group by ceasing to send signals to the network.

[0039] In one embodiment, receiving resources in the receiving resource group perform functions specified by the blockchain protocol, computations or other operations related to mining or consensus functions specified in the blockchain protocol, simple payment verification (SPV) operations, verifying blockchain transactions before or after they are written to the blockchain, searching the blockchain to identify, locate and / or confirm whether a given transaction or block exists in the blockchain, generating blockchain transactions, writing transactions to the blockchain, and / or broadcasting transactions to the blockchain network.

[0040] In one embodiment, a portion of the blockchain-related data may be sent from a sending resource to one or more receiving resource groups, and each of the one or more groups may be polled to obtain a targeted response. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0042] Figure 1 A schematic block diagram of a system for implementing a blockchain.

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

[0044] Figure 3A A schematic block diagram of a client application is shown.

[0045] Figure 3B It shows that Figure 3A A schematic mockup of an exemplary user interface represented by a client application.

[0046] Figure 4 A schematic block diagram of some node software for processing transactions is shown.

[0047] Figure 5 An embodiment of the present invention is shown in which resources belonging to a multicast group communicate with each other to distribute electronic data securely, efficiently, and quickly.

[0048] Figure 6a An example of an IPv4 address in dotted decimal notation is shown.

[0049] Figure 6b An example of an IPv6 address in hexadecimal notation is shown.

[0050] Figure 6c Shows how address prefixes are reserved to indicate IPv6 address types.

[0051] Figure 7A unicast transmission of a data packet from a server address to a global unicast address of a computer (shown as PC1) is shown.

[0052] Figure 8 shows a multicast transmission for Figure 7 Here, packets sent from the server are routed over the Internet to the multicast address for retrieval by subscribers.

[0053] Fig. 9 shows anycast transmission for Figure 7 and Figure 8 Compare this with where a server sends a packet to an anycast address; the packet is forwarded to the topologically closest router / node for the subscribed resource set.

[0054] Fig.10 Showing block propagation in the Bitcoin network.

[0055] Fig.11 An exemplary embodiment of the present disclosure is shown in which nodes in a blockchain network perform multicast transmission of one or more mined blocks.

[0056] Fig.12 An exemplary embodiment of the present disclosure is shown in which a node in a blockchain network performs an anycast transmission to an anycast address.

[0057] Fig.13 An exemplary embodiment of the present disclosure is shown, wherein the use of multicast transmission and anycast transmission is combined for chunk distribution purposes.

[0058] Fig.14 An illustration is provided of the advantageous use of multicast of blocks according to an embodiment of the present disclosure, including consideration of geographic factors to increase distribution speed and efficiency.

[0059] Fig.15 It shows that nodes on the blockchain network broadcast blocks to key nodes in the network through multicast transmission. DETAILED DESCRIPTION

[0060] By way of technical background, and with particular reference to FIGS. 6 to Fig. 9 , provides an explanation of some transmission protocols and technologies that can be used in conjunction with the present disclosure to provide the technical effects and benefits of various embodiments.

[0061] As is known in the art, the Internet Protocol (IP) is a communication protocol that provides an identification and location system for computers on a network and routes data packets through the Internet. Resources (i.e., devices / systems) on the Internet are assigned unique IP addresses for identification and location definition. IPv6 is designed to solve the IP address shortage problem caused by IPv4.

[0062] IPv6 Address:

[0063] Figure 6a An example of an IPv4 address in dotted decimal notation is shown. The address consists of four 8-bit parts, each separated by a dot, called an octet.

[0064] For comparison, Figure 6b An example of an IPv6 address in hexadecimal notation is shown, where each hexadecimal character represents a series of 4 bits. The address consists of eight 8-bit parts, each separated by a comma. Each 8-bit part is called a hexadecimal number (hextet). The address can be simplified using various rules, including i) replacing multiple consecutive all-zero hexadecimal numbers with double colons (only once), and ii) removing any leading zeros of the hexadecimal number; this produces:

[0065] 2001:db8::a111:b222:0:abcd

[0066] Given the differences in address formats, IPv6 allows for more addresses than IPv4. This, in turn, provides the ability to reserve subspaces for different address types. Address prefixes are reserved to represent various address types, such as Figure 6c As shown, the global prefix is ​​a block of IP addresses that is provided to end users by their Internet Service Providers (ISPs). The length is at least 88 bits, with the subnet ID comprising 16 bits and the host / interface ID comprising 64 bits.

[0067] These address types generally represent different methods of projecting information within a network, including those shown in the following table:

[0068] Address Type Prefix information Global unicast 2000:: / 3 Publicly routable The only local FC00:: / 7 Routable in LAN Link Local FE80 / 10 Not routable Multicast FF00:: / 8 Group Address Anycast 2000:: / 3 Shared Address

[0069] Table 1

[0070] Multicast:

[0071] Multicast is a one-to-many network transmission scheme in which a sending resource transmits a single data packet to multiple destinations. The resource sends only one copy of the data across the network. After the data has been replicated at the applicable connection points in the network, resources that have subscribed to the source of the sender's transmission will subsequently receive a copy of the data. Multicast transmissions are particularly efficient in terms of bandwidth consumption because the sending resource only sends one copy of the data, even though all groups receive one copy. This is in contrast to unicast, in which the sending resource establishes a connection with each intended recipient and sends a separate copy of the data to each recipient.

[0072] like Figure 6cAs shown, subspaces of IPv6 addresses can be designated for different types of addresses (unicast, multicast, etc.). Figure 6c The address shown in (2001:0db8::a111:b222:0:abcd) is an example of such an address. For unicast transmissions, packets are sent between global unicast addresses. There are different types of IPv6 unicast addresses. Global unicast addresses are routable unicast addresses. (This is similar to the use of public IPv4 addresses) - see, for example, https: / / www.ciscopress.com / articles / article.asp?p=2803866&seqNum=4.

[0073] refer to Figure 7 , unicast transmission of a packet from the server's address to PC1's global unicast address will cause the packet to be routed through the Internet and arrive at PC1 at address 2001:db8::a111:b222:0:abcd. PC1 will be the only resource processing the packet.

[0074] For multicast, instead of sending the packet to PC1's address, send the packet to the multicast address. This will be an IPv6 address with the prefix FF. Resources that wish to receive data from the derived party join the multicast group for that multicast address. This is called their "subscription".

[0075] When a packet is sent from a server, it is routed across the Internet to a multicast address (e.g. Figure 8 Figure 2 shows a multicast transmission from the server to subscribers PC1 and PC2). Once the packet arrives, the subscribers (e.g., PC1 and PC2) are able to retrieve the data, while non-subscribers PC3 and PC4 ignore the packet. This multicast reduces the need to send two separate packets from the server to PC1 and PC2. Only when it arrives at the RLocal is a separate copy of the packet created.

[0076] In order for multicast packets to reach PC1, resource PC1 must report to RLocal that it wishes to join multicast group FF00: / 8. When RLocal sees this report, it will open its interface to PC1 and promise to forward any multicast messages to PC1 if it sees any multicast packets on the network. A router in the network (e.g., R2) will be selected as the Rendezvous Point (RP) for the multicast to FF00: / 8. Knowing that the best path to R2 goes through R1, RLocal will send a Join Report to R1, asking R1 to forward the request for the FF00: / 8 multicast transaction to Rendezvous Point R2. R1 will send a Join Report to R2. If the Rendezvous Point wants to receive the multicast packet, it will forward the packet to R1, which will then pass the packet to RLocal, which will then pass the packet to PC1.

[0077] Anycast

[0078] IPv6 anycast includes the case where multiple routers share a public IPv6 anycast address. As shown in Table 1 above, the anycast address shares the same prefix as the global unicast address. For example:

[0079] 2001:db8::a111:b222:0:abcd

[0080] Can also be used as an anycast address.

[0081] If a packet is sent by a sending resource to an anycast address, the packet is forwarded to the nearest router / node of the subscribed set of resources. While geographic distance is a factor in determining the nearest resource, there are other factors that play a role in the calculation: number of hops, efficiency, latency, and cost, among others. Finally, with anycast, only one resource is expected to receive the packet, often described as a one-to-nearest transmission.

[0082] refer to Fig. 9 , which shows an anycast transmission from a server to router R3, it can be seen that the data packet is sent to the anycast address 2001:db8: / 32 shared by at least three routers (R1, R3, RLocal). The closest of these routers is R3, so the data packet is sent to R3. It should be remembered that "closest" does not necessarily mean geographical proximity.

[0083] Illustrative Embodiments

[0084] Turning now to a discussion of illustrative embodiments of the present disclosure, and referring to Figures 5 to 15, provides a scheme for distributing data quickly, securely and scalably on a computing network using these transmission technologies. In a preferred embodiment, data is transmitted from one or more sending resources to one or more receiving resources via a network (e.g., the Internet). In some scenarios, the receiving resources are organized into logical groups, and each group may include one or more resources. Resources may include any type of computing resources, controlled by or belonging to any one or more organizations, and configured for any suitable purpose. Each resource may include one or more hardware and / or software components and is configured to communicate with other resources via an electronic network. In some cases, a resource may be a mining node on a blockchain network, while in other cases, a resource may be a digital wallet, a cryptocurrency exchange, a search engine, a file server, or a service provider, etc. There is no limitation on the type, form, purpose, or configuration of one or more resources.

[0085] Each group is associated with a corresponding group identifier, which serves as a unique address to which data can be sent. All resources in a given group are associated with the address of the group and can therefore receive data sent from a sender to the group address. The address can be a multicast address, and in a preferred embodiment, the address is an IPv6 multicast address. Therefore, each receiving resource group is represented by an IP address. Therefore, the group address can be used to implement one-to-many communication, because the sending resource only needs to send a data packet to the group address once, and each resource in the group can receive the data packet, rather than sending a data packet to each resource in a one-to-one communication (for example, as performed in a unicast transmission).

[0086] A receiving resource can subscribe to (i.e., join) a group by sending a Multicast Listener Discovery (MLD) message indicating its intent to participate. Advantageously, the joining resource can be located on a local area network (LAN) or the Internet, since multicast groups are not restricted by local or global network geography. As long as a resource signals that it is a member of a group, the resource can receive multicast packets sent to the group address. Thus, a resource can dynamically join or leave a group at any time by simply signaling to the network to join or stop joining the group.

[0087] Thus, a multicast group is used to identify a group of receivers, each of which has an interest in or need for a particular data transmission sent to the group's addresses. While only resources belonging to a given group can be receivers, any resource can send data to the group, whether or not it belongs to the multicast group. Resources in one group can send data to another group, and vice versa.

[0088] Multicast Listener Discovery (MLD) and MLD Snooping

[0089] As is known in the art, MLD is built into the IPv6 protocol. See, for example, https: / / en.wikipedia.org / wiki / Multicast_Listener_Discovery. MLD Snooping uses MLD to provide multiple efficiencies because it avoids flooding packets across the network, thereby avoiding transmitting data to network resources that have not yet signaled an interest in receiving that data. In addition, it provides greater network security because it avoids denial of service (DOS) attacks from unknown network sources.

[0090] By default, MLD snooping is disabled. Therefore, when a switch receives a packet with a multicast address, the packet is sent to all interface ports in its VLAN, except the port where the packet was received. In other words, the switch floods the packet in the VLAN. If a resource is not a member of the multicast group and is not interested in the data on that channel, the packet is ignored. Obviously, this results in unnecessary network traffic and inefficient use of energy and processing resources.

[0091] However, when MLD snooping is enabled, the switch forwards multicast addressed packets only to interface ports that have signaled an interest in receiving packets destined for that address. In other words, the switch only sends packets to ports that belong to members that have subscribed to the multicast group. Thus, MLD snooping allows a sending resource to selectively transmit packets to resources that have indicated an interest in receiving packets. If no network resources are subscribed to the multicast group, the sending resource does not send any packets. For more details, visit:

[0092] https: / / techhub.hpe.com / eginfolib / networking / docs / switches / WB / 15-18 / 5998-8170_wb_2920_ipv6_config_guide / content / v33585413.html.

[0093] Distribution of blockchain-related data:

[0094] In one particularly advantageous scenario, the sending resources and / or receiving resources are computing resources for sending, receiving, storing and / or processing blockchain-related data. In one example, these resources may be nodes in a blockchain network that implement a particular blockchain protocol (e.g., the Bitcoin SV protocol). A multicast group may be created that includes all nodes or a subset of nodes in a blockchain network. For example, a multicast group may be established to share data between a pool of miners, a set of PoW computing resources, or any other type of operation. However, in other examples, one, some, or none of these resources may be nodes on a blockchain network, but may be resources that process data in some manner for blockchain and / or cryptocurrency-related purposes. For example, these resources may include digital wallet providers, cryptocurrency exchanges, banks and financial institutions, distributed verification providers, and the like.

[0095] The efficiency of IPv6 is considered beneficial to blockchain networks such as Bitcoin because 1) Bitcoin itself is maintained by a distributed network of nodes; and 2) these nodes communicate peer-to-peer over the Internet.

[0096] For the Bitcoin network, each full node is expected to store an up-to-date copy of the blockchain / ledger, the memory pool (a data set of unconfirmed transactions), and the UTXO set (a list of all unsent transaction outputs). In order to maintain the latest versions of these data sets, constant communication is required between nodes, where verified transactions and blocks are shared between these nodes. Blocks contain a set of transactions as well as a block header. The block header itself contains a nonce used to mine the block, as well as a Merkle root representing the set of transactions in the block. Embodiments can provide advantages in the following aspects:

[0097] ● Transaction Propagation:

[0098] When a wallet submits a transaction to the Bitcoin network (e.g., a user uses Bitcoin to purchase an item at a store), the full node 104 that receives the transaction checks that the transaction is valid (the content satisfies all the rules of the Bitcoin protocol version of the node's software), and that the transaction is not a double spend of an existing transaction in the memory pool. (A "double spend" occurs when two spending transactions attempt to spend the same output of a given funding transaction on the blockchain). If both criteria are met, the Bitcoin node 104 updates its personal memory pool and sends the verified transaction to the set of other Bitcoin nodes it is connected to. Each of these receiving nodes proceeds to perform the same steps of validity checking, updating, and transaction transmission. This allows the transaction to be propagated through the Bitcoin network.

[0099] ● Block Propagation:

[0100] refer to Fig.10, which shows the propagation of blocks between nodes in a blockchain (e.g., the Bitcoin network). When a node mines a new block from the transaction pool in its memory pool, the node updates its data repository (UTXO set, memory pool, blockchain) and forwards the new block to its connected nodes. For the Bitcoin protocol, a node can have up to 125 connections, of which only 8 are outgoing connections.

[0101] These connected nodes in turn perform their own validity checks on the block, update their data repositories, and relay the block onwards. This allows the block to be propagated through the Bitcoin network.

[0102] The speed at which transactions and blocks propagate is particularly important, as nodes and / or wallets will need the latest version of their data sets (UTXO set, memory pool, blockchain) in order to minimize the risk of double spending. It is also in the best interest of full mining nodes 104 to know about the latest mined blocks as early as possible. This is to reduce the time it takes these mining nodes to generate proof of work (PoW) for the memory pool, where some or all of these transactions have been included in the mined block.

[0103] For the BTC network, a newly mined block takes an average of 10 seconds to propagate through the network. This propagation time is proportional to the size of the block (maximum 1MB for the BTC network). On the other hand, nodes implementing the Bitcoin SV protocol that allows for large block sizes need innovative solutions to reduce the time it takes to propagate large blocks. Therefore, faster block propagation is critical for scalability.

[0104] Block header propagation

[0105] Given that nodes receive transactions from multiple sources, and the mempools of these nodes may share transactions, sending an entire newly mined block to at least 8 outgoing connections may be inefficient, as the receiving node may already have copies of many of the transactions in the mined block in its mempool.

[0106] To solve this problem, instead of sending the newly mined block to the output node, the sending node can send a copy of the block header and a list of transaction IDs (hashes of transactions) contained in the block. In some embodiments, this can be an ordered list depending on the blockchain protocol being used. This (ordered) list, along with the Merkle root and random number of the header, can prove the validity of the mined block. The receiving node can use the ordered list to determine which transactions (if any) it does not already have in its memory pool. The receiving node can then send a request to the sending node for copies of pending transactions. Upon receiving this request, the sending node sends these copies to the requesting node. The requesting node then writes or compiles the block based on the transaction and header information it has received from the sending node, and then adds the new block to its copy of the blockchain.

[0107] Multicast distribution using IPv6:

[0108] According to some embodiments, IPv6 transmission of data packets is employed to facilitate block distribution through or in a blockchain network. Fig.11 An example of a multicast distribution of a mined block from node 5 to a network of nodes is shown. Nodes in a blockchain network (or a subset of the network) that wish to receive block updates can choose to subscribe to a shared multicast address based on specific criteria. One or more sending (source) nodes can send applicable blocks to the multicast address. These blocks can be full blocks or partial blocks, and can also be mined blocks or pre-mined blocks.

[0109] exist Fig.11 In the example of , blockchain node 4 receives Bitcoin transactions from PC1, PC2, and node 5 and is able to successfully produce a mined block. This is intended to be distributed to the set of interested nodes as efficiently as possible. In this example, these interested nodes are node 1 and node 2. Both nodes have subscribed to the multicast address 2001:db8: / 32. Node 4 sends a copy of the block to the multicast address. Once at that address, the block is replicated and a copy is sent to the subscribers node 1 and node 2.

[0110] As mentioned above with regard to block header propagation, sending a full block to a recipient may mean that a node receives a copy of a transaction it already has. This can lead to inefficiencies if the required data (or at least part of it) can be accessed locally and does not need to be sent over the network.

[0111] With this in mind, a variation of the following process can be performed:

[0112] Instead of sending the entire block via multicast, the sending node can send only the block header and the (ordered) transaction list via IPv6 multicast to the multicast address; therefore, all subscribing nodes will receive this information via multicast transmission;

[0113] Each receiving (i.e., subscribing) node uses the received information to determine which pending transactions (if any) they need to produce a complete block;

[0114] If the receiving node determines that it needs at least one transaction to generate a block, it sends a request for the required transaction (i.e., the missing transaction) to the sending node (via unicast transmission); the request includes the ID of its missing transaction;

[0115] ●The sending node receives the request from the receiving node;

[0116] The sending node sends a transmission including the requested missing transaction to the receiving node. Preferably, this will be a unicast transmission only to the single receiving node that has sent the request. This is because the pending node set of the corresponding receiving node may be unique, thereby reducing the value or benefit of sending the pending transaction to the entire subscription group via IPv6 multicast.

[0117] MLD Snooping. As mentioned above, MLD Snooping can provide significant efficiencies and benefits to the transmission of data in the network. For blockchain-related services or functions, this can significantly improve the applications and service providers implemented by blockchains, as well as enhance the network that implements the underlying blockchain protocol itself.

[0118] Using IPv6 multicast, the sending resource can enable MLD snooping. Embodiments of the present disclosure may include at least, but are not limited to, the features included in the following clause set 8. This enables the sender to selectively transmit data packets only to those resources that indicate that they wish to receive data packets. This means that the transmission of blockchain-related or related data can be effectively targeted to a specific destination. This effectively changes the information flow from a push mode to a subscription / publish mode; that is, the receiving host subscribes to the IPv6 multicast group, and then the data packet is forwarded from the switch running MLD snooping (layer 2) to the router running MLD (layer 3), and then forwarded to the receiving host. Therefore, only necessary traffic is forwarded through the network. This at least to some extent solves the recognized technical challenge of how to achieve scalability in blockchain networks, which requires sending a large number of transactions per second. Therefore, blockchain-related methods and systems combined with the use of MLD snooping promote or enable the construction of improved blockchain networks and blockchain-implemented applications.

[0119] For example, consider an IPv6 multicast group consisting of 2 members, Alice and Bob, who wish to participate in SPV verification. Assume that one of the members is a merchant and the other is a customer who wishes to purchase goods or services from the merchant using Bitcoin. The use of MLD and MLD snooping allows both Alice and Bob to receive Merkle paths as responses to submissions from nodes on the Bitcoin network, thereby significantly improving SPV transactions. In some embodiments, certain nodes on the blockchain network may provide this functionality as a subscription-based service. In other examples, applications and services may subscribe to a multicast group address to receive blockchain transactions submitted upstream from the blockchain node itself. This is possible because the transactions are public. This improved data flow enables blockchain transactions to be verified using Merkle paths through Merkle proofs, rather than scanning or iterating the blockchain ledger. Similarly, this provides a more efficient solution for building blockchain-related applications that need to interact with, use, or query blockchain-related data.

[0120] Advantageously, some embodiments of the present disclosure provide a scheme for implementing a memory pool or UTXO set of a blockchain network. According to such embodiments, a node on the network may be a blockchain node and may join a multicast group as described herein. The node may be a full blockchain node 104. The node may transmit blockchain-related data between group members via an IPv6 multicast message. The blockchain-related data may be or include at least one unconfirmed blockchain transaction or at least one unspent transaction output (UTXO). Although international patent application WO2018 / 234987 discloses the use of multicast to propagate initial transactions through an overlay network of dedicated nodes located on top of a blockchain network, there is no disclosure of the use of IPv6 multicast for use with (full) nodes on the blockchain network itself. In addition, the international patent application does not disclose the use of multicast to propagate unconfirmed transactions, such as those required to implement a memory pool. In fact, the Bitcoin network still does not use IPv6 for inter-node communication, and WO2018 / 234987 proactively discloses the use of DHT instead of multicast, because this indicates that the network lacks sufficient scalability to cope with the increase in transaction output brought about by multicast distribution.

[0121] Anycast distribution using IPv6:

[0122] Anycast is particularly useful in situations where transmission speed is of particular concern. With regard to block propagation in a blockchain network, nodes want to receive a copy of newly mined blocks as quickly as possible. Nodes can choose to join an anycast address when they obtain a copy of a newly mined block. This essentially means assigning an anycast address to yourself (i.e., a network interface). An anycast address is essentially a shared unicast address. Interested nodes can then send a request transmission to the anycast address, indicating that they are looking for a copy of the newly mined block and / or requesting a copy of the newly mined block. The request transmission will go to the topologically closest node that belongs to the anycast address. This closest node will then send a copy of the mined block directly (using unicast) to the node that made the request.

[0123] Fig.12 An example of an anycast transmission from node 5 to anycast address 2001:db8: / 32 is shown. Nodes 1, 2, and 3 have obtained a copy of the newly mined block. After receiving and verifying a copy of the mined block, they each assign themselves to the anycast address 2001:db8: / 32. It is commonly understood that this anycast address means that the address indicates that the recipient has a copy of the newly mined block. Node 5 sends a request for a copy of the block to the anycast address; the topologically closest node (of nodes 1, 2, and 3) will be the node that receives the request.

[0124] exist Fig.12In this case, the closest node is Node 1. Said node will then send a copy of the block to Node 5 via unicast, if selected. Given that the closest node is selected, this means that Node 1 is likely to receive a full copy of the block sooner.

[0125] However, it should be noted that the "closest" node depends on several factors other than geographic proximity; latency and cost are listed as factors in its determination. If the channel to node 1 becomes overwhelmed with block transfers and block requests, the "closest" calculation may select another node as the new closest node. This distributes requests and block transfers among the nodes that have new blocks.

[0126] In the case of block header transmission, the process can still operate as described above. In a preferred embodiment, the request for the block header of the newly mined block will be performed through an anycast request. When the closest node is determined, a unicast transmission will be sent from the requesting node (node ​​5) requesting the pending transactions of the closest node (node ​​1). It should be remembered that pending transactions are transactions in the newly mined block that are not in the memory pool of the requesting node. These pending transactions will be sent to the requesting node (node ​​5).

[0127] Combining multicast with anycast and / or unicast for distribution

[0128] Fig.13 An illustration of a block distribution using a combination of multicast and anycast is provided. In such an embodiment, the use of multicast and anycast described previously is combined to provide a block distribution from a source node ( Fig.13 The scheme is to send blocks to multicast subscribing nodes (N1 in layer 0) of the multicast group (N2…N4 in layer 1). Other interested nodes (N6, N7 in layer 2) determine which members of the multicast group (layer 1) are their closest peers through anycast query transmissions. These layer 2 nodes then proceed to download blocks from the nearest layer 1 nodes.

[0129] for Fig.13 , node N1 is the first node to mine a block and multicasts the block to the set of subscribers N2, N3, and N4. N5 is not a subscriber. Each of these nodes is expected to also assign itself an anycast address (shared unicast address). The nodes that share this address are expected to be the nodes with the newly mined block. Nodes N1 and N7 are interested in this new block and send a request (Q) to the anycast address shared by N2, N3, and N4. The request is routed to the nearest node. For N6, the nearest node is N2. N2 receives the request for the block and sends it to N6. For N7's request, it reaches N4 (the nearest node). N4 sends the block to N7 via unicast transmission.

[0130] This can be achieved using a fixed anycast address, as described below. It should be noted that this is for illustration purposes only, and some of the following steps may be omitted, and the order in which the steps are provided below is not intended to be limiting, as some steps may be performed in a different order than shown below; the following list of steps is not exhaustive:

[0131] i. A set of associated (e.g., key stakeholder) nodes agree on their common obligations, responsibilities, or goals (e.g., allocating chunks or blocks according to a specific protocol or in accordance with the terms of an agreement).

[0132] ii. These associated nodes subscribe to the shared multicast address. The multicast address may be determined by one or more of these nodes, or by an address determiner that sends the multicast address to the associated nodes. After subscribing to the address, these nodes are now members of the multicast group, i.e., they listen to the multicast address.

[0133] iii. Affiliate nodes promote / advertise their services to the wider network (e.g., the Bitcoin network) or at least to their local or designated community or association within the network.

[0134] iv. At least one of these associated nodes or the other promotes its shared multicast address to the wider (Bitcoin) network or at least its respective local or designated community. Nodes mining new blocks need to send their new blocks (or block headers and ordered transaction lists) to this multicast address.

[0135] v. At least one of these associated nodes or the other communicates the unique anycast address to the broader Bitcoin network or at least its respective local or designated community.

[0136] vi. Nodes (can be affiliated or unaffiliated) mine new blocks.

[0137] vii. A mining node (i.e., a node that has mined a new block) sends the new block (or block header and transaction list) to a multicast address.

[0138] viii. Blocks (or block headers and transactions) are routed via IPv6 to all members of the multicast group; in other words, data is sent to the multicast address via multicast transmission.

[0139] ix. At least one (but preferably all) of these associated nodes perform the necessary checks to verify the legitimacy of the newly mined block.

[0140] x. If the block header and transaction list have been sent instead of the full block:

[0141] a. The associated node compares the transactions in the ordered list with the transactions in its memory pool. If it cannot match at least one transaction in the list with a transaction in its memory pool, the associated node sends a unicast request to the mining node for one or more pending transactions.

[0142] b. The mining node sends one or more missing transactions to the key node via unicast transmission.

[0143] In case of anycast:

[0144] 1. Non-associated nodes can intermittently send requests to the anycast address of the multicast group. The request message can include the unicast address of the sending node.

[0145] 2. If an associated node with an anycast address (i.e., a member of the receiving multicast group) receives a request for a copy of a new block, the associated node then sends a copy of the block (or block header and transaction list) to the requesting node via unicast (receiving a request via anycast means that the group member is the closest in the group to the node sending the request).

[0146] 3. If the block header and ordered list are sent to a non-associated node:

[0147] a. The node checks the transactions in the ordered list in its memory pool, i.e., as described above, the node checks its memory pool and checks whether each transaction in the list is in its memory pool; if any transaction in the list is missing from the memory pool, the node sends a unicast request to the associated node to request one or more pending (missing) transactions.

[0148] b. The associated node sends one or more missing transactions to the node via unicast transmission.

[0149] After a certain time has passed or a criterion has been met (e.g., a block was sent by the associated node to at least 25 nodes), then the associated node may unassign itself from the anycast address. The associated node focuses on listening for new blocks at the multicast address.

[0150] It should be noted that:

[0151] ●Nodes can listen for new blocks at a multicast address while receiving block requests and propagating new blocks.

[0152] ●A node can subscribe to multiple multicast addresses, i.e., a node can listen to multiple different types of blocks on the Bitcoin network.

[0153] • A node can remove itself from a multicast group or anycast address at its own choice.

[0154] Given the limits on the number of outbound nodes typically present in the way the Bitcoin network is implemented (8 for BSV), nodes seeking to quickly propagate their newly mined blocks may find value in carefully considering the maximum of 8 nodes to which they connect.

[0155] For example, 8 nodes can be strategically selected based on their geographic location, as each node can be a high-capacity node concentrated in its geographic region. (“High-capacity” includes factors such as bandwidth, low latency, computing power, storage, etc.) These 8 nodes join the multicast for new block propagation, i.e., listen to the shared multicast address. Any node that mines a block sees fit to perform a multicast to this centralized set of 8 nodes, which then communicate the block to other nodes in their respective geographic regions.

[0156] consider Fig.14 , which provides an example of blockchain-related data distribution using multicast and geo-location-based anycast of block-related data. A block mined by node N1 located in Canada is sent via multicast to a key central node (N2) located in Brazil, a key central node (N4) located in Germany, and a key central node (N3) located in Nigeria. A node (N5) located in Australia sends a request for a new block to the shared anycast address of N2, N3, and N4. The request reaches N3 located in Nigeria (determined to be the closest), which then sends the new block to node N5 located in Australia.

[0157] It should be noted that the centralization of key nodes within the Bitcoin network may not map directly to geographic locations. These nodes can be "topologically centralized" or have a high concentration in emerging clusters / communities within the network. For example, Tao et al. [Tao, B., Dai, HN, Wu, J., Ho, IWH, Zheng, Z., and Cheang, CF, 2021, Complex Network Analysis of the Bitcoin Transaction Network, IEEE Transactions on Circuits and Systems Series 2: Rapid Briefs, Vol. 69, No. 3, pp. 1009-1013] also showed the existence of communities in the Bitcoin Core network. Fig.15 The network in Figure 1 shows that node N1 broadcasts blocks to key "central" nodes (N2...N8) in the Bitcoin network via multicast. These receiving nodes can then distribute block-related data to other nodes in their community.

[0158] For purposes of illustration and not limitation, some exemplary use cases are now provided.

[0159] Example Use Case 1: Double Spends, “Foresight Rules”, and Network Alerts:

[0160] Satoshi Nakamoto's white paper "Bitcoin: A Peer-to-Peer Electronic Cash System" introduced the concept of the "seeer rule" regarding transactions and blocks on the Bitcoin network. According to this rule, when a mining node evaluates blocks according to the protocol, it considers the first block it sees as the first valid block, which is broadcast to the network and is the farthest from the genesis block in the valid chain. This is essential to avoid "double spending" scenarios.

[0161] As the Bitcoin SV Wiki (https: / / wiki.bitcoinsv.io / index.php / First_seen_rule) explains:

[0162] “When two blocks are competing in an orphan race and a node attempts to build on top of one of them, if a new block is found on the rival, the node stops processing the block it saw first and moves to the longest chain. When transactions are received, the seer rule is applied to determine which transaction is valid in case of a double spend. When a node detects a double spend, the node always considers the transaction it received first as the valid spend of that coin.

[0163] This rule has been further expanded to add that any blocks found that include a double spend transaction should also be considered invalid and the node should continue mining on it unless a second block is found on top of that block, indicating that a majority of the network has determined that the other transaction is the first seen transaction.”

[0164] It is therefore crucial to get communications across the network as quickly as possible. Every “hop” that must be made between nodes in order to fully distribute information throughout the network takes time, and therefore the network becomes less secure. Currently, such communications are sent across the network using unicast transmissions, meaning that each message has a sender and a receiver, requiring multiple hops as the information is relayed between nodes.

[0165] However, according to the present disclosure, double spend alerts can be sent to mining nodes in a multicast group so that all nodes receive the alerts simultaneously and as quickly as possible, and can take necessary remedial actions. There are no "hops" between nodes, because each node that has joined the multicast group is listening to the stream and will receive the message on its own. Therefore, such embodiments provide improvements in the handling, timing, and security of network communications and alerts.

[0166] In other exemplary applications, a multicast group may include members that are not miners or full nodes on the network, but need to share blockchain related information (e.g., transactions, blocks, or portions of blocks). For example, one, some, or all of these members may be merchants or other parties that wish to send, receive, or otherwise process blockchain transactions. In some cases, a merchant may wish to perform SPV verification on a transaction and need to share information about the Merkle path and block headers for SPV verification. Block discovery creates hash headers or block headers. These are sent to all SPV nodes. Using multicast can deliver this data in a near-instantaneous communication manner.

[0167] In another example, the sending resource can be a source of digital currency (e.g., a central bank), and the recipient can be a bank or other financial institution that handles the digital currency. For example, a central bank can issue a central bank digital currency (CBDC). In the case of traditional cash, the minting source distributes physical banknotes and coins to various banks via vehicle transportation. In the case of digital cash, the distribution can be handled by a multicast group, where the members of the group are the banks to which the central bank wishes to distribute the funds.

[0168] Example Use Case 2: Distributed Blockchain Functionality:

[0169] Embodiments can be used for any type of data, and the sending resource and / or the receiving resource can be set or used to perform any type of function. In a non-limiting example, data related to the Merkel challenge as described in the international patent application PCT / EP2023 / 051529 can be sent to a multicast group. In such a scenario, a resource wants to entrust the storage of a file or other resource to multiple storage providers, so the sending resource generates a Merkel tree representing each segment of the file, and then sends the file to one or more storage providers. Subsequently, when the sending resource wants to confirm that the storage provider still has an unchanged copy of the data that has been sent to the sending resource, the sender changes the data in a specific way, recalculates the Merkel root of the tree, and asks the storage provider to make the same changes to its copy and send back the recalculated Merkel root. The resource can quickly confirm whether the storage provider can provide the expected Merkel root. If the Merkel root sent back does not match what the resource expects, the storage provider's copy must be damaged or changed in some way. When used in conjunction with the present disclosure, the resource can send separate parts of the file to different storage providers, each of which is a member of a given multicast group. When the integrity of a file needs to be confirmed, or when the component parts need to be reassembled, the resource will request this operation by polling the group.

[0170] In another exemplary use case, the data sent to the multicast group is blockchain-related data because it constitutes at least a portion of a blockchain transaction or transaction block, at least a portion of a locking script or unlocking script, or includes data related to a Merkle proof / path, or data used to implement a consensus mechanism (e.g., PoW or PoS related data). Merkle proof data may include data related to a blockchain transaction and data used to prove (or verify) that a transaction is included in a particular block. Merkle proofs and their use for verifying transactions in blocks and related technologies such as simple payment verification (SPV) are known in the art. Other non-limiting examples of blockchain-related data may include data used or associated with a consensus mechanism of a blockchain network. For example, this may be data related to a proof of work (PoW) calculation or some other blockchain consensus mechanism. In one example, this may be data related to a PoW calculation, such as the data described in UK patent application number GB2206634.4.

[0171] When used for blockchain-related purposes, at least one receiving resource in the group may be set to, configured to, and / or used to perform one or more of the following operations:

[0172] Functionality specified and / or required / needed by the blockchain protocol;

[0173] Computations or other operations related to mining or consensus functions specified in the blockchain protocol;

[0174] Simple Payment Verification (SPV) operations;

[0175] Verify blockchain transactions before or after they are written to the blockchain;

[0176] Searching a blockchain to identify, locate, and / or confirm whether a given transaction or block exists in the blockchain;

[0177] Generate blockchain transactions, submit transactions to the blockchain, and / or broadcast transactions to the blockchain network.

[0178] Example use case 3: Resolving packet loss

[0179] In other examples, members of a multicast group can advantageously use a combination of multicast, anycast, and unicast transmissions to ensure or achieve incomplete reception of data from a sending resource. Consider a scenario where a sending resource wishes to send a portion of data to all members of a multicast group, but the receiving members of the group fail to receive all of the transmitted data. This is a fairly common challenge in network communications (see https: / / en.wikipedia.org / wiki / Packet_loss ).

[0180] For example, suppose a multicast transmission including 10 packets is sent to the multicast group, but a particular group member (referred to as the receiving resource) receives only 8 of the 10 packets sent. The receiving resource loses packets 2 and 7. The receiving resource can obtain the missing packets by using an anycast transmission to request the missing packets from the nearest member of the multicast group. Since the data transmission is sent to the multicast group, the receiving resource knows that the other group members have received the data transmission.

[0181] The scheme can be implemented using the following method, which includes the following steps:

[0182] 1. Sending a portion of the data (e.g., included in multiple packets) from a transmission resource to a resource group associated with a multicast address using a multicast transmission;

[0183] 2. determining at a resource within the resource group that the resource has not received a complete portion of the data;

[0184] 3. Sending an anycast transmission from the resource to the nearest other members of the multicast group, requesting the missing data sub-portions (packets) that the resource has not yet received; and / or

[0185] 4. Receive the missing (discarded) data sub-portion at the resource from the nearest other member of the multicast group. The missing data sub-portion may be provided to the resource from the nearest other member by any suitable method (eg, unicast).

[0186] This provides a solution to the technical problem of how to solve or cope with packet loss. A combination of anycast requests to the nearest members and unicast responses that provide the dropped data are used to recover the dropped packets, using the initial transmission via multicast, thereby providing an efficient and fast method. As with other use case examples and embodiments, this technology can be utilized with any type of data and can be utilized by any type of resource, including but not limited to blockchain related data / resources.

[0187] List the terms

[0188] The enumerated clauses are now provided to illustrate some possible embodiments that may be provided in accordance with the present disclosure. The clause sets provided below are for illustration only and should not be construed as restrictive, exclusive, or exhaustive. Features described in one clause set may be utilized and incorporated into one or more clause sets in other clause sets. In any one or more of the clause sets in the following clause sets, embodiments may provide computer-implemented methods and / or data distribution methods. Additionally or alternatively, embodiments may provide improved data transmission or exchange methods or improved electronic communications.

[0189] A computer-implemented method for distributing data is disclosed. The method may include: sending a portion of (e.g., blockchain-related) data from a sending resource to one or more groups of receiving resources; each of the one or more groups may be associated with a corresponding address; the address may be a multicast address. In other words, resource groups may be formed, wherein, for each group, a resource is a subscribing member of the group, and all members are associated with an address identifying the group. Some or all of the receiving resources may be full nodes 104 on a blockchain network, or nodes in an overlay network, the nodes being located above one or more full nodes on the blockchain network but communicating with the one or more full nodes on the blockchain network. The sending resource may be a full blockchain node 104, or a node on a blockchain overlay network, the nodes being located above one or more full nodes on the blockchain network but communicating with the one or more full nodes on the blockchain network. These features may apply to one or more of the clause sets provided below.

[0190] Some embodiments may provide a scheme for implementing a memory pool for a blockchain network.

[0191] Some embodiments may provide a scheme for implementing a UTXO set for a blockchain network.

[0192] This article also discloses:

[0193] ● A computer device, the computer device comprising: a memory, the memory comprising one or more memory units; and a processing device, the processing device comprising one or more processing units, wherein the memory stores code configured to be run on the processing device, the code being configured to, when run on the processing device, execute a method according to any embodiment described or defined herein; and / or

[0194] ● A computer program embodied on a computer readable memory and configured to, when run on one or more processors, perform any method described or defined herein.

[0195] Clause Set 1:

[0196] Can provide:

[0197] Clause 1.1 A method comprising:

[0198] A transmission is sent from at least one sending resource to at least one receiving resource; the sending resource and / or the receiving resource may be nodes on a network.

[0199] The sending resource and / or the receiving resource may be an MLDv1 host or an MLDv2 host, a network switch or a router on the network. The transmission may be sent by the sending resource according to a multicast forwarding table. The features described in clause set 8 may be incorporated into clause set 1 or any other clause set.

[0200] According to alternative (but not exclusive) wording, there may be provided: a computer-implemented method comprising:

[0201] A portion of the blockchain-related data is sent from a sending resource to a multicast address associated with a receiving resource group over a network. The receiving resource group may be one of a plurality of receiving resources, each group of the plurality of receiving resources being associated with a corresponding multicast address. In some embodiments, the blockchain-related data may be sent to one, some, or all of the groups. When the data is sent to more than one group, the data is sent to each of the corresponding multicast addresses of the group to which the data is sent.

[0202] The network may be a peer-to-peer (P2P) network and / or a distributed network. The network may be a blockchain network, wherein the nodes 104 on the blockchain network 106 are used to perform operations according to the protocol of the blockchain. In other embodiments, the network may be the Internet or a LAN or a VLAN or a telecommunications network, or a packet switching network 101.

[0203] The sending resource and / or the at least one receiving resource may be configured to perform operations according to the protocol of a given blockchain. Additionally or alternatively, the sending resource and / or the at least one receiving resource may be a node on a blockchain network, a cryptocurrency exchange resource, a digital wallet, or a blockchain-related service provider. In some exemplary embodiments, at least one receiving node is not a node on the blockchain network; in other words, it may be external to the blockchain network and / or may not be arranged to implement a blockchain protocol or perform consensus / protocol-related functions. Additionally or alternatively, in some exemplary embodiments, the sending resource is not a node on the blockchain network.

[0204] Additionally or alternatively, the sending resource and / or at least one receiving resource may be a resource configured and / or used to process blockchain-related data (e.g., data related to any one or more of the following):

[0205] Blockchain transactions

[0206] ●At least one unconfirmed blockchain transaction

[0207] ●At least one unspent transaction output (UTXO)

[0208] Block related data

[0209] ● Merkle paths and / or proofs for verification or other purposes

[0210] ● Proof of Work and / or Proof of Stake operations or any other consensus operations

[0211] Blockchain mining operations

[0212] Blockchain-related alerts or signals that are related to or can be used by some or all of the following:

[0213] o Nodes on the blockchain network; and / or

[0214] oUsers of blockchain networks, such as exchanges, wallets, and blockchain-related service providers.

[0215] The transmission may include (at least) data relating to:

[0216] One or more blockchain transactions; the data may include at least one entire transaction and / or a portion of at least one transaction;

[0217] Blockchain transaction blocks;

[0218] at least one Merkle path and / or Merkle proof; the Merkle path / proof data may include at least a portion of a Merkle tree associated with a transaction block; it may be suitable for verification (e.g., SPV-style verification), or for confirming that a given node or root is in a given path or tree, or for any one or more other purposes;

[0219] ● Proof-of-work and / or proof-of-stake operations, or any other consensus-related operations performed by nodes on a blockchain network;

[0220] One or more blockchain mining operations, such as operations performed by a full node 104 on a blockchain network 106;

[0221] Blockchain-related alerts or signals that are related to or can be used by some or all of the following:

[0222] o Nodes on the blockchain network; and / or

[0223] o Users of a blockchain network, such as exchanges, wallets, and blockchain-related service providers, overlay one or more nodes in a network, which are an overlay layer relative to the blockchain network.

[0224] The at least one sending resource may send the transmission to the at least one receiving resource in response to a request. The request may be sent by the at least one receiving resource or by another resource. The request may be received by the at least one sending resource from the at least one receiving request or the other resource. The request may include a request for data. The request may include blockchain-related data, such as data related to at least a portion of one or more blockchain transactions or transaction IDs (TxIDs), one or more blockchain blocks or one or more block headers, and / or a Merkle path or proof.

[0225] The data may be transmitted over an electronic network as / in the form of one or more packets of data ("packets").

[0226] Clause 1.2 The method according to clause 1.1, wherein the transmission is performed via a public network such as the Internet; preferably, wherein:

[0227] The transmission is IPv6 transmission, IPv4 transmission, anycast transmission or multicast transmission.

[0228] Clause 1.3 A method according to clause 1.1 or 1.2, wherein the sending resource and / or the at least one receiving resource:

[0229] is a member of an anycast group; and / or

[0230] Is a member of the multicast group.

[0231] Clause Set 2:

[0232] Additionally or alternatively, one or more embodiments of the present disclosure may be defined according to the following clauses. Any of the clauses defined in Clause Set 2 may be combined with one or more clauses in any other clause set provided herein or any other features disclosed herein.

[0233] Clause 2.1 A method comprising:

[0234] The receiving resource sends a request for blockchain-related data to a sending address associated with a member of a sending resource group among a plurality of sending resource groups on the network; and

[0235] In response to the request, blockchain-related data is received from at least one sending resource of the group.

[0236] The sending address may be a sending anycast address or a multicast address. The method may be a computer-implemented data distribution method. Additionally or alternatively, the method may be an improved data transmission or exchange method, or an electronic communication method.

[0237] Clause 2.2 The method according to clause 2.1, wherein receiving the blockchain-related data includes: receiving the blockchain-related data from the at least one sending resource via unicast or multicast transmission.

[0238] Clause 2.3 A method according to clause 2.2 or 2.1, wherein receiving the blockchain-related data comprises: receiving the blockchain-related data from the at least one sending resource via anycast transmission.

[0239] Clause 2.4 A method according to any preceding clause, wherein the received blockchain-related data comprises one or more portions of blockchain-related data received from multiple members of the group.

[0240] Clause 2.5 A method according to clause 2.4, wherein each portion of blockchain-related data comprises a hash of the corresponding portion.

[0241] Clause 2.6 A method according to any of the preceding clauses, the method comprising: sending an anycast or multicast query transmission; and in response to the anycast or multicast query transmission, receiving (from the nearest sending resource) at least a portion of the following: a blockchain block, a blockchain transaction and / or a Merkle path.

[0242] Clause 2.7 A method according to any of the preceding clauses, wherein the sending address is associated with a sending resource that possesses a complete copy of the blockchain block.

[0243] Clause 2.8 The method according to clause 2.7, comprising: receiving an anycast or multicast query transmission from the (topologically) nearest receiving resource; and in response to the anycast or multicast query transmission, sending at least a portion of the following to the (topologically) nearest receiving resource: a blockchain block, a blockchain transaction and / or a Merkle path.

[0244] Clause 2.9 A method (e.g., a computer-implemented data distribution method), the method comprising: a sending resource sending blockchain-related data to a receiving address associated with a member of a receiving resource group among a plurality of receiving resource groups on a network. The receiving address may be an anycast or multicast address.

[0245] Clause 2.10 A method according to any of the preceding clauses, wherein the blockchain-related data comprises a hash of the data.

[0246] Clause 2.11 A method according to clause 2.9 or 2.10, the method comprising: de-allocating the transmission resources from a transmission address.

[0247] Clause 2.12 A method according to clause 2.12, wherein the de-allocation is performed in response to determining that a predetermined condition has been met (for example, the blockchain-related data has been sent to a predetermined number of receiving resources, and / or a certain time has passed, or a given date and time has been reached, etc.).

[0248] Clause 2.13 A method according to clause 2.12, wherein the de-allocating is performed in response to determining that a preselected time period has elapsed.

[0249] Clause Set 3:

[0250] Additionally or alternatively, one or more embodiments of the present disclosure may be defined according to the following clauses. Any of the clauses defined in Clause Set 3 may be combined with one or more clauses in any other clause set provided herein or any other features disclosed herein.

[0251] Clause 3.1. A computer-implemented method of distributing data, the method comprising:

[0252] Sending a portion of blockchain-related data from one (or at least one) sending resource on a network to one or more receiving resource groups on a certain / said network, wherein each of the one or more groups is associated with a corresponding multicast address. The network may be the Internet. In a preferred embodiment, all receiving resources in each group share a common multicast address unique to the group; each resource group has a corresponding multicast address, and all members of the group subscribe to the corresponding multicast address in order to receive multicast transmissions sent to the shared multicast address of the group.

[0253] The at least one sending resource may send the data portion via a transmission. The data portion may be sent to at least one receiving resource group in response to a request or as part of a request. The request may include a request for data. The request may include blockchain-related data, such as data related to one or more blockchain transactions or transaction IDs (TxIDs), one or more blockchain blocks or one or more block headers and / or at least a portion of a Merkle path or proof. The data may be sent via the Internet.

[0254] Clause 3.2. A method according to clause 3.1, wherein the sending resource and / or one, part or all of the receiving resources in at least one of the one or more groups are or include:

[0255] A node in a network; the network may be a blockchain network, the Internet or a telecommunications network; or a node in an overlay network, which is an overlay layer relative to the (underlying) blockchain network;

[0256] Computing resources associated with or controlled by a financial institution;

[0257] Merchant resources;

[0258] Cryptocurrency exchanges;

[0259] A computing resource configured to perform or facilitate SPV verification, or to use the results of SPV verification;

[0260] Blockchain-related service providers; and / or

[0261] Digital wallet.

[0262] Clause 3.3. A method according to clause 3.1 or 3.2, wherein the data comprises:

[0263] Communications or alerts related to blockchain-related events or activities.

[0264] Clause 3.4. A method according to clause 3.3, wherein the alert relates to a double spend or double spend attempt in the blockchain network.

[0265] Clause 3.5. A method according to any of the preceding clauses, wherein the blockchain-related data includes one, some or all of the following:

[0266] i) at least part of a blockchain transaction;

[0267] ii) at least a portion of a blockchain block;

[0268] iii) at least a portion of a blockchain transaction script;

[0269] iv) at least part of a Merkle path, Merkle tree, or Merkle proof;

[0270] v) data used or associated with the consensus mechanism of a blockchain network;

[0271] vi) the results of proof-of-stake or proof-of-work operations;

[0272] vi) The results of validation operations including blockchain block validation or SPV validation.

[0273] Clause 3.6. A method according to any of the preceding clauses, wherein:

[0274] The blockchain-related data is sent by the sending resource to the one or more receiving resource groups using multicast communication.

[0275] Clause 3.7. A method according to any of the preceding clauses, wherein:

[0276] i) the multicast address is an IP multicast address; and / or

[0277] ii) the multicast address is an IPv6 multicast address; and / or

[0278] iii) The blockchain-related data is sent to the one or more receiving resource groups via the Internet.

[0279] Clause 3.8. A method according to any of the preceding clauses, wherein:

[0280] Each of the one or more receiving host groups includes one or more receiving resources; and / or

[0281] Each receiving peer in a given receiving resource group is operable to receive data sent to the multicast address for the particular receiving resource group.

[0282] Clause 3.9. A method according to any of the preceding clauses, comprising the following steps:

[0283] Resource subscription receives resource group; preferably, wherein the resource is subscribed by sending a signal to a certain / said network; (the said network may be the Internet)

[0284] A resource leaves a group of receiving resources; preferably, wherein the resource leaves the group by ceasing to send signals to the network.

[0285] Clause 3.10. A method according to any of the preceding clauses, wherein:

[0286] The sending resource and / or at least one receiving resource in the at least one or more receiving resource groups is set to, configured to, and / or used to perform one or more of the following operations:

[0287] Functions specified by the blockchain protocol;

[0288] Computations or other operations related to mining or consensus functions specified in the blockchain protocol;

[0289] Simple Payment Verification (SPV) operations;

[0290] Compute or verify Merkle paths, proofs of Merkle paths, or roots;

[0291] Verify blockchain transactions before or after they are written to the blockchain;

[0292] Searching a blockchain to identify, locate, and / or confirm whether a given transaction or block exists in the blockchain;

[0293] Generate blockchain transactions, write transactions to the blockchain, and / or broadcast transactions to the blockchain network.

[0294] Clause 3.11. A method according to any preceding claim, comprising the steps of:

[0295] Polling each of the one or more groups to obtain a targeted response by sending the portion of blockchain-related data from the sending resource to the one or more groups of receiving resources.

[0296] Clause 3.12. A computer-implemented method comprising the steps of:

[0297] Send multicast communications to resource groups on the blockchain network.

[0298] Clause 3.13. The method according to clause 12, wherein at least one, some or all of the following apply:

[0299] i) the communication is sent from the sending resource to the resource group;

[0300] ii) the resource group is a multicast group, and one or part of the resources in the resource group are receiving resources of the multicast group;

[0301] iii) the communication involves a double spend or double spend attempt in the network;

[0302] iv) said communication is an alert.

[0303] Clause 3.14. A computer device, comprising:

[0304] a memory, the memory comprising one or more memory cells; and

[0305] A processing device comprising one or more processing units, wherein the memory stores code arranged to be executed on the processing device, the code being configured to perform a method according to any one of clauses 3.1 to 3.13 when executed on the processing device.

[0306] Clause 3.15. A computer program embodied on a computer readable memory and configured to, when executed on one or more processors, perform a method according to any one of clauses 3.1 to 3.13.

[0307] Clause Set 4:

[0308] Additionally or alternatively, one or more embodiments of the present disclosure may be defined according to the following clauses. Any of the clauses defined in Clause Set 4 may be combined with one or more clauses in any other clause set provided herein or any other features disclosed herein.

[0309] Clause 4.1. A method comprising the steps of:

[0310] Sending a multicast communication from a sending resource to at least one resource group, wherein preferably:

[0311] i) the sending resource and / or at least one resource in the at least one group is or includes:

[0312] Nodes on a blockchain network; and / or

[0313] a digital wallet or digital wallet provider; and / or

[0314] Cryptocurrency exchanges; and / or

[0315] Resources associated with one or more blockchain mining nodes; and / or

[0316] A service provider that is configured to provide blockchain-related services to one or more users.

[0317] Clause 4.2. A method according to clause 4.1, wherein:

[0318] i) the communication is sent via a public network, preferably the Internet; and / or

[0319] ii) the at least one resource group is a multicast group comprising member resources arranged or used to receive communications sent to a (multicast) address associated with the multicast group; and / or

[0320] iii) the communication involves a double spend or double spend attempt in the network; and / or

[0321] iv) the communication is an alert or other communication including blockchain-related data.

[0322] Clause Set 5:

[0323] Additionally or alternatively, one or more embodiments of the present disclosure may be defined according to the following clauses. Any of the clauses defined in Clause Set 5 may be combined with one or more clauses in any other clause set provided herein or any other features disclosed herein.

[0324] Embodiments disclosed herein may provide methods and techniques for improved electronic communication between resources on a network. The embodiments may be configured to ensure or improve the reliability of data exchange or transmission between parties. In one possible form of wording, such embodiments may include a method comprising one, some, or all of the following steps:

[0325] 1. Sending at least one data packet from one or more sending resources to one or more receiving resources via an electronic network. The one or more resources may be members of a multicast group. In other words, they may be subscribers to a common (shared) multicast address; additionally or alternatively, one or more of the receiving resources may be associated with a shared anycast address; in some cases, the one or more sending resources may also be associated with the shared multicast and / or anycast address; the at least one data packet may be sent to the shared multicast address.

[0326] 1.1. The at least one data packet can be received by at least one receiving resource among the receiving resources;

[0327] 1.2. The at least one receiving resource determines whether the at least one receiving resource should receive (or needs to receive) at least one other data packet after receiving the at least one data packet;

[0328] 1.3. Sending a request for the at least one other data packet from the at least one receiving resource to at least one other resource; preferably, wherein:

[0329] The at least one other resource is a member of the multicast group; and / or

[0330] The at least one other resource is a member of the anycast group; and / or

[0331] The request is sent using multicast transmission, anycast transmission or unicast transmission;

[0332] 1.4. The at least one other resource receives the request for the at least one other data packet from the at least one receiving resource;

[0333] 1.5. Sending the at least one other data packet from the at least one other resource to the at least one receiving resource; preferably, wherein the at least one data packet is sent to the at least one receiving resource using unicast transmission.

[0334] In alternative wording, such embodiments may be described as provided in the following clauses.Features of the foregoing method may be included in any of the following clauses, and vice versa.

[0335] Clause 5.1. A method comprising the steps of:

[0336] A request is sent from a (request) sending resource that is a member of a resource group to at least one other resource that is a member of the resource group, wherein preferably:

[0337] i) the request comprises a request for one or more data packets; and / or

[0338] ii) said request is sent due to incomplete reception of a data transmission sent to said transmission resource, preferably wherein the incomplete data transmission is sent to said transmission resource and / or said at least one other resource via or by a multicast transmission sent to said resource group; and / or

[0339] iii) the request is sent as any anycast transmission to the (topologically) nearest resource in the resource group relative to the sending resource; and / or

[0340] iv) the request is sent as any multicast transmission to the (topologically) nearest resource in the resource group; and / or

[0341] v) the request is sent due to incomplete reception (by the sending resource) of a data transmission sent (by the data sending resource) to the (requesting) sending resource, preferably wherein the request comprises a request for at least a portion of data (e.g. a data packet) which the (requesting) sending resource failed to receive due to the incomplete reception of the data transmission.

[0342] Clause 5.2. A method according to clause 5.1, wherein the sending resource and / or the at least one other resource is or includes:

[0343] Nodes on a blockchain network; and / or

[0344] a digital wallet or digital wallet provider; and / or

[0345] Cryptocurrency exchanges or their components; and / or

[0346] Resources associated with or in communication with one or more blockchain mining nodes; and / or

[0347] A service provider that is set up to provide blockchain-related services to one or more users; and / or

[0348] A resource configured to perform, facilitate, or use the results of an SPV verification. The resource may include software configured to perform or facilitate a Simplified Payment Verification (SPV) operation, or to process the results of an SPV operation.

[0349] Clause 5.3. A method according to clause 5.1 or 5.2, wherein:

[0350] i) the communication is sent via a public network, preferably the Internet; and / or

[0351] ii) the at least one resource group is a multicast group comprising member resources arranged or used to receive communications sent to a (multicast) address associated with the multicast group; and / or

[0352] iii) the communication involves a double spend or double spend attempt in the network; and / or

[0353] iv) the communication is an alert or other communication that includes blockchain-related data; and / or

[0354] v) the communication includes blockchain related data and / or at least a portion of a Merkle path or Merkle tree; and / or

[0355] vi) Data used to perform or facilitate SPV-style verification.

[0356] Clause 5.4. The method according to clause 5.1, 5.2 or 5.3, comprising the steps of:

[0357] One or more portions of data are provided from the other resource to the (requesting) sending resource.

[0358] Furthermore, according to one or more embodiments, a method may be provided, the method comprising:

[0359] In response to a request from a (requesting) sending resource, providing at least a portion of the data to the (requesting) sending resource; preferably, the (requesting) sending resource is a member of a resource group, and the at least a portion of the data is provided by or from other resources that are members of the resource group to the sending resource; and wherein, preferably:

[0360] i) the request comprises a request for one or more data packets; and / or

[0361] ii) said request is sent to said other resource due to incomplete reception of a data transmission sent to said sending resource, preferably wherein the incomplete data transmission is sent to said (requesting) sending resource and / or said at least one other resource via or by a multicast transmission sent to said resource group; and / or

[0362] iii) the request is sent as any anycast transmission to the (topologically) nearest resource in the resource group relative to the sending resource; and / or

[0363] iv) the request is sent as any multicast transmission to the (topologically) nearest resource in the resource group; and / or

[0364] v) the request is sent due to incomplete reception (by the sending resource) of a data transmission sent (by the data sending resource) to the (requesting) sending resource, preferably wherein the request comprises a request for at least a portion of data (e.g. a data packet) which the (requesting) sending resource failed to receive due to the incomplete reception of the data transmission.

[0365] Clause Set 6:

[0366] Additionally or alternatively, one or more embodiments of the present disclosure may be defined according to the following clauses. Any of the clauses defined in Clause Set 6 may be combined with one or more clauses in any other clause set provided herein or any other features disclosed herein.

[0367] Clause 6.1 A method comprising one or more of the following steps:

[0368] 1. Form or provide a network node group (set);

[0369] 2. Associating the node group with the multicast address; these nodes are now group members of the multicast, i.e., they listen to the multicast address; in another form of wording, steps 1 and 2 can be expressed as: one or more nodes join the multicast group;

[0370] 3. Promote / advertise / communicate available services and / or resources, wherein the promotion / advertisement / communicate of the services is performed by one or more nodes / members of the group to one or more recipients on a network; the network may or may not be a blockchain network; the communication may be or include an invitation to send data to the group members via the multicast address;

[0371] 4. The one or more nodes / members promote / advertise / communicate the shared multicast address of the group to the one or more recipients on the network; in one or more embodiments, this may include inviting or requesting the one or more recipients to send (e.g., blockchain-related) data to the group members at the group multicast address, for example, inviting or requesting a blockchain mining node to send one or more new blocks, or transactions, Merkle trees, etc., or parts thereof, to the shared multicast address of the group; in some embodiments, step 4 (i.e., sharing the multicast address) may be combined with step 3 (i.e., advertising the service to the recipients on the network);

[0372] 5. One or more nodes / members of the group promote / advertise / communicate a unique anycast address to the network recipients;

[0373] 6. Blockchain mining nodes mine new blocks or blockchain transactions;

[0374] 7. Sending the new block from the mining node to the shared multicast address of the group; it should be noted that in other embodiments, the data requested by the one or more group members and sent by the network recipient to the one or more group members may not include or be related to blockchain data, such as blocks or transactions; in some embodiments, the data may be any type of data, or may be blockchain-related data, such as all or part of a block, all or part of a transaction, data for consensus-related operations, data for verifying transactions and / or blocks, data for SPV-style verification, all or part of a Merkle tree / path, etc.;

[0375] 8. Routing the data (e.g., a block or a portion of a block) to all members of the multicast group; this may be performed over the Internet using IPv6 transport;

[0376] 9. intermittently sending requests from said one or more nodes / members to said anycast address of said multicast group; preferably, said requests include a unicast address of a sending node;

[0377] 10. Associating a node (member) with a previously promoted anycast address; preferably, wherein this operation is performed upon receipt of a new block or other type of data;

[0378] 11. The node / member sends a copy of the data (e.g., a block or a portion of a block) to the requesting node via a unicast transmission; this operation may be performed if a node with the anycast address (a member of the multicast group) receives a request for a copy of the new block;

[0379] 12. Unassigning the node / group member from the anycast address; in some examples, this is performed upon determining that a predetermined amount of time has elapsed or a predetermined criterion has been met;

[0380] 13. The nodes / group members listen for new data transmissions sent to the group's multicast address.

[0381] One or part of the above steps may be omitted or performed in an order different from the order described above, or may be combined with one or more other steps.

[0382] Clause Set 7:

[0383] Additionally or alternatively, one or more embodiments of the present disclosure may be defined according to the following clauses. Any of the clauses defined in Clause Set 7 may be combined with one or more clauses in any other clause set provided herein or any other features disclosed herein.

[0384] The method according to this embodiment may be substantially as described herein, particularly with respect to block header propagation. According to one possible form of wording, such an embodiment may include a computer-implemented method comprising the steps of: sending data from a sending node to a plurality of receiving nodes. Preferably, each of the receiving nodes is associated with an IPv6 multicast address. The data may include at least a portion of a block header of (for) a blockchain block; and a list of one or more blockchain transactions included in the blockchain block and related to the block header.

[0385] The method may further comprise the step of: at least one of the receiving nodes using the data to identify at least one other blockchain transaction (i.e., at least one "missing" transaction) that the at least one receiving node requires in order to generate the blockchain block. In other words, the at least one receiving node will only be able to generate a complete, exhaustive version or copy of the block if the at least one receiving node has a) a blockchain header and b) a complete list of the transactions contained in the blockchain block. Thus, the at least one receiving node may perform a check to identify any other transactions that it requires that are not included in the list sent by the sending node. Identifying the at least one other blockchain transaction may comprise searching for the at least one other blockchain transaction in a stored set of blockchain transactions. The stored set of transactions may be maintained by the at least one receiving node. Additionally or alternatively, the stored set of transactions may be accessible to or accessible by the at least one receiving node.

[0386] The method may include the steps of: obtaining the at least one other (missing) transaction from the stored set of blockchain transactions; and generating the blockchain block using the at least one other transaction and the list of one or more blockchain transactions.

[0387] However, if the at least one other transaction is not found in the stored transaction set, the method may include the following steps: sending a request for the at least one other blockchain transaction from the at least one receiving node to one or more of: the sending node; or the IPv6 multicast address; or one or more other nodes. The method may include the following steps: the sending node receiving the request from the at least one receiving node; and sending a transmission from the sending node to the at least one receiving node, the transmission including the at least one other blockchain transaction. The transmission may be a unicast transmission.

[0388] Additionally or alternatively, the embodiments may be described in the following clauses. Any features included in any of these clauses may also be incorporated into or combined with the aforementioned method steps, and vice versa.

[0389] Clause 7.1 A computer-implemented method comprising the steps of:

[0390] Sending a block header (at least a portion of it) and a list of one or more blockchain transactions and / or blockchain transaction identifiers (TxTD) from a sending node to a multicast address;

[0391] Preferably, wherein the (IPv6) multicast address is subscribed to by a plurality of receiving (ie, subscribing) nodes.

[0392] In some embodiments, at least one of the sending node and / or the receiving node is a node on a blockchain network. Preferably, the multicast address is an IPv6 multicast address.

[0393] Clause 7.2: The method according to clause 7.1, comprising the following steps:

[0394] at least one, but preferably all, of the receiving nodes using the received information to identify any one or more missing transactions required by the at least one receiving node in order to generate a complete block with the block header;

[0395] Preferably, wherein a transaction is a missing transaction if the transaction is in the list of one or more transactions but is not included in a set of transactions (eg, a member pool) maintained by and / or accessible by the at least one receiving node.

[0396] Clause 7.3: A method according to clause 7.1 or 7.2, comprising the following steps:

[0397] If the receiving node identifies any one or more missing transactions, sending a request for the one or more missing transactions or the one or more transaction identifiers from the at least one receiving node to the sending node (preferably by unicast transmission) or the multicast group (preferably by multicast or anycast transmission);

[0398] Preferably, said request comprises said corresponding one or more transaction identifiers (TxIDs) of the requested one or more missing transactions.

[0399] Clause 7.4: A method according to clauses 7.1, 7.2 and / or 7.3, comprising the following steps:

[0400] The sending node receives the request from the receiving node.

[0401] Clause 7.5: A method according to clauses 7.1, 7.2, 7.3 and / or 7.4, comprising the following steps:

[0402] A transmission is sent from the sending node to the receiving node, the transmission comprising the requested one or more missing transactions and / or one or more transaction identifiers; preferably, wherein the transmission is a unicast transmission; preferably, the unicast transmission is only sent to each receiving node that has sent the request.

[0403] The method may also include generating a blockchain block including the block header using the list of one or more transactions / TxIDs and at least one requested missing transaction and / or transaction identifier. This may be performed when the receiving node receives the transmission. The receiving node may then perform one or more blockchain-related operations (e.g., validation or verification operations).

[0404] Clause Set 8:

[0405] Additionally or alternatively, one or more embodiments of the present disclosure may be defined according to the following clauses. Any of the clauses defined in clause set 8 may be combined with one or more clauses in any other clause set provided herein or any other features disclosed herein.

[0406] Clause 8.1 A method comprising the steps of:

[0407] sending a transmission (communication) to a multicast address from a transmission resource having multicast listener device (MLD) snooping enabled over an electronic network; and wherein:

[0408] i) the transmission includes blockchain-related data; and / or

[0409] ii) the multicast address is associated with at least one receiving resource, the receiving resource being:

[0410] A node in a network; the network may be a blockchain network, the Internet or a telecommunications network;

[0411] Computing resources associated with or controlled by a financial institution;

[0412] Merchants control resources;

[0413] Cryptocurrency exchanges or their components;

[0414] A computing resource configured to perform or facilitate SPV verification, or to use the results of SPV verification;

[0415] Blockchain-related service providers; and / or

[0416] Digital wallets or their components; and / or

[0417] Resources for performing or facilitating simple payment verification (SPV) operations, or for processing the results of SPV operations;

[0418] iii) the transmission is or includes data relating to an alert, preferably wherein the alert is associated with, related to or configured for use by one or more nodes on the blockchain network; and / or

[0419] iv) the transmission includes:

[0420] Blockchain related data and / or at least a portion of a Merkle path or Merkle tree; and / or

[0421] Data used to perform or facilitate SPV-style verification, or to use the results of SPV verification.

[0422] One or more receiving resources may be associated with the multicast address. In other words: at least one receiving resource may subscribe to (i.e., listen to) the multicast address. The one or more receiving resources may be referred to as a multicast group. The multicast address may be an IPv6 address. The sending resource and / or the one or more receiving resources may be devices or systems on a network. The network may be a physical network or a logical network. The network may be a VLAN. The sending resource may be a multicast router.

[0423] Clause 8.2 A method according to clause 8.1, wherein the transmission resource is used to transmit the transmission to a list of one or more device ports on the electronic network that have indicated or signaled an interest or intent to receive the transmission.

[0424] The list may be an IPv6 multicast forwarding table or database.

[0425] Clause 8.3 A method according to clause 8.1 or 8.2, wherein:

[0426] i. The sending resource is configured and / or used to monitor the receiving resource and / or MLD message between multicast routers; and / or

[0427] ii. The sending resource may inspect or utilize the (monitored) MLD messages to generate a list of IPv6 addresses and corresponding network interfaces connected to the one or more receiving resources.

[0428] Clause 8.4 A method according to any preceding clause of clause set 8, wherein the sending resource is used to:

[0429] i) sending the transmission only to the network interfaces connected to the corresponding receiving resources associated with the multicast address (subscribed / listening for network traffic addressed to the multicast address); and / or

[0430] ii) not sending the transmission if no receive resources are associated with the multicast address.

[0431] Clause 8.5 A method according to any of the preceding clauses in Clause Set 8, wherein:

[0432] One or more of the receiving resources are used to send a membership report including a list of source addresses. The membership report can be sent in INCLUDE or EXCLUDE mode.

[0433] The sending resources and / or the receiving resources may be used to implement MLD snooping substantially as described in the art:

[0434] https: / / www.juniper.net / documentation / us / en / software / junos / multicast / topics / conc ept / mld-snooping-overview-l2.html.

[0435] Article Set 9

[0436] Additionally or alternatively, one or more embodiments of the present disclosure may be defined according to the following clauses. Any of the clauses defined in clause set 9 may be combined with one or more clauses in any other enumerated clause set provided herein or any other features disclosed herein.

[0437] However, in one or more embodiments, one, some or all of the sending nodes and / or receiving nodes in the group may be full nodes on the blockchain network or nodes on the overlay network, and the data may include unconfirmed transactions (their associated data) that have been verified but not yet written to the blockchain ledger. In such embodiments, systems and methods for implementing a memory pool (also referred to as a storage pool) may be provided, wherein the memory pool forms part of a blockchain network or an overlay network that interacts with the blockchain network, is provided in a blockchain network or an overlay network that interacts with the blockchain network, or is associated with a blockchain network or an overlay network that interacts with the blockchain network. This may be referred to herein as a "blockchain overlay network." According to https: / / wiki.bitcoinsv.io / index.php / Mining , it is known that “a memory pool is a temporary transaction repository and can be used to hold transactions grouped in different ways, such as transactions to be mined in the next block, transactions to be monitored, or transactions that cannot be mined due to nLocktime / nSequence locks.” Without limitation, the term memory pool as used in this article may include this definition.

[0438] In other embodiments, systems and methods for implementing UTXO sets may be provided.

[0439] Therefore, it is possible to provide:

[0440] Clause 9.1 A method for implementing a storage pool or UTXO set of a blockchain network, the method comprising the following steps:

[0441] sending a transmission from a sending resource to at least one receiving resource; or at least one receiving resource receiving a transmission from a sending resource,

[0442] in:

[0443] The sending resource and / or the at least one receiving resource is a node on a network; and

[0444] The transmission is sent using IPv6 multicast and includes at least a portion of a blockchain transaction.

[0445] In some embodiments, the at least a portion of a blockchain transaction may include the entire blockchain transaction. The transaction may have been verified (validated) by a validation entity that is configured to validate the transaction in accordance with a blockchain protocol. The transaction may be unconfirmed, awaiting successful mining into a block on the blockchain ledger associated with the blockchain protocol.

[0446] In some embodiments, the at least a portion of the blockchain transaction may include a UTXO.

[0447] Clause 9.2 A method according to clause 9.1, wherein:

[0448] i) the sending resource and / or the at least one receiving resource is a full or light node on a blockchain network; or

[0449] ii) The sending resource and / or the at least one receiving resource is a node on a blockchain overlay network.

[0450] Exemplary System Overview

[0451] For illustration purposes only and for reference Figures 1 to 4 , now provide an example of a computing environment in which one or more embodiments of the present disclosure may be implemented. The reference numerals mentioned below refer to Figures 1 to 4 .

[0452] Figure 1 An exemplary system 100 for implementing a blockchain 150 is shown. The system 100 may include a packet-switched network 101, typically a wide area network such as the Internet. The packet-switched network 101 includes a plurality of blockchain nodes 104, which 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. Therefore, each blockchain node 104 is highly connected to other blockchain nodes 104.

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

[0454] The blockchain 150 includes a series of data blocks 151, wherein a respective copy of the blockchain 150 is maintained at each of the plurality of blockchain nodes 104 in the distributed or blockchain network 106. As described above, maintaining a copy of the blockchain 150 does not necessarily mean storing the blockchain 150 in its entirety. Instead, the blockchain 150 can be pruned as long as each blockchain node 150 stores a block header (discussed below) for each block 151. Each block 151 in the blockchain includes one or more transactions 152, wherein a transaction in this context refers to a data structure. The nature of the data structure will depend on the type of transaction protocol used as part of the transaction model or plan. A given blockchain uses a particular transaction protocol throughout. In a common transaction protocol, the data structure of each transaction 152 includes at least one input and at least one output. Each output specifies an amount of a digital asset represented as a property, an example of which is an output that is cryptographically locked to a user 103 (requiring the user's signature or other solution to unlock, thereby redeeming or spending). Each input points to the output of a previous transaction 152, thereby linking these transactions.

[0455] Each block 151 also includes a block pointer 155, which points to a previously created block 151 in the blockchain to define the order of blocks 151. Each transaction 152 (except for the coinbase transaction) includes a pointer to a previous transaction to define the order of the transaction sequence (Note: the sequence of transactions 152 can branch). The blockchain of blocks 151 is traced back to the genesis block (Gb) 153, which is the first block in the blockchain. One or more original transactions 152 earlier in the blockchain 150 point to the genesis block 153, not to the previous transaction.

[0456] Each blockchain node 104 is configured to forward transactions 152 to other blockchain nodes 104, so that transactions 152 are propagated throughout the network 106. Each blockchain node 104 is configured to create blocks 151 and store corresponding copies of the same blockchain 150 in its corresponding memory. Each blockchain node 104 also maintains an ordered set (or "pool") 154 of transactions 152 waiting to be incorporated into block 151. Ordered pools 154 are often referred to as "memory pools". In this article, the term is not intended to be limited to any particular blockchain, protocol, or model. The term refers to a set of ordered transactions that a node 104 has accepted as valid, and for which the node 104 is forced to not accept any other transaction that attempts to spend the same output.

[0457] In a given current transaction 152j, an input (or each input) includes a pointer that references an output of a previous transaction 152i in the transaction sequence, specifying that the output is to be redeemed or "spent" in the current transaction 152j. In general, the previous transaction can be any transaction in the ordered set 154 or any block 151. Although the previous transaction 152i will need to exist and be verified to be valid in order to ensure that the current transaction is valid, the previous transaction 152i does not have to exist when the current transaction 152j is created or even sent to the network 106. Therefore, in this article, "previous" refers to the predecessor in the logical sequence linked by the pointer, and not necessarily the creation time or sending time in the time sequence, and therefore, does not necessarily exclude the situation where transactions 152i, 152j are created or sent out of order (see the discussion of orphan transactions below). The previous transaction 152i can also be called a predecessor transaction or a predecessor transaction.

[0458] The inputs of the current transaction 152j also include input authorizations, such as the signature of the user 103a to whom the outputs of the previous transaction 152i are locked. In turn, the outputs of the current transaction 152j may be cryptographically locked to the new user or entity 103b. Thus, the current transaction 152j may transfer the amounts defined in the inputs of the previous transaction 152i to the new user or entity 103b defined in the outputs of the current transaction 152j. In some cases, a transaction 152 may have multiple outputs to split the input amounts among multiple users or entities (one of which may be the original user or entity 103a for changes). In some cases, a transaction may also have multiple inputs to aggregate the amounts from multiple outputs of one or more previous transactions and reallocate them to one or more outputs of the current transaction.

[0459] According to an output-based transaction protocol, such as Bitcoin, when a party 103, such as an individual user or an organization, wishes to issue a new transaction 152j (either by an automated program employed by the party or manually), the issuing party sends the new transaction from its computer terminal 102 to a recipient. The issuing party or recipient will ultimately send the transaction to one or more blockchain nodes 104 of the network 106 (now typically a server or data center, but in principle it can also be other user terminals). It is also not excluded that the party 103 issuing the new transaction 152j can send the transaction directly to one or more blockchain nodes 104, and in some examples, the transaction may not be sent to the recipient. The blockchain node 104 receiving the transaction checks whether the transaction is valid according to the blockchain node protocol applied at each blockchain node 104. The blockchain node protocol typically requires the blockchain node 104 to check whether the cryptographic signature in the new transaction 152j matches the expected signature, which depends on the previous transaction 152i in the ordered sequence of transactions 152. In such an output-based transaction protocol, this may include checking whether the cryptographic signature or other authorization of the party 103 included in the input of the new transaction 152j matches the condition defined in the output of the previous transaction 152i assigned by the new transaction, wherein the condition typically includes at least checking whether the cryptographic signature or other authorization in the input of the new transaction 152j unlocks the output of the previous transaction 152i to which the input of the new transaction is linked. The condition may be defined at least in part by a script included in the output of the previous transaction 152i. Alternatively, this may be determined solely by the blockchain node protocol, or may be determined by a combination thereof. In either case, if the new transaction 152j is valid, the blockchain node 104 forwards it to one or more other blockchain nodes 104 in the blockchain network 106. These other blockchain nodes 104 apply the same test according to the same blockchain node protocol, and therefore forward the new transaction 152j to one or more other nodes 104, and so on. In this way, the new transaction is propagated throughout the network of blockchain nodes 104.

[0460] In the output-based model, the definition of whether a given output (e.g., UTXO) is allocated (e.g., spent) is whether it is validly redeemed by the input of another subsequent transaction 152j according to the blockchain node protocol. Another condition for the transaction to be valid is that the output of the previous transaction 152i that it attempts to redeem has not been redeemed by another transaction. Similarly, if invalid, the transaction 152j will not be propagated (unless marked as invalid and propagated for reminder) or recorded in the blockchain 150. This prevents double spending, that is, the transaction processor allocates the output of the same transaction more than once. On the other hand, the account-based model prevents double spending by maintaining account balances. Because there is also a defined transaction order, the account balance has a single defined state at any time.

[0461] In addition to verifying that transactions are valid, blockchain nodes 104 compete to be the first node to create a block of transactions in a process generally referred to as mining, which is supported by "proof of work". At a blockchain node 104, a new transaction is added to an ordered pool 154 of valid transactions that have not yet appeared in a block 151 recorded on the blockchain 150. The blockchain nodes then compete to assemble a new valid transaction block 151 of transactions 152 in the ordered transaction set 154 by attempting to solve a cryptographic puzzle. Typically, this involves searching for a "nonce" value such that when the nonce is juxtaposed with a representation of the ordered pool 154 of pending transactions and hashed, the output of the hash value satisfies a predetermined condition. For example, the predetermined condition may be that the output of the hash value has a certain predefined number of leading zeros. Note that this is only one specific type of proof of work puzzle, and other types are not excluded. A property of a hash function is that it has an unpredictable output relative to its input. Therefore, this search can only be performed by brute force, consuming a large amount of processing resources at each blockchain node 104 that attempts to solve the puzzle.

[0462] The first blockchain node 104 that solves the puzzle announces the puzzle solution on the network 106, providing the solution as proof, which can then be easily checked by other blockchain nodes 104 in the network (once a solution to the hash value is given, it is directly possible to check whether the solution satisfies the output of the hash value). The first blockchain node 104 propagates a block to other nodes that accept the block to reach a threshold consensus, thereby enforcing the protocol rules. The ordered set of transactions 154 is then recorded by each blockchain node 104 as a new block 151 in the blockchain 150. A block pointer 155 is also assigned to the new block 151n pointing to the previously created block 151n-1 in the blockchain. The large amount of work required to create a proof-of-work solution (e.g., in the form of a hash) signals the first node 104's intention to follow the blockchain protocol. These rules include not accepting a transaction as valid if it allocates the same output as a previously verified valid transaction, otherwise it is called a double spend. Once created, the block 151 cannot be modified because it is identified and maintained at each blockchain node 104 in the blockchain network 106. The block pointers 155 also impose an order on the blocks 151. Because transactions 152 are recorded in ordered blocks at each blockchain node 104 in the network 106, an immutable public ledger of transactions is provided.

[0463] It should be noted that the different blockchain nodes 104 competing to solve a puzzle at any given time may do so based on different snapshots of the pool 154 of transactions that have not yet been published at any given time, depending on when they began searching for a solution or the order in which they received the transactions. The person solving the corresponding puzzle first defines the transactions 152 included in the new block 151n and their order, and updates the current pool of unpublished transactions 154. The blockchain nodes 104 then continue to compete to create blocks from the newly defined ordered pool of unpublished transactions 154, and so on. In addition, there is a protocol to resolve any "forks" that may occur, where two blockchain nodes 104 solve puzzles within a short time of each other, thereby propagating conflicting views of the blockchain between the nodes 104. In short, the fork direction that is the longest becomes the final blockchain 150. It should be noted that this does not affect users or agents of the network, as the same transaction will appear in both forks.

[0464] According to the Bitcoin blockchain (and most other blockchains), a node that successfully constructs a new block 104 is granted the ability to newly allocate an additional, accepted amount of digital assets in a new special type of transaction that allocates an additional limited amount of digital assets (as opposed to an inter-agent or inter-user transaction, which transfers a certain amount of digital assets from one agent or user to another). This special type of transaction is often called a "coinbase transaction", but may also be called a "starting transaction" or "generating transaction". It usually forms the first transaction of a new block 151n. The proof of work signals the intention of the node that constructs the new block to follow the protocol rules, thereby allowing the particular transaction to be redeemed later. The blockchain protocol rules may require a maturation period, such as 100 blocks, before the special transaction can be redeemed. Typically, a regular (non-generating) transaction 152 will also specify an additional transaction fee in one of its outputs to further reward the blockchain node 104 that created the block 151n in which the transaction was published. This fee is often called a "transaction fee" and is discussed below.

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

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

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

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

[0469] The computer device 102 of each party 103 includes a corresponding processing device, which includes one or more processors, such as one or more CPUs, graphics processing units (GPUs), other accelerator processors, specific application processors and / or FPGAs. The computer device 102 of each party 103 also includes a memory, that is, a computer-readable memory in the form of a non-temporary computer-readable medium. The memory may include one or more memory units, which use one or more memory media, such as 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 computer device 102 of each party 103 stores software, which includes a corresponding instance of at least one client application 105 that is set to run on the processing device. It should be understood that any action attributed to a given party 103 in this article can be executed by software running on the processing device of the corresponding computer device 102. The computer device 102 of each party 103 includes at least one user terminal, such as a desktop or laptop computer, a tablet computer, a smart phone, or a wearable device such as a smart watch. The computer device 102 of a given party 103 may also include one or more other network resources, such as cloud computing resources accessed through a user terminal.

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

[0471] The client application 105 includes at least a "wallet" function. This has two main functions. One of the functions is to enable the corresponding party 103 to create, authorize (e.g., sign) and send transactions 152 to one or more Bitcoin nodes 104, which are then propagated in the network of blockchain nodes 104 and included in the blockchain 150. Another function is to report to the corresponding party the amount of digital assets it currently owns. In an output-based system, this second function includes collating the amounts defined in the outputs of various transactions 152 belonging to the relevant parties scattered in the blockchain 150.

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

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

[0474] When a given party 103 (say Alice) wishes to send a new transaction 152j to be included in the blockchain 150, she will formulate the new transaction according to the relevant transaction protocol (using the wallet function in her client application 105). She will then send the transaction 152 from the client application 105 to one or more blockchain nodes 104 to which she is connected. For example, this may be the blockchain node 104 that Alice's computer 102 is best connected to. When any given blockchain node 104 receives the new transaction 152j, it will process it according to the blockchain node protocol and its corresponding role. This includes first checking whether the newly received transaction 152j meets certain conditions for becoming "valid", specific examples of which will be discussed in detail later. In some transaction protocols, the validity conditions may be configurable on a per-transaction basis through a script included in the transaction 152. Alternatively, the conditions may simply be a built-in function of the node protocol, or defined by a combination of script and node protocol.

[0475] If the newly received transaction 152j passes the validity test (i.e., under the “valid” condition), any blockchain node 104 that receives the transaction 152j will add the new verified valid transaction 152 to the ordered transaction set 154 maintained at the blockchain node 104. Further, any blockchain node 104 that receives the transaction 152j will then propagate the verified valid transaction 152 to one or more other blockchain nodes 104 in the network 106. Since each blockchain node 104 applies the same protocol, it is assumed that the transaction 152j is valid, which means that the transaction will soon be propagated throughout the network 106.

[0476] Once in the ordered pool 154 of pending transactions maintained at a given blockchain node 104, that blockchain node 104 will begin racing to solve the proof-of-work puzzle on the latest version of its respective pool 154 containing the new transaction 152 (keep in mind that other blockchain nodes 104 can attempt to solve the puzzle based on different transaction pools 154. However, whoever solves the puzzle first will define the set of transactions included in the latest block 151. Ultimately, the blockchain node 104 will solve the puzzle for a portion of the ordered pool 154, which includes Alice's transaction 152j). Once the pool 154 including the new transaction 152j completes the proof-of-work, it will immutably become part of one of the blocks 151 in the blockchain 150. Each transaction 152 includes a pointer to an earlier transaction, so the order of transactions is also immutably recorded.

[0477] Different blockchain nodes 104 may initially receive different instances of a given transaction and therefore have conflicting views about which instance is “valid” before one instance is published in a new block 151, at which point all blockchain nodes 104 agree that the published instance is the only valid instance. If a blockchain node 104 accepts one instance as valid and then discovers that a second instance has been recorded in the blockchain 150, the blockchain node 104 must accept this and will discard (i.e., treat as invalid) the instance it originally accepted (i.e., the instance that has not yet been published in block 151).

[0478] Another type of transaction protocol operated by some blockchain networks as part of the account-based transaction model can be called an "account-based" protocol. In the account-based case, each transaction is defined not by reference to the UTXO of a previous transaction in the past sequence of transactions, but by reference to an absolute account balance. The current state of all accounts is stored individually in the blockchain by the nodes of the network and is continuously updated. In such systems, transactions are ordered using an account's running transaction record (also called a "position"). This value is signed by the sender as part of their cryptographic signature and hashed as part of the transaction reference calculation. In addition, optional data fields can also be signed in the transaction. For example, a data field can point to a previous transaction if it contains the ID of the previous transaction.

[0479] UTXO-based model

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

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

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

[0483] When Alice creates her new transaction Tx1, or at least when she sends it to the network 106, the previous transaction Tx0 may already be valid and included in block 151 of the blockchain 150. The transaction may already be included in one of the blocks 151 at this time, or it may still be waiting in the ordered set 154, in which case the transaction will be included in the new block 151 soon. Alternatively, Tx0 and Tx1 may be created and sent to the network 106 together; or, if the node protocol allows buffering of "orphan" transactions, Tx0 may even be sent after Tx1. The terms "previous" and "successor" as used herein in the context of transaction sequences refer to the order of transactions in the sequence defined by the transaction pointers specified in the transactions (which transaction points to which other transaction, etc.). They may equally be replaced by "predecessors" and "successors", "predecessors" and "descendants", or "parents" and "children", etc. This does not necessarily refer to the order in which they are created, sent to the network 106, or arrive at any given full blockchain node 104. However, subsequent transactions (descendant transactions or "child transactions") pointing to a previous transaction (predecessor transaction or "parent transaction") will not be valid unless the parent transaction is valid. A child transaction that arrives at the full blockchain node 104 before the parent transaction is considered an orphan transaction. Depending on the node protocol and / or node behavior, it may be discarded or buffered for a period of time to wait for the parent transaction.

[0484] One of the one or more outputs 203 of the previous transaction Tx0 includes a specific UTXO, labeled UTXO0. Each UTXO includes a value specifying the amount of digital assets represented by the UTXO and a locking script that defines the conditions that the unlocking script in the input 202 of the subsequent transaction must satisfy in order for the subsequent transaction to be valid and thus successfully redeem the UTXO. Typically, the locking script locks the amount to a specific party (the beneficiary of the transaction for that amount). That is, the locking script defines the unlocking condition, which typically includes the following conditions: the unlocking script in the input of the subsequent transaction includes the cryptographic signature of the party to which the previous transaction was locked.

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

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

[0487] When a new transaction Tx1 arrives at a full blockchain node 104, the node applies the node protocol. This includes running the locking script and the unlocking script together to check whether the unlocking script satisfies the conditions defined in the locking script (where the conditions may include one or more criteria). In an embodiment, this involves juxtaposing two scripts:

[0488] <Sig PA> <pa>||[Checksig PA]

[0489] Where "||" means concatenation, "<…>" means putting data on the stack, and "[…]" means a function consisting of locked scripts (in this case, a stack-based language). Similarly, scripts can be run one after another using a common stack instead of concatenating the scripts. In either case, when run together, the scripts use Alice's public key P A (included in the locking script of the output of Tx0) to verify that the unlocking script in the input of Tx1 contains Alice's signature when signing the expected portion of the data. The expected partial data itself (the "message") also needs to be included in order to perform this verification. In an embodiment, the signed data includes the entire Tx1 (so there is no need to include a separate element to plaintext specify the signed partial data, as it is already present).

[0490] Those skilled in the art will be familiar with the details of authentication via public-private cryptography. Basically, if Alice has signed a message using her private key cryptographically, then given Alice's public key and the message in plain text, other entities such as node 104 can authenticate that the message must have been signed by Alice. Signing typically involves hashing the message, signing the hash value, and marking this to the message as a signature, thereby enabling any holder of the public key to authenticate the signature. Therefore, it should be noted that in embodiments, any reference herein to signing a particular data fragment or transaction portion, etc., may mean signing the hash value of that data fragment or transaction portion.

[0491] If the unlocking script in Tx1 satisfies one or more conditions specified in the locking script of Tx0 (so, in the example shown, if Alice's signature is provided and authenticated in Tx1), then the blockchain node 104 considers Tx1 to be valid. This means that the blockchain node 104 will add Tx1 to the pending transaction ordered pool 154. The blockchain node 104 will also forward the transaction Tx1 to one or more other blockchain nodes 104 in the network 106 so that it will propagate throughout the network 106. Once Tx1 is valid and included in the blockchain 150, this will define UTXO0 from Tx0 as spent. It should be noted that Tx1 is only valid if it spends unspent transaction output 203. If it attempts to spend an output that has already been spent by another transaction 152, then Tx1 will be invalid even if all other conditions are met. Therefore, the blockchain node 104 also needs to check whether the UTXO referenced in the previous transaction Tx0 has been spent (that is, whether it has formed a valid input for another valid transaction). This is one of the reasons why it is important for the blockchain 150 to impose a defined order on transactions 152. In practice, a given blockchain node 104 may maintain a separate database marking the UTXO 203 of a transaction 152 as having been spent, but ultimately defining whether a UTXO has been spent depends on whether it has formed a valid input to another valid transaction in the blockchain 150.

[0492] If the total amount specified in all outputs 203 of a given transaction 152 is greater than the total amount pointed to by all its inputs 202, this is another basis for failure in most transaction models. Therefore, such a transaction will not be propagated or included in block 151.

[0493] Note that in the UTXO-based transaction model, a given UTXO needs to be spent as a whole. You cannot "leave behind" a portion of the amount defined in a UTXO as spent while spending another portion. However, the amount of a UTXO can be split between multiple outputs of subsequent transactions. For example, the amount defined in UTXO0 of Tx0 can be split between multiple UTXOs in Tx1. Therefore, if Alice does not want to give all of the amount defined in UTXO0 to Bob, she can use the remaining portion to make change for herself in the second output of Tx1, or to pay another party.

[0494] In practice, Alice will also typically need to include a fee for the Bitcoin node 104 that successfully includes Alice's transaction 104 in block 151. If Alice does not include such a fee, Tx0 may be rejected by the blockchain node 104, and therefore, although technically valid, may not be propagated and included in the blockchain 150 (if the blockchain node 104 does not want to accept transaction 152, the node protocol does not force the blockchain node 104 to accept). In some protocols, the transaction fee does not require its own separate output 203 (i.e., no separate UTXO is required). Instead, any difference between the total amount pointed to by input 202 and the total amount specified by output 203 of a given transaction 152 will be automatically provided to the blockchain node 104 that issued the transaction. For example, assume that a pointer to UTXO0 is the only input of Tx1, and Tx1 has only one output UTXO1. If the amount of the digital asset specified in UTXO0 is greater than the amount specified in UTXO1, the difference can be distributed by the node 104 that wins the proof-of-work competition to create a block containing UTXO1. Alternatively or additionally, this does not necessarily preclude that a transaction fee may be explicitly specified in one of the UTXOs 203 in the transaction 152 itself.

[0495] Alice and Bob's digital assets consist of the UTXO locked to them in any transaction 152 anywhere in the blockchain 150. Therefore, in general, the assets of a given party 103 are scattered among the UTXOs of various transactions 152 throughout the blockchain 150. No single number defining the total balance of a given party 103 is stored anywhere in the blockchain 150. The role of the wallet function of the client application 105 is to collate the various UTXO values ​​locked to the respective parties and not yet spent in other subsequent transactions. To achieve this, it can query a copy of the blockchain 150 stored at any one Bitcoin node 104.

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

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

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

[0499] Side Channel

[0500] like Figure 1 As shown, the client application on each of Alice and Bob's computer devices 102a, 120b can include additional communication functionality. This additional functionality enables Alice 103a to establish a separate side channel 107 with Bob 103b (at the instigation of any party or third party). Side channel 107 enables data to be exchanged away from the blockchain network. Such communications are sometimes referred to as "off-chain" communications. For example, this can be used to exchange transactions 152 between Alice and Bob without registering the transaction (yet) on the blockchain network 106 or publishing it on the chain 150 until one of the parties chooses to broadcast it to the network 106. Sharing transactions in this way is sometimes referred to as sharing "transaction templates". The transaction template may lack one or more inputs and / or outputs required to form a complete transaction. Alternatively or additionally, the side channel 107 can be used to exchange any other transaction-related data, such as keys, negotiation amounts or terms, data content, etc.

[0501] The side channel 107 may be established via the same packet switching network 101 as the blockchain network 106. Alternatively or additionally, the side channel 301 may be established via a different network such as a mobile cellular network or a local area network such as a wireless local area network, or even via a direct wired or wireless link between Alice's and Bob's devices 102a, 102b. In general, a side channel 107 referred to anywhere in this document may include any one or more links via one or more networking technologies or communication media that are used to exchange data "off-chain", i.e., off-chain. The link bundle or collection as a whole may be referred to as a side channel 107 in the case of multiple links. Therefore, it should be noted that if Alice and Bob are said to exchange certain information or data, etc., via a side channel 107, this does not necessarily mean that all of this data must be sent over exactly the same link or even the same type of network.

[0502] Client Software

[0503] Figure 3A An exemplary implementation of a client application 105 for implementing an embodiment of the disclosed solution is shown. The client application 105 includes a transaction engine 401 and a user interface (UI) layer 402. According to the solution discussed above and discussed in further detail later, the transaction engine 401 is configured to implement basic transaction-related functions of the client 105, such as formulating transactions 152, receiving and / or sending transactions and / or other data through the side channel 301, and / or sending transactions to one or more nodes 104 for propagation through the blockchain network 106.

[0504] The UI layer 402 is configured to present a user interface through a user input / output (I / O) mode of the corresponding user's computer device 102, including outputting information to the corresponding user 103 through the user output mode of the device 102, and receiving input from the corresponding user 103 through the user input mode of the device 102. For example, the user output mode may include one or more screens (touch or non-touch screen) that provide visual output, one or more speakers that provide audio output, and / or one or more tactile output devices that provide tactile output, etc. The user input mode may include, for example, an input array of one or more touch screens (which may be the same or different from that / those used for the output mode); one or more cursor-based devices such as a mouse, trackpad, or trackball; one or more microphones and voice or sound recognition algorithms for receiving voice or sound input; one or more gesture-based input devices for receiving input in the form of manual or physical gestures; or one or more mechanical buttons, switches, or joysticks, etc.

[0505] Note: Although various functions in this document may be described as being integrated into the same client application 105, this does not necessarily constitute a limitation. Instead, they can be implemented in a suite of two or more different applications, such as one application as a plug-in to another application or interfacing via an API (application programming interface). For example, the functionality of the transaction engine 401 can be implemented in a separate application rather than in the UI layer 402, or the functionality of a given module such as the transaction engine 401 can be split between multiple applications. At the same time, it is not excluded that some or all of the described functions can be implemented, for example, at the operating system level. Where a single or given application 105 or the like is referenced anywhere in this document, it should be understood that this is only by way of example, and more generally, the described functions can be implemented in any form of software.

[0506] Figure 3B A model is given of an example of a user interface (UI) 500 that may be presented by the UI layer 402 of the client application 105a on Alice's device 102a. It should be understood that a similar UI may be presented by the client 105b on Bob's device 102b or any other party's device.

[0507] By means of diagrams, Figure 3B The UI 500 is shown from Alice's perspective. The UI 500 may include one or more UI elements 501, 502, 503, which are presented as different UI elements through user output.

[0508] For example, the UI elements may include one or more user-selectable elements 501, which may be different buttons on a screen, different options in a menu, or the like. The user input method is configured to enable the user 103 (in this case, Alice 103a) to select or otherwise operate one of the options, such as by clicking or touching the UI element on the screen, or speaking the name of the desired option (Note: the term "manual" as used herein is only used to contrast with automatic, and is not necessarily limited to performing operations by hand).

[0509] Alternatively or additionally, the UI element may include one or more data entry fields 502 through which a user can perform ... These data entry fields are presented via a user output means, such as on a screen, and data may be entered into the fields via a user input means, such as a keyboard or touch screen. Alternatively, the data may be received verbally, such as based on speech recognition.

[0510] Alternatively or additionally, the UI element may include one or more information elements 503 that output information to the user. For example, this / these may be presented on a screen or audibly.

[0511] It should be understood that the specific manner in which various UI elements, selection options, and input data are presented is not important. The functions of these UI elements will be discussed in more detail later. It should also be understood that the UI 500 shown in Figure 3 is only a diagram model, and in practice, it may include one or more further UI elements, which are not described for the sake of brevity.

[0512] Node software

[0513] Figure 4 An example of node software 450 running on each full blockchain node 104 of the network 106 in an example of a UTXO-based or output-based model is shown. It should be noted that another entity may run the node software 450 without being classified as a node 104 on the network 106, i.e., not performing the actions required of the node 104. The node software 450 may include, but is not limited to, a protocol engine 451, a scripting engine 452, a stack 453, an application-level decision engine 454, and a collection of one or more blockchain-related functional modules 455. Each node 104 may run node software that includes, but is not limited to, all three of the following: a consensus module 455C (e.g., proof of work), a propagation module 455P, and a storage module 455S (e.g., a database). The protocol engine 401 is typically configured to identify different fields of a transaction 152 and process such fields according to the node protocol. When a transaction 152i (Tx m-1 )’s output (e.g., UTXO) is an input transaction 152j (Tx j ), the protocol engine 451 identifies Tx j The unlocking script in and passes it to the script engine 452. The protocol engine 451 also j Pointer in the input to identify and retrieve Tx i .Tx i may be published on blockchain 150, in which case the protocol engine may retrieve Tx from the copy of block 151 of blockchain 150 stored at node 104 i . Or, Tx i It can also be published on blockchain 150. In this case, protocol engine 451 can retrieve Tx from unpublished ordered transaction set 154 maintained by node 104. i Regardless of the method used, the script engine 451 will identify Tx i The locked script in the reference output is passed to the script engine 452.

[0514] Therefore, the script engine 452 has Tx i The locking script and the j The unlocking script for the corresponding input. For example, Figure 2 Transaction labels Tx0 and Tx1 are shown in FIG, but the same transaction can also be applied to any transaction pair. As previously described, the script engine 452 runs two scripts together, which will include placing data on and retrieving data from the stack 453 according to the stack-based scripting language used (e.g., script).

[0515] By running the scripts simultaneously, the script engine 452 determines whether the unlocking script satisfies one or more criteria defined in the locking script, i.e., whether the unlocking script unlocks the output including the locking script? The script engine 452 returns the result of the determination to the protocol engine 451. If the script engine 452 determines that the unlocking script does meet one or more criteria specified in the corresponding locking script, the result "TRUE" is returned. Otherwise, the result "FALSE" is returned.

[0516] In the output-based model, the result "TRUE" from the script engine 452 is one of the conditions for the validity of the transaction. Typically, one or more further protocol-level conditions evaluated by the protocol engine 451 must also be satisfied; for example, Tx j The total amount of digital assets specified in the inputs of tx does not exceed the total amount pointed to in its outputs, and tx i The pointed output of has not been spent by another valid transaction. The protocol engine 451 evaluates the result from the script engine 452 and one or more protocol-level conditions, and only if they are all TRUE, the protocol engine verifies the transaction Tx j The protocol engine 451 outputs an indication of whether the transaction is valid to the application-level decision engine 454. j Only when the conditions are really valid, the decision engine 454 can choose to control the consensus module 455C and the propagation module 455P at the same time to execute its Tx j . This includes the consensus module 455C, adding Tx to the corresponding ordered transaction set 154 of the node j , for incorporation into block 151; and propagation module 455P, Tx j Forwarded to another blockchain node 104 in the network 106. Optionally, in an embodiment, the application-level decision engine 454 may apply one or more additional conditions before triggering one or both of these functions. For example, the decision engine may choose to publish a transaction only if the transaction is valid and sufficient transaction fees are reserved.

[0517] In addition, it should be noted that in this article, the terms "TRUE" and "FALSE" are not necessarily limited to returning results that are expressed only in the form of a single binary number (bit), although this is indeed a possible implementation. More generally, "TRUE" can refer to any state indicating a successful or positive result, while "FALSE" can refer to any state indicating an unsuccessful or non-positive result. For example, in an account-based model, the combination of implicit protocol-level verification of signatures and additional positive outputs of smart contracts can be used to indicate that the result is "TRUE" (if both individual results are TRUE, the overall result is considered to be TRUE).

[0518] Disclaimer

[0519] It is not an admission that any reference cited or referred to herein constitutes prior art. The discussion of any such reference states the assertions of its authors, and the applicant reserves the right to challenge the accuracy and relevance of the cited documents. It should be clearly understood that although a number of prior art publications are referred to herein, such reference does not constitute an admission that any of these documents constitutes part of the common general knowledge in the art in the United Kingdom, the United States or any other country.

[0520] U.S. Patent Application 16 / 625,641, published as US2020 / 0162550, derived from PCT / IB2018 / 054501, is incorporated herein by reference. In addition, International Patent Application No. PCT / EP2023 / 051529 and any derivative applications filed in the United States are incorporated herein by reference.

[0521] To the maximum extent permitted by law, all references cited herein are incorporated by reference. The incorporation by reference of the above documents is subject to the limitation that the subject matter incorporated shall not be inconsistent with the content expressly disclosed herein. The incorporation by reference of the above documents is further limited that any claims contained in the documents are not incorporated by reference. The incorporation by reference of the above documents is again limited that any definitions provided in the documents are not incorporated by reference unless expressly included herein.< / pa>

Claims

1. A computer-implemented data distribution method, the method comprising: Sending a portion of blockchain-related data from a sending resource over a network to a multicast address associated with a group of receiving resources.

2. The method according to claim 1, wherein the sending resource and / or one, part or all of the receiving resources in the group are or include: Nodes in a blockchain network; A node in an overlay network, the overlay network being an overlay layer relative to the blockchain network; Set up as a service provider that provides blockchain-related services; Computing resources associated with or controlled by a financial institution; Cryptocurrency exchanges or their components; Merchant Resources or components thereof; Digital wallets or components thereof; A software component for performing or facilitating a simple payment verification (SPV) operation, or processing the results of an SPV operation; An MLDv1 host or MLDv2 host, network switch, or router on the network.

3. A method according to claim 1 or 2, wherein the data includes or relates to: Communications or alerts relating to blockchain-related events or activities; preferably, wherein the alerts relate to double spends or double spend attempts in a blockchain network.

4. The method according to any one of claims 1 to 3, wherein the network is or comprises the Internet.

5. A method according to any preceding claim, wherein the blockchain-related data comprises one, part or all of the following: i) at least part of a blockchain transaction; ii) at least a portion of a blockchain block; iii) at least a portion of a blockchain transaction script; iv) at least part of a Merkle path, Merkle tree, or Merkle proof; v) data used or associated with the consensus mechanism of a blockchain network; vi) the results of or related data from proof-of-stake or proof-of-work operations; vi) the results of, or other data related to, verification operations, including blockchain block verification or Simplified Payment Verification (SPV) operations.

6. A method according to any preceding claim, wherein: The blockchain related data is sent from the sending resource to the receiving resource group in the following manner: i) via multicast communications; and / or ii) According to the multicast forwarding table.

7. A method according to any preceding claim, wherein: i) the multicast address is an IP multicast address; and / or ii) the multicast address is an IPv6 multicast address; and / or iii) the blockchain-related data is sent to the receiving resource group via the Internet; iv) the sending resource is used to enable Multicast Listener Discovery (MLD) snooping; preferably, the method comprises the step of enabling MLD snooping by the sending resource.

8. A method according to any preceding claim, wherein: Each receiving resource in the receiving resource group is used to receive data sent to the multicast address of the receiving resource group.

9. A method according to any preceding claim, comprising the steps of: A resource subscribes to a receiving resource group; preferably, the resource subscribes by sending a signal to a network; A resource leaves a group of receiving resources; preferably, wherein the resource leaves the group by ceasing to send signals to a network.

10. A method according to any preceding claim, wherein: At least one receiving resource in the receiving resource group is set to, configured to and / or used to perform one or more of the following operations: Functions specified by the blockchain protocol; Computations or other operations related to mining or consensus functions specified in the blockchain protocol; Simple Payment Verification (SPV) operations; Compute a Merkle path, Merkle tree, or the root of a Merkle tree; Verify blockchain transactions before or after they are written to the blockchain; Searching a blockchain to identify, locate, and / or confirm whether a given transaction or block exists in the blockchain; Generate blockchain transactions, write transactions to the blockchain, and / or broadcast transactions to the blockchain network.

11. The method according to any of the preceding claims, wherein the receiving resource group is one receiving resource group among a plurality of receiving resource groups, and the method comprises the following steps: Each of the plurality of groups is polled to obtain a target response by sending the portion of the blockchain-related data from the sending resource to the plurality of receiving resource groups.

12. A method comprising: Sending a multicast communication from a transmission resource to at least one resource group, wherein the transmission resource and / or at least one resource in the at least one group is or includes: Nodes on a blockchain network; and / or a digital wallet or digital wallet provider; and / or Cryptocurrency exchanges or their components; and / or Resources associated with one or more blockchain mining nodes; and / or A service provider or its component that is configured to provide at least one blockchain-related service to one or more users; Merchant resources or components thereof, including digital wallets and / or for communicating with a blockchain network.

13. The method according to claim 12, wherein: i) said communications are sent via a public network, preferably the Internet; and / or ii) the at least one resource group is a multicast group comprising member resources, the member resources being arranged or used to receive communications sent to a multicast address associated with the multicast group; and / or iii) the communication involves a double spend or double spend attempt in the network; and / or iv) the communication is an alert or other communication that includes blockchain-related data; v) The communication includes blockchain related data and / or at least a portion of a Merkle path or a Merkle tree.

14. A computer-implemented method comprising the steps of: Data is sent from a sending node to a plurality of receiving nodes associated with a multicast address, the data comprising: At least a portion of a header of a blockchain block; and A list of one or more blockchain transactions contained in the blockchain block.

15. The method according to claim 14, comprising the steps of: using the data, by at least one of the receiving nodes, to identify at least one other blockchain transaction required by the at least one receiving node in order to generate the blockchain block; Preferably, the identification of the at least one other blockchain transaction comprises searching for the at least one other blockchain transaction in a stored blockchain transaction set maintained by the at least one receiving node and / or accessible to the at least one receiving node.

16. The method according to claim 15, comprising the steps of: A request for the at least another blockchain transaction is sent from the at least one receiving node to the sending node or the multicast address or one or more other nodes.

17. The method according to claim 16, comprising the steps of: The sending node receives the request from the at least one receiving node; as well as A transmission is sent from the sending node to the at least one receiving node, the transmission comprising the at least another blockchain transaction; preferably, wherein the transmission is a unicast transmission.

18. A computer device, comprising: a memory, the memory comprising one or more memory units; as well as A processing device comprising one or more processing units, wherein the memory stores a code arranged to be executed on the processing device, the code being configured to execute the method according to any one of claims 1 to 17 when executed on the processing device.

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

Images