Computer-implemented method and system for improving blockchain network communication

Abstract

Methods and techniques provided herein employ multicast and anycast transmissions to coordinate and distribute tasks and / or process requests between resource groups on a network. In one embodiment, the resource group may include nodes or other resources in a blockchain network that implement all or part of content of a particular blockchain protocol (e.g., a Bitcoin SV protocol), and / or service providers that provide services to blockchain-related organizations, groups, or networks.

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 such data between resources / entities that receive, process, and / or store blockchain-related 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 (or multicast transmission) enables the transmission of data packets to multiple destinations in a single send operation, which is native to the base specification of IPv6. For IPv6 multicast, data packets are sent to a multicast address corresponding to a group of devices, and then the data packets are routed to all devices in the group. On the other hand, IPv6 anycast transmission (or anycast transmission) enables a source resource to send a data packet to an anycast address corresponding to a group of devices, but the data packet is routed to only one device in the group (the device topologically closest to the sender).

[0006] Compared with other packet transmission / broadcasting methods such as unicast and broadcast, the combination of multicast and anycast 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 and anycast 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 data networks. 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, making 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, since certain embodiments may cover or intersect various technical fields, confusion may arise between the various terms.

[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 referenced 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 also 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.

[0014] The term "blockchain-related data" as used herein includes, but is not limited to, any data used, transmitted, received, stored, or otherwise processed with respect to or in order to implement operations, functions, or services performed by a blockchain protocol or blockchain-based application. Public, private, or permissioned blockchains also fall within the scope of this disclosure. Summary of the invention

[0015] The embodiments of the present disclosure provide a solution for transmitting data via a network. Preferably:

[0016] ● the solution may use IPv6 compliant data communications; and / or

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

[0018] The network may be 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, network resources can be associated to form one or more multicast groups, each of which has its own corresponding multicast address. A multicast address is a logical set identifier of network resources in a multicast group so that all network resources of the multicast group can receive data packets sent from a sending resource through a multicast transmission directed to the multicast address. In some embodiments, the multicast address can be an IPv6 multicast address or an IPv4 multicast address, and the data packets are sent and received via the Internet.

[0020] In one particularly advantageous example, the present disclosure may involve sending data from a sending resource to a multicast group of receiving resources. In a preferred embodiment, the data relates to at least a portion of a blockchain block and / or a blockchain transaction. In such examples, the sending resource only needs to send the data once so that all intended receiving resources receive a copy, rather than sending the data multiple times to each individual receiving resource as a unicast.

[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 node running a client according to the protocol and performing at least one of the following functions according to the requirements and provisions of the blockchain protocol: mining, verification, consensus, and blockchain maintenance functions. In some embodiments, the full node may include a memory pool for storing transactions before the transactions are written to the 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 in combination with the attached Figure 1 To Attachment Figure 4 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 a full blockchain node.

[0022] The receiving resources in each multicast group may be of various types, forms, configurations, or purposes, and the sending resources may be members of the multicast group or outside it. The present disclosure is not intended to limit the type or nature of the data being sent, nor is it intended to limit the purpose of sending the data. 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 may be provided for implementing a memory pool in a blockchain network or an overlay network that interacts with a blockchain network, or for implementing a memory pool associated with a blockchain network or an overlay network that interacts with a blockchain network.

[0023] Advantageous applications of the present disclosure may include, among other things, the ability to send data to a multicast group of network resources that provide distributed and / or parallel blockchain-related functions. For example, such functions may be mining functions, on-chain search functions, verification functions, computation providers such as service providers that perform proof-of-work computations and outputs, or work related to proof-of-stake, etc.

[0024] In another exemplary embodiment of the present disclosure, network resources can be associated to form one or more anycast groups, each of which has its own corresponding anycast address. An anycast address is a logical set identifier of network resources in an anycast group, so that one network resource in the anycast group (usually a network resource topologically closest to a sending resource) receives a data packet sent from the sending resource to the anycast address. In some embodiments, the anycast address can be an IPv6 anycast address, and the data is sent and received via the Internet.

[0025] In one particularly advantageous example, the present disclosure may involve sending data from a sending resource to an anycast group of receiving resources, the data relating to at least a portion of a blockchain block and / or blockchain transaction. In such examples, the sending resource sends the data to the anycast address of the group, and a routing function routes the data to a network resource of the anycast group (typically a network resource topologically closest to the sending resource) without requiring the sending resource to determine or select a single receiving resource in accordance with unicast. The receiving resources in the anycast group may be of various types, forms, configurations, or purposes, and the sending resource may be a member or external member of the anycast group. The present disclosure is not intended to limit the type or nature of the data being sent, nor the purpose for which the data is being sent.

[0026] Advantageous applications of the present disclosure may include, among other things, the ability to send data to one or more anycast groups of network resources that provide distributed and / or parallel 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 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 in combination with 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 faster or more efficient propagation of transactions through a conventional (underlying) blockchain network, but also involve an improvement in the throughput of transactions or blocks or parts thereof.

[0027] The methods and techniques provided in the embodiments use multicast transmission and anycast transmission to coordinate and distribute tasks and / or process requests between resource groups on the network. In one embodiment, the resource group may include nodes or other resources in the blockchain network that implement all or part of a specific blockchain protocol (e.g., the Bitcoin SV protocol).

[0028] In an embodiment, the methods and techniques may involve sending data (e.g., at least one data packet) from one or more sending resources to one or more receiving resources over an electronic network. The one or more receiving resources may be members of a multicast group associated with a particular multicast address; further, the one or more sending resources may be members of an anycast group associated with a particular anycast address.

[0029] In an embodiment, the methods and techniques may also involve at least one of the following operations:

[0030] - associating the first resource group with an anycast group having a specific anycast address; and / or

[0031] - associating the second resource group with a multicast group having a specific multicast address; and / or

[0032] - sending an initial message (i.e., one or more data packets) from a sending resource to a specific multicast address corresponding to a multicast group, the sending resource may or may not belong to the anycast group, the initial message including i) the specific anycast address of the anycast group, and ii) data related to one or more tasks or processing requests; and / or

[0033] - routing the initial message to each resource of the multicast group.

[0034] The phrase "assigning a multicast group to a group of resources" refers to the resources subscribing to (ie, joining) the multicast group, as is known in the art and explained herein.

[0035] In an embodiment, the method and technology may also involve, in response to receiving data (i.e., the initial message), at least one resource (receiving resource) belonging to the multicast group sending a response message (e.g., at least one data packet) to a specific anycast address corresponding to the anycast group, wherein the response message conveys an intention or willingness to perform or complete the one or more tasks or processing requests related to the received data (i.e., the initial message).

[0036] In an embodiment, the methods and techniques may also involve at least one of the following operations:

[0037] - routing the response message to a resource of the anycast group, the resource being topologically closest to the resource in the multicast group that sent the response message; and / or

[0038] - in response to receiving a response message, at least one resource of the anycast group determines which resource (receiving resource) in the multicast group that has sent the response message is topologically closest to the resource of the anycast group; and / or

[0039] - the resource of the anycast group uses a traceroute utility to determine which resource in the multicast group that has sent a response message is topologically closest to the resource used by the anycast group; and / or

[0040] - at least one resource of the anycast group collaborates with such topologically closest resource (receiving resource) of the multicast group to perform the one or more tasks or processing requests associated with the initial message and the response message; and / or

[0041] -Configure at least one resource (receiving resource) of the multicast group to decide not to respond to the initial message if the resource is busy or unable to perform or complete the one or more tasks or processing requests related to the initial message according to certain standards; and / or configure at least one resource (receiving resource) of the multicast group to decide not to respond to the initial message if the resource is unwilling to perform or complete the one or more tasks or processing requests related to the initial message according to other standards.

[0042] In an embodiment, the first resource group and / or the second resource group may include resources that verify one or more blockchain transactions, a pool of miners or a set of proof-of-work computing resources, resources that create transaction blocks using proof-of-work or proof-of-stake consensus, or resources that process data in some manner for blockchain-related purposes and / or cryptocurrency-related purposes.

[0043] In an embodiment, the one or more tasks or processing requests may involve blockchain transactions or other blockchain data.

[0044] In an embodiment, the one or more tasks or processing requests may involve:

[0045] - Verify one or more blockchain transactions;

[0046] - Use computational resources of proof-of-work or other consensus mechanisms such as proof-of-stake to mine transaction blocks;

[0047] -Create transaction blocks using proof-of-stake or proof-of-work consensus mechanisms;

[0048] - Processing or distributing data to one or more recipients (such as nodes in a network); the data may be an alert, executable code; software update or installation; a document or file; or another type of communication / data;

[0049] - Simple Payment Verification; or

[0050] Process the data in some way for blockchain-related purposes and / or cryptocurrency-related purposes. BRIEF DESCRIPTION OF THE DRAWINGS

[0051] 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:

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

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

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

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

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

[0057] 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.

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

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

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

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

[0062] 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.

[0063] 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 resource (ie, router / node) of the subscribed resource set.

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

[0065] 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.

[0066] 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.

[0067] 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.

[0068] 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.

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

[0070] Fig.16 is a flow chart illustrating an exemplary method for coordinating and distributing tasks and / or processing requests among resource groups on a network using multicast and anycast transmissions.

[0071] Fig.17A and Fig. 17B is a flow chart showing a portion of the method of FIG. 6 from the perspective of transmission resources belonging to an anycast group.

[0072] Fig.18A and Fig.18B It is shown from the perspective of the receiving resources belonging to the multicast group. Fig.16 Flowchart of a portion of a method. DETAILED DESCRIPTION

[0073] Figure 5An embodiment is shown in which network resources belonging to a multicast group communicate with each other for the purpose of safely, efficiently, and quickly distributing electronic data. In this illustrative embodiment, three groups of network resources 501 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 has one resource 501, and the third group has one hundred resources 501. As explained herein, a multicast group 502 is a group of resources that can be addressed by a single multicast address. A resource 501 that sends any type of data to another resource may be referred to as a sending resource in this article, and the data recipient may be referred to as a receiving resource.

[0074] Figure 5 Each of the three resource multicast groups is shown communicating with each other. 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 data requests from one or more recipients. Alternatively, the transmission may simply provide data to the recipient without including a request for a response. The present disclosure does not limit the nature, form, or type of action performed by the recipient after receiving the data from the sending resource. The transmission may be performed using multicast and / or anycast.

[0075] When using multicast transmissions, 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 all) resources that are members of the receiving multicast group receive the data.

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

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

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

[0079] 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.

[0080] 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.

[0081] IPv6 Address:

[0082] 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.

[0083] 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:

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

[0085] 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.

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

[0087] 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

[0088] Table 1

[0089] Multicast:

[0090] Multicast is a one-to-many network communication solution in which a sending resource transmits a single data packet to a multicast address corresponding to a multicast group with multiple resources / destinations. The sending resource sends only one copy of the data to the multicast address. After the data is replicated at the applicable connection point in the network, resources that have subscribed to the multicast group 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 if all members of the multicast group receive a 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.

[0091] like Figure 6c As 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:adcd) 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.

[0092] refer to Figure 7 , unicast communication 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.

[0093] For multicast transmission, 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 server join the multicast group for that multicast address. This is called their "subscription".

[0094] When a packet is sent from a server, it is routed across the Internet to a multicast address (e.g. Figure 8Figure 4 shows a multicast transmission from a server to subscribers PC1 and PC2). Once the packet arrives, subscribers (e.g., PC1 and PC2) are able to retrieve the data, while non-subscribers PC3 and PC4 ignore the packet. This multicast transmission reduces the need to send two separate packets from the server to PC1 and PC2. A separate copy of the packet is created only when it arrives at RLocal. In order for the multicast packet to reach PC1, resource PC1 must report to RLocal that it wishes to join the 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 forwards the packet to R1, which then passes the packet to RLocal, which then passes the packet to PC1.

[0095] Anycast

[0096] IPv6 anycast transmission can be used in networks where multiple resources / destinations share a common IPv6 anycast address. As shown in Table 1 above, the anycast address shares the same prefix as the global unicast address. For example:

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

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

[0099] If a packet is sent by a sending resource to an anycast address, the packet is forwarded to the topologically closest or nearest resource in the set of resources corresponding to the anycast address. While geographic distance is a factor in determining the topologically closest resource, there are other factors that play a role in the calculation: number of hops, efficiency, latency, and cost. Finally, for anycast transmissions, only one resource is expected to receive the packet, which is often described as a one-to-nearest transmission.

[0100] Fig. 9An anycast transmission from a server to router R3 is shown, and it can be seen that the packet is sent to the anycast address 2001:db8: / 32 shared by at least three routers (R1, R3, and RLocal). The closest of these routers is R3, so the packet is sent to R3. It should be remembered that "closest" does not necessarily mean geographically close.

[0101] Illustrative Embodiments

[0102] Turning now to a discussion of illustrative embodiments of the present disclosure, and referring to Figure 5 to Figure 1 9, provides a scheme for distributing data quickly, securely and scalably on a 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, 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.

[0103] Each group is associated with a corresponding group identifier, which serves as a unique address to which data can be sent.

[0104] For multicast transmission, the group is a multicast group, and all resources in the multicast group are associated with the multicast address of the group, and can therefore receive data sent from a sender to the multicast group address. The multicast address can be an IPv6 multicast address or an IPv4 multicast address. The multicast address can be used to implement one-to-many communication because the sending resource only needs to send a data packet to the multicast address once, and each resource in the multicast group can receive the data packet, rather than sending a data packet to each resource in a one-to-one communication (such as is done in unicast transmission).

[0105] A receiving resource can subscribe to (i.e., join) a multicast 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 multicast group, the resource can receive multicast packets sent to the multicast address of the multicast group. Thus, a resource can dynamically join or leave a multicast group at any time by simply signaling the network to join or stop joining the multicast group.

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

[0107] For anycast transmission, the group is an anycast group associated with the anycast address of the group. The anycast address is a logical set identifier of network resources in the anycast group so that one resource of the anycast group (usually a resource that is topologically closest or proximate to a sending resource) receives a data packet sent from the sending resource to the anycast address via anycast transmission. In some embodiments, the anycast address may be an IPv6 anycast address, and the data is sent and received via the Internet. The anycast group address may be used to effectively implement 1-to-closest-of-many communication.

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

[0109] 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.

[0110] 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.

[0111] 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:

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

[0113] Distribution of blockchain-related data:

[0114] In a 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 way 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, mining pools, service providers that provide support functions for cryptocurrency-related organizations or blockchain-related organizations, and the like.

[0115] 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.

[0116] For the Bitcoin network, each full node 104 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 random number 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:

[0117] ● Transaction Propagation:

[0118] 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 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.

[0119] ● Block Propagation:

[0120] 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.

[0121] 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.

[0122] 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.

[0123] 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.

[0124] Block header propagation

[0125] 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.

[0126] 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.

[0127] Data distribution using IPv6 multicast transmission:

[0128] According to some embodiments, IPv6 communication of data packets may be employed to facilitate block distribution through or in a blockchain network. Fig.11 An example of the distribution of mined blocks from node 5 to a network of nodes using multicast transmission 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.

[0129] exist Fig.11In the example of , blockchain node 4 receives Bitcoin transactions from PC1, PC2, and node 5, and is able to successfully produce a mined block, which 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 the address, the block is replicated and a copy is sent to the subscribers node 1 and node 2.

[0130] 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.

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

[0132] 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;

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

[0134] 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;

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

[0136] 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.

[0137] 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.

[0138] Using IPv6 multicast transmission, the sending resource is able to enable MLD snooping. This enables the sending resource to selectively transmit packets only to those resources that have indicated a desire to receive the packets. This means that the transmission of blockchain-related or related data can be effectively targeted to specific destinations. 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 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 partially 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.

[0139] 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.

[0140] 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.

[0141] Data distribution using IPv6 anycast transport:

[0142] Anycast transmissions are 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, when obtaining a copy of a newly mined block, can choose to join an anycast group associated with an anycast address. This essentially means assigning oneself (i.e., a network interface) to an anycast address. 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 group associated with the anycast address. This closest node will then send a copy of the mined block directly (using unicast) to the requesting node.

[0143] 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.

[0144] exist Fig.12In this case, the closest node is node 1. Then, if selected, node 1 will send a copy of the block to node 5 via unicast communication. Given that the closest node is selected, this means that node 1 is likely to receive a full copy of the block faster.

[0145] However, it should be noted that the "closest" node can depend on several factors other than geographic proximity; for example, latency and cost can be used 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.

[0146] 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).

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

[0148] Fig.13 An illustration of using a combination of multicast transmission and anycast transmission for block distribution is provided. In such an embodiment, the use of the previously described multicast transmission and anycast transmission 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.

[0149] 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.

[0150] 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:

[0151] 1. 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).

[0152] 2. 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.

[0153] 3. 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.

[0154] 4. 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.

[0155] 5. 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.

[0156] 6. Nodes (can be associated or unassociated) mine new blocks.

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

[0158] 8. The block (or block header and transaction) is routed via IPv6 to all members of the multicast group; in other words, the data is sent to the multicast address via multicast transmission.

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

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

[0161] 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.

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

[0163] In case of anycast transport:

[0164] 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.

[0165] 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).

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

[0167] 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.

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

[0169] 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.

[0170] It should be noted that:

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

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

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

[0174] 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.

[0175] 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.

[0176] consider Fig.14 , which provides an example of blockchain-related data distribution using anycast transmission based on geographical location and multicast transmission of block-related data. The 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.

[0177] 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.

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

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

[0180] 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.

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

[0182] “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.

[0183] 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.”

[0184] 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.

[0185] 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.

[0186] 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 validation on a transaction and need to share information about the Merkle path and block headers for SPV validation. Block discovery creates hash headers or block headers. These are sent to all SPV nodes. Using multicast transmissions can deliver this data in a near-instantaneous communication manner.

[0187] 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.

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

[0189] 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.

[0190] 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.

[0191] 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:

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

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

[0194] Simple Payment Verification (SPV) operations;

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

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

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

[0198] Example use case 3: Resolving packet loss

[0199] 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 ).

[0200] For example, assume that a multicast transmission including 10 packets is sent to the multicast group, but a particular group member (which may be referred to as a receiving resource) receives only 8 of the 10 packets sent. The receiving resource loses packets 2 and 7. The receiving resource can obtain the lost packets by using an anycast transmission to request the lost 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.

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

[0202] 1. Use multicast transmission to send a portion of the data (multiple packets) from the sending resource to the resource group associated with the multicast address;

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

[0204] 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

[0205] 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).

[0206] 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.

[0207] Use multicast and anycast transports to coordinate and distribute the execution of tasks and / or processing requests

[0208] According to some embodiments, multicast transmission and anycast transmission can be used to coordinate and distribute tasks and / or processing requests between resource groups on the network. In one embodiment, the resource group may include a full (mining) node 104 running client software for a given protocol, or other resources of a blockchain network, such as a light node that implements all or part of a specific blockchain protocol (e.g., Bitcoin SV protocol). These nodes may include wallets. In some embodiments, the node may be a node of an overlay network that covers the blockchain network, a node in an overlay network, or a node on an overlay network. In such examples, the overlay node is not a full mining node 104. For example, the resource group may include a pool of miners or a set of PoW computing resources, or resources that process data in some way for blockchain-related purposes and / or cryptocurrency-related purposes. For example, these resources may include digital wallet providers, cryptocurrency exchanges, banks and financial institutions, distributed verification providers, etc. In this embodiment, the task and / or processing request may involve blockchain transactions or other blockchain data, such as verifying one or more blockchain transactions, mining transaction blocks using proof-of-work computing resources, or creating transaction blocks using a proof-of-stake consensus mechanism, simple payment verification, or processing data in some way for blockchain-related purposes and / or cryptocurrency-related purposes.

[0209] Fig.16 An illustration of a method for coordinating and distributing tasks and / or processing requests among resource groups on a network using multicast transmissions and anycast transmissions is provided.

[0210] The method begins at 1601 when a number of resources join (or are otherwise associated with) an anycast group. The anycast group is associated with an anycast address of the anycast group.

[0211] In 1603, one of the resources of the anycast group (or some other resource that does not need to be part of the anycast group) (i.e., the sending resource) sends an initial message to one or more multicast groups via multicast transmission. The initial message is represented by one or more data packets. The initial message is sent to the multicast address of each given multicast group. The initial message includes the anycast address of the anycast group and data related to one or more tasks or processing requests.

[0212] In 1605, resources belonging to the multicast group receive the initial message, and each corresponding resource of the multicast group decides whether it wants or can respond to the initial message to convey the intention, ability or willingness to perform or complete the one or more tasks or processing requests related to the initial message. A given resource of the multicast group may ignore the initial message if:

[0213] 1. The resource is busy or unable to perform or complete the one or more tasks or processing requests associated with the initial message according to certain criteria; or

[0214] 2. The resource is unwilling to perform or complete the one or more tasks or processing requests associated with the initial message based on other criteria. For example, the processing request may not comply with policies or rules within or implemented by its organization.

[0215] In 1607, each resource in the multicast group that wishes to respond to the initial message (i.e., a responding resource) sends a response message to the anycast group via anycast transmission. The response message is represented by one or more data packets. The response message is sent to the anycast address of the anycast group. The response message is routed to the resource in the anycast group that is topologically closest to the responding resource.

[0216] In 1609, one or more resources of the anycast group receive one or more response messages and determine which response resource in the multicast group that has sent the response message is topologically closest to the resource of the anycast group, and then cooperate with such topologically closest response resource to perform the one or more tasks or processing requests related to the initial message / response message. In an embodiment, the topologically closest response resource can transmit a data packet including the execution results of the one or more tasks or processing requests to the anycast group by sending such data packet to the anycast address of the anycast group. The resource in the anycast group that receives such data packet can then forward such data to other resources of the anycast group using multicast transmission or alternatively using unicast (direct) transmission.

[0217] The method can coordinate and distribute tasks and / or processing requests between resources of two groups (anycast group and multicast group) that are topologically closest to each other. This may be advantageous in a distributed environment where the speed of network communication (or minimization of network latency) between resources of the two groups may affect the operation, efficiency, and / or economic rewards given to the resources. For example, in a blockchain network where the resource groups include a pool of miners or a set of PoW computing resources operating as part of the blockchain network consensus mechanism, the coordination and distribution of tasks and / or processing requests can minimize network latency between resources to improve the computational efficiency of the resources, with the goal of maximizing the economic rewards of the resources as part of the consensus mechanism (e.g., resources are rewarded for winning a race to assemble a new valid transaction block by solving a cryptographic puzzle).

[0218] Fig.17A and Fig. 17B Shown as Fig.16Part of the method includes operation of a receiving resource configured to listen for and receive an initial message transmitted over a network using a multicast transmission.

[0219] In 1701, a resource joins a resource multicast group identified by a multicast address.

[0220] In 1703, the resource listens for an initial message sent to the multicast group address.

[0221] In 1705, the resource receives an initial message from a sending resource (see 1603). The initial message is sent to the multicast address of the multicast group. The initial message includes the anycast address of a specific anycast group (used in the response message) and data related to one or more tasks or processing requests.

[0222] In 1707, the resource decides whether it wishes to respond to the initial message to convey an intention, ability, or willingness to perform or complete the one or more tasks or processing requests associated with the initial message. The resource may ignore the initial message if:

[0223] 1. The resource is busy or unable to perform or complete the one or more tasks or processing requests associated with the initial message according to certain criteria; or

[0224] 2. The resource is not willing to perform or complete the one or more tasks or processing requests associated with the initial message based on other criteria.

[0225] At 1709, if the resource decides to respond to the initial message, the operation of the resource continues to 1711. Otherwise, the operation of the resource returns to 1703 to listen for, receive, and process one or more other initial messages.

[0226] In 1711, the resource acts as a response resource and sends a response message to a specific anycast group (using the anycast address specified in the initial message) via anycast transmission. The response message is sent to the anycast address of the specific anycast group (extracted and copied from the initial message). The response message is routed to the resource in the specific anycast group that is topologically closest to the response resource.

[0227] In 1713, the resource (i.e., the responding resource) waits for further messages from resources of the specific anycast group and then performs the one or more tasks or processing requests associated with the initial message / response message. The further message may be sent from the anycast group member that is topologically closest to the responding resource.

[0228] Fig.18A and Fig.18B Shown as Fig.16 The method includes operating a sending resource as part of the process, the sending resource being configured to generate and send an initial message for transmission over a network using multicast transmission.

[0229] In 1801, a number of resources join (or are otherwise associated with) a specific anycast group. The specific anycast group is associated with a unique anycast address of the specific anycast group.

[0230] In 1803, one of the resources of the specific anycast group (or another resource that does not need to be part of the specific anycast group) (i.e., the sending resource) generates an initial message for one or more multicast groups via multicast transmission. The initial message includes the anycast address of the specific anycast group (used in the response message) and data related to one or more tasks or processing requests.

[0231] In 1805, the sending resource sends the initial message to the multicast group via multicast transmission. The initial message is sent to the multicast address of each given multicast group.

[0232] In 1807, the resources of the specific anycast group wait to receive one or more response messages in response to the initial message.

[0233] In 1809, when no response message from at least one resource of the multicast group is received within the predetermined time period, the operation proceeds to 1811. Otherwise (in the case where a response message from at least one resource of the multicast group is received within the predetermined time period), the operation proceeds to 1813.

[0234] In 1811, one of the resources of the specific anycast group (or another resource that does not need to be part of the specific anycast group (e.g., the same or different sending resource)) generates a new initial message containing an update of data related to one or more tasks or processing requests, and the operation returns to 1805 to 1809 to send the new initial message to one or more multicast groups via multicast transmission and listen for and process response messages related thereto. For example, the payment amount can be updated to increase the reward for performing the task, or the original parameters or criteria contained in the initial message can be changed.

[0235] In 1813, each given resource in the specific anycast group that has received one or more response messages determines which resource in the multicast group that has sent the response message is topologically closest to the given resource of the specific anycast group. Such operations can use the traceroute tool, which is a command line tool available in most operating systems. The tool provides a complete path to the destination address and also displays the time (or delay) spent between intermediate routers in the path. The output of traceroute represents the number of hops and delays in the path to the destination address. This information can be collected for the path to each resource in the multicast group that has sent a response message, and such information can be processed to determine which resource in the multicast group that has sent the response message is topologically closest to the given resource of the specific anycast group. In addition or alternatively, other suitable network tools can also be used.

[0236] In 1815, the given resource of the specific anycast group collaborates with the topologically closest resource of the multicast group determined in 1813 to perform the one or more tasks or processing requests related to the initial message / response message.

[0237] In an embodiment, the one or more tasks or processing requests may involve blockchain transactions, blockchain blocks, or other blockchain-related data, and may be configured to perform or involve the following operations: verifying one or more blockchain transactions, mining transaction blocks using proof-of-work computing resources, or creating transaction blocks using a proof-of-stake consensus mechanism, simple payment verification, or processing data in some manner for blockchain-related purposes and / or cryptocurrency-related purposes, etc.

[0238] List the terms

[0239] 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.

[0240] 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.

[0241] In one possible wording form, the method may include one, some or all of the following steps:

[0242] sending an initial message from a sending resource to a group of at least one receiving resource subscribed to a resource multicast group; the initial message is sent to a multicast address associated with the resource multicast group and includes an anycast address associated with the resource anycast group and data related to a task to be performed;

[0243] A group of at least one receiving resource subscribed to a resource multicast group receives an initial message from a sending resource; the initial message is sent to a multicast address associated with the resource multicast group and includes an anycast address associated with the resource anycast group and data related to a task to be performed;

[0244] sending a corresponding response message to the anycast address from at least one of the receiving resources;

[0245] receiving, at the resource anycast group, the response message from the at least one receiving resource;

[0246] For each (corresponding) resource in the resource anycast group: determining which of the at least one receiving resource that has sent a response message is topologically closest to the (corresponding) resource in the anycast group;

[0247] According to the determination result of the previous step, determining which of the receiving resources is topologically closest to the resource anycast group (the identified specific member);

[0248] sending a confirmation message from the (identified specific) member of the anycast group to a receiving resource (i.e., a topologically closest resource in the resource multicast group), the confirmation message comprising data confirming the ability, intent, or willingness of the (identified specific) resource in the resource anycast group to collaborate with the topologically closest receiving resource to perform a task;

[0249] the receiving resource (i.e., the resource in the resource multicast group that is topologically closest to the (identified specific) member of the anycast group) receiving a confirmation message from the (identified specific) member of the anycast group, the confirmation message including data confirming the ability, intent, or willingness of the (identified specific) resource in the resource anycast group to collaborate with the topologically closest receiving resource to perform a task;

[0250] The task is performed at, by, or on behalf of a topologically closest receiving resource.

[0251] Some or all of the receiving resources may be full nodes 104 on the blockchain network, or nodes in an overlay network, which are located above one or more full nodes on the blockchain network but communicate with the one or more full nodes on the blockchain network. The sending resources may be full blockchain nodes 104, or nodes on a blockchain overlay network, which are located above one or more full nodes on the blockchain network but communicate 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.

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

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

[0254] This article also discloses:

[0255] ● 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

[0256] ● 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.

[0257] Clause Set 1:

[0258] Embodiments disclosed herein may provide methods and techniques for coordinating and distributing tasks and / or processing requests between resource groups on a network using multicast transmission and anycast transmission. In one embodiment, the resource group may include nodes or other resources in a blockchain network that implement all or part of a particular blockchain protocol (e.g., the Bitcoin SV protocol). Embodiments may be configured to minimize network latency between resources to improve the computational efficiency of the resources.

[0259] Clause 1a: In one possible wording, such embodiments may include a method having one or more of the following steps:

[0260] associating the first resource group with an anycast group having a specific anycast address;

[0261] Sending an initial message from a sending resource to a specific multicast address, the initial message including i) the specific anycast address of the anycast group, and ii) data related to one or more tasks or processing requests;

[0262] In response to receiving the initial message, at least one resource belonging to the multicast group sends a response message to the specific anycast address corresponding to the anycast group, wherein the response message conveys acceptance of the one or more tasks or processing requests related to the initial message.

[0263] The multicast address corresponds to a multicast group (of computing resources) associated with the particular multicast address.

[0264] The method may also include the step of associating the second resource group with a multicast group having a specific multicast address. This may include each member (i.e., resource) of the second resource group subscribing to the multicast address. In other words, each member of the second resource group joins the multicast group associated with the multicast address.

[0265] The accepting of the one or more tasks or processing requests may include communicating an ability, intention, or willingness to perform or complete the one or more tasks or processing requests associated with the initial message.

[0266] The initial message may include one or more of a description of at least one task or process to be performed, a payment or reward associated with performance of the task or process, data, values, parameters and / or metadata related to the task / process.

[0267] The accepting may include a request for further data related to the at least one task or process.

[0268] Clause 1b:

[0269] In an alternative or additional wording, such embodiments may include a method having one, some or all of the following steps:

[0270] Data (e.g., at least one data packet) is sent from one or more sending resources to one or more receiving resources via an electronic network; the one or more receiving resources may be members of a multicast group associated with a particular multicast address; and further, the one or more sending resources may be members of an anycast group associated with a particular anycast address.

[0271] Clause 1c: In an alternative or additional wording, such embodiments may include a method having one, some or all of the following steps:

[0272] A receiving resource that is a member of a multicast group receives an initial message that is: i) sent from a sending resource to a multicast address associated with the multicast group;

[0273] ii) comprising a) an anycast address corresponding to the anycast group, and b) data associated with one or more tasks or processing requests;

[0274] The receiving resource sends a response message to the anycast address in response to receiving the initial message, wherein the response message conveys and / or includes acceptance of the one or more tasks or processing requests contained in the initial message.

[0275] Any features provided for any of clauses 1a, 1b and 1c may be used for any other phrase of clause 1. In other words, features in 1a, 1b, 1c may be used interchangeably between phrases of clause 1.

[0276] The following clauses may be derived from any wording of clause 1 above.

[0277] 2. The method according to clause 1, further comprising at least one of the following steps:

[0278] 2.1 Associating the first resource group with an anycast group having a specific anycast address; and / or

[0279] 2.2 Associating the second resource group with a multicast group having a specific multicast address; and / or

[0280] 2.3 sending an initial message (i.e., one or more data packets) from a sending resource to a specific multicast address corresponding to a multicast group, wherein the sending resource may or may not belong to the anycast group, the initial message including i) the specific anycast address of the anycast group, and ii) data related to one or more tasks or processing requests; and / or

[0281] 2.4 Routing the initial message to each resource of the multicast group.

[0282] 3. According to the method described in any one of clauses 1, 2.1, 2.2, 2.3 and 2.4, the method also includes: in response to receiving data (i.e., the initial message), at least one resource (receiving resource) belonging to the multicast group sends a response message (e.g., at least one data packet) to a specific anycast address corresponding to the anycast group, wherein the response message conveys the intention or willingness to execute or complete the one or more tasks or processing requests related to the received data (i.e., the initial message).

[0283] 4. The method according to clause 3, further comprising at least one of the following steps:

[0284] 4.1 routing the response message to a resource of the anycast group, the resource being topologically closest to the resource in the multicast group that sends the response message; and / or

[0285] 4.2 In response to receiving the response message, at least one resource of the anycast group determines which resource (receiving resource) in the multicast group that has sent the response message is topologically closest to the resource of the anycast group; and / or

[0286] 4.3 The resource of the anycast group uses the traceroute tool to determine which resource in the multicast group that has sent the response message is topologically closest to the resource used by the anycast group; and / or

[0287] 4.4 at least one resource of the anycast group collaborates with such topologically closest resource of the multicast group (receiving resource) to perform the one or more tasks or processing requests associated with the initial message and the response message; and / or

[0288] 4.5 Configure at least one resource (receiving resource) of the multicast group to decide not to respond to the initial message if the resource is busy or cannot perform or complete the one or more tasks or processing requests related to the initial message according to certain standards; and / or configure at least one resource (receiving resource) of the multicast group to decide not to respond to the initial message if the resource is unwilling to perform or complete the one or more tasks or processing requests related to the initial message according to other standards.

[0289] According to additional or alternative wording, the method may include:

[0290] Each respective member of the anycast group determines which responding member of the multicast group is topologically closest to it ("it" refers to each respective member of the anycast group); and / or

[0291] According to the judgments made by all corresponding members of the anycast group, it is determined which receiving resource among the receiving resources that have sent the response message is topologically closest to the member of the anycast group. In other words, according to the judgments made by the respective members of the anycast group, the shortest path between the anycast group and the responding multicast group member is determined. Thus, the topologically closest multicast group member is identified and made the resource with which the closest anycast group member will continue to communicate and collaborate so as to complete the task in the fastest and most efficient manner.

[0292] 5. A method according to any one of clauses 1, 2.1, 2.2, 2.3 and 2.4, 3, 4.1, 4.2, 4.3, 4.4 and 4.5, wherein the first resource group and / or the second resource group may include resources for verifying one or more blockchain transactions, a pool of miners or a set of proof-of-work computing resources, resources for creating transaction blocks using proof-of-work or proof-of-stake consensus, or resources for processing data in some manner for blockchain-related purposes and / or cryptocurrency-related purposes.

[0293] 6. A method according to any one of clauses 1, 2.1, 2.2, 2.3 and 2.4, 3, 4.1, 4.2, 4.3, 4.4, 4.5 and 5, wherein the one or more tasks or processing requests involve blockchain transactions, blockchain blocks or other blockchain-related data.

[0294] 7. A method according to any one of clauses 1, 2.1, 2.2, 2.3 and 2.4, 3, 4.1, 4.2, 4.3, 4.4, 4.5, 5 and 6, wherein the one or more tasks or processing requests relate to:

[0295] - Verify one or more blockchain transactions;

[0296] - Mining transaction blocks using proof-of-work computing resources;

[0297] -Create transaction blocks using the Proof of Stake consensus mechanism;

[0298] - Simple Payment Verification; or

[0299] Process the data in some way for blockchain-related purposes and / or cryptocurrency-related purposes.

[0300] Clause Set 2:

[0301] 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.

[0302] Clause 2.1 A method comprising:

[0303] 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

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

[0305] 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.

[0306] 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.

[0307] 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.

[0308] 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.

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

[0310] 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.

[0311] 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.

[0312] 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.

[0313] 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.

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

[0315] 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.

[0316] 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.).

[0317] 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.

[0318] Clause Set 3:

[0319] 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.

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

[0321] 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.

[0322] 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.

[0323] 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:

[0324] 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;

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

[0326] Merchant resources;

[0327] Cryptocurrency exchanges;

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

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

[0330] Digital wallet.

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

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

[0333] 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.

[0334] 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:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0350] 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.

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

[0352] 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)

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

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

[0355] 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:

[0356] Functions specified by the blockchain protocol;

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

[0358] Simple Payment Verification (SPV) operations;

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

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

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

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

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

[0364] 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.

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

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

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

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

[0369] 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;

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

[0371] iv) said communication is an alert.

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

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

[0374] 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.

[0375] 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.

[0376] Clause Set 4:

[0377] 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.

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

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

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

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

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

[0383] Cryptocurrency exchanges; and / or

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

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

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

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

[0388] 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

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

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

[0391] Clause Set 5:

[0392] 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.

[0393] 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:

[0394] At least one data packet is sent 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.

[0395] The at least one data packet may be received by at least one of the receiving resources;

[0396] The method may also include one or more of the following:

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

[0398] ● 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:

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

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

[0401] ■ the request is sent using multicast transmission, anycast transmission or unicast transmission;

[0402] = said at least one other resource receiving said request for said at least one other data packet from said at least one receiving resource;

[0403] ● 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.

[0404] 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.

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

[0406] 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:

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

[0408] 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

[0409] 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

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

[0411] 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.

[0412] 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:

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

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

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

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

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

[0418] 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.

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

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

[0421] 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

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

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

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

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

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

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

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

[0429] 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:

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

[0431] 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

[0432] 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

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

[0434] 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.

[0435] Clause Set 6:

[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 6 may be combined with one or more clauses in any other clause set provided herein or any other features disclosed herein.

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

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

[0439] 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;

[0440] 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;

[0441] 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);

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

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

[0444] 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.;

[0445] 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;

[0446] 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;

[0447] 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;

[0448] 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;

[0449] 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;

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

[0451] 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.

[0452] Clause Set 7:

[0453] 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.

[0454] 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.

[0455] 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.

[0456] 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.

[0457] 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.

[0458] 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.

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

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

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

[0462] 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.

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

[0464] 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;

[0465] 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.

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

[0467] 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);

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

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

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

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

[0472] 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.

[0473] 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).

[0474] Clause Set 8:

[0475] 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.

[0476] 8.1 A method comprising the following steps:

[0477] 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:

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

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

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

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

[0482] Merchants control resources;

[0483] Cryptocurrency exchanges or their components;

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

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

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

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

[0488] 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

[0489] iv) the transmission includes:

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

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

[0492] 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.

[0493] 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.

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

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

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

[0497] 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.

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

[0499] 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

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

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

[0502] 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.

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

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

[0505] Clause Set 9:

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

[0507] Clause 9.1 A computer-implemented method, the method comprising: sending and / or receiving resources for generating, storing, processing, accessing and / or maintaining a data packet, the data packet preferably comprising blockchain-related data; determining an allocation address based on the data packet; and sending a transmission of the data packet from the sending resource to the allocation address at least in part via an electronic network.

[0508] Additionally or alternatively, according to alternative wording, embodiments of the present disclosure may provide a method for balancing the transmission of data records in a network. The method may include: using and / or providing resources for processing (e.g., generating, storing, processing, accessing and / or maintaining) data records; the method may include the step of determining an allocation address for the record by parsing / processing the record. The allocation address may correspond to a group of one or more resources, wherein the resource can subscribe to and unsubscribe from the group. The transmission of the record may be sent from the resource to the allocation address. The allocation address may be determined based on a specified portion of data. The specified portion of data may be a portion of a blockchain transaction or blockchain block. The specified portion of data may be data, or include part or all of a transaction ID or blockchain block ID, or a portion of metadata in a transaction output, etc. A predetermined digital number from the specified portion of data may be used as a method of identifying a recipient (e.g., a machine processing the data record). The data may be sent through the network to a recipient resource or resource group whose address corresponds to the specified portion of data. For example, (one or more) data records containing a TXID or metadata containing the 8-bit pattern 01101110 (e.g., starting with the 8-bit pattern 01101110, ending with the 8-bit pattern 01101110, or containing the 8-bit pattern 01101110) can be sent to a machine or group of machines identified by an address or identifier containing 01101110.

[0509] Clause 9.2. The method of clause 9.1, wherein the assigned address is a multicast address associated with a receiving resource group.

[0510] Clause 9.3. A method according to any of the preceding clauses, wherein the record comprises at least one of: a portion of a transaction (Tx); an output identifier; a hash of a script; a transaction identifier (TXID); a blockchain block; and a block header. The output identifier may be an identifier associated with an output in the blockchain transaction (Tx). For example, the output identifier may be a UTXO identifier. The hash of the script may be a hash of a script (e.g., a UTXO script) associated with an output of the transaction (Tx).

[0511] Clause 9.4. A method according to any of the preceding clauses, wherein determining the assigned address comprises: processing the data packet to determine a key; and selecting at least one address from a set of addresses using the key, the processing preferably comprising parsing the data packet.

[0512] Clause 9.5. A method as described in any preceding clause, wherein the sending resource holds, provides or includes a data structure including a set of allocated addresses associated with a corresponding set of keys.

[0513] Clause 9.6. A method according to any of the preceding clauses, wherein the sending resource generates, stores, processes, accesses and / or maintains a (blockchain) block (of zero or more blockchain transactions) comprising a plurality of data packets, wherein each of the data packets in the block comprises blockchain-related data.

[0514] The method may include the steps of determining an assigned address for each data packet in the chunk; and sending a transmission of each data packet in the chunk at least in part from the transmission resource to the corresponding assigned address over an electronic network.

[0515] Clause 9.7. The method of clause 9.6, wherein the block is divided into sub-blocks, and the sending resource transmits each sub-block to a corresponding assigned address via an electronic network.

[0516] Clause 9.8. The method of clause 9.6 or 9.7, wherein the plurality of data packets are segmented into eight sub-blocks, each sub-block being sent to a corresponding assigned address.

[0517] Clause 9.9. A method according to any preceding clause, wherein the sending resource is additionally or alternatively used as a receiving resource, the method further comprising: receiving the data packet and / or the plurality of data packets, and at least one of: propagating the data packet to the allocated address. Preferably, propagating the block comprises: transmitting a plurality of data packets to the corresponding allocated address; merging the block; and / or transmitting the plurality of data packets for propagation to the corresponding allocated address.

[0518] Additionally or alternatively, the method may include the steps of collecting at least one of the data packet, multiple data packets or blocks and then parsing each data packet to determine the key; and broadcasting each data packet to at least one address in the address set using the key.

[0519] Clause 9.10. A method as described in any preceding clause, wherein the sending resource or the receiving resource subscribes to at least one receiving resource and / or at least one multicast group.

[0520] Clause 9.11. The method of clause 9.10, wherein the sending resource or the receiving resource subscribes to a multicast address configured to receive at least one data packet assigned to the multicast address. Preferably, the assignment is determined based on the at least one data packet.

[0521] Clause 9.12. The method according to clause 9.10 or 9.11, the method further comprising the sending resource: subscribing to a receiving resource group by sending a signal to a network (e.g., the Internet and / or a blockchain network); and / or leaving the receiving resource group, preferably, wherein the resource leaves the group by stopping sending a signal to the network. The various aspects according to clause 9 may be combined with clause 9.2.

[0522] Clause 9.13. A method as described in any of the preceding clauses, wherein the data packet includes: a communication, notification, message or alert related to a blockchain-related event or activity.

[0523] Clause 9.14. A method as described in any of the preceding clauses, wherein the alert relates to a double spend or double spend attempt in a blockchain network.

[0524] Clause 9.15. A method according to any preceding clause, wherein the sending resource and / or the receiving resource is set to, configured to and / or used to perform one or more of the following operations:

[0525] Functions specified by the blockchain protocol;

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

[0527] Simple Payment Verification (SPV) operations;

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

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

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

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

[0532] Clause 9.16. A method as described in any preceding clause, wherein the data packet includes at least one of the following:

[0533] At least part of a blockchain transaction;

[0534] At least a portion of a blockchain block;

[0535] At least a portion of a blockchain transaction script;

[0536] A Merkle tree of the block recording the data packet;

[0537] recording a Merkle root of the block of the data packet;

[0538] a Merkle path, wherein the Merkle path is capable of determining a value of the Merkle root of the block for recording the data packet according to the hash of the data packet;

[0539] Merkel proved;

[0540] Data used with or associated with the consensus mechanism of a blockchain network;

[0541] The results of or data related to proof-of-stake or proof-of-work operations;

[0542] a block identifier (block_ID), the block identifier being associated with the blockchain block;

[0543] a transaction identifier (TxID), the transaction identifier being associated with a transaction (Tx) among a plurality of blockchain transactions within the blockchain block;

[0544] A function of the block identifier (block_ID) and the transaction identifier (TxID);

[0545] a concatenation of the block identifier (block_ID) and the transaction identifier (TxID);

[0546] Digital signature;

[0547] Authentication code;

[0548] A signed message, wherein the signed message is used to determine the transaction status;

[0549] Protocol logo;

[0550] discretionary public key (DPK); and

[0551] Autonomous Transaction ID (DTxID).

[0552] Clause 9.17. A method according to any preceding clause, wherein the sending resource and / or the receiving resource comprises:

[0553] Nodes in a blockchain network;

[0554] Set up as a service provider that provides blockchain-related services;

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

[0556] Cryptocurrency exchanges or their components;

[0557] Merchant Resources or components thereof;

[0558] Digital wallets or components thereof;

[0559] A software component for performing or facilitating a simple payment verification (SPV) operation, or processing the results of an SPV operation;

[0560] An MLDv1 host or MLDv2 host, network switch, or router on the network.

[0561] Clause 9.18. A computer device comprising:

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

[0563] 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 9.1 to 9.17 when executed on the processing device.

[0564] Clause 9.19. 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 9.1 to 9.17.

[0565] Article Set 10:

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

[0567] Clause 10.1. A computer-implemented method, the method comprising: operating a transmission resource for generating, storing, processing, accessing and / or maintaining a data packet, the data packet preferably comprising blockchain-related data; and, transmitting a transmission of the data packet from the transmission resource to a multicast group at least in part via an electronic network, wherein the multicast group makes the data packet available to an end user. The data packet may be made available through controlled access. The controlled access may be managed (i) through controlled access to the multicast group (e.g., through a subscription) and / or (ii) through controlled access to the data packet. Controlled access may be configured by the transmission resource, for example, by enabling controlled access to the multicast group and / or by protecting the data packet prior to transmission.

[0568] Clause 10.2. The method of clause 10.1, further comprising: receiving resources for storing, processing, accessing and / or maintaining the data packet.

[0569] Clause 10.3. The method of clause 10.2, wherein: the receiving resource subscribes to the multicast group or another multicast group to receive the data packet or another data packet.

[0570] Clause 10.4. A method according to any of the preceding clauses, wherein: the sending resource transmits multiple data packets; and / or the receiving resource receives multiple data packets.

[0571] Clause 10.5. A method according to any preceding clause, wherein the data packet is at least partly a data stream, such as a multimedia communication channel.

[0572] Clause 10.6. A method as described in any preceding clause, wherein the data packet has a subcomponent for providing multiple data channels.

[0573] Clause 10.7. A method according to any preceding clause, wherein the data packet and / or access to the multicast group is secure and accessible using an access key and / or a smart contract.

[0574] Clause 10.8. The method of clause 10.7, wherein a first access key is required to access the data packet; and a second access key is required to access the multicast group.

[0575] Clause 10.9. A method according to clause 10.7 or 10.8, wherein the sending resource generates the access key and sends the required access key to at least one of a recipient and an end user of the data packet to access the data packet.

[0576] Clause 10.10. A method according to clause 10.9, wherein the access key is provided during an exchange using a payment channel and / or smart contract.

[0577] Clause 10.11. A method according to any one of clauses 10.7 to 10.10, wherein: the access key provides access to the multicast group and / or the data packet for at least one of the following: (i) a fixed time period, (ii) a fixed amount of data, (iii) a fixed number of units, (iv) a fixed number of data packets, (v) unrestricted access.

[0578] Clause 10.12. A method according to any one of clauses 10.4 to 10.11, wherein: the sending resource transmits the multiple data packets to a corresponding allocated address, wherein the allocated address is determined based on: the corresponding data packets, or, the access key; and / or, the receiving resource receives the multiple data packets from at least one multicast group and aggregates the data packets.

[0579] Clause 10.13. The method of clause 10.12, wherein the assigned address is a multicast address associated with a receiving resource group.

[0580] Clause 10.14. A computer-implemented method, the method comprising: operating a receiving resource for storing, processing, accessing and / or maintaining a data packet, the data packet preferably comprising blockchain-related data; and receiving, at least in part, a transmission of the data packet via a multicast group that receives the data packet from an electronic network, and consuming the data packet as an end user.

[0581] Clause 10.15. A method according to clause 10.14, wherein the data packet and / or access to the multicast group is secure and accessible using an access key, preferably obtained through a payment channel.

[0582] Clause 10.16. A method according to any preceding clause, wherein the data packet comprises at least one of: a portion of a transaction (Tx); an output identifier; a hash of a script; a transaction identifier (TXID); a blockchain block; a block header. For example, the output identifier may be a UTXO. The script may be associated with an output provided within a blockchain transaction.

[0583] Clause 10.17. A method according to any preceding clause, wherein the data packet comprises at least one of the following:

[0584] At least part of a blockchain transaction;

[0585] At least a portion of a blockchain block;

[0586] At least a portion of a blockchain transaction script;

[0587] A Merkle tree of the block recording the data packet;

[0588] recording a Merkle root of the block of the data packet;

[0589] a Merkle path, wherein the Merkle path is capable of determining a value of the Merkle root of the block for recording the data packet according to the hash of the data packet;

[0590] Merkel proved;

[0591] Data used with or associated with the consensus mechanism of a blockchain network;

[0592] The results of or data related to proof-of-stake or proof-of-work operations;

[0593] a block identifier (block_ID), the block identifier being associated with the blockchain block;

[0594] a transaction identifier (TxID), the transaction identifier being associated with a transaction (Tx) among a plurality of blockchain transactions within the blockchain block;

[0595] A function of the block identifier (block_ID) and the transaction identifier (TxID);

[0596] a concatenation of the block identifier (block_ID) and the transaction identifier (TxID);

[0597] Digital signature;

[0598] Authentication code;

[0599] A signed message, wherein the signed message is used to determine the transaction status;

[0600] Protocol logo;

[0601] Autonomous Public Key (DPK);

[0602] Autonomous Transaction ID (DTxID).

[0603] Clause 10.18. A method according to any preceding clause, wherein sending a resource and / or receiving a resource comprises:

[0604] Nodes in a blockchain network;

[0605] Set up as a service provider that provides blockchain-related services;

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

[0607] Cryptocurrency exchanges or their components;

[0608] Merchant Resources or components thereof;

[0609] Digital wallets or components thereof;

[0610] A software component for performing or facilitating a simple payment verification (SPV) operation, or processing the results of an SPV operation;

[0611] MLDv1 hosts or MLDv2 hosts, network switches or routers on the network;

[0612] a vehicle; the vehicle may be an autonomous vehicle or a semi-autonomous vehicle;

[0613] Drones, which may be autonomous.

[0614] In the case where the receiving resource is a vehicle or a drone, the data may include or be one or more of the following: traffic-related data, maps or geographic data; instructions, alerts or notifications, music, video and / or voice communications (e.g., messages and phone calls) to operate, control, direct or influence the vehicle / drone or its behavior.

[0615] Clause 10.19. A computer device comprising: a memory comprising one or more memory units; and 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 10.1 to 10.18 when executed on the processing device. The computer device may comprise or form part of a vehicle or drone.

[0616] Clause 10.20. 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 10.1 to 10.18.

[0617] Article Set 11

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

[0619] 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 herein may include this definition.

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

[0621] Therefore, it is possible to provide:

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

[0623] 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,

[0624] in:

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

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

[0627] 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.

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

[0629] Clause 11.2 A method according to clause 11.1, wherein:

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

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

[0632] Exemplary System Overview

[0633] 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 .

[0634] 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.

[0635] 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.

[0636] 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.

[0637] 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.

[0638] 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.

[0639] 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.

[0640] 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.

[0641] 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.

[0642] 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.

[0643] 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.

[0644] 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.

[0645] 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.

[0646] 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.

[0647] 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.

[0648] 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.

[0649] 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).

[0650] 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.

[0651] 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.

[0652] 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.

[0653] 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.

[0654] 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.

[0655] 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.

[0656] 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.

[0657] 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.

[0658] 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.

[0659] 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).

[0660] 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.

[0661] UTXO-based model

[0662] 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.

[0663] 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.

[0664] 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.

[0665] 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 have been included in one of the blocks 151 at this time, or it may still be waiting in the ordered set 154, in which case it 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 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 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.

[0666] 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.

[0667] 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.

[0668] 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.

[0669] When a new transaction Tx1 arrives at a 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:

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

[0671] 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).

[0672] 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.

[0673] 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.

[0674] 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.

[0675] 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.

[0676] 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.

[0677] 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.

[0678] 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.

[0679] 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).

[0680] 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.

[0681] Side Channel

[0682] 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.

[0683] 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.

[0684] Client Software

[0685] 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.

[0686] 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.

[0687] 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.

[0688] 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.

[0689] 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.

[0690] 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).

[0691] 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.

[0692] 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.

[0693] 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.

[0694] Node software

[0695] Figure 4 An example of node software 450 running on each 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 tx is passed to the script engine 452. The protocol engine 451 also j The 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.

[0696] 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).

[0697] 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.

[0698] 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.

[0699] 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).< / pa>

Claims

1. A method comprising the following steps: associating the first resource group with an anycast group having a specific anycast address; associating the second resource group with a multicast group having a specific multicast address; Sending an initial message from a sending resource to the specific multicast address, the initial message including i) the specific anycast address of the anycast group, and ii) data related to one or more tasks or processing requests; as well as In response to receiving the initial message, at least one resource belonging to the multicast group sends a response message to the specific anycast address, wherein the response message conveys acceptance of the one or more tasks or processing requests. The method according to claim 1 , wherein the transmission resource belongs to the anycast group.

3. The method according to claim 1 or 2, wherein i) the initial message is routed to each resource of the multicast group; and / or ii) The multicast address is an IPv6 multicast address.

4. The method according to any preceding claim, wherein the response message is routed to a resource of the anycast group that is topologically closest to a resource in the multicast group that sent the response message.

5. The method according to any of the preceding claims, further comprising: In response to receiving the response message, at least one resource of the anycast group determines which resource of the multicast group that sent the response message is topologically closest to the resource of the anycast group.

6. The method according to claim 5, wherein the step of determining which resource in the multicast group that has sent a response message is topologically closest to the resource of the anycast group: i) use of traceroute tools; and / or ii) being repeatedly performed by each resource in the first resource group.

7. The method according to claim 5, further comprising: The at least one resource of the anycast group collaborates with the topologically closest resource to perform the one or more tasks or processing requests associated with the initial message and / or the response message.

8. The method according to any one of the preceding claims, further comprising: At least one resource of the multicast group decides not to respond to the initial message if it is busy or unable to perform or complete the one or more tasks or processing requests associated with the initial message according to certain criteria; or At least one resource of the multicast group decides not to respond to the initial message if it is unwilling or unable to perform or complete the one or more tasks or processing requests related to the initial message based on other criteria.

9. A method according to any preceding claim, wherein The first resource group and / or the second resource group include resources that verify one or more blockchain transactions, a pool of miners or a set of proof-of-work computing resources, resources that create transaction blocks using proof-of-stake consensus, or resources that process data in some manner for blockchain-related purposes and / or cryptocurrency-related purposes.

10. A method according to any preceding claim, wherein The one or more tasks or processes involve blockchain transactions, blockchain blocks, or other blockchain-related data.

11. A method according to any preceding claim, wherein The one or more tasks or processes involve verifying one or more blockchain transactions, mining transaction blocks using proof-of-work computing resources, creating transaction blocks using a proof-of-stake consensus mechanism, simple payment verification, or processing data in some manner for blockchain-related purposes and / or cryptocurrency-related purposes.

12. A computer device, comprising: a memory, the memory comprising one or more memory units; as well as A processing device comprising one or more processing units, wherein the memory stores code arranged to be executed on the processing device, and the code is configured to execute at least a part of the method according to any one of claims 1 to 11 when executed on the processing device.

13. A computer program embodied on a computer readable memory and configured to, when run on one or more processors, perform at least part of the method according to any one of claims 1 to 11.

Images