Sending and receiving blockchain data

Abstract

A computer-based method for obtaining application-related data, the method being performed by a first party, Determining the first multicast network address associated with the first application, The process involves obtaining one or more proofs of each blockchain transaction and / or inclusion using a first multicast address, wherein each proof of inclusion is associated with its respective blockchain transaction, and each blockchain transaction contains its respective data relating to the first application.

Description

[Technical Field]

[0001] This disclosure relates to a method for sending and receiving blockchain data, such as transactions and SPV certificates, using multicast addresses. [Background technology]

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

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

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

[0005] IP multicast is designed for applications and services that need to reach many hosts connected to a network simultaneously. Illustrative applications include video conferencing, corporate communications, and the distribution of news, software, and stock information. A source host might support these applications by learning the IP addresses of N destination hosts, establishing N connections with them, and sending N copies of each packet. In contrast, IP multicast is more efficient because the source host must learn a single group address and send a single packet to reach N destination hosts. IP multicast differs from broadcast in that packets are sent not across an entire subnetwork, but rather to a selected group of hosts that may be on different subnetworks and have registered themselves as a group. Another difference is that broadcast only supports one-to-many type communication, while multicast also supports many-to-many type communication. Any IP network that is concerned with reducing network resource overhead for one-to-many or many-to-many data or multimedia applications with multiple recipients can benefit from multicast.

[0006] While both IPv4-based and IPv6-based networks support IP multicast, this specification states that the limited address space of IPv4 limits the ability of IPv4 multicast to reach a growing number of internet-connected devices. In addition, the common use of Network Address Translation (NAT) vehicles, which translate public IPv4 addresses to private addresses, makes it extremely difficult, if not impossible, to support several applications that use multicast connectivity. Globally unique IPv6 addresses eliminate the need for NAT boxes and simplify multicast communication between hosts. More specifically, the wider address space of IPv6 reduces the likelihood of separate multicast streams from different sources using the same group address and interfering with each other. IPv6 multicast also more clearly defines domain control, i.e., the ability to prevent multicast leaks outside the managed domain, and makes it easier to allocate and manage multicast groups.

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

[0008] As blockchain-based applications develop, the number of transactions issued increases, and therefore the size of the blockchain grows. Even more rapid development is expected in the coming years. A group of users may use the same application (e.g., an application other than Bitcoin) and use the blockchain to record application-specific data. Users may only be interested in receiving transactions related to this application. Using the current infrastructure, a user interested in specific data would either need to run a blockchain node or rely on a third party to run a node. This node would have to listen to all blockchain-related traffic and filter out transactions of interest. Alternatively, each user would need to join one or more existing network nodes and receive a public SPV certificate. However, existing network nodes are not required to provide SPV certificates, as this represents an additional cost for them (especially as blockchain usage increases).

[0009] Therefore, it is necessary to efficiently retrieve transactions containing application-specific data without having to retrieve or listen to all transactions, including those unrelated to the application in question. [Means for solving the problem]

[0010] According to one aspect disclosed herein, a computer-based method is provided for obtaining application-related data, the method being performed by a first party, Determining the first multicast network address associated with the first application, The process involves obtaining one or more proofs of each blockchain transaction and / or inclusion using a first multicast address, wherein each proof of inclusion is associated with its respective blockchain transaction, and each blockchain transaction contains its respective data relating to the first application.

[0011] Each application is a non-Bitcoin application. An application may be a blockchain application, but it may not be on the Bitcoin blockchain. Each application may be a different application.

[0012] In another aspect disclosed herein, a computer-based method is provided for propagating application-related data, the method being performed by a second party, Determining the first multicast network address associated with the first application, The process comprises sending one or more respective blockchain transactions and / or one or more proofs of inclusion to a first multicast address, wherein each proof of inclusion is associated with its respective blockchain transaction, and each respective blockchain transaction contains the respective data relating to the first application.

[0013] Embodiments of this 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 where every transaction is required to execute a specific application. Only blockchain nodes that actively participate in the activation process (e.g., blockchain nodes) may choose to receive all transactions when they are required to activate each transaction and generate a new block.

[0014] As disclosed herein, the overlay network is established by segmenting network traffic using multicast addresses (e.g., IPv4 or IPv6) linked to use cases and / or applications. In this way, users and other interested parties listen only to the portion of traffic they are interested in. Traffic to an application may include transactions sent for publication by users / applications, transactions issued by nodes with their respective SPV certificates, or any other information that may be of interest or relevance to that application, such as warnings, updates, etc.

[0015] The provided embodiment offers several advantages. For example, use-case specific overlay networks reduce overall network traffic (i.e., the number of transactions exchanged) because only interested parties receive them. Furthermore, to manage the entire set of transactions being issued and to store the entire blockchain, blockchain nodes require only specialized hardware and / or software. In addition, applications and users are provided with a simplified interface to the blockchain. They only need to submit transactions to multicast addresses linked to their applications and optionally wait for SPV certificates rather than connecting to blockchain nodes.

[0016] Multicast addresses may be assigned to specific applications, such as central bank digital currencies (CBDCs) or social media protocols. A given user may want to subscribe to multicast addresses for many such applications, either as part of an overlay network or separately. Therefore, it is desirable for users to be able to communicate efficiently with the router to determine the set of multicast addresses the router needs. Thus, a method is needed to efficiently map and manage all sets of multicast addresses, each corresponding to different types of network traffic.

[0017] In another aspect disclosed herein, a computer-implemented method is provided for facilitating the transmission and reception of application-related data, wherein each of a plurality of multicast addresses is associated with each of a plurality of applications, and the method is performed by a third party. Maintaining a mapping between multiple multicast addresses and multiple applications, Receiving, from a party making the request, a request to obtain a set of respective multicast addresses associated with a set of respective applications, wherein the set of respective applications belongs to a plurality of respective applications, and sending the requested set of respective multicast addresses to the party making the request.

[0018] According to another aspect disclosed herein, a computer-implemented method for facilitating the transmission and reception of application-related data is provided, wherein a plurality of respective multicast addresses are associated with a plurality of respective applications, the method is executed by a fourth party, maintaining a mapping between a plurality of respective multicast addresses and a plurality of respective applications, and making the mapping and / or a commitment of the mapping available to one or more parties.

[0019] In some embodiments, the mapping is a hash tree, such as a Merkle tree. The use of a Merkle tree or equivalent enables a node to track a set of network traffic types being used, using the same principles as used for transactions. A Merkle tree enables efficient storage and updating of the set from the perspective of a node. The Merkle tree root provides a lightweight representation of the set that can be easily circulated and checked by other entities within an overlay network, such as a router, to improve service provider integrity.

[0020] To assist in understanding the embodiments of the present disclosure and to show how such embodiments may be implemented, reference is made, by way of example only, to the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] [Figure 1]This is a schematic block diagram of a system for implementing blockchain. [Figure 2] This diagram schematically illustrates some examples of transactions that can be recorded in a blockchain. [Figure 3] This diagram schematically shows the basic format of an IPv6 multicast address. [Figure 4] This diagram schematically illustrates an exemplary system for propagating application-related data. [Figure 5] This diagram schematically illustrates how the exemplary systems of the parties involved interact via multicast addresses. [Figure 6] This diagram schematically shows an exemplary Merkle tree that encodes a set of multicast addresses. [Figure 7] This diagram shows an exemplary flow for requesting and providing multicast addresses. [Modes for carrying out the invention]

[0022] 1. Propagation of application-related data Embodiments of this disclosure enable parties to communicate blockchain-based application-related data. Such data may be communicated without the need to directly interact with the blockchain network 106. Figure 4 shows an exemplary system 400 of parties that utilize multicast addresses to communicate data. The exemplary system 400 includes a first party 401, a second party 402, a third party 403, and a fourth party 404. Each party operates its respective computing device configured to perform the actions described below as being performed by that party. In some examples, the first party 401 and / or the second party 402 are users such as Alice 103a or Bob 103b. In some examples, the first party 401 is the blockchain node 104. In some examples, the third party 403 is the network router. In some examples, the fourth party 404 is the blockchain node 104. Although illustrated separately, in some examples one or more parties may be the same party. For example, the first party 401 and the fourth party 404 may be blockchain nodes 104.

[0023] The embodiment utilizes multicast addresses to communicate application-specific data. The application may take any form, such as a protocol, a communication protocol like instant messaging, or a token protocol like CBDC. Each application is associated with (i.e., assigned) a dedicated multicast address, such as an IPv4 or IPv6 multicast address. Multicast addresses associated with a particular application may be assigned by the application owner (e.g., a social media platform) or by a standards authority. Multicast addresses may be generated based on the application, for example, the name of the application. Multicast addresses may be cryptographically linked to the application.

[0024] 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 may be obtained from a public resource such as a blockchain, or from the application owner (i.e., the application provider) or another party. As shown in Figure 4, the first network address may be provided to the second party 402 by the third party 403. Much more on this will be explained below.

[0025] The second party 402 sends a blockchain transaction containing data related to the first application to the first multicast address. That is, the blockchain transaction is sent via the internet addressed to the first multicast address. A person skilled in the art is well aware of how to route data to a multicast address. The second party 402 may send multiple blockchain transactions containing data related to the first application to the first multicast address.

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

[0027] As an addition or alternative, the second party sends a proof of inclusion for a blockchain transaction containing data relating 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 is 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 simplified verification proof (SPV). Those skilled in the art are familiar with SPVs. The second party 402 may send a number of proofs of inclusion to the first multicast address, each proof proving that a particular blockchain transaction containing data relating to the first application is recorded on blockchain 150.

[0028] The second party 402 may determine a number of multicast addresses, each associated with a particular application. For example, the second party 402 may receive a list of addresses from the third party 403, as will be further described below. The second party 402 may send a transaction containing data relating to a particular application, and / or a proof of inclusion of a transaction containing data relating to a particular application, to the multicast address associated with (i.e., addressed to) that particular application.

[0029] The first party 401 is also configured to determine (e.g., obtain, receive, or generate) a first multicast address associated with the first application. The first party 401 may determine the first multicast address with respect to the second party in any of the manners described above, including requesting the first multicast address from and receiving it from the third party 403.

[0030] The first party 401 joins (i.e., listens to / monitors) the first multicast address in search of blockchain messages related to the first application. In either case, the first party 401 is configured to retrieve data sent to the first multicast address, where the blockchain message may include a blockchain transaction and / or proof of inclusion of a blockchain transaction. For example, the first party 401 may receive a transaction submitted to the first multicast address by the second party 402 by joining the first multicast address.

[0031] The first party 401 may perform one or more actions in response to obtaining a blockchain transaction and / or proof. For example, the first party 401 may store the blockchain transaction and / or proof in memory. For example, the first party 401 may send one or more of the blockchain transactions to one or more parties, for example, one or more blockchain nodes 104. The first party 401 may issue one or more of the blockchain transactions on blockchain 150. In some examples, the first party 401 may first activate one or more of the blockchain transactions and issue only the activated transactions on blockchain 150.

[0032] Once issued on blockchain 150, the first party 401 may send each proof of inclusion for the issued transaction (e.g., an SPV proof) to the first network address. The second party 402 may retrieve the proof of inclusion sent by the first party 401 to the first network address in order to determine whether the transaction has been issued on blockchain 150.

[0033] The second party 402 may determine a number of multicast addresses, each associated with a particular application. For example, the second party 402 may receive a list of addresses from the third party 403, as will be further described below. The second party 402 may retrieve from the multicast addresses associated with (i.e., addressed to) that particular application a transaction containing data relating to that particular application, and / or proof of inclusion of a transaction containing data relating to that particular application.

[0034] In some examples, each application may be associated with multiple multicast addresses. Each address may be used for a specific purpose, such as an address for transactions, an address for SPV certificates, an address for payments, an address for renewals, and so on.

[0035] Generally, it should be noted that the first party 401 may perform any of the actions performed by the second party 402, and vice versa.

[0036] 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 can be configured to route traffic on network 101.

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

[0038] The mapping may take the form of a Merkle tree. One or more leaves of the Merkle tree are generated based on each multicast address. That is, each multicast address is hashed separately to form the leaf hash of the Merkle tree. Each application may be assigned an index in the Merkle tree by having its associated multicast address hashed to form a leaf hash in its index of the Merkle tree.

[0039] The third party 403 may retrieve a list of applications for which a multicast address is requested. The third party 403 may determine a list of indices based on the list of applications and look up multicast addresses in the Merkle tree that occupy the positions corresponding to those indices. The third party 403 may verify that the multicast addresses at those positions correspond to the requested applications and may supply the multicast addresses to the requesting party only if they correspond to the requested applications.

[0040] A fourth party 404 (for example, blockchain node 104) may also maintain the same mapping. For example, the fourth party 404 may generate the mapping. The fourth party 404 may supply the mapping to the third party 403. If the mapping is a Merkle tree, the fourth party 404 may supply either 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.

[0041] 1.1 Specific Examples Embodiments of this disclosure enable users and other types of parties to send and receive application-related data, such as transactions or Merkle certificates, including Simplified Payment Verification (SPV) certificates, which are stored on or otherwise associated with a blockchain. This section provides specific examples of the embodiments described above.

[0042] Each related application may be associated with a multicast address. The association could be, for example, - A multicast address cryptographically linked to the application, or - It may be a multicast address assigned by a third party (for example, IANA, i.e., the global coordination of DNS routes, IP addressing, and other Internet Protocol resources).

[0043] In the latter case, the application may need to apply address allocation. Users, devices, and other interested parties may subscribe to that multicast address to receive updates as described above.

[0044] Blockchain node 104 may subscribe to all multicast addresses (or at least most of them) in order to receive, validate, and issue transactions. Once a transaction is issued, an SPV certificate may be broadcast to the same multicast address to inform other parties involved, such as application users. It may be the responsibility of the multicast address creator to notify network node 104 that it needs to subscribe to those addresses. Alternatively, an application may use multiple multicast addresses dedicated to specific traffic (e.g., sending transactions and receiving SPV certificates). It may be the responsibility of the multicast address creator to notify network node 104 that it needs to subscribe to those addresses.

[0045] Blockchain node 104 may prune transactions or transaction data after publication. New services may emerge in the overlay network for storing or backing up data required by specific applications, such as application-specific permanent record-keeping nodes. Users can use these services to retrieve data without having to query node 104. SPV certificates serve as validity authentication and tamper-proof mechanisms.

[0046] Figure 5 shows an exemplary flow for a payment from a user to an application, involving some application-specific data. 1) The application user sends the transaction, including the payment, and some data to the multicast address. a. The application receives payment transactions and data. b. Network node 104 receives the transaction. c. A node for permanent record storage stores the data for future use. 2) Network node 104 activates the transaction and inserts it into the block. 3) Network node 104 sends the transaction SPV certificate to the multicast address. a. The application user receives an SPV certificate indicating that a transaction has been issued and optionally stores it for future reference. b. The application receives the SPV certificate and processes the data. c. A node for permanent record storage records the SPV certificate.

[0047] Application-specific overlay networks may continue to use data authenticated using blockchain 150 without further interaction with network nodes.

[0048] Blockchain network 106, at a given moment, n, created and broadcast by applications and users. T n different transaction types T Assume there are several different types of network traffic. Each different protocol, application, or traffic type is

[0049]

number

[0050] It can be associated with different registered multicast addresses, which are labeled as such. The order of this index may be arbitrary, or the index may be arbitrarily ordered to signify (for example) the age of the corresponding protocol or application.

[0051] As shown in Figure 6, the Merkle tree may be formed from any subset of these multicast IP addresses. This may be done by simply generating a standard binary Merkle tree, such as the one used in Bitcoin for transactions, where each leaf node corresponds to a hash of a multicast IP address. Such a Merkle tree, encoding the entire set of multicast addresses for all types of network traffic on blockchain 150, may be derived by any blockchain node 104, since they receive and propagate all types of traffic from one another as part of the core blockchain network 106. Nodes 104 may wish to issue their Merkle trees or at least their roots as certificates and advertisements for the types of network traffic currently supported (or seen on) the blockchain network 106. This could be a useful service for application hosts as well as law enforcement and regulatory bodies. The Merkle roots may be signed by node 104, or any party maintaining such a tree, to enhance the value of the certificate.

[0052] Consider a user or device labeled A on the edge of an overlay network based on the core blockchain network, such as a local CBDC overlay or social media platform. A is n k I want to subscribe to a set of k services or applications that correspond to n network traffic types. kThis means that A needs to obtain a certain number of multicast IP addresses. To obtain these addresses, A can communicate with router R, which maintains a mapping between traffic types and multicast IP addresses. R may store this mapping as a Merkle tree, as briefly described above. This allows R to efficiently store and look up a large set of addresses, as well as check them against any publicly available certificate of the network traffic tree issued by blockchain node 104 in the core node network 106.

[0053] n k An example protocol that allows A to join a given traffic type is as follows: 1. A wants n to join. k Select a traffic type. 2. A is encoded as (for example) a traffic type code or a list of strings, n k Determine the traffic type and send a multicast discovery request to R. 3. R ​​translates the request into a list of indices where each traffic type multicast address corresponds to an index stored in the Merkle tree.

[0054]

number

[0055] I'll do that. 4. R is indexed as required by A.

[0056]

number

[0057] Check that leaf nodes exist in the network and that they support the expected network traffic type. a. For any index that fails this test, R sends a null address back to A in step 7. 5. R is an IP address

[0058]

number

[0059] Take it out. 6. Optional: R is leaf

[0060]

number

[0061] Then, recalculate the Merkle root using the corresponding partial Merkle proof and compare it to the published version of the root. 7. R responds to those requests

[0062]

number

[0063] Send to A. 8. A is a multicast IP address

[0064]

number

[0065] It begins receiving the desired traffic to be sent to.

[0066] The purpose of Step 4 is for the router to check that a registered multicast IP address exists for each given network traffic type. In other words, this step is used to check that a routing path exists for A to join the multicast IP address for each traffic type.

[0067] In step 6, R can optionally recalculate the Merkle root of its local tree and compare it to the issued root of the node to check that its address is up-to-date and still valid.

[0068] In general, n k k 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.

[0069] A process diagram of an exemplary protocol is shown in Figure 7.

[0070] One or more embodiments of this disclosure provide the following functions:

[0071] Multicast addresses may be used to create partitions within a blockchain network (i.e., an overlay network) based on a specific application or use case.

[0072] A multicast address is linked to an application. The link may be a multicast address cryptographically linked to the application, or a multicast address assigned by a third party.

[0073] Interested users and other parties may subscribe to application-specific multicast addresses to receive application-specific traffic.

[0074] Applications and users may send applications-related transactions to a relative multicast address that identifies network node 104 and signifies that there is no requirement to communicate with it.

[0075] Network nodes may subscribe to all multicast addresses to receive activation and publication transactions.

[0076] A network node may issue an SPV certificate to the same multicast address to notify interested parties that a transaction is being issued.

[0077] The application may use multiple multicast addresses, for example, a multicast address for broadcasting transactions and a multicast address for receiving SPV certificates.

[0078] The following use cases may be realized using the embodiments described herein.

[0079] A central bank may release a blockchain-based CBDC solution that monitors all relevant transactions without requiring the setup of a full set of nodes. Similarly, users may send direct payments (peer-to-peer) to other users. The recipient broadcasts the transaction for public disclosure on the blockchain, and both parties receive SPV confirmation from blockchain node 104.

[0080] Video games may use blockchain to record transactions. Players may subscribe to multicast addresses to receive updates. In an even lighter approach, multicast addresses may be linked to different parts of the game (e.g., different worlds, circuits, battles, depending on the game).

[0081] Blockchain node 104 may specialize in activating transactions from multicast addresses. Blockchain node 104 processes such transactions with high priority and responds quickly using SPV certificates. Blockchain node 104 may charge applications and services willing to pay for priority or guaranteed SPV certificates in exchange for a more expensive service.

[0082] The storage service may subscribe to multicast addresses, store data and SPV certificates, and sell access to data relevant to a specific application or use case. Blockchain node 104 may prune data without affecting the functionality of the application and overlay network.

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

[0084] Client-side software or devices that enable access to blockchain-based applications may establish subscriptions to many streams of network traffic.

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

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

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

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

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

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

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

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

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

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

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

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

[0097] Any given blockchain node may be configured to perform one or more of the following operations: validating transactions, storing transactions, propagating transactions to other peers, and performing consensus (e.g., proof-of-work) / mining operations. In some examples, each type of operation is performed by a different node 104; that is, nodes may specialize in a particular operation. For example, node 104 may focus on transaction validation and propagation, or on block mining. In some examples, blockchain node 104 may perform two or more of these operations in parallel. Any reference to blockchain node 104 may refer to an entity configured to perform at least one of these operations.

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

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

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

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

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

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

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

[0105] An alternative type of transaction protocol, operated by several blockchain networks, is sometimes referred to as an "account-based" protocol as part of the account-based transaction model. In the account-based example, each transaction specifies the amount to be transferred not by retrospectively referencing the UTXO of a preceding transaction in a sequence of past transactions, but rather by referencing an absolute account balance. The current state of all accounts is accumulated and constantly updated by nodes of that network, separate from the blockchain. In such a system, transactions are ordered using the account's running transaction account (also called a "position" or "nonce"). This value is signed by the sender as part of their cryptographic signature and hashed as part of the transaction reference calculation. In addition, an optional data field may also be signed by the transaction. This data field may point backward to a previous transaction, for example, if the data field contains a previous transaction ID.

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

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

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

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

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

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

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

[0113] Therefore, in the illustrated example, the UTXO0 in the output 203 of Tx0 requires Alice's signature Sig P A for the locking script [Checksig P A to pay back UTXO0 (strictly speaking, for the subsequent transaction attempting to pay back UTXO0 to be valid). [Checksig P A includes the notation (i.e., hash) of the public key P A from Alice's public key-private key pair. The input 202 of Tx1 has a pointer that points backward to Tx1 (for example, in an embodiment, the transaction ID of that transaction, i.e., TxID0, which is the hash of the entire transaction Tx0). The input 202 of Tx1 has an index that identifies UTXO0 within Tx0 to distinguish it among any other possible outputs of Tx0. The input 202 of Tx1 has an unlocking script <Sig P A>Furthermore, the data (or "message") that needs to be signed by Alice to provide a valid signature may be defined by a locking script, by the node protocol, or a combination thereof.

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

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

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

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

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

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

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

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

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

[0123] Several embodiments have been described regarding blockchain networks implementing a proof-of-work consensus mechanism to secure the underlying blockchain. However, proof-of-work is only one type of consensus mechanism, and generally, embodiments may use any type of preferred consensus mechanism, such as proof-of-stake, delegated proof-of-stake, proof-of-capacity, or proof-of-elapsed time. As a specific example, proof-of-stake uses a randomized process to determine which blockchain node 104 will be given the opportunity to generate the next block 151. The node chosen is often called a validator. Blockchain nodes can look up their tokens over a period of time to have the opportunity to become a validator. Generally, the node that locks the largest contribution over the longest period of time has the best opportunity to become the next validator.

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

[0125] Statement 1. A computer-based method for obtaining application-related data, the method being performed by the first party, Determining the first multicast network address associated with the first application, The process involves obtaining one or more proofs of each blockchain transaction and / or inclusion using a first multicast address, wherein each proof of inclusion is associated with its respective blockchain transaction, and each blockchain transaction contains the respective data relating to the first application.

[0126] Statement 2. The method of Statement 1, comprising storing one or more proof of each blockchain transaction and / or inclusion.

[0127] Statement 3. The method of Statement 1 or Statement 2, comprising sending one or more proofs of each blockchain transaction and / or inclusion to one or more parties.

[0128] Statement 4. A method of any of the aforementioned statements, comprising activating one or more blockchain transactions in accordance with the blockchain protocol.

[0129] Statement 5. The method of Statement 4, comprising issuing one, part, or all of each of the one or more blockchain transactions to be activated onto the blockchain.

[0130] Statement 6. Any of the above statements in any manner, Obtaining proof of inclusion for one, part, or all of each blockchain transaction issued on the blockchain, This includes sending each proof of inclusion to the first multicast address.

[0131] Statement 7. Any of the above-mentioned methods of making a statement, The method involves using one, part, or all of the respective proofs of inclusion to verify that each associated blockchain transaction is issued on the blockchain.

[0132] Statement 8. A method of any of the statements described above, wherein the determination comprises generating a first multicast address.

[0133] Statement 9. The determination is made by any of the methods in Statements 1 to 7, wherein the determination is made by receiving the first multicast address.

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

[0135] Statement 11. A method of any statement described above, comprising monitoring a first multicast address to obtain proof of one or more respective blockchain transactions and / or inclusions.

[0136] Statement 12. The method of any of the statements above, wherein the first multicast address is generated based on the first application.

[0137] Statement 13. The method of Statement 12, wherein the first multicast address is cryptographically linked to the first application.

[0138] Statement 14. The method of any of the statements described above, wherein the first multicast address is an IPv4 or IPv6 address.

[0139] Statement 15. Any of the above statements in any manner, This involves determining multiple multicast addresses, with each multicast address being associated with a specific application. Each application is configured to obtain one or more respective blockchain transactions and / or one or more respective proofs of inclusion using its respective multicast address, wherein each respective proof of inclusion is associated with its respective blockchain transaction, and each respective blockchain transaction contains the respective data related to its respective application.

[0140] Statement 16. Any of the above statements in any manner, Determining one or more additional multicast network addresses associated with the first application, The process involves obtaining one or more proofs of each blockchain transaction and / or inclusion using one or more additional multicast network addresses, wherein each proof of inclusion is associated with its respective blockchain transaction, and each blockchain transaction comprises its respective data relating to the first application.

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

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

[0143] Statement 19. A computer-based method for propagating application-related data, the method being performed by a second party. Determining the first multicast network address associated with the first application, The process comprises sending one or more respective blockchain transactions and / or one or more proofs of inclusion to a first multicast address, wherein each proof of inclusion is associated with its respective blockchain transaction, and each respective blockchain transaction contains the respective data relating to the first application.

[0144] Statement 20. The method of Statement 19, comprising obtaining, using the first multicast address, each proof of inclusion associated with one or more blockchain transactions sent to the first multicast address.

[0145] Statement 21. The method of Statement 19 or Statement 20, wherein the determination comprises receiving a first multicast address.

[0146] Statement 22. The method of Statement 21, comprising sending a request to a third party for the respective network addresses associated with one or more respective applications, wherein one or more respective applications comprise a first application.

[0147] Statement 23. By any means of Statement 19 or any statement subordinate thereto, Determining one or more additional multicast network addresses associated with the first application, The process comprises sending one or more respective blockchain transactions and / or one or more proofs of inclusion to one or more additional multicast network addresses, wherein each proof of inclusion is associated with its respective blockchain transaction, and each respective blockchain transaction contains its respective data relating to the first application.

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

[0149] Statement 25. By the method of Statement 23 or Statement 24, The method comprises sending one or more blockchain transactions to a first multicast network address and one or more proofs of inclusion to one of the additional multicast network addresses.

[0150] Statement 26. A computer-implemented method for facilitating the transmission and reception of application-related data, wherein each of a plurality of multicast addresses is associated with each of a plurality of applications, and the method is performed by a third party. Maintaining a mapping between multiple multicast addresses and multiple applications, Receiving requests from requesting parties for each set of multicast addresses associated with each set of applications, where each set of applications belongs to multiple applications, It includes sending the requested set of multicast addresses to the requesting party.

[0151] Statement 27. The method of Statement 26, wherein the mapping comprises a hash tree, and each of the multiple leaf hashes of the hash tree is generated by hashing each multicast address among the multiple multicast addresses.

[0152] Statement 28. The method of Statement 27, wherein each application is associated with each index of the hash tree, and the method is Convert the requested set of multicast addresses associated with each set of applications into a list of indices, where each index in the list corresponds to the index associated with each application associated with the requested multicast address. This includes verifying that each leaf hash of the hash tree occupying each position associated with each index in the set of indices corresponds to the respective requested multicast address.

[0153] Statement 29. A method of Statement 26 or any statement subordinate thereto such that each index associated with each application is assigned according to the respective age of each application.

[0154] Statement 30. By means of Statement 26 or any statement subordinate thereto This involves obtaining the target root hash of the target hash tree, where the target root hash is generated by the blockchain node. It includes verifying that the root hash of the hash tree corresponds to the target root hash.

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

[0156] Statement 32. A computer-implemented method for facilitating the transmission and reception of application-related data, wherein each of a plurality of multicast addresses is associated with each of a plurality of applications, and the method is performed by a fourth party. Maintaining a mapping between multiple multicast addresses and multiple applications, This includes making the mapping and / or commitment to the mapping available to one or more parties.

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

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

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

[0160] In other embodiments disclosed herein, a method may be provided comprising an action by any of the first, second, third, and fourth parties. In other embodiments disclosed herein, a system may be provided comprising computer equipment of the first, second, third, and fourth parties. [Explanation of symbols]

[0161] 100 Systems 101 Packet-switched network, network 102 Computer equipment 103 Users, Parties, Agents 103a Alice 103b Bob 104 nodes, blockchain nodes, Bitcoin nodes, network nodes 105 Client applications, software 106. Distributed network, blockchain network, peer-to-peer (P2P) network, core blockchain network 150 Blockchains 151 blocks, blockchain blocks 152 transactions, blockchain transactions 154 ordered sets, ordered pools 201 Header 202 Input, Input Field 203 Output, Output Fields 400 System 401 First Party 402 Second party 403 Third Party 404 The Fourth Party

Claims

1. A computer-based method for obtaining application-related data, performed by a first party, A step of determining a first multicast network address associated with a first application, A method comprising the steps of obtaining one or more proof of each blockchain transaction and / or inclusion using the first multicast address, wherein each proof of inclusion is associated with each blockchain transaction and each blockchain transaction comprises each data relating to the first application.

2. The method according to claim 1, further comprising the step of storing each of the one or more blockchain transactions and / or each of the one or more proofs of inclusion.

3. The method according to claim 1 or 2, further comprising the step of sending each of the one or more blockchain transactions and / or each of the one or more proofs of inclusion to one or more parties.

4. The method according to any one of claims 1 to 3, further comprising the step of activating one or more blockchain transactions in accordance with a blockchain protocol.

5. The method according to claim 4, further comprising the step of issuing one, part, or all of the one or more blockchain transactions to be activated to the blockchain.

6. The steps include obtaining proof of inclusion for one, part, or all of the one or more blockchain transactions issued on the blockchain, The steps include sending each proof of inclusion to the first multicast address and The method according to any one of claims 1 to 5, comprising:

7. The method according to any one of claims 1 to 6, comprising the step of using one, part, or all of the one or more respective proofs of inclusion to verify that each associated blockchain transaction is issued on the blockchain.

8. The method according to any one of claims 1 to 7, wherein the step of determining comprises the step of generating the first multicast address.

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

10. The method according to claim 9, comprising the step of sending a request to a third party for each network address associated with one or more applications, wherein each of the one or more applications comprises the first application.

11. The method according to any one of claims 1 to 10, wherein the acquisition step comprises the step of monitoring the first multicast address to obtain proof of one or more blockchain transactions and / or inclusions.

12. The method according to any one of claims 1 to 11, wherein the first multicast address is generated based on the first application.

13. The method according to claim 12, wherein the first multicast address is cryptographically linked to the first application.

14. The method according to any one of claims 1 to 13, wherein the first multicast address is an IPv4 or IPv6 address.

15. A step of determining multiple multicast addresses, wherein each multicast address is associated with a respective application. The method according to any one of claims 1 to 14, comprising the step of obtaining, for each application, one or more respective blockchain transactions and / or one or more respective proofs of inclusion using the respective multicast address, wherein each respective proof of inclusion is associated with a respective blockchain transaction, and each respective blockchain transaction comprises respective data relating to the respective application.

16. The steps include determining one or more additional multicast network addresses associated with the first application, The method according to any one of claims 1 to 15, comprising the step of obtaining one or more proof of each blockchain transaction and / or inclusion using one or more additional multicast network addresses, wherein each proof of inclusion is associated with each blockchain transaction, and each blockchain transaction comprises each data relating to the first application.

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

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

19. A computer-based method for propagating application-related data, performed by a second party, A step of determining a first multicast network address associated with a first application, A method comprising the steps of sending one or more proof of each blockchain transaction and / or inclusion to the first multicast address, wherein each proof of inclusion is associated with each blockchain transaction and each blockchain transaction comprises data relating to the first application.

20. The method according to claim 19, further comprising the step of obtaining, using the first multicast address, each proof of inclusion associated with each of the one or more blockchain transactions sent to the first multicast address.

21. The method according to claim 19 or 20, wherein the step of determining comprises the step of receiving the first multicast address.

22. The method according to claim 21, comprising the step of sending a request to a third party for each network address associated with one or more applications, wherein each of the one or more applications comprises the first application.

23. The steps include determining one or more additional multicast network addresses associated with the first application, The method according to any one of the dependent claims of claim 19 or any of its dependent claims, comprising the steps of sending one or more proof of each blockchain transaction and / or inclusion to one or more additional multicast network addresses, wherein each proof of inclusion is associated with each blockchain transaction, and each blockchain transaction comprises each data relating to the first application.

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

25. The method according to claim 23 or 24, further comprising the steps of sending each of the one or more blockchain transactions to the first multicast network address and each of the one or more proofs of inclusion to one of the additional multicast network addresses.

26. A computer-based method for facilitating the transmission and reception of application-related data, wherein each of a plurality of multicast addresses is associated with each of a plurality of applications, and the method is performed by a third party. The steps include maintaining a mapping between each of the plurality of multicast addresses and each of the plurality of applications, A step of receiving a request from a requesting party for a set of multicast addresses associated with each set of applications, wherein each set of applications belongs to each of the plurality of applications, The steps include sending the requested set of multicast addresses to the requesting party and A method that includes [a certain feature].

27. The method according to claim 26, wherein the mapping comprises a hash tree, and each of the plurality of leaf hashes of the hash tree is generated by hashing each multicast address among the plurality of multicast addresses.

28. Each application is associated with a corresponding index in the hash tree, and the method is A step of converting the requested set of multicast addresses associated with each set of applications into a list of indices, wherein each index in the list corresponds to the respective index associated with each application associated with the requested multicast address, The steps include verifying that each leaf hash of the hash tree occupying each position associated with each index in the set of indices corresponds to the respective requested multicast address, and The method according to claim 27, comprising:

29. The method according to claim 26 or any one of its dependent claims, wherein each of the indices associated with each of the aforementioned applications is assigned according to the respective age of each of the aforementioned applications.

30. A step of obtaining the target root hash of the target hash tree, wherein the target root hash is generated by a blockchain node. A step of verifying that the root hash of the hash tree corresponds to the target root hash. The method according to any one of the dependent claims of claim 26 or the method comprising:

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

32. A computer-based method for facilitating the transmission and reception of application-related data, wherein each of a plurality of multicast addresses is associated with each of a plurality of applications, and the method is performed by a fourth party. The steps include maintaining a mapping between each of the plurality of multicast addresses and each of the plurality of applications, The steps of making the mapping and / or commitment to the mapping available to one or more parties. A method that includes [a certain feature].

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

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

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

Images