Sending and receiving blockchain data

Abstract

A computer-implemented method of obtaining application-related data, wherein the method is performed by a first party and comprises: determining a first multicast network address associated with a first application; and using the first multicast address to obtain one or more respective blockchain transactions and / or one or more respective inclusion attestation, each respective inclusion attestation being associated with a respective blockchain transaction, where each respective blockchain transaction includes respective data associated with the first application.

Description

Technical Field

[0001] The present disclosure relates to methods for sending and receiving blockchain data (e.g., transactions and SPV proofs) using multicast addresses. Background Art

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

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

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

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

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

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

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

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

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

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

[0012] As blockchain-based applications continue to grow, the number of transactions issued increases, and the size of the blockchain scales accordingly. Even faster growth is expected in the coming years. A group of users may use the same application (for example, an application other than Bitcoin) and use the blockchain to record application-specific data. They may only be interested in receiving transactions related to that application. Based on the current infrastructure, users interested in specific data must either run their own blockchain node or rely on a third-party node. These nodes must listen to all blockchain-related traffic and filter out transactions of interest. Alternatively, each user needs to subscribe to one or more existing network nodes and receive an SPV issuance certificate. However, existing network nodes are not required to provide SPV certificates, as this is an additional cost for them, especially as blockchain usage grows.

[0013] Therefore, there is a need to be able to efficiently obtain transactions with application-specific data without having to obtain or snoop all transactions, including those that are not relevant to the application of interest.

[0014] According to one aspect disclosed herein, a computer-implemented method for obtaining application-related data is provided, wherein the method is performed by a first party and includes: determining a first multicast network address associated with a first application; and using the first multicast address to obtain one or more corresponding blockchain transactions and / or one or more corresponding proofs of inclusion, each corresponding proof of inclusion being associated with a corresponding blockchain transaction, wherein each corresponding blockchain transaction includes corresponding data related to the first application.

[0015] Every application is an application other than Bitcoin. An application can be a blockchain application, but not a Bitcoin blockchain. Every application can be a different application.

[0016] According to another aspect disclosed herein, a computer-implemented method for disseminating application-related data is provided, wherein the method is performed by a second party and includes: determining a first multicast network address associated with a first application; and sending one or more corresponding blockchain transactions and / or one or more corresponding inclusion proofs to the first multicast address, each corresponding inclusion proof being associated with a corresponding blockchain transaction, wherein each corresponding blockchain transaction includes corresponding data related to the first application.

[0017] Embodiments of the present disclosure provide techniques for optimizing traffic management on a blockchain so that users receive only the transactions they are interested in. This creates an overlay network that includes all the transactions required to run a specific application. Only blockchain nodes that actively participate in the verification process (e.g., blockchain nodes) can choose to receive all transactions, as they are required to verify each transaction and generate new blocks.

[0018] As disclosed herein, an overlay network is established by partitioning network traffic using (e.g., IPv4 or IPv6) multicast addresses linked to use cases and / or applications. This way, users and other interested parties listen to only the portion of traffic they are interested in. Application-related traffic can include transactions sent from users / applications for publication, transactions published by nodes with corresponding SPV proofs, or any other information that may be of interest or relevance to the application, such as alerts, updates, etc.

[0019] The provided embodiments have several advantages. For example, use-case-specific overlay networks reduce overall network traffic (i.e., the number of transactions exchanged) because only the relevant parties receive these transactions. Furthermore, only blockchain nodes require specialized hardware and / or software to manage the entire set of transactions being published and store the entire blockchain. Furthermore, a simplified interface to the blockchain is provided for applications and users. Instead of connecting to a blockchain node, they simply submit transactions to a multicast address linked to the application and optionally wait for an SPV proof.

[0020] Multicast addresses can be assigned to specific applications, such as central bank digital currencies (CBDCs) or social media protocols. As part of an overlay network or otherwise, a given user may wish to subscribe to the multicast addresses of many such applications. Therefore, it is desirable for the user to be able to efficiently communicate with the router to determine the set of multicast addresses it requires. Therefore, a method is needed to efficiently map and manage the set of all multicast addresses, each corresponding to a different type of network traffic.

[0021] According to another aspect disclosed herein, a computer-implemented method for facilitating sending and receiving application-related data is provided, wherein a plurality of corresponding multicast addresses are associated with a plurality of corresponding applications, wherein the method is performed by a third party and includes: maintaining a mapping between the plurality of corresponding multicast addresses and the plurality of corresponding applications; receiving, from a requester, a request for a set of corresponding multicast addresses associated with a set of corresponding applications, the set of corresponding applications belonging to the plurality of corresponding applications; and sending the requested set of corresponding multicast addresses to the requester.

[0022] According to another aspect disclosed herein, there is provided a computer-implemented method for facilitating sending and receiving application-related data, wherein a plurality of corresponding multicast addresses are associated with a plurality of corresponding applications, wherein the method is performed by a fourth party and comprises: maintaining a mapping between the plurality of corresponding multicast addresses and the plurality of corresponding applications; and providing the mapping and / or a commitment of the mapping to one or more parties.

[0023] In some embodiments, the mapping is a hash tree (e.g., a Merkle tree). Using a Merkle tree or equivalent, a node can track the set of network traffic types being used using the same principles as transactions. From the node's perspective, the Merkle tree allows for efficient storage and updating of the set. The root of the Merkle tree provides a lightweight representation of the set that can be easily passed between and checked by other entities (e.g., routers) within the overlay network to improve consistency for service providers. BRIEF DESCRIPTION OF THE DRAWINGS

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

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

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

[0027] Figure 3 The basic format of an IPv6 multicast address is schematically shown;

[0028] Figure 4 An exemplary system for disseminating application-related data is schematically illustrated;

[0029] Figure 5 An exemplary system schematically illustrates parties interacting via a multicast address;

[0030] Figure 6 schematically illustrates an exemplary Merkle tree encoding a set of multicast addresses;

[0031] Figure 7 An exemplary process for requesting and providing a multicast address is shown. DETAILED DESCRIPTION

[0032] 1. Dissemination of application-related data

[0033] Embodiments of the present disclosure enable parties to communicate data related to blockchain-based applications. Such data can be communicated without directly interacting with the blockchain network 106. Figure 4 An exemplary system 400 is shown for communicating data between parties using a multicast address. Exemplary system 400 includes a first party 401, a second party 402, a third party 403, and a fourth party 404. Each party operates a respective computing device configured to perform the actions described below. In some examples, first party 401 and / or second party 402 are users, such as Alice 103a or Bob 103b. In some examples, first party 401 is a blockchain node 104. In some examples, third party 403 is a network router. In some examples, fourth party 404 is a blockchain node 104. Although shown separately, in some examples, one or more parties may be the same party. For example, first party 401 and fourth party 404 may be blockchain nodes 104.

[0034] Embodiments utilize multicast addresses to communicate application-specific data. Applications can take any form, such as protocols, such as communication protocols like instant messaging or token protocols like CBDCs. Each application is associated with (i.e., assigned) a dedicated multicast address, such as an IPv4 or IPv6 multicast address. The multicast address associated with a particular application can be assigned by the application owner (e.g., a social media platform) or a standards body. The multicast address can be generated based on the application (e.g., the name of the application). The multicast address can be cryptographically linked to the application.

[0035] The second party 402 is configured to determine (e.g., obtain, receive, generate) a first network address associated with the first application. The first network address can be obtained from a public resource such as a blockchain, or from the application owner (i.e., application provider) or a different party. Figure 4 As shown, the first network address may be provided by a third party 403 to a second party 402. This is described in more detail below.

[0036] Second party 402 sends a blockchain transaction containing data related to the first application to the first multicast address. In other words, the blockchain transaction is sent over the internet addressed to the first multicast address. Those skilled in the art are familiar with how to route data to a multicast address. Second party 402 can send multiple blockchain transactions containing data related to the first application to the first multicast address.

[0037] Application-related data can be any type of data, including payment data. For example, the application can be a payment processor, in which case the application data can include the recipient's public key or public key hash, the sender's signature, etc.

[0038] Additionally or alternatively, the second party sends a proof of inclusion for a blockchain transaction containing data related to the first application to the first multicast address. The proof of inclusion provides proof (i.e., can be used to prove) that the blockchain transaction has been recorded on blockchain 150. An example of a proof of inclusion is a Merkle proof. A specific example of a proof of inclusion is a Simple Verification Proof (SPV). Those skilled in the art will be familiar with SPV. Second party 402 can send multiple proofs of inclusion to the first multicast address, each of which proves that a specific blockchain transaction containing data related to the first application has been recorded on blockchain 150.

[0039] The second party 402 may determine a plurality of multicast addresses, each associated with a particular application. For example, the second party 402 may receive a list of addresses from a third party 403, as discussed further below. The second party 402 may send (i.e., address) transactions containing data associated with a particular application and / or proofs of inclusion of transactions containing data associated with a particular application to the multicast address associated with the particular application.

[0040] The first party 401 is further configured to determine (e.g., obtain, receive, generate) a first multicast address associated with the first application. The first party 401 can determine the first multicast address in any of the ways described above for the second party, including requesting and receiving the first multicast address from the third party 403.

[0041] First party 401 subscribes to (i.e., listens / monitors) a first multicast address to obtain blockchain messages related to a first application. In any case, first party 401 is configured to retrieve data sent to the first multicast address. Here, blockchain messages may include blockchain transactions and / or proofs of inclusion of blockchain transactions. For example, first party 401 can receive transactions submitted to the first multicast address by second party 401 by subscribing to the first multicast address.

[0042] The first party 401 may perform one or more actions in response to obtaining one or more blockchain transactions and / or one or more attestations. As an example, the first party 401 may store the one or more blockchain transactions and / or one or more attestations in a memory. As another example, the first party 401 may send one or more of the blockchain transactions to one or more parties (e.g., one or more blockchain nodes 104). The first party 401 may publish one or more of the blockchain transactions on the blockchain 150. In some examples, the first party 401 may first verify one or more of the blockchain transactions and only publish the verified transactions on the blockchain 150.

[0043] Once published on blockchain 150, first party 401 may send a corresponding inclusion proof (e.g., an SPV proof) of the published transaction to the first network address. Second party 402 may retrieve the inclusion proof sent by first party 401 to the first network address to determine whether the transaction has been published on blockchain 150.

[0044] The second party 402 may determine a plurality of multicast addresses, each associated with a particular application. For example, the first party 402 may receive a list of addresses from a third party 403, as discussed further below. The first party 402 may retrieve transactions containing data related to a particular application and / or proofs of inclusion for transactions containing data related to the particular application from (i.e., addressed to) a multicast address associated with the particular application.

[0045] In some examples, each application can be associated with multiple multicast addresses. Each address can be used for a specific purpose, such as one for transactions, one for SPV proofs, one for payments, one for updates, etc.

[0046] It should be noted that, in general, the first party 401 may perform any of the actions performed by the second party 402, and vice versa.

[0047] As described above, the third party 403 may provide one or more multicast addresses to the first party 401 and / or the second party 402. The third party 403 may include a network router that may be configured to route traffic on the network 101.

[0048] Each application is associated with (i.e., assigned) a multicast address. A third party 403 maintains a mapping between the applications and the associated multicast addresses. The third party 403 is configured to receive requests for corresponding multicast addresses for one or more applications, for example, from the first party 401 and / or the second party 402. In response, the third party 403 uses the mapping to determine the requested multicast address and sends it to the requesting party (e.g., the first party 401 and / or the second party 402).

[0049] This mapping can take the form of a Merkle tree. One or more leaves of the Merkle tree are generated based on the corresponding multicast address. That is, each multicast address is hashed individually to form a corresponding leaf hash of the Merkle tree. Each application can be assigned an index into the Merkle tree, where the associated multicast address is hashed to form a leaf hash at that index in the Merkle tree.

[0050] Third party 403 can retrieve a list of applications requesting multicast addresses. Based on the list of applications, third party 403 can determine a list of indices and search the Merkle tree for multicast addresses occupying positions corresponding to these indices. Third party 403 can verify whether the multicast addresses at these positions correspond to the requested applications and only provide the multicast addresses to the requester if they do correspond to the requested applications.

[0051] A fourth party 404 (e.g., blockchain node 104) may also maintain the same mapping. For example, the fourth party 404 may generate the mapping. The fourth party 404 may provide the mapping to the third party 403. If the mapping is a Merkle tree, the fourth party 404 may provide the entire Merkle tree or only the Merkle root. The Merkle root may be signed by the fourth party 404. The third party 403 may use the Merkle root to verify its own Merkle tree.

[0052] 1.1 Specific Examples

[0053] Embodiments of the present disclosure enable users and other types of parties to transmit and receive application-related data stored on or otherwise associated with a blockchain, such as transactions or Merkle proofs such as Simple Payment Verification (SPV) proofs. This section provides specific examples of the embodiments described above.

[0054] Each relevant application can be associated with a multicast address. For example, the association can be:

[0055] - a multicast address is encrypted and linked to the application; or

[0056] - Multicast addresses are assigned by a third party (e.g., IANA, the global coordination body responsible for the DNS root domain, IP addressing, and other Internet Protocol resources).

[0057] In the latter case, the application may need to request an address assignment. Users, devices, and other related parties can subscribe to the multicast address to receive updates as described above.

[0058] Blockchain nodes 104 can subscribe to all multicast addresses (or at least most of them) to receive, verify, and publish transactions. Once a transaction is published, an SPV proof can be broadcast to the same multicast address to inform other interested parties, such as application users. The creator of the multicast address may be responsible for notifying network nodes 104 that they need to subscribe to their address. Alternatively, applications can use multiple multicast addresses dedicated to specific traffic (e.g., for sending transactions, receiving SPV proofs). The creator of the multicast address may be responsible for notifying network nodes 104 that they need to subscribe to their address.

[0059] Blockchain nodes 104 can prune transactions or transaction data after publication. New services may emerge in the overlay network to store or back up data required by specific applications, such as application-specific archival nodes. Users can use these services to retrieve data without querying nodes 104. SPV proofs serve as a validity verification and tamper-proofing mechanism.

[0060] exist Figure 5 An example flow of a payment from a user to an application with some application-specific data is shown in:

[0061] 1) The application user sends a transaction containing a payment and some data to the multicast address

[0062] a. The application receives payment transactions and data

[0063] b. Network node 104 receives the transaction

[0064] c. Archive nodes store data for future use

[0065] 2) Network node 104 verifies the transaction and inserts it into the block

[0066] 3) Network node 104 sends the transaction SPV proof to the multicast address

[0067] a. The application user receives an SPV proof proving the transaction was published, and optionally stores the SPV proof for future reference

[0068] b. The application receives the SPV certificate and processes the data

[0069] c. The archiving node records the SPV proof.

[0070] The application-specific overlay network can continue to use data authenticated by the blockchain 150 without further interaction with network nodes.

[0071] Assume that the blockchain network 106 has n T Different types of network traffic, corresponding to the n created and broadcast by applications and users T Each different protocol, application, or traffic type can be associated with a different registered multicast address (marked The order of the indexes may be arbitrary, or the indexes may be optionally ordered to represent, for example, the age of the corresponding protocols or applications.

[0072] like Figure 6As shown, a Merkle tree can be formed from any subset of these multicast IP addresses. This can be accomplished simply by generating a standard binary Merkle tree (e.g., the standard binary Merkle tree used for transactions in Bitcoin) where each leaf node corresponds to the hash of a multicast IP address. Such a Merkle tree encodes the entire set of multicast addresses for all types of network traffic on blockchain 150 and can be derived by any blockchain node 104, as they will receive and propagate all types of traffic from each other as part of the core blockchain network 106. Nodes 104 may wish to publish their Merkle tree, or at least the root of their Merkle tree, as proof and advertisement of the types of network traffic currently supported (or seen on) blockchain network 106. This can be a useful service for application hosts, as well as law enforcement and regulatory agencies. The Merkle root can be signed by nodes 104 or any party maintaining such a tree to enhance the value of this proof.

[0073] Consider a user or device (labeled A) at the edge of an overlay network based on a core blockchain network (e.g., a regional CBDC overlay or a social media platform). A wants to subscribe to a k There are a set of k services or applications corresponding to the types of network traffic. This means that A needs to obtain n corresponding to these traffic types. k multicast IP addresses. To obtain these addresses, A can communicate with a router R that maintains a mapping between traffic types and multicast IP addresses. R can store this mapping as a Merkle tree, as outlined above. This enables R to efficiently store and look up large sets of addresses and check these addresses against any publicly available proof of the network traffic tree published by blockchain nodes 104 in the core node network 106.

[0074] Allow A to subscribe to n k Example protocols for the following traffic types are as follows:

[0075] 1.A selects the n he wants to subscribe to k traffic types.

[0076] 2.A sends a request to R k The multicast discovery request may be encoded as a list of traffic type codes or strings.

[0077] 3. R ​​converts the request into indices corresponding to the index where each multicast address of the corresponding traffic type is stored in the Merkle tree. List.

[0078] 4. R checks the index based on A's request The leaf node at exists and corresponds to the expected network traffic type.

[0079] a. For any index that fails this test, R sends a NULL address back to A in step 7.

[0080] 5.R retrieve IP address

[0081] 6. Optional: Use Leaf and the corresponding partial Merkle proof to recompute the Merkle root and compare it with the published root version.

[0082] 7.R sends to A in response to their requests.

[0083] 8.A starts receiving packets sent to the multicast IP address The required flow rate.

[0084] The purpose of step 4 is to have the router check whether there is a registered multicast IP address for each given network traffic type. In other words, this step is used to check whether there is a routing path for A to subscribe to the multicast IP address for each traffic type.

[0085] In step 6, optionally, R may recompute the Merkle root of its local tree and compare it with the published root of the node to check that the address is up to date and still valid.

[0086] Generally speaking, n k It does not need to be equal to k. It can also be some function of k, depending on the type of network traffic and how it is generated.

[0087] exist Figure 7 A flow chart of an exemplary protocol is shown in .

[0088] One or more embodiments of the present disclosure provide the following features.

[0089] Multicast addresses can be used to create partitions of the blockchain network (i.e., overlay networks) based on specific applications or use cases.

[0090] The multicast address is linked to the application. This link can be an encrypted link to the application's multicast address or a multicast address assigned by a third party.

[0091] Interested users and other parties can subscribe to the application-specific multicast address to receive application-specific traffic.

[0092] Applications and users can send application-related transactions to the relative multicast address, which means that there is no need to identify and communicate with the network node 104.

[0093] Network nodes can subscribe to all multicast addresses to receive transactions for verification and publication.

[0094] Network nodes can publish SPV proofs to the same multicast address to notify relevant parties that the transaction has been published.

[0095] An application can use multiple multicast addresses, for example, one for broadcasting transactions and one for receiving SPV proofs.

[0096] The following use cases can be implemented using the embodiments described herein.

[0097] A central bank can issue a blockchain-based CBDC scheme and monitor all related transactions without having to establish a full node. Similarly, a user can send a direct payment to another user (peer-to-peer). The recipient broadcasts the transaction for publication in the blockchain, and both parties receive SPV confirmation from the blockchain node 104.

[0098] Video games can use blockchains to record transactions. Players can subscribe to a multicast address to receive updates. In a more lightweight approach, multicast addresses can be linked to different parts of the game (e.g., different worlds, tracks, battles, depending on the game).

[0099] Blockchain node 104 can specifically verify transactions from multicast addresses. It processes these transactions with high priority and responds quickly with SPV proofs. Blockchain node 104 can charge premium service fees to applications and services willing to pay for priority or guaranteed SPV proofs.

[0100] Storage services can subscribe to a multicast address, store data and SPV proofs, and sell access to data relevant to a specific application or use case. Blockchain nodes 104 can prune data without affecting the functionality of applications and the overlay network.

[0101] Router services can help users connect to blockchain-based applications such as CBDCs.

[0102] Client software or devices that enable access to blockchain-based applications can establish subscriptions to a number of streams of network traffic.

[0103] 2. Exemplary System Overview

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0126] 3. UTXO-based model

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

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

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

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

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

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

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

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

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

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

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

[0138] 4. Further comments

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

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

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

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

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

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

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

[0146] Statement 1. A computer-implemented method of obtaining application-related data, wherein the method is performed by a first party and comprises:

[0147] determining a first multicast network address associated with a first application; and,

[0148] Retrieve one or more respective blockchain transactions and / or one or more respective inclusion proofs using the first multicast address, each respective inclusion proof being associated with a respective blockchain transaction, wherein each respective blockchain transaction includes respective data related to the first application.

[0149] Statement 2. The method of statement 1, comprising storing the one or more corresponding blockchain transactions and / or the one or more corresponding inclusion proofs.

[0150] Statement 3. The method of statement 1 or 2, comprising sending the one or more corresponding blockchain transactions and / or the one or more corresponding inclusion proofs to one or more parties.

[0151] Statement 4. The method of any preceding statement, comprising verifying the one or more corresponding blockchain transactions according to a blockchain protocol.

[0152] Statement 5. The method of statement 4, comprising publishing one, some, or all of the one or more verified corresponding blockchain transactions to a blockchain.

[0153] Statement 6. The method according to any preceding statement, comprising:

[0154] obtaining corresponding inclusion proofs for one, some, or all of the one or more corresponding blockchain transactions issued to the blockchain; and

[0155] The corresponding inclusion proof is sent to the first multicast address.

[0156] Statement 7. The method according to any preceding statement, comprising:

[0157] One, some, or all of the one or more corresponding inclusion proofs are used to verify whether the associated corresponding blockchain transaction is published on the blockchain.

[0158] Statement 8. The method of any preceding statement, wherein said determining comprises generating said first multicast address.

[0159] Statement 9. The method of any one of statements 1 to 7, wherein the determining comprises: receiving the first multicast address.

[0160] Statement 10. The method of statement 9, comprising sending a request to a third party for a corresponding network address associated with one or more corresponding applications, wherein the one or more corresponding applications include the first application.

[0161] Statement 11. The method of any preceding statement, wherein said obtaining comprises monitoring said first multicast address for one or more corresponding blockchain transactions and / or one or more corresponding inclusion proofs.

[0162] Statement 12. The method of any preceding statement, wherein the first multicast address is generated based on the first application.

[0163] Statement 13. The method of statement 12, wherein the first multicast address is linked to the first application in an encrypted manner.

[0164] Statement 14. The method of any preceding statement, wherein the first multicast address is an IPv4 address or an IPv6 address.

[0165] Statement 15. The method of any preceding statement, comprising:

[0166] determining a plurality of respective multicast addresses, each respective multicast address being associated with a respective application; and,

[0167] For each respective application, one or more respective blockchain transactions and / or one or more respective inclusion proofs are retrieved using the respective multicast address, each respective inclusion proof being associated with a respective blockchain transaction, wherein each respective blockchain transaction includes respective data related to the respective application.

[0168] Statement 16. The method of any preceding statement, comprising:

[0169] determining one or more additional multicast network addresses associated with the first application; and,

[0170] Using the one or more additional multicast network addresses, one or more respective blockchain transactions and / or one or more respective inclusion proofs are retrieved, each respective inclusion proof being associated with a respective blockchain transaction, wherein each respective blockchain transaction includes respective data related to the first application.

[0171] Statement 17. The method of statement 16, wherein each of the one or more additional multicast network addresses is associated with a type and / or purpose of corresponding data sent to and / or from the corresponding multicast network address.

[0172] Statement 18. The method of statement 16 or 17, wherein the one or more corresponding blockchain transactions are obtained from the first multicast network address and the one or more corresponding inclusion proofs are obtained from an additional multicast network address of the one or more additional multicast network addresses.

[0173] Statement 19. A computer-implemented method of disseminating application-related data, wherein the method is performed by a second party and comprises:

[0174] determining a first multicast network address associated with the first application;

[0175] Sending one or more corresponding blockchain transactions and / or one or more corresponding inclusion proofs to the first multicast address, each corresponding inclusion proof being associated with a corresponding blockchain transaction, wherein each corresponding blockchain transaction includes corresponding data related to the first application.

[0176] Statement 20. The method of statement 19, comprising: using the first multicast address to obtain corresponding inclusion proofs associated with the one or more corresponding blockchain transactions sent to the first multicast address.

[0177] Statement 21. The method of statement 19 or 20, wherein the determining comprises: receiving the first multicast address.

[0178] Statement 22. The method of statement 21, comprising sending a request to a third party for a corresponding network address associated with one or more corresponding applications, wherein the one or more corresponding applications include the first application.

[0179] Statement 23. The method of statement 19 or any statement dependent thereon, comprising:

[0180] determining one or more additional multicast network addresses associated with the first application; and,

[0181] Sending one or more respective blockchain transactions and / or one or more respective inclusion proofs to the one or more additional multicast network addresses, each respective inclusion proof being associated with a respective blockchain transaction, wherein each respective blockchain transaction includes respective data related to the first application.

[0182] Statement 24. The method of statement 23, wherein each of the one or more additional multicast network addresses is associated with a type and / or purpose of corresponding data sent to and / or from the corresponding multicast network address.

[0183] Statement 25. The method of statement 23 or 24, comprising:

[0184] The one or more corresponding blockchain transactions are sent to the first multicast network address, and the one or more corresponding inclusion proofs are sent to one of the additional multicast network addresses.

[0185] Statement 26. A computer-implemented method for facilitating sending and receiving application-related data, wherein a plurality of respective multicast addresses are associated with a plurality of respective applications, wherein the method is performed by a third party and comprises:

[0186] Maintaining a mapping between the plurality of corresponding multicast addresses and the plurality of corresponding applications;

[0187] receiving, from a requestor, a request for a corresponding set of multicast addresses associated with a corresponding set of applications, the corresponding set of applications belonging to the plurality of corresponding applications; and

[0188] The requested corresponding multicast address set is sent to the requesting party.

[0189] Statement 27. The method of statement 26, wherein the mapping comprises a hash tree, wherein a plurality of respective leaf hashes of the hash tree are generated by hashing a respective multicast address of the plurality of respective multicast addresses.

[0190] Statement 28. The method of statement 27, wherein each respective application is associated with a respective index of the hash tree, and wherein the method comprises:

[0191] converting the requested set of respective multicast addresses associated with the set of respective applications into a list of indices; wherein each index in the list corresponds to the respective index associated with the respective application, the respective application being associated with the requested multicast address; and

[0192] Verifying whether each respective leaf hash of the hash tree occupying a respective position associated with a respective index in the set of indexes corresponds to the respective requested multicast address.

[0193] Statement 29. The method of statement 26 or any statement dependent thereon, wherein the respective index associated with the respective application is assigned according to a respective age of the respective application.

[0194] Statement 30. The method of statement 26 or any statement dependent thereon, comprising:

[0195] Obtain a target root hash of a target hash tree, wherein the target root hash is generated by a blockchain node;

[0196] Verify whether the root hash of the hash tree corresponds to the target root hash.

[0197] Statement 31. The method of statement 30, wherein the target root hash is signed by the blockchain node.

[0198] Statement 32. A computer-implemented method for facilitating sending and receiving application-related data, wherein a plurality of respective multicast addresses are associated with a plurality of respective applications, wherein the method is performed by a fourth party and comprises:

[0199] include:

[0200] maintaining a mapping between the plurality of corresponding multicast addresses and the plurality of corresponding applications; and,

[0201] The mapping and / or a commitment of the mapping is provided to one or more parties.

[0202] Statement 33. The method of statement 32, wherein the mapping comprises a hash tree, wherein a plurality of respective leaf hashes of the hash tree are generated by hashing a respective multicast address of the plurality of respective multicast addresses, and wherein the commitment is a root hash of the hash tree.

[0203] Statement 34. A computer device comprising:

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

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

[0206] Statement 35. A computer program embodied on a computer readable memory and configured to, when executed on one or more processors, perform the method of any one of statements 1 to 33.

[0207] According to another aspect of the present disclosure, a method may be provided, the method comprising actions by any one of the first party, the second party, the third party, and the fourth party. According to another aspect of the present disclosure, a system may be provided, the system comprising computer devices of the first party, the second party, the third party, and the fourth party.

Claims

1. A computer-implemented method for obtaining application-related data, wherein the method is performed by a first party and comprises: determining a first multicast network address associated with the first application; as well as Retrieve one or more respective blockchain transactions and / or one or more respective inclusion proofs using the first multicast address, each respective inclusion proof being associated with a respective blockchain transaction, wherein each respective blockchain transaction includes respective data related to the first application.

2. The method according to claim 1, comprising: Storing the one or more corresponding blockchain transactions and / or the one or more corresponding inclusion proofs.

3. The method according to claim 1 or 2, comprising: Sending the one or more corresponding blockchain transactions and / or the one or more corresponding proofs of inclusion to one or more parties.

4. A method according to any preceding claim, comprising: The one or more respective blockchain transactions are verified according to a blockchain protocol.

5. The method according to claim 4, comprising: Publishing one, some, or all of the one or more verified corresponding blockchain transactions to the blockchain.

6. A method according to any preceding claim, comprising: Obtaining corresponding inclusion proofs for one, some, or all of the one or more corresponding blockchain transactions issued to the blockchain; as well as The corresponding inclusion proof is sent to the first multicast address.

7. A method according to any preceding claim, comprising: One, some, or all of the one or more corresponding inclusion proofs are used to verify whether the associated corresponding blockchain transaction is published on the blockchain.

8. The method according to any preceding claim, wherein the determining comprises: Generate the first multicast address.

9. The method according to any one of claims 1 to 7, wherein the determining comprises: Receive the first multicast address.

10. The method according to claim 9, comprising: A request is sent to a third party for a corresponding network address associated with one or more corresponding applications, wherein the one or more corresponding applications include the first application.

11. The method according to any preceding claim, wherein said obtaining comprises: The first multicast address is monitored for one or more corresponding blockchain transactions and / or one or more corresponding inclusion proofs.

12. The method according to any preceding claim, wherein the first multicast address is generated based on the first application.

13. The method of claim 12, wherein the first multicast address is linked to the first application in an encrypted manner.

14. The method according to any preceding claim, wherein the first multicast address is an IPv4 address or an IPv6 address.

15. A method according to any preceding claim, comprising: determining a plurality of corresponding multicast addresses, each corresponding multicast address being associated with a corresponding application; as well as For each respective application, one or more respective blockchain transactions and / or one or more respective inclusion proofs are retrieved using the respective multicast address, each respective inclusion proof being associated with a respective blockchain transaction, wherein each respective blockchain transaction includes respective data related to the respective application.

16. A method according to any preceding claim, comprising: determining one or more additional multicast network addresses associated with the first application; as well as Using the one or more additional multicast network addresses, one or more respective blockchain transactions and / or one or more respective inclusion proofs are retrieved, each respective inclusion proof being associated with a respective blockchain transaction, wherein each respective blockchain transaction includes respective data related to the first application.

17. The method of claim 16, wherein each of the one or more additional multicast network addresses is associated with a type and / or purpose of respective data sent to and / or from the respective multicast network address.

18. The method of claim 16 or 17, wherein the one or more corresponding blockchain transactions are obtained from the first multicast network address, and the one or more corresponding inclusion proofs are obtained from one of the one or more additional multicast network addresses.

19. A computer-implemented method of disseminating application-related data, wherein the method is performed by a second party and comprises: determining a first multicast network address associated with the first application; Sending one or more corresponding blockchain transactions and / or one or more corresponding inclusion proofs to the first multicast address, each corresponding inclusion proof being associated with a corresponding blockchain transaction, wherein each corresponding blockchain transaction includes corresponding data related to the first application.

20. The method according to claim 19, comprising: Retrieve, using the first multicast address, respective proofs of inclusion associated with the one or more respective blockchain transactions sent to the first multicast address.

21. The method of claim 19 or 20, wherein the determining comprises: Receive the first multicast address.

22. The method according to claim 21, comprising: A request is sent to a third party for a corresponding network address associated with one or more corresponding applications, wherein the one or more corresponding applications include the first application.

23. The method according to claim 19 or any claim appendant thereto, comprising: determining one or more additional multicast network addresses associated with the first application; as well as Sending one or more respective blockchain transactions and / or one or more respective inclusion proofs to the one or more additional multicast network addresses, each respective inclusion proof being associated with a respective blockchain transaction, wherein each respective blockchain transaction includes respective data related to the first application.

24. The method of claim 23, wherein each of the one or more additional multicast network addresses is associated with a type and / or purpose of respective data sent to and / or from the respective multicast network address.

25. The method according to claim 23 or 24, comprising: The one or more corresponding blockchain transactions are sent to the first multicast network address, and the one or more corresponding inclusion proofs are sent to one of the additional multicast network addresses.

26. A computer-implemented method for facilitating sending and receiving application-related data, wherein a plurality of respective multicast addresses are associated with a plurality of respective applications, wherein the method is performed by a third party and comprises: Maintaining a mapping between the plurality of corresponding multicast addresses and the plurality of corresponding applications; receiving, from a requestor, a request for a respective set of multicast addresses associated with a respective set of applications, the respective set of applications belonging to the plurality of respective applications; as well as The requested corresponding multicast address set is sent to the requesting party.

27. The method of claim 26, wherein the mapping comprises a hash tree, wherein a plurality of respective leaf hashes of the hash tree are generated by hashing a respective multicast address of the plurality of respective multicast addresses.

28. The method of claim 27, wherein each respective application is associated with a respective index of the hash tree, and wherein the method comprises: converting the requested set of corresponding multicast addresses associated with the set of corresponding applications into a list of indices, each index in the list corresponding to the corresponding index associated with the corresponding application associated with the requested multicast address; as well as Verifying that each respective leaf hash of the hash tree occupying a respective position associated with a respective index in the set of indexes corresponds to a respective requested multicast address.

29. The method of claim 26 or any claim dependent thereon, wherein the respective index associated with the respective application is assigned according to the respective age of the respective application.

30. The method according to claim 26 or any claim appendant thereto, comprising: Obtain a target root hash of a target hash tree, wherein the target root hash is generated by a blockchain node; Verify whether the root hash of the hash tree corresponds to the target root hash.

31. The method of claim 30, wherein the target root hash is signed by the blockchain node.

32. A computer-implemented method for facilitating sending and receiving application-related data, wherein a plurality of respective multicast addresses are associated with a plurality of respective applications, wherein the method is performed by a fourth party and comprises: include: Maintaining a mapping between the plurality of corresponding multicast addresses and the plurality of corresponding applications; as well as The mapping and / or a commitment of the mapping is provided to one or more parties.

33. The method of claim 32, wherein the mapping comprises a hash tree, wherein a plurality of respective leaf hashes of the hash tree are generated by hashing a respective one of the plurality of respective multicast addresses, and wherein the commitment is a root hash of the hash tree.

34. 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 run on the processing device, the code being configured to perform the method according to any one of claims 1 to 33 when run on the processing device.

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

Images