Computer-implemented systems and methods for efficient and secure processing, access, and transmission of data via blockchain

Abstract

Methods and systems are provided for storing, sharing, searching, writing, and accessing data (content) on a blockchain, such as the Bitcoin ledger. Embodiments of the method may include processing at least one blockchain transaction, including a protocol flag, at least one optional public key, and at least one optional transaction ID. These are optional in the sense that they are required in accordance with the present disclosure and not as part of the underlying blockchain protocol. At least one transaction (Tx) also includes multiple inputs, each having i) a parent public key (PPK) and ii) a signature (S) generated using the parent public key (PPK). Transactions thus form indexed nodes in a graph or hierarchical tree of logically related nodes, at least some of which contain or reference pieces of data. Nodes in such a tree can have multiple parents and / or children. Authorized access to data is cryptographically enforced. Large, complex datasets can be represented, stored, communicated, and identified in a secure and efficient manner via a resilient peer-to-peer architecture.

Description

[Technical Field]

[0001] Embodiments of the present disclosure relate generally to improvements for secure data transfer across electronic networks, and peer-to-peer networks in particular. The present disclosure relates to data storage, access, retrieval, processing, and transmission, and more particularly to such data-related activities on blockchain networks. Embodiments are particularly suited, but not limited to, for use in processing and sharing data between entities using blockchain as an underlying mechanism or platform to eliminate, or at least mitigate, drawbacks associated with traditional server-based architectures. Accordingly, embodiments of the present disclosure provide a secure, resilient, efficient, and cryptographically-enforced alternative network infrastructure for data processing, storage, access control, versioning, and transfer. [Background technology]

[0002] A "blockchain" refers to a form of distributed data structure in which duplicate copies of the blockchain are maintained at each of multiple nodes in a distributed peer-to-peer (P2P) network (hereinafter referred to as the "blockchain network") and made publicly available. A blockchain contains a chain of blocks of data, with each block containing one or more transactions. Each transaction, except for so-called "coinbase transactions," points back to the preceding transaction in a sequence that may span one or more blocks, up to one or more coinbase transactions, which are described below. Transactions submitted to the blockchain network are included in new blocks. New blocks are often produced by a process called "mining," which involves multiple nodes each competing to perform a "proof of work," i.e., solving a cryptographic puzzle based on a representation of a defined set of ordered and verified pending transactions awaiting inclusion in a new block of the blockchain. It should be noted that a blockchain may be deleted by a node, and publication of a block is achieved by simply publishing the block header.

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

[0004] Nodes in a blockchain network (often referred to as “miners”) perform a distributed transaction registration and validation process, which is described in more detail below. Briefly, during this process, nodes validate transactions and insert them into block templates attempting to identify valid proof-of-work solutions. Once a valid solution is found, a new block is propagated to other nodes in the network, thus allowing each node to record a new block in the blockchain. To record a transaction in the blockchain, a user (e.g., a blockchain client application) submits the transaction to one of the nodes in the network, where it is propagated. Nodes receiving the transaction may compete to find a proof-of-work solution that will incorporate the validated transaction into the new block. Each node is configured to implement the same node protocol, which includes one or more conditions for a transaction to be valid. Invalid transactions are not propagated to or incorporated into a block. Assuming the transaction is verified and thereby accepted into the blockchain, the transaction (including any user data) remains registered and indexed as an immutable public record at each node in the blockchain network.

[0005] Nodes that successfully solve the proof-of-work puzzle to create the latest block are typically rewarded with a new transaction called a "coinbase transaction" that distributes a sum of digital assets, i.e., a number of tokens. Detection and rejection of invalid transactions is performed by competing nodes that act as agents of the network and have an incentive to report and block fraudulent activity. Public disclosure of information allows users to continuously audit node performance. By simply publishing block headers, participants can guarantee the ongoing integrity of the blockchain.

[0006] In an “output-based” model (sometimes referred to as a 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 that specifies the total value of a digital asset derivable from the preceding sequence of transactions. A usable output is sometimes referred to as a UTXO (“unspent transaction output”). An output may further include a locking script that specifies the conditions for the output’s future redemption. A locking script is a predicate that defines the conditions necessary to validate and transfer a digital token or asset. Each input of a transaction (other than a coinbase transaction) includes a pointer (i.e., a reference) to that output in the preceding transaction and may further include an unlocking script to unlock the locking script of the pointed-to output. Thus, we refer to a pair of transactions as the first and second transactions (or “target” transactions). The first transaction includes at least one output specifying a value of the digital asset and a locking script defining one or more conditions for unlocking the output. The second, target transaction includes at least one input including a pointer to the output of the first transaction and an unlocking script for unlocking the output of the first transaction.

[0007] In such a model, when a second target transaction is sent to the blockchain network to be propagated and recorded in the blockchain, one validity criterion applied by each node is that the unlocking script meets all of one or more conditions defined in the locking script of the first transaction, and another is that the output of the first transaction has not yet been redeemed by another transaction that was previously valid. Any node that finds the target transaction invalid according to either of these conditions will not propagate the transaction (potentially registering an invalid transaction as a valid transaction) or not include it in the new block recorded in the blockchain.

[0008] An alternative type of transaction model is the account-based model, where each transaction does not define the amount transferred by referencing back to the UTXO of a previous transaction in a sequence of past transactions, but rather by referencing an absolute account balance. The current state of every account is stored and constantly updated by nodes separate from the blockchain.

[0009] As mentioned above, additional layers of functionality can be used on top of a blockchain. Furthermore, blockchain protocols may enable the storage of additional user data or indexes to data in transactions. Today, data communication is typically achieved through the use of systems that serve data across the Internet, with servers hosting websites and pages that users visit to access desired data, typically using search engines. However, using the Internet as a repository for storing and sharing data is not without challenges. These include concerns about how to effectively and securely manage data and how to enable the efficient storage, retrieval, and exchange of data with authorized third parties. While the Internet uses a decentralized architecture, in practice, it allows centralized organizations and companies to manage and monetize much data and content, often without the consent or even knowledge of the parties or entities that created the data. Internet-related functionality and tools, such as search engines, email services, file and web hosting, etc., are often dominated, if not effectively controlled, by large corporations and organizations that use their own computing resources, e.g., servers, for these purposes. If these servers fail or are compromised by security hacks or DDoS attacks, critical services can be disrupted or data security and privacy can be compromised. Some question whether these organizations have become "too big to fail" - that they have too much power and vested interests to be trusted to run a network as essential and global as the internet.The Internet's client-server approach and centralized implementation raise serious technical concerns regarding scalability, security, privacy, data ownership, and exploitation of data mining. It is effectively vulnerable to trusted entities.

[0010] These concerns have led some observers to explore the use of blockchain to address at least some of these shortcomings associated with the internet. See, for example, the book entitled "Life After Google: The Fall of Big Data and the Rise of the Blockchain Economy," by George Gilder, Gateway Editions, July 2018, ISBN-10: 9781621575764 and ISBN-13: 9781621575764. Therefore, a decentralized, distributed, resilient, and scalable alternative is desirable.

[0011] Various aspects of the blockchain-implemented solution known as “the Metanet” are presented in International Patent Applications PCT / IB2019 / 059807, PCT / IB2019 / 059808, PCT / IB2019 / 059809, PCT / IB2019 / 059793, PCT / IB2019 / 059795, PCT / IB2019 / 059791, PCT / IB2019 / 059803, and PCT / IB2019 / 060226, all of which are incorporated herein in their entireties.

[0012] Metanet is a transaction-based protocol for building an on-chain realization of a large-scale network for indexing, linking, permissioning, sharing, and storing data, such as the internet. A core aspect of this protocol is ensuring that internet-like data mined into the blockchain is contained in a specific transaction format, so that a directed acyclic graph (DAG) of this data can be interpreted off-chain by any user. The Metanet DAG contains nodes (blockchain transactions) and edges (created by cryptographic signatures) that connect these nodes.

[0013] Metanet's design goals include the need for sufficient simplicity and generality while also ensuring that graphs constructed according to the protocol do not contain any cycles, a known requirement for any DAG, as cycles can cause various technical challenges, such as security and authorization failures in hierarchical systems built on DAG structures. To achieve these technical goals, nodes in the Metanet DAG can only have parents of either 0 or 1 (an in-degree of 0 or 1). In contrast, no such restriction is imposed on the number of children any node may have (out-degree-free). While the restriction placed on node in-degree is appropriate for many applications and use cases, there are also situations in which it is desirable to have more than one parent for a given node. For example, this may be the case when implementing a versioning structure such as GIT, or when efficiently and accurately representing a data structure involving the amalgamation of two entities on a chain. Summary of the Invention

[0014] One or more embodiments of the present disclosure provide an alternative and improved data mechanism for secure and efficient storage, sharing, structuring, authorization, versioning, indexing, addressing, accessing, and / or searching of data. The embodiments provide an improvement that allows, at a minimum, nodes in a (Metanet type) hierarchy of nodes to have multiple parents, without compromising the security and other benefits flowing from the Metanet protocol. Thus, embodiments of the present disclosure ensure that multiple parent nodes, referred to for ease of reference as "Metanet confluences," can be created without introducing cycles into the Metanet DAG, which can create technical problems, including compromised security and authorization issues.

[0015] Embodiments also provide, among other advantages, the ability to store, share, and access structured data on top of a blockchain in more versatile and complex structures than previously known in the art, thus leading to improved efficiency in accessing, retrieving, and transmitting data with broader applicability in terms of applications that use that data and organizations / entities that utilize, generate, and / or control that data. This improved technical versatility and broader applicability enables the implementation of more complex and advantageous data applications that use the blockchain network as the underlying infrastructure and security mechanism.

[0016] The principle that enables the creation of metanet confluence is replacing the requirement of "zero or one parent per node" with "zero or one parent per input." This departure from known technology presents many technical challenges, not least because applications and systems (e.g., digital wallets and data-oriented blockchain applications) that implement and utilize blockchain transactions and the resulting data structures / networks need to be reconfigured and redesigned. Embodiments require, for example, changes to cryptographic operations performed in the creation of new data structures and subsequent verification of cryptographic controls, such as digital signatures. Solutions to at least these challenges are provided by embodiments of the present disclosure, described below. [Brief explanation of the drawings]

[0017] Aspects and embodiments of the present disclosure will now be described, by way of example only, and with reference to the accompanying drawings. [Figure 1] FIG. 1 illustrates one exemplary system for implementing a blockchain for use in accordance with an embodiment of the present disclosure. [Figure 2] FIG. 2 illustrates one exemplary UTXO-based transaction protocol that can be used with the system shown in FIG. [Figure 3A] FIG. 3A illustrates a possible implementation of a client application for use in accordance with one or more embodiments disclosed herein. [Figure 3B] FIG. 3B illustrates a user interface (UI) that may be used in accordance with one or more of the embodiments disclosed herein. [Figure 4] FIG. 4 illustrates exemplary node software that may run on each blockchain node of a network, according to one or more embodiments disclosed herein. [Figure 5] FIG. 5 shows a schematic diagram of a simple metanet structure including a confluence node with two parents, according to one exemplary embodiment of the present disclosure. [Figure 6] Figure 6 shows a metanet tree (DAG) with transactions as nodes and signatures as edges. [Figure 7] FIG. 7 shows one exemplary embodiment where a confluence node is formed by the convergence of two different Metanet trees. DETAILED DESCRIPTION OF THE INVENTION

[0018] Summary of Metanet Protocol and DAG Structure Various aspects of the Metanet Protocol and some possible implementations are provided in detail in PCT / IB2019 / 059807, PCT / IB2019 / 059808, PCT / IB2019 / 059809, PCT / IB2019 / 059793, PCT / IB2019 / 059795, PCT / IB2019 / 059791, PCT / IB2019 / 059803, and PCT / IB2019 / 060226. However, for convenience and ease of reference, a brief overview of the Metanet Protocol and its principles is provided here.

[0019] In addition to being used to transfer digital assets, it is known in the art that blockchain transactions (TX) can be used to store and communicate data. This can be any type of data, including any written text, software or code, digital media content, such as images, etc. The term "data" in this document is not intended to be limiting with respect to its type, format, purpose, or nature.

[0020] The Metanet includes a "tier-2" protocol that does not require modification of the protocol or consensus rules associated with the underlying blockchain, but further provides a mechanism whereby transactions (which may be referred to as "nodes") can be structured in a logical, hierarchical manner that allows node addressing, permissions, and content (i.e., data) version control.

[0021] The objectives and effects of the Metanet-implemented structure include, but are not limited to: (i) The ability to associate related content across different transactions (TX) to enable efficient and secure search, identification, and access. (ii) Content identification using human-readable keyword searches can improve the speed, accuracy, and efficiency of searching and retrieval. (iii) The ability to build and emulate structures such as servers within the blockchain without the need for a centralized architecture. This alternative architecture not only addresses the challenges associated with ownership and control of data by a centralized party, but also introduces network resilience, availability, and distributed processing not possible with traditional approaches. (iv) Ability to leverage and utilize the immutable time-stamping and event-ordering benefits of blockchain technology. Traditional internet-based implementations do not include such mechanisms and therefore cannot provide a solution that is flexible or robust in its functionality. (v) The use of blockchain-implemented micropayment channels and the ability to leverage such mechanisms to exercise finer and more nuanced control over when and how access is granted, resulting in permission, privacy, control, and monetization options not possible in traditional internet-based systems.

[0022] The metanet approach is to structure the data provided in a transaction as a directed graph (DAG), whose nodes and edges are as follows:

[0023] Node - A transaction related to the Metanet protocol. A node stores content. (The terms "content" and "data" are used interchangeably within this document.)

[0024] Nodes are created by including OP_RETURN in their script, which in Bitcoin is a script opcode that marks a transaction output as invalid. Note: Those skilled in the art will readily appreciate that embodiments can be devised that do not use OP_RETURN. Embodiments utilizing non-Bitcoin protocols may alternatively include functionally equivalent or similar mechanisms while still falling within the scope of this disclosure.

[0025] Immediately after OP_RETURN<Metanet Flag> This indicates that the transaction is configured to be used in accordance with and with the Metanet protocol. Each node has a public key P node The combination of this public key and an arbitrary metanet transaction ID uniquely specifies the node's index.

number

[0026] Metanet transaction / node IDs are referred to as "discretionary" to distinguish them as transaction identifiers that are not part of or specified by the underlying blockchain protocol.

[0027] The hash function (H) should be consistent with the underlying blockchain protocol used in this embodiment, for example, SHA-256 or RIPEMD-160 for Bitcoin.

[0028] Edge - Association of a child node with a parent node Edges use SigP signatures on inputs to Metanet transactions. parent appears, and therefore only parents are permitted to create edges. In previous MetaNet disclosures, parent nodes can have any number of children, but every node is defined to have at most one parent. In the language of graph theory, the in-degree of each node is at most 1, and the out-degree of each node is arbitrary.

[0029] However, such limitations exist for a wide variety of applications, and there is often a desire or need for simplification of structure and / or implementation. Such an approach can be restrictive or even disadvantageous for use cases and applications that require more complex representations. In such situations, it may not be possible to accurately or in a sufficiently complex way reflect the required structure of the system. A restrictive model may then lead to a flawed or inconvenient system design, or even make the solution infeasible. Some examples of such applications are provided below.

[0030] It should be noted that an edge is an aspect of the Metanet protocol and is not itself a transaction related to the underlying blockchain.

[0031] A valid metanet node (one that has a parent) is given by a transaction of the form: [Table 1] Table 1

[0032] Note that the first P_RETURN element here is always the 4-byte prefix '0x4d455441', which is simply the hexadecimal form of the metanet flag 'META'.

[0033] However, the simplest form of metanet node (called a “root” node) is one that has no parent and can be represented in a blockchain transaction (Tx) as follows, using a null element in place of any transaction ID of the parent: [Table 2] Table 2

[0034] Thus, a Metanet transaction is a blockchain transaction constructed according to the Metanet protocol to contain all the information needed to specify the index of a node and its parent.

number

[0035] Furthermore, only parents can create edges to their children, since the signature of the parent node is required. <TxID parentIf the field is absent or does not point to a valid metanet transaction, the node is an orphan. It has no higher-level nodes that are reachable. Additional attributes may be added for each node. These may include flags, names, and keywords.

[0036] As shown, the node index (transaction) is Can be decomposed a)Public key P node , which is interpreted as the address of the node b) Transaction ID TxID node , which is interpreted as the version of the node.

[0037] Two advantageous features arise from this structure. 1. Versioning - If there are two nodes with the same public key, we take the node with the transaction ID with the largest proof of work as the latest version of that node. If the nodes are in different blocks, this can be checked using the block height. For transactions within the same block, this is determined by the Topological Transaction Ordering Rule (TTOR). 2. The children of the permission-node are given the public key P node can be created only if the owner of signs the transaction input when creating the child node. node represents not only the address of a node, but also the permission to create child nodes. This is intentionally similar to a standard Bitcoin transaction - not just a public key in an address, but the permissions associated with that address. Note that since the parent node's signature appears in the UXTO unlocking script, it will be verified through the standard miner validation process once the transaction is accepted into the network, which means that the permission to create a child node is verified by the Bitcoin network itself.

[0038] It is worth noting that standard Internet Protocol (IP) addresses are unique within a network at any given time, whereas the index of a node within a metanet is always unique, and there is no concept of a separate network; data is stored as a single object ID. node This allows for permanent anchoring to the

[0039] This node and edge structure allows us to visualize the metanet as a graph, as shown in Figure 6, which shows an exemplary metanet tree (DAG) with transactions as nodes and signatures as edges.

[0040] Therefore, the rules for the DAG structure used in Metanet can be summarized as follows: 1. A node in a DAG is a blockchain transaction. 2.The edges of the DAG are digital signatures. 3. Each node receives a transaction identifier TxID node The public key P combined with node A unique identifier ID generated from node It has. (Note that this metanet node / transaction ID is an additional identifier that is distinct from the transaction ID (TxID) required by the underlying blockchain protocol. To distinguish between the two forms of transaction ID, we refer to the one used according to the metanet protocol as “discretionary” because it is not a requirement of the blockchain protocol itself.) 4. Node public key Pnode is a signature SigP to generate Metanet-valid children of that node. node Define the necessary conditions for 5. A node may have an in-degree of 0 or 1 and any out-degree (i.e., a free parameter).

[0041] If a node has a parent, the public key that signs its input must be that of its parent, P parent This is denoted as P, because the parent key defines the permission requirements for creating children. For a root node (which has no parent), this signing key P any can be any public key, and there is no such requirement.

[0042] However, in both cases, we can see that Rule 5 is used because there is either one parent signing key (Table 1) or no parent signing keys (Table 2), and therefore either transaction can only be considered to have one parent or zero parents, respectively. The transactions shown in these tables are the simplest form of Metanet valid transactions. From these, however, more complex transactions can be created that contain many inputs and outputs, content / data, and schemas built on this basic framework. A Metanet DAG structure can be created by constructing transactions using these simple rules.

[0043] Exemplary embodiments of the present disclosure For illustrative purposes, a description will now be provided of one or more embodiments of the present disclosure, which provide at least efficient and secure techniques for storing, processing, searching, transferring, and / or retrieving data in, from, or through an electronic peer-to-peer network, such as a blockchain. One or more embodiments also provide an alternative blockchain-implemented network infrastructure for storing, processing, searching, transferring, searching, identifying, and / or sharing data between computing nodes. By extending the functionality of blockchain networks in new technical ways, one or more embodiments of the present disclosure provide security and control of access to digital assets across alternative and improved computing platforms, including blockchains and associated blockchain protocols implemented using computing nodes. Improved control and security are achieved along with increased network resilience, decentralization, and security.

[0044] Furthermore, embodiments enable the creation and use of more complex data structures that are related, secured, and addressed / indexed via cryptographic mechanisms. Thus, embodiments enable more efficient means of locating, identifying, and accessing related data items distributed across a global, decentralized, peer-to-peer storage platform (ledger). This presents a significant technical challenge, not least because related data items may be stored anywhere within the ledger (i.e., transactions) and, therefore, it is crucial that they be organized in a way that allows efficient access, both in terms of time and resource processing. Embodiments also ensure that operations performed in connection with stored data are performed only by authorized parties, thus maintaining the integrity and security of the data within the system.

[0045] One or more embodiments of the present disclosure implement the concept of "Metanet confluences." As shown in FIG. 5, Metanet nodes are created that have one or more parent nodes. A Metanet confluence (or "confluence node") is a class of node whose technical characteristics and functionality differ from the class of nodes defined in the original Metanet protocol summarized above.

[0046] A Metanet confluence is a node, i.e., a position in a graph, where multiple, previously unconnected Metanet trees or branches (graphs) converge. To create such a node, input signatures from two parents are required—one from each of the multiple converged trees or branches. This also means that a Metanet confluence transaction is, by definition, a node with more than one parent, which violates the one-parent paradigm rule specified in the original Metanet protocol summarized above. Thus, the present disclosure is a significant deviation from the original protocol in that it teaches contrary to previous Metanet teachings.

[0047] parent paradigm As mentioned above, one of the rules established in the original Metanet protocol is the parent paradigm, which states: "A node may have 0 or 1 parent"

[0048] This rule allows the definition and distinction of two classes in total: root nodes (nodes with no parents) and non-root nodes (nodes with exactly one parent), as shown in Tables 1 and 2. In this framework, there is no notion of a class of nodes with a number of parents other than 0 or 1.

[0049] 5 and 7, confluence nodes are a new class of nodes that can have any number of parents k in the range 2≦k≦n, where n is the number of inputs in the confluence node transaction. To accommodate the class of confluence nodes, the parent paradigm protocol rule is replaced with the following: "The node For each input A node may have 0 or 1 parent per input.

[0050] This change in the parent paradigm will now be described for all three classes of nodes in a simple and concise manner, summarized below in Table 3. The "minimum" number of inputs for a node is the minimum number of inputs required to accommodate all of the node's parents. [Table 3] Table 3: Summary of node classes described under the redefined parent paradigm

[0051] It should be noted here that when referring to a node's inputs, we are actually referring to that node's "Metanet-related" inputs. For example, it is possible to have a simple, non-root node that has many inputs, but only one is signed by a parent key in accordance with this disclosure. Other inputs may be entirely unrelated to the Metanet protocol, and may, for example, be used to fund transactions or specify payments in addition to creating the node.

[0052] Importantly, the metanet protocol is always agnostic to such additional inputs and only considers metanet-related inputs. This principle also applies to the confidence transaction nodes in the same way. A confidence node can have n inputs, where only a subset of k of these inputs are metanet-related. This means that the confidence node has k < n parents. Because the metanet protocol only considers the k inputs that are metanet-related.

[0053] It should be noted that there are three scenarios in which metanet confidence can be used. The first is when confidence converges multiple, separate trees thereby, the second is when confidence converges multiple branches in one tree thereby, and the third is some combination of the other scenarios.

[0054] Confluence Transaction Structure The structure of the metanet confidence transaction is similar to the structure of a non-root transaction, with two important differences. 1. The confidence transaction includes a separate input for each of its parents. Each input corresponds to the permission of the i-th (i th ) parent that creates the child and includes the signature SigP parent,i and the public key P parent,t in its unlocking script. 2. The confidence transaction includes a reference TxID parent for each of its parents. In one or more embodiments, these references start from the third element in the OP_RETURN output of the confidence transaction.

[0055] These two aspects of the Confluence Transaction are deviations from the Metanet transaction format to create simple root and non-root transactions, updated here to accommodate multiple parents.

[0056] This allows confluence transactions to be read and interpreted in exactly the same way for root and non-root nodes, so that each parent node of a confluence can be identified from its input script and OP_RETURN reference.

[0057] The transaction shown in Table 4 is the simplest example of metanet confluence. parent,A and P parent,B Two inputs from two parents, A and B, denoted by , respectively, and two OP_RETURN parent transaction references, TxID. parent,A and TxID parent,B Contains: [Table 4] Table 4: A confluence node with two parents created using two Metanet-related inputs

[0058] The OP_RETURN output of the confluence transaction also establishes permission to create children of the confluence, i.e., the children have the public key P confluence =S confluence ·Private key S corresponding to G confluence It can only be created by the owner of G, where G is the base point of the elliptic curve.

[0059] It is therefore prudent to recommend that both parent signatures be added with either the signature flag SIGHASH_ALL or SIGHASH_ALL in the Bitcoin protocol, or a functionally similar / identical mechanism in alternative blockchain protocols. SIGHASH_ALL is a signature hash type that signs the entire transaction except for any unlocking scripts, preventing modification of the signed portion. SIGHASH_ALL|ANYONECANPAY signs all but one output, which is a specified input, and also allows anyone to add or remove other inputs. The use of SIGHASH_ALL ensures that both parent public keys always sign the OP_RETURN output, and thus ensures that P is signed when a confluence transaction is created. confluence certify and agree on the newly defined partition to create a child assigned to

[0060] This means that the parent public key P parent,A and P parent,B This is an important consideration when creating a confluence transaction, since P may be controlled by different entities. In such a case, confluence therefore requires two entities to independently use their own keys to create a “shared” key P confluence It is possible to define a consolidation of privileges or permissions into a single shared privilege using

[0061] This offers a significant improvement over the prior art in that it provides a more versatile and sophisticated cryptographic control mechanism, which also means that embodiments can be advantageously used to better reflect the technical (control, security, and ownership) requirements of data producers, owners, and users.

[0062] Whether this key is actually shared (e.g., by partitioning) among multiple entities is an implementation choice that depends on a given embodiment, however, this integration of the concept of "key authority" should be acknowledged because metanet confluence nodes inherit the permission structure defined in the core metanet design.

[0063] A more complex example of a confluence transaction is shown below in Table 5. This confluence is generalized to encompass k parents, meaning it has a minimum of k inputs, including signatures from k parent nodes and k references to each parent transaction.

[0064] This confluence therefore represents the total convergence of the k trees and / or branches. [Table 5] Table 5: Confluence nodes with k parents created using k Metanet-related inputs

[0065] In the transaction diagram above, we have represented the simplest form of a confluence of k parents with exactly n=k inputs. However, as outlined above, it is possible for such a confluence to have more inputs than parents.

[0066] The transaction diagram in Table 6 shows an example of a confluence transaction with n>k inputs. Recall that for a confluence to have k parents, it requires a minimum of k inputs to represent them, but this does not preclude the existence of additional nk inputs that are not considered relevant to the metanet view of confluence. [Table 6] Table 6: The conflence nodes of Table 5. It shows a total of n inputs, where only k < n are meta-net related (cells of the table with single-line boundaries), and the rest are not meta-net related (cells of the table with double-line boundaries).

[0067] This conflence is structurally identical to the transaction shown in Table 5, and the only difference is the additional inputs (shown in the two bottom-left cells with double-line boundaries). The remaining part of the transaction (single-line boundary cells) is substantially the same as Table 5, and only note that the actual values (r, s) of the parent signature are probably different because the additional inputs changed the signed transaction message. The single-line boundary part of this transaction is what the meta-net protocol considers and reads when constructing the meta-net graph.

[0068] Confluence Use Case Scenarios The improved meta-net solution provided in this disclosure enables modeling and representing a larger number of data structures. For example, embodiments enable modeling and implementing shared ownership or control of data in ways that were impossible with existing solutions. Using this disclosure, a wide variety of authorization and permission technologies are now possible, resulting in improved data and system security. The sharing / management of blockchain data, or the proof thereof, can be more easily represented using multiple parents than a structure where a single key is "shared" between entities. This disclosure enables an explicit way to sign, enforce, and / or prove shared ownership / consent / permission for nodes. This can be useful, or even essential, in many applications.

[0069] Thus, embodiments provide a greater degree of flexibility and expressiveness compared to previous Metanet disclosures. They provide enhanced functionality for data storage, processing, and retrieval systems that can be constructed from more complex structures and, therefore, more sophisticated hierarchies. By providing for more complex representations of the underlying data structures, the present disclosure enables the construction of advantageous technical solutions with respect to access control and efficiency of data identification and transmission.

[0070] Designing an efficient, scalable, and secure data storage and retrieval system is not a trivial task. Numerous use case scenarios may create a need for a solution according to the present disclosure. These include, but are not limited to, example scenarios such as:

[0071] · Multiple Trees - Separate Metanet trees converge An example of this is provided in Figure 7, which illustrates a scenario in which previously separate and distinct Metanet trees converge in a single confluence transaction in accordance with an embodiment of the present disclosure. The single Metanet tree has a well-defined permission structure governed by a hierarchy of public key addresses and signatures that create edges between nodes. One exemplary situation is when two entities, e.g., companies or other organizations, need to merge their access permissions across file systems. Consider a scenario where two companies undergo an acquisition / merger / conglomeration, with their assets represented on-chain by separate metanet trees. Each company's tree can represent either a set of assets or an on-chain record of the company structure. The two companies provide input from their respective tree ends.

[0072] · Multiple branches-Distinct branches converge within a single Metanet tree This scenario occurs when two branches existing within a single tree are merged together. One example could be a merge of a file with several changes or a file with a "commit" action in a version control system such as GIT.

[0073] · A combination of both previous scenarios -Tree and branch combination convergence This is a more complex scenario resulting from more complex operations, resulting in both multiple trees and multiple branches being merged into the same confluence. This can occur, for example, through more complex merges or through a version control system. The scenario can provide a fully fledged file system implementation that implements Create, Read, Update, Delete (CRUD) operations, defines transaction formats or types for each CRUD operation, and makes use of Metanet's versioning capabilities.

[0074] Each of the above scenarios is encompassed by the concept of metanet confluence detailed above, but may arise due to different use cases or implementation requirements.

[0075] Enumerated clauses Embodiments of the present disclosure provide an arrangement that advantageously utilizes at least the distributed, immutable, and persistent advantages of blockchain technology to enable data to be stored, processed, searched, sought, and / or transmitted between parties in a secure and improved manner on a blockchain.

[0076] According to embodiments of the present disclosure, a computer-implemented method and corresponding system may be provided. The method may be described as enabling or controlling secure communication, processing, storage, structuring, retrieval, identification, authorization, and / or sharing of data via a blockchain. Additionally or alternatively, it may be described as a method for relating or linking data stored in (separate / different) blockchain transactions to enable identification, retrieval, and / or sharing of said data. It also provides security solutions for ensuring access to data, ensuring that only authorized parties have access to the data.

[0077] Embodiments of the present disclosure are provided in the following enumerated clauses for purposes of illustration and not limitation. 1. A (computer and / or blockchain implemented) method comprising processing at least one blockchain transaction (Tx), the method comprising: a transaction ID (TxID); At least one arbitrary transaction ID (DTxID), and Protocol flags, At least one discretionary public key (DPK); A plurality of inputs, each of which is i) a parent public key (PPK), and ii) multiple inputs, including a signature (S) generated using a parent public key (PPK); may include:

[0078] This combination of features allows pieces of data to be stored, identified, logically associated, cryptographically securely protected, and / or accessed on the blockchain, and also to be linked / associated with one another when provided in multiple transactions contained within the blockchain. It allows for the construction of graph- or tree-like hierarchical structures that reflect relationships and associations among pieces of data and facilitate their processing, discovery, access, creation, and sharing. It also facilitates who performs operations on a given data item and by whom. Here, "sharing" can include providing, transmitting, communicating, sending, or providing access to a piece of data to a node or user. Logically associated transactions may not be stored on the blockchain at adjacent block heights, but they (and therefore their associated data) can be easily and securely identified and / or accessed.

[0079] The multiple inputs may associate a transaction (which may be referred to herein as a “confluence” or “confluence node” or “data node”) with one or more additional blockchain transactions. The one or more additional transactions may be a “metanet node” or “confluence node.” At least one of the one or more additional transactions may include at least one optional transaction ID (DTxID), a protocol flag, at least one optional public key (DPK), and one or more inputs, each having a parent public key and a signature generated using the parent public key. The at least one or more additional transactions may be referred to as logical parent transactions (LPTx).

[0080] A transaction ID (TxID) is an identifier for a transaction as known in the art of blockchain protocols—each blockchain transaction has a unique ID as part of the underlying blockchain protocol. In contrast, a discretionary public key (DPK) and / or a discretionary transaction ID (DTxID) may be “discretionary” in that they are not essential components of a transaction as dictated by the underlying blockchain protocol, but are provided as part of the present invention. In other words, they are not required for a transaction to be valid according to the underlying blockchain protocol (e.g., Bitcoin). Additionally or alternatively, they may be described as additional, non-essential items that are provided as part of the present invention, not because the blockchain protocol requires them.

[0081] Preferably, the protocol flag is associated with and / or indicates a blockchain-based protocol for searching, storing, and / or retrieving data within one or more blockchain transactions. The protocol flag may be an indicator or marker. It may indicate that a transaction is formed according to a predetermined protocol, which may be a protocol other than the protocol of the underlying blockchain. It may be a retrieval protocol according to any embodiment described herein (i.e., what is referred to herein as the "metanet" protocol).

[0082] The term “processing” means any activity related to a transaction and / or its associated data, including generating, transmitting, verifying, accessing, retrieving, sharing, submitting to a blockchain network, and / or identifying.

[0083] An optional transaction ID may be an identifier, label, indicator, or tag associated with a transaction (Tx) according to embodiments of the present invention. We use the term “indicator” to include all of these terms. As will be readily understood by those skilled in the art, note that each transaction on a blockchain is uniquely identified by an identifier, typically referred to in the art as a TxID. The TxID is an essential, required, non-optional part of the underlying blockchain protocol. This non-optional TxID should not be confused with the optional transaction ID (DTxID) referred to herein.

[0084] The combination of at least one arbitrary public key and transaction ID can specify a unique identifier or index for a transaction (Tx), and the ID Tx =P Tx ||TxID Tx The method may include generating an arbitrary ID based on the arbitrary public key and the transaction ID.

[0085] 2. The method of clause 1, wherein the transaction (Tx) further includes a portion of data or a reference to a portion of data. The reference to the portion of data may be a pointer, address, or other indicator of where the data is stored. The portion of data may be any type of data or digital content, for example, a computer-executable item, text, video, image, sound file, etc. The portion of data is referred to as "content." The portion of data, or the reference thereto, may be in a processed form, for example, a hash digest of the portion of data. The data may be stored on the blockchain or may be stored off the blockchain (i.e., "off chain").

[0086] Preferably, a transaction (Tx) further includes one or more attributes, which allow for more detailed searching of the data / content. Attributes are also called "values," "labels," "tags," or "identifiers." They can be used to describe or annotate a piece of data, or to provide additional information about a piece of data.

[0087] Preferably, the one or more attributes include a keyword, tag, or identifier associated with: i) any part of the data provided or referenced within a transaction (Tx); and / or ii) Transaction (Tx).

[0088] 3. The method according to clause 1 or 2, wherein the data portion or a reference to the data portion, the protocol flag, at least one optional public key (DPK), and / or at least one optional transaction ID (DTxID) are provided in the output (UTXO) of the blockchain transaction (Tx), one or more of which may be provided in a locking script associated with the output (UTXO).

[0089] 4. A method according to any one of clauses 1 to 3, wherein each parent public key (PPK) in the plurality of inputs is associated with a respective logical parent transaction (LPTx), identified by a respective arbitrary transaction ID (DTxID) provided in the output (UTXO) of the transaction (Tx).

[0090] 5. The method described in Clause 4, wherein the blockchain transaction (Tx) is arranged as follows: i) At least two of the parent public keys (PPKs) of multiple inputs must sign the output (UTXO) of the transaction (Tx), or ii) All of the parent public keys (PPKs) of the multiple inputs must sign the output (UTXO) of the transaction (Tx).

[0091] 6. The method of any of clauses 1 to 5, wherein a portion of data, a reference to a portion of data, a protocol flag, at least one optional public key (DPK), and / or at least one optional transaction ID (DTxID) is provided in the blockchain transaction (Tx) at a position following a marker or code for marking the output as invalid for subsequent use as input to a subsequent transaction. This may be an opcode in a script. This may be an OP_RETURN opcode in one or more variants of the Bitcoin protocol, or a functionally similar / equivalent opcode in another blockchain protocol.

[0092] 7. The method of any of clauses 1 to 6, further comprising using the arbitrary public key (DPK) and the transaction ID (TxID) to search for and / or identify the transaction (Tx) or a logical parent transaction in the blockchain.

[0093] 8. The method of clause 7, further comprising using blockchain transactions (Tx) to represent data nodes in a hierarchy, tree, or graph of data nodes. A data node may be described as a transaction that represents a node in the tree, graph, or hierarchy and that contains or references a portion of data in a dataset.

[0094] 9. The method of any of clauses 1 to 8, wherein the protocol flag is associated with and / or indicates a blockchain-based protocol for searching, storing, and / or retrieving data in one or more blockchain transactions.

[0095] 10. The method of any one of clauses 1 to 9, comprising processing at least one further blockchain transaction (Tx2); A further transaction ID (TxID2), at least one further optional transaction ID (DTxID); Protocol flags, at least one further optional public key (DPK); One or more inputs, each of which: i) a parent public key (PPK), and ii) A signature (S), generated using the parent public key (PPK), containing and one or more inputs. In other words, multiple transactions can be provided for a hierarchical or tree-like structure, as described above.

[0096] 11. A method according to clause 10, wherein at least one transaction (Tx) and at least one further transaction (Tx2) are arranged to form a hierarchy of blockchain transactions, and such that: A portion of the data provided or referenced in at least one further transaction (Tx2) at a lower level of the hierarchy is accessed or identified by comparison with a cryptographic key used to sign at least one transaction at a higher level of the hierarchy.

[0097] 12. A blockchain-implemented network or system comprising a plurality of computational nodes, wherein each computational node in the blockchain-implemented network or system includes a processor and memory containing executable instructions that, upon execution by the processor, cause the system or network to perform the computer-implemented method of any of the preceding clauses.

[0098] 13. The network or system of clause 12, further comprising at least one wallet functionality, wherein preferably the wallet functionality is configured to store, generate, and / or process hierarchical deterministic keys. The network may be configured to operate using and / or interface with a blockchain protocol.

[0099] 14. A non-transitory computer-readable storage medium having executable instructions stored thereon that, when executed by a processor of a computer system, cause the computer system to perform the computer-implemented method of any of clauses 1 to 11.

[0100] In accordance with the present disclosure, there may be provided a method comprising providing or using a plurality of blockchain transactions in a (logical) hierarchy such that a portion of data provided or referenced in at least one further transaction in a lower level of the hierarchy can be accessed or identified by comparison with a cryptographic key used to sign a first transaction in a higher level of the hierarchy, wherein: At least one transaction in the hierarchy (the first or further transaction) comprises a transaction ID (TxID), a protocol flag, a discretionary public key (DPK), a discretionary transaction ID (DTxID), and each input is i) a parent public key (PPK), and ii) multiple inputs, including a signature (S) generated using a parent public key (PPK); Includes.

[0101] Additionally or alternatively, the method may include using a first blockchain transaction to provide or prohibit access to a portion of data provided or referenced in at least one further transaction at a lower level in a hierarchy of blockchain transactions based on a cryptographic key used to sign the first blockchain transaction. The first and / or further transactions may include a transaction ID (TxID), a protocol flag, an arbitrary public key (DPK), an arbitrary transaction ID (DTxID), and multiple inputs. Each input includes: i) a parent public key (PPK), and ii) a signature (S) generated using the parent public key (PPK).

[0102] According to another aspect of the present disclosure, a computer-implemented system for searching a blockchain and / or identifying / accessing data via a blockchain may be provided, which may be referred to as a blockchain search system.

[0103] The enumerated provisions are provided below:

[0104] A. A computer-implemented system configured to enable a user (human or computer-implemented resource) to search, access, view, write, and / or retrieve a portion of data provided in at least one blockchain transaction (Tx). The system generates a transaction index (TX) that contains the transaction ID and the public key associated with the transaction (Tx). index ) to identify at least one transaction (Tx). At least one transaction At least one arbitrary transaction ID (DTxID), and Protocol flags, At least one discretionary public key (DPK); One or more inputs, each of which: i) a parent public key (PPK), and ii) a signature (S) generated using the parent public key (PPK); one or more inputs, including Contains at least one output (UTXO), including Thus, in one or more embodiments, at least a transaction includes multiple inputs, each input having a parent public key and a signature generated using the parent public key.

[0105] B. The system described in clause A, wherein said system is provided within or configured to interface with and / or communicate with a computer-implemented (blockchain search) system.

[0106] C. A system as described in clause A or B, further including at least one wallet function.

[0107] D. The system of clause C, wherein the at least one wallet is configured to generate, store, and / or process hierarchical deterministic keys.

[0108] E. The system of clause C or D, wherein the at least one wallet functionality is configured to store at least one cryptographic key and / or at least one token in a trusted execution environment.

[0109] F. A system according to any of clauses A through E, further comprising: a decompression component configured to decompress a portion of the data if compressed; recombinant components, and / or a decryption component configured to decrypt the portion of the data if it is encrypted.

[0110] G. A system according to any of clauses A through F, further comprising: and at least one presentation component configured to present the portion of the data to a user in a viewable format.

[0111] H. A system according to any of clauses A through G, further comprising: means for inputting or generating a search path for identifying at least one transaction (Tx) on a blockchain, the search path comprising: i) Transaction Index (TXi ndex ), and ii) Contains attributes related to the transaction (Tx).

[0112] I. The system of clause H, wherein the at least one attribute is a mnemonic associated with the transaction, and / or the at least one attribute is null.

[0113] J. The system described in any of Clauses A through I, further configured to communicate with wallet functionality or other resources to facilitate the processing, storage, and / or generation of cryptographic keys, blockchain transactions, and / or digital signatures.

[0114] K. A system according to any of clauses A through J, further comprising: Transaction Index (TX index ), and preferably configured to store a respective transaction index for one or more transactions.

[0115] L. The system of any of clauses A through K, further configured to transfer control of a portion of a digital asset to a destination before accessing the portion of the data.

[0116] M. The system of any of clauses A through L, further configured to send a request to a peer on the blockchain for a portion of the data and / or receive a portion of the data from a peer on the blockchain.

[0117] N. The system of any of clauses A through M, wherein the system is further configured to use a time locking mechanism to control access to portions of the data.

[0118] Exemplary System Overview 1 illustrates an exemplary system 100 for implementing a blockchain 150. The system 100 may include a packet-switched network 101, which is typically a wide-area internetwork such as the Internet. The packet-switched network 101 includes multiple blockchain nodes 104 that may be arranged to form a peer-to-peer (P2P) network 106 within the packet-switched network 101. Although not shown, the blockchain nodes 104 may be arranged as a nearly complete graph. Thus, each blockchain node 104 is highly connected to other blockchain nodes 104.

[0119] Each blockchain node 104 includes a peer's computing device, with different ones of the nodes 104 belonging to different peers. Each blockchain node 104 includes one or more processors, e.g., one or more central processing units (CPUs), accelerator processors, application-specific processors and / or field programmable gate arrays (FPGAs), and processing units including application-specific integrated circuits (ASICs). Each node also includes memory, i.e., computer-readable storage in the form of a non-transitory computer-readable medium or media. The memory may include one or more memory units using one or more memory media, e.g., magnetic media such as a hard disk, electronic media such as a solid-state drive, flash memory, or EEPROM, and / or optical media such as an optical disk drive.

[0120] A blockchain 150 includes a chain of blocks of data 151, with a copy of each blockchain 150 maintained at each of multiple blockchain nodes 104 within a distributed or blockchain network 160. As noted above, maintaining a copy of the blockchain 150 does not necessarily mean storing the blockchain 150 in its entirety. Instead, the blockchain 150 may be pruned, so long as each blockchain node 150 stores the block header (described below) of each block 151. Each block 151 in the chain includes one or more transactions 152, where a transaction in this context refers to a type of data structure. The nature of the data structure depends on the type of transaction protocol used as part of the transaction model or scheme. A given blockchain uses one particular transaction protocol throughout. In one common type of transaction protocol, the data structure for each transaction 152 includes at least one input and at least one output. Each output specifies as a property an amount representing some quantity of digital assets, an example of which is the user 103 to whom the output is cryptographically locked (requiring that user's signature or other solution to unlock and thereby redeem or spend). Each input points back to the output of a preceding transaction 152, thereby linking the transactions.

[0121] Each block 151 also contains a block pointer 155 that points back to a previously generated block 151 in the chain to define a sequential order for the blocks 151. Each transaction 152 (other than a coinbase transaction) contains a pointer that points back to a previous transaction to define an order for the sequence of transactions (the NB sequence of transactions 152 can branch). The chain of blocks 151 goes back to a generator block (Gb) 153, which was the first block in the chain. One or more original transactions 152 earlier in the chain 150 pointed to the generator block 153, not to a previous transaction.

[0122] Each blockchain node 104 is configured to transfer transactions 152 to other blockchain nodes 104, thereby propagating the transactions 152 throughout the network 106. Each blockchain node 104 is configured to generate blocks 151 and store copies of each of the same blockchains 150 in its memory. Each blockchain node 104 also maintains an ordered set 154 of transactions 152 waiting to be incorporated into a block 151. The ordered set 154 is often referred to as a "mempool." This term, as used herein, is not intended to be limited to a particular blockchain, protocol, or model. This refers to an ordered set of transactions that a node 104 accepts as valid and that the node 104 is obligated to not accept other transactions that attempt to consume the same output.

[0123] For a given current transaction 152j, the input (or each input) contains a pointer that references the output of the preceding transaction 152i in the sequence of transactions, specifying that this output is redeemed or "spent" in the current transaction 152j. In general, a preceding transaction can be any transaction in the ordered set 154 or any block 151. A preceding transaction 152i does not necessarily have to exist when the current transaction 152j is created or even when it is sent to the network 106, but the preceding transaction 152i must exist and be verified for the current transaction to be valid. Thus, as used herein, "preceding" refers to preceding in the logical order linked by the pointer, and thus not necessarily to the time of creation or transmission in chronological order, and therefore does not necessarily preclude transactions 152i, 152j from being created or transmitted out of order (see the discussion below regarding orphan transactions). The preceding transaction 152i may also be referred to as an antecedent transaction or a predecessor transaction.

[0124] The input of the current transaction 152j also includes an input authorization, e.g., the signature of the user 103a to whom the output of the previous transaction 152i is locked. The output of the current transaction 152j can then be cryptographically locked to a new user or entity 103b. Thus, the current transaction 152j can transfer the amount defined in the input of the previous transaction 152i to the new user or entity 103b defined in the output of the current transaction 152j. In some cases, a transaction 152j can have multiple outputs to divide the input amount among multiple users or entities (one of which may be the original user or entity 103a to provide the change). In some cases, a transaction can also have multiple inputs, collecting amounts from multiple outputs of one or more previous transactions and then redistributing them against one or more outputs of the current transaction.

[0125] According to an output-based transaction protocol such as Bitcoin, when an entity 103, such as a user or a machine, wants to execute a new transaction 152j, it sends the new transaction from its computer terminal 102 to a recipient. The entity or recipient ultimately sends this transaction to one or more blockchain nodes 104 of the network 106 (today, typically a server or data center, but in principle, it could be another user terminal). The entity 103 executing the new transaction 152j can also send the transaction to one or more blockchain nodes 104, and in some cases, it is not excluded to send it to no recipient. The blockchain nodes 104 receiving the transaction check whether the transaction is valid according to a blockchain node protocol applied to each blockchain node 104. The blockchain node protocol typically requires the blockchain nodes 104 to check that the cryptographic signature in the new transaction 152j matches an expected signature, which depends on the previous transaction 152i in the ordered sequence of transactions 152. In such an output-based transaction protocol, this may involve checking that a cryptographic signature or other authorization of entity 103 included in the input of new transaction 152j matches a condition defined in the output of previous transaction 152i to which the new transaction assigns it. Here, this condition typically includes at least checking that the cryptographic signature or other authorization in the input of new transaction 152j unlocks the output of previous transaction 152i to which the input of the new transaction is linked. This condition may be defined, at least in part, by a script included in the output of the previous transaction 152i. Alternatively, it may simply be fixed in the blockchain node protocol alone, or it may be a combination of these.In any case, if the new transaction 152j is valid, the blockchain node 104 forwards it to one or more other blockchain nodes 104 in the blockchain network 106. These other blockchain nodes 104 apply the same tests according to the same blockchain node protocol and so forward the new transaction 152j to one or more further nodes 104. In this way, the new transaction is propagated throughout the entire network of blockchain nodes 104.

[0126] In an output-based model, the definition of whether a given output (e.g., UTXO) is allocated is whether it has yet been validly redeemed by the input of another, onward transaction 152j according to the blockchain node protocol. Another condition for a transaction to be valid is that the output of the preceding transaction 152i that it attempts to transfer or redeem has not already been allocated / redeemed by another transaction. If it is not valid, again, the transaction 152j is not propagated (unless flagged as invalid and propagated for warning purposes) or recorded in the blockchain 150. This prevents double-spending, whereby a transactor attempts to allocate the same transaction output multiple times. On the other hand, an account-based model prevents double-spending by maintaining account balances. Again, because there is a defined order of transactions, an account balance has a single defined state at any one time.

[0127] In addition to validating transactions, blockchain nodes 104 also compete to be the first to create a block of transactions in a process commonly called mining, which is supported by "proof-of-work." Blockchain nodes 104 add new transactions to an ordered set 154 of valid transactions that do not already appear in a block 151 recorded in the blockchain 150. Blockchain nodes then compete to assemble a new valid block 151 from the ordered set 154 of transactions 152 by attempting to solve a cryptographic puzzle. Typically, this involves searching for a "nonce" value such that when the nonce is concatenated with a representation of the ordered set of transactions 154 and hashed, the hash output satisfies a predetermined condition. For example, the predetermined condition may be that the hash output has a certain predefined number of leading zeros. Note that this is just one particular type of proof-of-work puzzle, and other types are not excluded. A property of a hash function is that it has an unpredictable output given its input, so this search can only be performed by brute force, thus consuming a significant amount of processing resources at each blockchain node 104 attempting to solve the puzzle.

[0128] A first blockchain node 104 that solves the puzzle announces this to the network 106 and provides its solution as a proof, which can then be easily checked by other blockchain nodes 104 in the network (once the solution to the hash is given, it is easy to check that it produces a satisfying hash output). The first blockchain node 104 accepts the block and therefore propagates it to threshold consensus of other nodes that enforce the protocol rules. The ordered set of transactions 154 is then recorded by each blockchain node 104 as a new block 151 in the blockchain 150. A block pointer 155 is also assigned to the new block 151n that points back to the previously generated block 151n-1 in the chain. The significant amount of effort required to create a proof-of-work solution, e.g., in the form of hashes, signals the first node 104's intention to follow the rules of the blockchain protocol. Such rules include not validating a transaction if it assigns the same output as a previously validated transaction. Once created, blocks 151 cannot be modified because they are known and maintained by each blockchain node 104 in the blockchain network 106. Block pointers 155 also impose a sequential order on blocks 151. This provides an immutable public ledger of transactions, as transactions 152 are recorded in ordered blocks at each blockchain node 104 in the network 106.

[0129] Note that different blockchain nodes 104 competing to solve the puzzle at any given time may do so based on different snapshots of the ordered set of yet-to-be-published transactions 154 at any given time, depending on when they began their search for a solution or the order in which the transactions were received. Whoever solves each puzzle first defines which transactions 152 are included in the next new block 151n and in what order, and the current set of yet-to-be-published transactions 154 is updated. The blockchain nodes 104 then continue competing to create blocks from the newly defined pending ordered set of yet-to-be-published transactions 154, and so on. There is also a protocol for resolving any "forks" that may arise, where two blockchain nodes 104 solve their puzzles within a very short time of each other, resulting in conflicting views of the blockchain being propagated between the nodes 104. In essence, whichever prong of the fork extends the longest becomes the final blockchain 150. Note that this does not affect users or agents of the network, as the same transaction appears in both forks.

[0130] According to the Bitcoin blockchain (and most other blockchains), a node that successfully constructs a new block 104 is given the ability to allocate the accepted amount of digital assets in a new special type of transaction that distributes a defined quantity of the digital assets (as opposed to a transaction between agents, or between users, that transfers an amount of digital assets from one agent or user to another). This special type of transaction is often called a “coinbase transaction,” but is also called an “initiation transaction.” It typically forms the first transaction of a new block 151n. The proof of work signals the node's intent to construct the new block in a way that allows this special transaction to be redeemed later, according to protocol rules. Blockchain protocol rules may require a maturation period of, for example, 100 blocks, before this special transaction can be redeemed. Often, a regular (non-generation) transaction 152 also specifies an additional transaction fee in one of its outputs to further reward the blockchain node 104 that created the block 151n in which the transaction was published. This fee is typically called a “mining fee” and is described below.

[0131] Due to the resources involved in validating and publishing transactions, at least each blockchain node 104 typically takes the form of a server, including one or more physical server units or entire data centers. However, in principle, any given blockchain node 104 could take the form of a single user terminal or a group of user terminals networked together.

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

[0133] The connected network 101 also includes computing devices 102 of multiple parties 103, each in the role of a consuming user. These users may interact with the blockchain network but do not participate in the validation, construction, or propagation of transactions and blocks. Some of these users or agents 103 may act as senders and receivers of transactions. Other users may interact with the blockchain 150 without necessarily acting as senders or receivers. For example, some parties may act as custodial entities that store a copy of the blockchain 150 (e.g., having obtained a copy of the blockchain from a blockchain node 104).

[0134] Some or all of the parties 103 may be connected as part of a different network, for example, a network overlaid on top of the blockchain network 106. Users of the blockchain network (often referred to as “clients”) can be said to be part of a system that includes the blockchain network, but these users are not blockchain nodes 104 because they do not perform the roles required of blockchain nodes. Instead, each party 103 can interact with the blockchain network 106 and thereby utilize the blockchain 150 by connecting (i.e., communicating) with a blockchain node 106. Two parties 103 and their respective devices 102 are shown for illustrative purposes: a first party 103a and their respective computing device 102a, and a second party 103b and their respective computing device 102b. It will be understood that many more such parties 103 and their respective computing devices 102 can exist and participate in the system 100, but are not shown for convenience. Each party 103 may be an individual or an organization. Purely by way of example, the first party 103a will be referred to herein as Alice and the second party 103b will be referred to as Bob, although it will be understood that this is not limiting and that references herein to Alice or Bob can be interchangeably referred to as "first party" and "second party," respectively.

[0135] The computing device 102 of each party 103 includes a respective processing unit comprising one or more processors, e.g., one or more CPUs, GPUs, other accelerator processors, application-specific processors, and / or FPGAs. The computing device 102 of each party 103 further includes memory, i.e., computer-readable storage in the form of a non-transitory computer-readable medium. This memory may include one or more memory units using one or more memory media, e.g., magnetic media such as hard disks, electronic media such as solid-state drives (SSDs), flash memory, or EEPROMs, and / or optical media such as optical disk drives. The memory on the computing device 102 of each party 103 stores software, including a respective instance of at least one client application 105, configured to operate on the processing unit. It will be understood herein that any operations attributed to a given party 103 may be performed using software executing on the processing unit of the respective computing device 102. The computing device 102 of each party 103 includes at least one user terminal, e.g., a desktop or laptop computer, a tablet, a smartphone, or a wearable device such as a smartwatch. The computing device 102 of a given party 103 may also include one or more other networked resources, such as cloud computing resources, that are accessed via the user terminal.

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

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

[0138] Note: While various client functions may be described as being integrated into a given client application 105, this is not necessarily limiting, and instead, any client function described herein may be implemented in a suite of two or more separate applications, one interfacing via an API, for example, or one plugging into the other. More generally, client functions may be implemented at the application layer, or at a lower layer, such as an operating system, or any combination thereof. While the following is described with respect to a client application 105, it will be understood that this is not limiting.

[0139] An instance of a client application or software 105 on each computing 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 transmit transactions 152 to the network 106. The client 105 can also contact the blockchain node 104 to query the blockchain 150 for any transactions in which the respective party 103 is a recipient (or, in embodiments, actually inspect other parties' transactions in the blockchain 150, since the blockchain 150 is a "public facility" that provides trust in transactions in part through public visibility). The wallet functionality on each computing device 102 is configured to form and transmit transactions 152 according to a transaction protocol. As described above, each blockchain node 104 executes software configured to validate transactions 152 according to the blockchain node protocol and forward transactions 152 for propagation throughout the blockchain network 106. The transaction protocol and the node protocol correspond to each other, and a given transaction protocol, together with a given node protocol, implements a given transaction model. The same transaction protocol is used for all transactions 152 in the blockchain 150. The same node protocol is used by all nodes 104 in the network 106.

[0140] When a given party 103, such as Alice, wishes to submit a new transaction 152j to be included in the blockchain 150, she formulates the new transaction (using a wallet function in her client application 105) according to the associated transaction protocol. She then sends the transaction 152 from her client application 105 to one or more connected blockchain nodes 104. For example, this may be the blockchain node 104 with the best connection to Alice's computer 102. When any given blockchain node 104 receives the new transaction 152j, the node processes it according to the blockchain node protocol and its respective role. This involves first checking whether the newly received transaction 152j meets certain conditions for being "valid," examples of which are described in more detail immediately below. In some transaction protocols, the conditions for validation can be set on a per-transaction basis by a script included in the transaction 152. Alternatively, the conditions may simply be a built-in feature of the node protocol or may be defined by a combination of the script and the node protocol.

[0141] Provided that the newly received transaction 152j passes the tests to be considered valid (i.e., is "validated"), any blockchain node 104 that receives the transaction 152j adds the new valid transaction 152 to the ordered set of transactions 154 maintained at that blockchain node 104. Additionally, any blockchain node 104 that receives the transaction 152j propagates the valid transaction 152 toward one or more other blockchain nodes 104 in the network 106. Because each blockchain node 104 applies the same protocol, assuming the transaction 152j is valid, this means that it will soon propagate throughout the network 106.

[0142] Once the ordered sets 154 of transactions maintained at a given blockchain node 104 are acknowledged, that blockchain node 104 begins a race to solve the proof-of-work puzzle for the latest versions of each ordered set 154 of transactions, including the new transaction 152. (Recall that other blockchain nodes 104 are trying to solve the puzzle based on different ordered sets 154 of transactions, but whoever gets there first defines the ordered set of transactions contained in the latest block 151. Ultimately, the blockchain node 104 solves the puzzle for the part of the ordered set 154 that includes Alice's transaction 152j.) Once proof-of-work has been done for the ordered set 154 that includes the new transaction 152j, it immutably becomes part of one of the blocks 151 in the blockchain 150. Each transaction 152 contains a pointer back to previous transactions, and the order of the transactions is also immutably recorded.

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

[0144] An alternative type of transaction protocol operated by some blockchain networks may be called an “account-based” protocol, as part of an account-based transaction model. In the account-based case, each transaction defines the amount to be transferred not by referencing back to the UTXO of a previous transaction in a sequence of past transactions, but rather by referencing an absolute account balance. The current state of every account is stored separately on the blockchain by the network's nodes and is constantly updated. In such a system, transactions are ordered using the account's running transaction tally (also called its “position”). This value is signed by the sender as part of the cryptographic signature and hashed as part of the transaction reference calculation. In addition, an optional data field may also be signed in the transaction. This data field can point back to a previous transaction, for example, if a previous transaction ID is included in the data field.

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

[0146] In a UTXO-based model, each transaction (“Tx”) 152 includes a data structure containing one or more inputs 202 and one or more outputs 203. Each output 203 may include an outstanding transaction output (UTXO), which can be used as a source of input 202 for another new transaction (if the UTXO has not already been redeemed). A UTXO contains a value specifying the total value of a digital asset, which represents the number of tokens placed on the distributed ledger. A UTXO may also include, among other information, the transaction ID of the origin of the UTXO. The transaction data structure may also include a header 201, which may include indicators of the sizes of the input fields 202 and output fields 203. The header 201 may also include the transaction ID. 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 raw transaction 152 submitted to the node 104.

[0147] Assume that Alice 103a wants to create transaction 152j to transfer the amount of the digital asset in question to Bob 103b. In FIG. 2, Alice's new transaction 152j is labeled "Tx1." It in turn takes the amount of digital asset locked for Alice in the output 203 of the preceding transaction 152i and transfers at least a portion of it to Bob. The preceding transaction 152i is labeled "Tx0" in FIG. 2; Tx0 and Tx1 are merely arbitrary labels. These do not necessarily imply that Tx0 is the first transaction in the blockchain 151 or that Tx1 is the immediately next transaction in the pool 154. Tx1 can point back to any of the preceding (i.e., prior) transactions that still have unspent outputs 203 locked for Alice.

[0148] The preceding transaction Tx0 may already be validated and included in a block 151 of the blockchain 150 when Alice creates the new transaction Tx1, or at least when she submits it to the network 106. It may already be included in one of the blocks 151 at that time, or it may still be waiting in the ordered set 154, in which case it will soon be included in the new block 151. Alternatively, if the node protocol allows for buffering of "orphans," Tx0 and Tx1 may be created and submitted to the network 106 together, or Tx0 may be submitted after Tx1. As used herein in the context of a transaction sequence, the terms "preceding" and "subsequent" refer to the order of transactions in the sequence defined by transaction pointers specified in the transactions (e.g., which transaction points to other transactions). These may also be interchangeably referred to as "predecessor" and "successor," or "antecedent" and "descendant," "parent" and "child," etc. This does not necessarily imply the order in which they are generated, transmitted to the network 106, or arrive at any given blockchain node 104. Nevertheless, a subsequent transaction (a descendant transaction or "child") that points to a preceding transaction (a prior transaction or "parent") is not validated until and unless the parent transaction is validated. A child that arrives at a blockchain node 104 before reaching its parent node 104 is considered an orphan. Depending on the node protocol and / or node behavior, it may be discarded or buffered for a period of time to wait for its parent.

[0149] One of the one or more outputs 203 of the preceding transaction Tx0 includes a particular UTXO, here labeled UTXO0. Each UTXO includes a value specifying the total value of the digital asset represented by the UTXO and a locking script that defines the conditions that must be met by the unlocking script in the input 202 of the subsequent transaction for the subsequent transaction to be validated, and therefore for the UTXO to be successfully redeemed. Typically, the locking script locks the total value to a particular party (the beneficiary of the transaction in which it is included). That is, the locking script defines the unlocking conditions, and typically includes a condition that the unlocking script in the input of the subsequent transaction include the cryptographic signature of the party to whom the preceding transaction is locked.

[0150] A locking script (aka scriptPubKey) is a piece of code written in a domain-specific language recognized by the node protocol. A specific example of such a language is called "Script" (with a capital S) used by blockchain networks. A locking script specifies the information needed to consume the transaction output 203, for example, the requirements for Alice's signature. The transaction output displays the unlocking script. An unlocking script (aka scriptSig) is a piece of code written in a domain-specific language that provides the information needed to satisfy the criteria of the locking script. For example, it may include Bob's signature. The unlocking script appears in the transaction input 202.

[0151] In the example shown, UTXO0 of output 203 of Tx0 is sent to the locking script [Checksig P A ], which means that Alice's signature Sig P must be present in order for UTXO0 to be redeemed (or more precisely, for any subsequent transaction that attempts to redeem UTXO0 to be valid). A[Checksig P A ] is Alice's public key P from her public-private key pair. A , a representation (i.e., a hash) of Tx1's input 202. Tx1's input 202 includes a pointer back to Tx1 (e.g., by its transaction ID, TxID0, which in an embodiment is a hash of the entire transaction Tx0). Tx1's input 202 includes an index that identifies UTXO0 within Tx0, to distinguish it among any other possible outputs of Tx0. Tx1's input 202 further includes an unlocking script that contains Alice's cryptographic signature, created by applying Alice's private key from her key pair to a predetermined portion of the data. <Sig P A (sometimes called a "message" in cryptography). The data (or "message") that needs to be signed by Alice to provide a valid signature can be defined by a locking script, a node protocol, or a combination of these.

[0152] When new transaction Tx1 arrives at blockchain node 104, the node applies the node protocol, which involves running the locking script and the unlocking script together to check whether the unlocking script meets the conditions defined in the locking script (where the conditions may include one or more criteria). In an embodiment, this involves concatenating the two scripts. <Sig P A > <P A >||[Checksig P A ] where "||" denotes concatenation, "<...>" means to put data on the stack, and "[...]" is a function that is composed of the locking script (a stack-based language in this example). Similarly, the scripts can be executed one after the other using a common stack rather than concatenating them. In either case, when executed together, the scripts use Alice's public key PA, as included in the locking script at the output of Tx0, to authenticate that the unlocking script at the input of Tx1 contains Alice's signature signing the expected portion of the data. To perform this authentication, the expected portion of the data itself (the "message") must also be included. In an embodiment, the signed data includes the entirety of Tx1 (thus, a separate element specifying the signed portion of the data in the clear need not be included, as it is already inherently present).

[0153] The details of authentication via public key-cryptographic key cryptography will be well known to those skilled in the art. Essentially, if Alice signs a message using her private key, then, given Alice's public key and the message in the clear, another entity, such as node 104, can authenticate that the message must have been signed by Alice. Signing typically involves hashing the message, signing the hash, and tagging the message as the signature, thus allowing any holder of the public key to authenticate the signature. Thus, note that references herein to signing a particular piece of data or part of a transaction, etc., can, in embodiments, mean signing a hash of that piece of data or part of a transaction.

[0154] If the unlocking script in Tx1 meets one or more conditions specified in the locking script of Tx0 (in the example, Alice's signature is provided and authenticated in Tx1), the blockchain node 104 considers Tx1 valid. This means that the blockchain node 104 adds Tx1 to the ordered set of transactions 154. The blockchain node 104 also forwards transaction Tx1 to one or more other blockchain nodes 104 in the network 106, so that it propagates throughout the network 106. Once Tx1 is validated and included in the blockchain 150, this defines the UTXO0 from Tx0 as spent. Note that Tx1 is only valid if it uses unspent transaction outputs 203. If it attempts to consume outputs that have already been consumed by another transaction 152, Tx1 becomes invalid, even if all other conditions are met. Therefore, blockchain node 104 also needs to check whether the UTXO referenced in the preceding transaction Tx0 has already been spent (i.e., whether it already forms a valid input to another valid transaction). This is one reason why it is important for blockchain 150 to impose a defined order on transactions 152. Indeed, a given blockchain node 104 may maintain a separate database mark for UTXOs 203 that transactions 152 have spent, but ultimately, what defines whether a UTXO is spent is whether it already forms a valid input to another valid transaction in blockchain 150.

[0155] If all total amounts specified in all outputs 203 of a given transaction 152 are greater than all total amounts pointed to by all its inputs 202, this is another basis for invalidity in most transaction models. Therefore, such a transaction is not propagated and is not included in block 151.

[0156] Note that in the UTXO-based transaction model, a given UTXO must be spent in its entirety. It is not possible to "leave behind" part of the total amount defined in a UTXO as spent while another part is spent. However, the total amount from a UTXO can be divided among multiple outputs of subsequent transactions. For example, the total amount defined in UTXO0 in Tx0 can be divided among multiple UTXOs in Tx1. Thus, if Alice does not want to give Bob the entire total amount defined in UTXO0, she can use the remaining amount to give herself change in the second output of Tx1 or to pay another party.

[0157] In practice, Alice will usually also need to include a fee for the Bitcoin node that publishes her transaction 104. If Alice does not include such a fee, Tx0 may be rejected by the blockchain node 104 and, therefore, while technically valid, will not be propagated and included in the blockchain 150 (the node protocol does not force blockchain nodes 104 to accept a transaction 152 if they do not want to). In some protocols, the transaction fee does not require its own separate output 203 (i.e., it does not require a separate UTXO). Instead, the difference between the total amount indicated by the inputs 202 and the total amount specified in the outputs 203 of a given transaction 152 is automatically given to the blockchain node 104 that issues the transaction. For example, assume that a pointer to UTXO0 is the only input to Tx1, and that Tx1 has only one output, UTXO1. If the total amount of digital assets specified in UTXO0 is greater than the amount specified in UTXO1, the difference may be allocated by the node 104 that issues the block containing UTXO1. However, it is not necessarily excluded that a transaction fee may alternatively or additionally be explicitly specified in the UTXO 203 of transaction 152 itself.

[0158] Alice and Bob's digital assets consist of UTXOs locked in any transaction 152 anywhere in the blockchain 150. Thus, typically, a given party 103's assets are dispersed throughout the UTXOs of various transactions 152 throughout the blockchain 150. No single number is stored anywhere in the blockchain 150 that defines a given party's 103 total balance. It is the role of the wallet function in the client application 105 to compile together the value of all the various UTXOs locked for each party that have not yet been spent in another, prior transaction. This can be done by querying the copy of the blockchain 150 as stored on any Bitcoin node 104.

[0159] Note that script code is often expressed generally (i.e., without using a precise language). For example, operation codes (opcodes) can be used to represent specific functions. "OP_..." refers to a specific opcode in a scripting language. As an example, OP_RETURN is an opcode in a scripting language that, when preceded by OP_FALSE at the beginning of a locking script, generates an unspendable output of the transaction, which can store data within the transaction and thereby immutably record the data on the blockchain 150. For example, the data can include a document that is desired to be stored on the blockchain.

[0160] Typically, the input to a transaction is a public key P AIn an embodiment, this is based on ECDSA using the elliptic curve secp256k1. The digital signature signs a specific piece of data. In some embodiments, for a given transaction, the signature signs some of the transaction inputs and some or all of the transaction outputs. The specific portion of the outputs to sign depends on the SIGHASH flag, which is a four-byte code usually included at the end of the signature that selects which outputs are signed (and therefore fixed at the time of signing).

[0161] A locking script is sometimes referred to as a "scriptPubKey," referring to the fact that each transaction typically includes the public key of the party being locked. An unlocking script is sometimes referred to as a "scriptSig," referring to the fact that it typically provides a corresponding signature. However, more generally, in all applications of blockchain 150, it is not required that the condition for redeeming a UTXO include verifying a signature. 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.

[0162] As shown in FIG. 1, the client applications on Alice's and Bob's computing devices 102a, 102b, respectively, can include additional communication capabilities. This additional functionality allows Alice 103a to establish a separate side channel 301 with Bob 103b (at the invitation of either party or a third party). The side channel 301 allows for the exchange of data separately from the blockchain network. Such communication is sometimes referred to as “off-chain” communication. For example, it can be used to exchange transactions 152 between Alice and Bob without the transaction being registered on the blockchain network 106 or progressing up the chain 150 until one of the parties chooses to broadcast it to the network 106. Sharing transactions in this manner is sometimes referred to as sharing a “transaction template.” A transaction template may lack one or more inputs and / or outputs necessary to form a complete transaction. Alternatively or additionally, the side channel 301 can be used to exchange other transaction-related data, such as keys, negotiated amounts or terms, data content, etc.

[0163] The side channel 301 may be established over the same packet-switched network 101 as the blockchain network 106. Alternatively or additionally, the side channel 301 may be established over a different network, such as a mobile cellular network, or a local area network, such as a local wireless network, or over a direct wired or wireless link between Alice's and Bob's devices 102a, 102b. Generally, the side channel 301 referred to anywhere herein may include any one or more links over one or more network technologies or communication media for exchanging data “off-chain,” i.e., separate from the blockchain network 106. When more than one link is used, the bundle or collection of off-chain links as a whole may be referred to as the side channel 301. Thus, when Alice and Bob are said to exchange particular information or data, or the like, over the side channel 301, note that this does not necessarily mean that all of this data must be transmitted over the exact same link or the same type of network.

[0164] Client Software 3A illustrates an exemplary implementation of a client application 105 for implementing embodiments of the presently disclosed scheme. The client application 105 includes a transaction engine 401 and a user interface layer 402. The transaction engine 401 is configured to implement the underlying transaction-related functionality of the client 105, such as forming transactions 152, receiving and / or sending other data via transaction and / or side channels 301, and / or sending transactions to one or more nodes 104 that propagate through the blockchain network 106. In accordance with embodiments disclosed herein, the transaction engine 401 of each client 105 includes functionality 403.

[0165] The UI layer 402 is configured to render a user interface via the user input / output (I / O) means of the device 102, including outputting information to each user 103 via the user output means of the user's computing device 102 and receiving input from each user 103 via the user input means of the device 102. For example, the user output means may include one or more display screens (touchscreen or non-touchscreen) for providing visual output, one or more speakers for providing audio output, and / or one or more tactile output devices for providing tactile output, etc. The user input means may include, for example, one or more touchscreens (the same or different from those used for the output means), one or more cursor-based devices such as a mouse, trackpad, or trackball, one or more microphones and voice recognition algorithms for receiving speech or voice input, one or more gesture-based input devices for receiving input in the form of manual or physical gestures, or an input array such as one or more mechanical buttons, switches, or joysticks.

[0166] Note: While various functionalities herein may be described as being integrated into the same client application 105, this is not necessarily limiting and may instead be implemented with two or more separate applications, e.g., one plugging into the other or interfacing via an API (application programming interface). For example, the functionality of the transaction engine 401 may be implemented in a separate application from the UI layer 402, or the functionality of a given module, such as the transaction engine 401, may be split among multiple applications. It is also not excluded that some or all of the described functionality may be implemented, for example, in the operating system layer. When reference is made anywhere herein to a single or given application 10, 5, etc., it will be understood that this is by way of example only, and more generally, the described functionality may be implemented in any form of software.

[0167] 3B shows an example mockup of a user interface 500 that may be rendered by the UI layer 402 of the client application 105a on Alice's device 102a. It will be appreciated that a similar UI may be rendered by the client 105b on Bob's device 102b, or by any other party.

[0168] 3B illustrates UI 500 from Alice's perspective. UI 500 may include one or more UI elements 501, 502, 502 that are rendered as separate UI elements via user output means.

[0169] For example, the UI elements may include one or more user-selectable elements 501, which may be different on-screen buttons, different options in a menu, etc. User input means are configured to allow user 103 (in this case, Alice 103a) to select or otherwise manipulate one of the options, such as by clicking or touching an on-screen UI element or by speaking the name of the desired option (note, the term "manual" is meant in contrast to automatic only and is not necessarily limited to the use of a hand or hands). etc., to select or otherwise manipulate one of the options. This option allows the user (Alice) to...

[0170] Alternatively or additionally, the UI element may include one or more data entry fields 502 through which a user can... These data entry fields are rendered via a user output means, e.g., on-screen, and data may be entered into the fields via a user input means, e.g., a keyboard or touch screen. Alternatively, data may be received orally, e.g., based on voice recognition.

[0171] Alternatively or additionally, the UI elements may include one or more information elements 503 that are output to output information to the user, for example, this / these may be rendered on a screen or audibly.

[0172] It will be understood that the particular means of rendering the various UI elements, selecting options, and inputting data are not essential. The functionality of these UI elements will be described in more detail shortly. It will also be understood that the UI 500 shown in FIG. 3 is merely a schematic mockup and may, in practice, include one or more additional UI elements that are not shown for the sake of brevity.

[0173] Node Software FIG. 4 illustrates an example of node software 450 running on each blockchain node 104 of the network 106 in an example UTXO-based or output-based model. Note that other entities can run node software 450 without being classified as a node 104 on the network 106, i.e., without performing the actions required of a node 104. The node software 450 may include, but is not limited to, a protocol engine 451, a scripting engine 452, a stack 453, an application-level decision engine 454, and a set of one or more blockchain-related function modules 455. Each node 104 can run node software including, but not limited to, all three of a consensus module 455C (e.g., proof-of-work), a propagation module 455P, and a storage module 455S (e.g., a database). The protocol engine 451 is typically configured to recognize different fields of a transaction 152 and process them according to the node protocol. Transaction 152j (Tx j ) is transferred to another, preceding transaction 152i (Tx i ) with inputs pointing to the output (e.g., UTXO), protocol engine 451 j and passes it to the script engine 452. The protocol engine 451 also jBased on the pointer at the input of Tx i Identify and search for Tx i is published in the blockchain 150, in which case the protocol engine can derive Tx from a copy of block 151 of the blockchain 150 stored on the node 104. i Alternatively, Tx i may not yet be published in the blockchain 150. In that case, the protocol engine 451 may select Tx from the ordered set of unpublished transactions 154 maintained by the node 104. i In any case, the script engine 451 searches for Tx i The script engine 452 then identifies the locking script in the referenced output of the script engine 452 and passes it to the script engine 452.

[0174] Therefore, the script engine 452 executes the Tx i Locking script and Tx j , and the corresponding inputs of the transaction 453. For example, transactions labeled Tx0 and Tx1 are illustrated in FIG. 2, but this could be the case for any pair of transactions. The script engine 452 executes the two scripts together, as described above, including placing data onto the stack 453 and popping data from the stack 453 according to the stack-based scripting language (e.g., script) used.

[0175] By executing the scripts together, script engine 452 determines whether the unlocking script meets one or more criteria defined in the locking script - i.e., whether the unlocking script "unlocks" the included output. Script engine 452 returns the result of this determination to protocol engine 451. If script engine 452 determines that the unlocking script meets one or more criteria specified in the corresponding locking script, it returns the result "true." Otherwise, it returns the result "false."

[0176] In an output-based model, a "true" result from the script engine 452 is one of the conditions for the validity of a transaction. Typically, there are also one or more additional protocol-level conditions evaluated by the protocol engine 451 that must also be satisfied. For example, Tx j the total amount of digital assets specified in the output of Tx does not exceed the total amount indicated by its input; and j The protocol engine 451 evaluates the results from the script engine 452 together with one or more protocol-level conditions, and executes transaction Tx only if they are all true. j The protocol engine 451 outputs an indication to the application level decision engine 454 whether the transaction is valid or not. j Only on the condition that Tx is actually verified, the decision engine 454 can control both the consensus module 455C and the propagation module 455P, and Tx j , which selects to perform respective blockchain-related functions on the Tx jand a consensus module 455C that adds Tx j Optionally, in embodiments, the application-level decision engine 454 may apply one or more additional conditions before triggering either or both of these functions. For example, the decision engine may choose to publish a transaction only if the transaction is valid and sufficient transaction fees remain.

[0177] It should also be noted that the terms "true" and "false" herein are not necessarily limited to returning a result expressed solely in the form of a single binary digit (bit), although this is certainly one possible implementation. More generally, "true" refers to any state that indicates a success or positive outcome, and "false" refers to any state that indicates a failure or negative outcome. For example, in an account-based model, a "true" outcome may be indicated by a combination of an implicit protocol-level validation of a signature and an additional positive output of a smart contract (if both outcomes are true, the overall result is considered true).

[0178] Other variations or use cases of the disclosed technology may become apparent to those skilled in the art once disclosed herein. The scope of the present disclosure is not limited by the described embodiments, but only by the appended claims.

[0179] For example, some embodiments above are described with respect to the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin nodes 104. However, it will be understood that the Bitcoin blockchain is a particular example of the blockchain 150, and the above description may apply generally 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 nodes 104 can be replaced with references to the blockchain network 106, the blockchain 150, and the blockchain nodes 104, respectively. The blockchains, blockchain networks, and / or blockchain nodes may share some or all of the described characteristics of the Bitcoin blockchain 150, the Bitcoin network 106, and the Bitcoin nodes 104, as described above.

[0180] In a preferred embodiment of the present invention, the blockchain network 106 is the Bitcoin network, and the Bitcoin nodes 104 perform at least all of the described functions of generating, publishing, propagating, and storing blocks 151 of the blockchain 150. It is not excluded that there may be other network entities (or network elements) that perform only one or some, but not all, of these functions. That is, a network entity may perform the function of propagating and / or storing blocks without generating and publishing them (recall that these entities are not considered to be nodes of the preferred Bitcoin network 106).

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

[0182] 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 network entities / elements may be implemented in hardware in the same manner as described above with reference to blockchain node 104.

Claims

1. 1. A computer-implemented method for storing, retrieving, and accessing data in a logical hierarchy of blockchain transactions, the method comprising: providing a blockchain transaction (Tx); The blockchain transaction is Transaction ID (TxID), At least one discretionary public key (DPK); at least one arbitrary transaction ID (DTxID) comprising a combination of the at least one arbitrary public key (DPK) and the transaction ID (TxID); Protocol flags, A piece of data or a reference to a piece of data, A plurality of inputs, each of which is i) a respective parent public key (PPK) associated with each logical parent transaction (LPTx) identified by a respective arbitrary transaction ID (DTxID) provided in the output (UTXO) of said blockchain transaction (Tx); and ii) a signature (S) generated using each of said parent public keys (PPKs); multiple inputs, including wherein the method comprises: using the at least one arbitrary transaction ID (DTxID) to search for and / or identify the blockchain transaction (Tx) or one of the respective logical parent transactions (LPTx) in a blockchain; method.

2. the portion of data or a reference to the portion of data, the protocol flag, the at least one optional public key (DPK), and / or the at least one optional transaction ID (DTxID) are in an output (UTXO) of the blockchain transaction (Tx) and are provided in a locking script associated with the output (UTXO); The method of claim 1.

3. The blockchain transaction (Tx) is i) at least two of the respective parent public keys of the plurality of inputs must sign the output (UTXO) of the blockchain transaction (Tx); or ii) all of the respective parent public keys of the plurality of inputs are required to sign the output (UTXO) of the blockchain transaction (Tx); The method of claim 2 , wherein the method is configured as follows:

4. the portion of data, the reference to the portion of data, the protocol flags, the at least one optional public key (DPK), and / or the at least one optional transaction ID (DTxID) are provided in the blockchain transaction (Tx) at a location following a marker or code for marking the output as invalid for subsequent use as input to a subsequent transaction; The method of claim 2.

5. The method further comprises: generating the at least one arbitrary transaction ID (DTxID) based on the transaction ID (TxID) and the at least one arbitrary public key (DPK); 5. The method of claim 1, comprising:

6. The method further comprises: using the blockchain transaction (Tx) to represent a data node in a hierarchy, tree, or graph of data nodes; 6. The method of claim 1, comprising:

7. the protocol flag is associated with and / or indicates a blockchain-based protocol for searching, storing, and / or retrieving data in one or more blockchain transactions; 7. The method according to any one of claims 1 to 6.

8. The method comprises: processing at least one further blockchain transaction (Tx2); The blockchain transaction is A further transaction ID (TxID2), at least one further optional transaction ID; Protocol flags, at least one further optional public key; and A plurality of inputs, each of which is i) their respective parent public keys (PPKs), and ii) a signature generated using each of said parent public keys (PPKs); multiple inputs, including Including, 8. The method according to any one of claims 1 to 7.

9. The blockchain transaction (Tx) and the at least one further blockchain transaction (Tx2) are configured to form a hierarchy of blockchain transactions, and as a result, a portion of data provided or referenced in the at least one further blockchain transaction (Tx2) at a lower level of the hierarchy is accessed or identified by comparison with a cryptographic key used to sign the blockchain transaction (Tx) at a higher level of the hierarchy; The method of claim 8.

10. 1. A computer-implemented method for storing, retrieving, and accessing data in a logical hierarchy of blockchain transactions, the method comprising: The step of providing or using multiple blockchain transactions in a hierarchy, resulting in a portion of data provided or referenced in at least one further transaction at a lower level of the hierarchy is accessed or identified by comparison with a cryptographic key used to sign a first transaction at a higher level of the hierarchy; Steps, including: The first transaction and / or the at least one further transaction may include: Transaction ID (TxID), Protocol flags, a discretionary public key (DPK), and an arbitrary transaction ID (DTxID) comprising a combination of the transaction ID (TxID) and the arbitrary public key (DPK); A plurality of inputs, each of which is i) their respective parent public keys (PPKs), and ii) a signature (S) generated using each of said parent public keys (PPKs); multiple inputs, including A method comprising:

11. 1. A computer-implemented method for storing, retrieving, and accessing data in a logical hierarchy of blockchain transactions, the method comprising: using the first blockchain transaction; granting or denying access to a portion of data provided or referenced in at least one further transaction at a lower level within the hierarchy of blockchain transactions based on the cryptographic key used to sign the first blockchain transaction; Steps, including: The first blockchain transaction and / or the further blockchain transaction: Transaction ID (TxID), Protocol flags, a discretionary public key (DPK), and an arbitrary transaction ID (DTxID) comprising a combination of the transaction ID (TxID) and the arbitrary public key (DPK); A plurality of inputs, each of which is i) a respective parent public key (PPK) associated with each logical parent transaction (LPTx), identified by a respective arbitrary transaction ID (DTxID) provided in the output (UTXO) of the blockchain transaction (Tx); and ii) a signature (S) generated using each of said parent public keys (PPKs); multiple inputs, including A method comprising:

12. 1. A computer-implemented system configured to enable a user to search, access, view, write, and / or retrieve a portion of data provided in at least one blockchain transaction (Tx); The computer-implemented system is configured to identify the at least one blockchain transaction (Tx) based on an arbitrary transaction ID (DTxID) that includes a combination of a transaction ID and a public key associated with the at least one blockchain transaction (Tx); The at least one blockchain transaction (Tx) The arbitrary transaction ID (DTxID); Protocol flags, a discretionary public key (DPK), and A plurality of inputs, each of which is i) their respective parent public keys (PPKs), and ii) a signature (S) generated using each of said parent public keys (PPKs); a plurality of inputs, including Contains at least one output (UTXO), Computer implemented systems.

13. A blockchain-implemented network or system comprising a plurality of computing nodes, Each computing node in the blockchain-implemented network or system: a processor; a memory containing executable instructions that, upon execution by the processor, cause the network or system to perform the method of any one of claims 1 to 11; A network or system, including

14. further comprising at least one wallet; the wallet is configured to store, generate, and / or process hierarchical deterministic keys; 14. A network or system according to claim 13.

15. A non-transitory computer readable storage medium having executable instructions stored thereon which, when executed by a processor of a computer system, cause the computer system to perform the method of any one of claims 1 to 11.

Images