Federated mining for blockchains

Abstract

Example embodiments may include: determining a plurality of miners of a backward- immutable distributed storage system, wherein each of the miners has recently written blocks of the backward-immutable distributed storage system with success, wherein recently writing with success includes one or more of: writing the blocks within a period of j seconds from a current time, or writing one or more of k most-recently written blocks; determining weights associated with the miners, each of the weights based on a number of the blocks written; causing the plurality of miners to each perform a task, wherein performance of the task produces a respective result for each of the miners; determining that a set of the miners each produced a common result; determining that a sum of the weights associated with miners that produced the common result exceeds a threshold value; and modifying the backward- immutable distributed storage system based on the common result.

Description

MBHB Docket No. 24-0791-WO Federated Mining for Blockchains CROSS-REFERENCE TO RELATED APPLICATION

[0001] This application claims priority to U.S. provisional patent application no. 63 / 673,443, filed July 19, 2024, which is hereby incorporated by reference in its entirety. BACKGROUND

[0002] A distributed, decentralized network is a network of entities, usually referred to as “nodes,” each of which stores or records a current state of the entire network, among other possible information. The state of the entire network may be made up of individual states, each associated with an entity that “owns” the individual state. The owning entity of a state is usually referred to as the “owner.” Among the characteristics and properties of a distributed, decentralized network is a principle that each node is bound by, or agrees to, a set of rules and / or protocols governing how and under what circumstances individual states may change. For example, proposed changes may need to be agreed upon by a majority of the nodes, and some form of proof or work or proof of stake may need to be carried out on any collection of one or more proposed state changes. Another rule may require that only the owner of a state can invoke or initiate a proposed change to that state. SUMMARY

[0003] A blockchain network is an example of a distributed, decentralized network. Specifically, a blockchain network may include a sequence of data structures, or “blocks,” each respective one of which records the entire history of the network states up through the time at which the respective block was added to the sequence. The sequence of blocks form a linked chain, and each block is encoded in such a way that it is practically, if not actually, impossible to modify once entered in the chain. New blocks can be added recording an updated state (temporal snapshot), but existing blocks cannot be changed. That is, the blockchain is backwardly immutable.

[0004] The backward immutability of blockchains, together with their distributed, decentralized nature of blockchains, can pose impediments to rectifying errant or otherwise defective network states recorded in blocks. The inventors have recognized that there is a need for a capability to remedy problematic network-state recordings in distributed, decentralized networks, but to be able to do so without tampering with the distributed, decentralized nature.MBHB Docket No. 24-0791-WO Thus, the inventors have devised techniques, methods, and systems for achieving these desirable goals.

[0005] One or more computer programs can be configured to perform particular operations or actions by virtue of including instructions that, when executed by a data processing apparatus, cause the apparatus to perform the actions in the form of computer- implemented methods.

[0006] Accordingly, a first example embodiment may involve receiving, by a computing device, verifications that a plurality of miners of a backward-immutable distributed storage system have respectively obtained a unit of data from an entity that is not part of the backward-immutable distributed storage system. The method also includes making, by the computing device, a first determination that a count related to the plurality of miners exceeds a predetermined threshold. The method also includes making, by the computing device, a second determination that each of the plurality of miners has recently mined a block of the backward-immutable distributed storage system with success, where previously mining the block includes one or more of: previously mining the block within j seconds from a current time, or previously mining one of k most-recently mined blocks. The method also includes based on the first determination and the second determination, submitting, by the computing device, an entry for block processing to be added to the backward-immutable distributed storage system.

[0007] A second example embodiment may involve receiving, by a computing device, verifications that a plurality of miners of a backward-immutable distributed storage system have respectively obtained a unit of data from an entity that is not part of the backward- immutable distributed storage system. The method also includes making, by the computing device, a first determination that a count related to the plurality of miners does not exceeds a predetermined threshold. The method also includes making, by the computing device, a second determination that each of the plurality of miners has recently mined a block of the backward- immutable distributed storage system with success, where previously mining the block includes one or more of: previously mining the block within j seconds from a current time, or previously mining one of k most-recently mined blocks. The method also includes waiting, by the computing device, until a further plurality of miners of the backward-immutable distributed storage system have respectively obtained the respectively obtained a unit of data, where a sum of the count and a further count related to the further plurality of miners exceeds the predetermined threshold. The method also includes based on the sum of the count and theMBHB Docket No. 24-0791-WO further count exceeding the predetermined threshold, submitting, by the computing device, an entry for block processing to be added to the backward-immutable distributed storage system.

[0008] A third example embodiment may involve receiving, by a computing device, verifications that a plurality of miners of a first backward-immutable distributed storage system have respectively obtained a unit of data from an entity that is not part of the first backward- immutable distributed storage system. The method also includes making, by the computing device, a first determination that a count related to the plurality of miners exceeds a predetermined threshold. The method also includes making, by the computing device, a second determination that each of the plurality of miners has recently mined a block of the first backward-immutable distributed storage system with success, where previously mining the block includes one or more of: previously mining the block within j seconds from a current time, or previously mining one of k most-recently mined blocks. The method also includes based on the first determination and the second determination, submitting, by the computing device, an entry for block processing to be added to a second backward-immutable distributed storage system.

[0009] A fourth example embodiment may involve receiving, by a computing device, verifications that a plurality of miners of a first backward-immutable distributed storage system have respectively obtained a unit of data from an entity that is not part of the first backward- immutable distributed storage system. The method also includes making, by the computing device, a first determination that a count related to the plurality of miners does not exceeds a predetermined threshold. The method also includes making, by the computing device, a second determination that each of the plurality of miners has recently mined a block of the first backward-immutable distributed storage system with success, where previously mining the block includes one or more of: previously mining the block within j seconds from a current time, or previously mining one of k most-recently mined blocks. The method also includes waiting, by the computing device, until a further plurality of miners of the first backward- immutable distributed storage system have respectively obtained the respectively obtained a unit of data, where a sum of the count and a further count related to the further plurality of miners exceeds the predetermined threshold. The method also includes based on the sum of the count and the further count exceeding the predetermined threshold, submitting, by the computing device, an entry for block processing to be added to a second backward-immutable distributed storage system.

[0010] A fifth example embodiment may involve locking, in a first cryptographically- immutable distributed storage system, a unit of data representing state of the firstMBHB Docket No. 24-0791-WO cryptographically-immutable distributed storage system. The method also includes communicating, between a first set of one or more computing devices associated with the first cryptographically-immutable distributed storage system and a second set of one or more computing devices associated with a second cryptographically-immutable distributed storage system, that the state is locked. The method also includes generating, by the second set of one or more computing devices, a placeholder for the state in the second cryptographically- immutable distributed storage system. The method also includes obtaining, by the second set of one or more computing devices, the state from the second cryptographically-immutable distributed storage system.

[0011] A sixth example embodiment may involve: determining a plurality of miners of a backward-immutable distributed storage system, wherein each of the miners has recently written one or more respective blocks of the backward-immutable distributed storage system with success, wherein recently writing the respective blocks with success includes one or more of: previously writing the respective blocks within a period of j seconds from a current time, or previously writing one or more of k most-recently written blocks; determining weights respectively associated with the miners, wherein each of the weights is based on a number of the respective blocks written by the respective miner during the period of j seconds or the k most-recently written blocks; causing the plurality of miners to each perform a task, wherein performance of the task produces a respective result for each of the miners; determining that a set of the miners each produced a common result; determining that a sum of the weights respectively associated with miners that produced the common result exceeds a threshold value; and modifying the backward-immutable distributed storage system based on the common result.

[0012] In a seventh example embodiment, a computing system may include at least one processor, as well as memory and program instructions. The program instructions may be stored in the memory, and upon execution by the at least one processor, cause the computing system to perform operations in accordance with any one or more of the previous example embodiments.

[0013] In an eighth example embodiment, an article of manufacture may include a non- transitory computer-readable medium, having stored thereon program instructions that, upon execution by a computing system, cause the computing system to perform operations in accordance with any one or more of the previous example embodiments.

[0014] In a ninth example embodiment, a system may include various means for carrying out each of the operations of any one or more of the previous example embodiments.MBHB Docket No. 24-0791-WO

[0015] These, as well as other embodiments, aspects, advantages, and alternatives, will become apparent to those of ordinary skill in the art by reading the following detailed description, with reference where appropriate to the accompanying drawings. Further, this summary and other descriptions and figures provided herein are intended to illustrate embodiments by way of example only and, as such, that numerous variations are possible. For instance, structural elements and process steps can be rearranged, combined, distributed, eliminated, or otherwise changed, while remaining within the scope of the embodiments as claimed.MBHB Docket No. 24-0791-WO BRIEF DESCRIPTION OF THE DRAWINGS

[0016] Figure 1 illustrates a schematic drawing of a computing device, in accordance with example embodiments.

[0017] Figure 2 illustrates a schematic drawing of a server device cluster, in accordance with example embodiments.

[0018] Figure 3 illustrates a simplified block diagram of an example system in which various operations of a system-level implementation may be carried out, in accordance with example embodiments.

[0019] Figures 4A and 4B illustrate a two representations of example processing by a system-level implementation of an action-entry request, in accordance with example embodiments.

[0020] Figure 5 illustrates an example message flow diagram associated with various aspects of a system-level operations, in accordance with example embodiments.

[0021] Figure 6 illustrates a simplified block diagram of another example system in which various operations of an entry-level implementation may be carried out, in accordance with example embodiments.

[0022] Figure 7A and 7B illustrate representations of example processing by an entry- level implementation of action-request verification, in accordance with example embodiments.

[0023] Figure 8 illustrates an example message flow diagram associated with various aspects of an entry-level operations, in accordance with example embodiments.

[0024] Figure 9 illustrates a flow chart, in accordance with example embodiments.

[0025] Figure 10 illustrates a flow chart, in accordance with example embodiments.

[0026] Figure 11 illustrates a flow chart, in accordance with example embodiments.MBHB Docket No. 24-0791-WO DETAILED DESCRIPTION

[0027] Example methods, devices, and systems are described herein. It should be understood that the words “example” and “exemplary” are used herein to mean “serving as an example, instance, or illustration.” Any embodiment or feature described herein as being an “example” or “exemplary” is not necessarily to be construed as preferred or advantageous over other embodiments or features unless stated as such. Thus, other embodiments can be utilized and other changes can be made without departing from the scope of the subject matter presented herein.

[0028] Accordingly, the example embodiments described herein are not meant to be limiting. It will be readily understood that the aspects of the present disclosure, as generally described herein, and illustrated in the figures, can be arranged, substituted, combined, separated, and designed in a wide variety of different configurations. For example, the separation of features into “client” and “server” components may occur in a number of ways.

[0029] Further, unless context suggests otherwise, the features illustrated in each of the figures may be used in combination with one another. Thus, the figures should be generally viewed as component aspects of one or more overall embodiments, with the understanding that not all illustrated features are necessary for each embodiment.

[0030] Additionally, any enumeration of elements, blocks, or steps in this specification or the claims is for purposes of clarity. Thus, such enumeration should not be interpreted to require or imply that these elements, blocks, or steps adhere to a particular arrangement or are carried out in a particular order. I. Introduction

[0031] Blockchain-based technology underlies and facilitates a new form of decentralized computing that has been used to provide cryptocurrencies, smart contracts, non- fungible tokens (NFTs), identity protection, and secure voting, among many other applications. There is speculation, at least from some sources, that a new version of the world-wide web (“web 3.0”) can be built atop one or more blockchains. Regardless, it appears indisputable that blockchain-based technology has had an impact on computer networks and other aspects of society even though it has only existed in a practical form for a little over a decade.

[0032] Herein, “blockchain-based” technology refers to any variation of blockchain technology or any technology that employs or relies upon blockchain mechanisms. This includes current and future variations of blockchain technology.

[0033] In short, a blockchain is a list of entries stored as a distributed database that can grow over time based on consensus protocols carried out by blockchain nodes. Groups ofMBHB Docket No. 24-0791-WO entries are added to the blockchain within data structures that take the form of blocks, and sequential blocks are cryptographically linked to one another. The blockchain nodes are computing devices or computing systems that can communicate with one another in a peer-to- peer fashion using blockchain software, and thus may reside in different locations and may be operated by different entities. Blockchain nodes may form an overlay on an existing computer network (e.g., the Internet), and may be jointly referred to as a blockchain network. To maintain independence and the decentralized character of the blockchain, each blockchain node may store its own copy of the entire blockchain.

[0034] Each block contains a cryptographic hash of the previous block in the blockchain, a timestamp, and data. The cryptographic hash may be produced by any one-way (hash) function that is mathematically and / or computationally impractical to reverse, such as SHA-256. The sequential linking of blocks through a cryptographic hash chain makes it very difficult for any party to modify a recently-placed block, and virtually impossible to modify earlier blocks.

[0035] Each blockchain user has a unique address to use with the blockchain. Each user also has a public key / private key pair that are cryptographically associated such that data encoded with the public key can be only be decoded by the corresponding private key, and vice versa. Thus, data encoded with a user’s public key are effectively encrypted so that they can only be decrypted by the user’s private key, and data encoded with the user’s private key results in a digital signature that is verifiable with the user’s public key.

[0036] An entry is typically some form of transaction between two or more users that includes the address of the “sending” user, the information being “sent,” and the address of one or more “receiving” users, all of which is signed with the digital signature of the sending user. Thus, the entry can easily be verified to be from the sending user (the sending user is authenticated) and have integrity (the entry was not changed after signing) as well as non- repudiation (the sender cannot later deny having signed the entry). The information being sent may be some amount of cryptocurrency, a smart contract, or some other token.

[0037] Proposed new entries are received by one or more blockchain nodes and their digital signatures are authenticated. In some cases, the validity of the entry may also be verified (e.g., an entry on a cryptocurrency blockchain cannot cause an amount of cryptocurrency held by the sender to be less than zero). These entries are formed into blocks, and then these blocks are distributed across the blockchain network to the other blockchain nodes. Each block may include one or more entries.MBHB Docket No. 24-0791-WO

[0038] Each blockchain node independently authorizes received blocks through an agreed-upon consensus protocol. An example of such a protocol is “proof of work,” where the blockchain nodes attempt to solve a mathematical puzzle by trial and error. For instance, the consensus protocol may require that the blockchain nodes attempt to find a nonce (e.g., an unknown value) such that a cryptographic hash function performed over the block with the nonce appended results in a hash value with a specified number of leading zeros. The process of carrying out this protocol is often referred to as “mining” and requires a significant amount of computational power.

[0039] The first blockchain node that discovers a suitable nonce broadcasts this nonce and the resulting hash value to the rest of the blockchain network. It is trivial for the other blockchain nodes to validate whether the nonce and hash value are correct. Such a block is said to have been “mined” and the discoverer may be awarded accordingly (e.g., with a small amount of cryptocurrency) to motivate participation in the protocol. Once a simple majority of the blockchain nodes agree that the block has been mined, the block is added to the blockchain by all blockchain nodes. Note that not all blockchain nodes need to act as miners in this fashion.

[0040] The cryptographic linking of blocks and proof of work being used for consensus, makes illegitimate modifications of a blockchain to be practically infeasible, as an attacker must modify all subsequent blocks in order for the modifications of one block to be accepted. Thus, blocks on a blockchain are effectively backwardly-immutable. Nonetheless, other consensus protocols, such as those based on proof of stake, may be used instead.

[0041] From time to time, a blockchain may undergo a fork and effectively change its character or become two different blockchains. Notably, the integrity of a blockchain relies on the blockchain nodes thereof agreeing on the rules used to add blocks and maintain history. If these nodes do not or cannot agree on the rules, or collectively agree to adopt a new set of rules, a fork is said to have occurred.

[0042] Some forks are accidental and short-lived. For instance, two miners may complete successful mining of a block at about the same time. After these miners begin broadcasting their solutions to the block, different blockchain nodes may add one or the other of these blocks to their local copies of the blockchain. Eventually, the addition of subsequent blocks will cause one of these versions of the blockchain to become longer than the other, and the blockchain nodes will abandon (orphan) the shorter version.

[0043] On the other hand, an intentional fork can happen when the rules are changed for at least some of the blockchain nodes. A soft fork occurs when the rules are changed in a backward-compatible fashion for a majority of the blockchain nodes (e.g., to add new types ofMBHB Docket No. 24-0791-WO entries). Thus, a single blockchain remains, with the blockchain nodes for which the rules have not been updated still recognizing new blocks as valid. Eventually, all blockchain nodes may be updated to the new rules.

[0044] A hard fork occurs when a majority of the blockchain nodes adopt new rules that render blocks produced by the new rules to be considered invalid under the old rules. Unless all blockchain nodes upgrade to the new rules, a permanent split can occur with a single blockchain diverging to become two independent blockchains – one operating in accordance with the new rules and the other operating in accordance with the old rules.

[0045] One of the major uses of blockchain technology, in addition to supporting cryptocurrencies, is the formation and execution of smart contracts. Smart contracts are executable logic (e.g., programs or code snippets) that are placed in entries. A smart contract’s logic is run when certain predetermined conditions are met. A simple smart contract may consist of “if-X-then-Y” logic, where X is a set of one or more conditions and Y is a set of one or more operations to be carried out when X becomes true.

[0046] As an example, smart contract logic may specify that when a shipment arrives at a recipient’s location (X), the recipient pays the sender an amount of money (Y). The smart contract may also specify one or more external data sources (e.g., output from sensors or application programming interfaces of other computing systems) that will be used to determine whether and when X becomes true. These sources are referred to as “oracles” and are trusted by all parties to the smart contract. For instance, an oracle for the above-mentioned shipment might be a wireless location sensor attached to the shipment that provides global positioning system (GPS) data, or a representational state transfer (REST) interface of a computing device that is tracking the shipment’s location.

[0047] Since entries on a blockchain containing smart contracts cannot be modified, execution of a smart contract may place further entries on the blockchain to carry out the operations of Y. Alternatively, off-block software tools may be used to check the status of a smart contract and then add entries as necessary for Y. In some cases, these further entries may also be smart contracts with different sets of conditionally–executable logic. Thus, smart contracts can be chained to perform a complex series of operations.

[0048] Given all of this, current blockchains have a set of generally desirable properties. They are decentralized and thus do not rely upon a single governmental or societal authority for their operation. A blockchain is a typically a public document that can be stored, viewed, and analyzed by anyone. Anyone can become a miner, but a majority control over all mining entities is required to corrupt the blockchain. Any user can create a blockchain “account” byMBHB Docket No. 24-0791-WO creating a unique address for themselves, and thus interact with other users by way of the blockchain without needing preapproval. Invalid transactions are automatically discarded by blockchain nodes. As noted, blocks are effectively backwardly-immutable (existing blocks cannot be changed) once they are placed on the blockchain, and become even harder to change over time as subsequent blocks are added.

[0049] Nonetheless, current blockchain technology also suffers from a number of limitations. First, there is no built-in recourse for theft, fraud, money laundering, or deceptive practices. As a result, blockchains have become host to these and other types of illegal activities, and evidence suggests that criminals are actively attracted to blockchains due to their lack of a central authority. Further, copyrighted or confidential information placed on a blockchain is effectively impossible to remove therefrom. Moreover, there is no way to recover a lost, misplaced, or stolen private key, and the owner of such a private key will not be able to access their blockchain account. These factors ultimately create enough risk for the average user that blockchain-based technology may fail to have utility beyond a few niche areas.

[0050] For example, compare the situation that confronts a blockchain user who mistakenly sends cryptocurrency to the wrong address (or who is lured by a fraudster to submit such a transaction, or whose private key is stolen by a hacker) versus the same user sending fiat currency through traditional banking channels. For the former, current blockchains afford no mechanism by which the cryptocurrency can be restored to its rightful owner even though the recipient has no legal entitlement to the funds and may very well have broken the law to obtain them. In contrast, the latter enjoys a host of protections, all of which are made possible by the fact that the transaction takes place through a chain of intermediary banks or other entities that are locatable and subject to court enforcement if they breach warranties or fail to alter the transactions to conform to the background law.

[0051] The example embodiments herein overcome these fundamental drawbacks to blockchain technology without changing the core tenets of its immutable and decentralized nature. In particular, a third party agreed upon ahead of time by blockchain users, or possibly designated by law or regulation, may be permitted to modify certain blockchain transactions after the fact. These modifications are not to existing blocks, but instead allow the third party to add new blocks to a blockchain that enforce and / or compel pre-established agreements, regulations, or judicial decisions, for example. Thus, the effects and / or outcomes of transactions or agreements represented in older blocks can be modified (e.g., corrected, rectified, or reversed) with the addition of newer blocks even if the older blocks themselves are immutable. At the same time, in accordance with example embodiments, procedures by whichMBHB Docket No. 24-0791-WO the third party may compel an action on the blockchain ensure that the third party’s authority to do so cannot be misused or corrupted. The procedures also operate according to the distributed, decentralized nature of the blockchain, and thereby do not compromise or forfeit the desirable aspects of blockchain-based technology.

[0052] A first possible embodiment is referred to herein as a “system-level” implementation because it involves changes to the blockchain itself – the data stored in entries and / or the rules carried out by blockchain nodes. This may involve deployment of a new blockchain or a soft or hard fork of an existing blockchain. All users that participate in this blockchain may explicitly (or implicitly through their use of the blockchain) agree that their entries are governed by a set of controls and enforcement of these controls that resides in one or more third parties (e.g., an arbitrator, court, other governmental body, or just another person or entity that is generally trusted). By way of example, the third party could be a judicial court.

[0053] By way of example, if there is a dispute between one or more users with respect to an entry in which they are involved, any of these users may request a ruling from such a third party. The third party may consider the request in light of the set of controls and / or applicable legal principles. If the third party decides that the entry needs to be modified, it records a representation of such a modification. This representation may be a new entry submitted directly to the blockchain, or a code, token, or other document published in a particular location (e.g., on a web site or a REST interface). The representation may identify the disputed entry, the users involved, the particular location (e.g., in the form of a uniform resource locator (URL)), and a transaction that the third party has determined to be appropriate to rectify or mitigate any harm done to one or more of the users. This representation may be digitally signed by the third party to establish its legitimacy, although a digital signature need not necessarily be required in all implementations and / or usage scenarios.

[0054] If the representation is not provided directly to the blockchain, an intermediary, off-chain entity controlling one or more server devices may obtain representations from the third party and submit them to the blockchain on behalf of the third party. For example, the intermediary entity may subscribe to notifications of new representations from the third party and / or periodically poll the third party (e.g., scrape its web site or REST interface).

[0055] Once submitted to blockchain nodes, these nodes may authorize the block and conduct the consensus protocol as described above. Additional authorization steps may be to verify the third party’s digital signature, verify that the representation actually exists at the particular location, and / or that the identified third party indeed has authority to modify entries on this blockchain. The blockchain nodes mine the entry’s block in the usual fashion and theMBHB Docket No. 24-0791-WO block gets added to the blockchain if a majority of the nodes agree that the block is valid and the mining was successful.

[0056] As an example, suppose that an entry on the blockchain involves user A transferring C units of cryptocurrency to user B. User A later finds out that their blockchain account was hacked to make this transaction. User A may contact the third party (e.g., a court), and supply evidence of the hacking (e.g., server logs, witness testimony, expert testimony, etc.). The third party may then rule in favor of user A and publish a representation of its ruling at a particular URL of its web site.

[0057] The representation may indicate that user B is to be compelled to transfer C units of cryptocurrency to user A on the blockchain (or some amount higher than C if user B was the perpetrator and punitive damages are included). The representation may include the URL, an effective date, and the identity of the third party, and may, if, for example necessary, be digitally signed by the third party. The effective date could be when a block containing the representation is mined, or at some point in the future (e.g., to give user B an opportunity to appeal or dispute the ruling). Alternatively, the effective date could be specified in the blockchain protocols and follow automatically. In some cases, the representation may temporarily freeze or seize the assets of user B on the blockchain so that user B cannot liquidate those assets prior to being compelled to make user A whole.

[0058] Once published, the intermediary entity may obtain the representation, form it into an entry, and submit it to the blockchain. During the mining process, the blockchain nodes may independently determine that the third party has the authority to compel this action (e.g., this capability of the third party may be built into the blockchain operation), and may also verify that the information stored at the URL matches the representation. As noted, once a majority of blockchain nodes agree that the block is valid and the mining was successful, the block can be added to the blockchain.

[0059] Advantageously, this mechanism does not require that the blockchain nodes, blockchain users, or third party trust the intermediary entity. Further, the blockchain might grant only certain powers to the third party with respect to the types of disputes that it can resolve, the remedies used, and the users over which it has authority. Moreover, the use of the consensus protocol guarantees that attempts to subvert or use the third party authority in an illegitimate fashion requires control over a majority of the blockchain nodes. As discussed above, the mining process makes doing so computationally infeasible for most actors.

[0060] While the above example illustrates the case of a transaction, the system-level implementation also provides operations for cases of smart contracts as well. More particularly,MBHB Docket No. 24-0791-WO in a scenario involving a smart contract, such as a dispute regarding fulfillment of a obligated action stipulated in the smart contract, the system-level implementation provides procedures for a trusted third party, such as a judicial court, act as an “authorized alias” for invoking the obligated action. As with the transaction case, the procedures ensure that any instance in which this new capability is exercised is secure and safe from hacking, corruptions, or any other form of misuse.

[0061] A second possible embodiment is referred to as an “entry-level” implementation because it involves coding pre-determined contingency actions into individual blockchain entries on an entry-by-entry basis, and subject to prior approval of only the parties participating in the agreement or transaction recorded in each such respective entry. The entry-level implementation may also be referred to as a “smart-contract” implementation because it may include smart-contract-like features of embedding coded actions in individual blockchain entries, but fortifies the confidence that the coded actions in any given entry will be carried out pursuant to the agreement by vesting authority to enforce the coded actions with a third party trusted by the parties to the agreement in the given entry. Unlike the first embodiment, the entry-level implementation may be able to be deployed using existing blockchains with smart contract support. Nonetheless, this embodiment could be carried out by way of a new blockchain or a fork of an existing blockchain.

[0062] Here, the entire blockchain need not necessarily be subject to the authority of any third party. Instead, pairs or groups of users may determine multilaterally to be bound by smart contracts that provide two new mechanisms: (i) a list of one or more remedial (or contingent) actions that are to be taken if certain conditions become true, and (ii) a third party who the users have agreed will have authority over the smart contract. Thus, the third party control may be granted on an entry-by-entry basis of the blockchain and not all blockchain entries are subject to such control. The remedial actions could be any type of state change that can be represented on the blockchain.

[0063] A smart contract may specify one or more conditions and associated remedial actions using the aforementioned “if-X-then-Y” logic. Each condition may be associated with a code, which could be a unique string of binary digits, a QR code, or take some other form. For example, user A and user B may engage in a smart contract in which user A will provide user B with 10 widgets and user B will provide user A with $500 (reflected in a digital asset) in return. These users may agree that the smart contract is further governed by two conditions, each with a remedial action: (i) if the widgets are not all delivered to user B by a particular time and date, then user A will refund $100 to user B, and (ii) if the widgets are not of workmanshipMBHB Docket No. 24-0791-WO quality as understood in the industry, then user A will refund all $500 to user B. Similarly, the amount of the payout to A may be left as a variable assignable by the third party. In some cases, the users may include a provision in the smart contract such that any other unspecified condition giving rise to a dispute is to be remediated by the third party.

[0064] This smart contract is submitted to the blockchain, then validated and mined as described above. Suppose that user B contends that the first remedial action has been triggered, and that the users are unable to resolve the dispute on their own. User B may then involve the pre-established third party, and provide evidence of late delivery to the third party (e.g., a bill of lading indicating that the widgets were delivered a week late). The third party may rule in favor of user B and publish a representation of its ruling at a particular URL of its web site.

[0065] The representation may include the smart contract, the URL, an effective date, the identity of the third party, and the code identifying the condition, and may be digitally signed by the third party. Once published, the intermediary entity may submit an entry to the blockchain for mining as described for the first embodiment. Here, the blockchain nodes may further validate that the code matches one from the smart contract. Once placed on the blockchain this entry serves to “modify” the smart contract – particularly, the presence of the code in an entry signed by the third party causes the remedial condition in the smart contract to be invoked, transferring $100 from user A to user B.

[0066] This mechanism also does not require that the blockchain nodes, blockchain users, or third parties trust the intermediary entity. Additionally, each of set of users involved in a smart contract can independently select their own third party, further decentralizing authority over different smart contracts. Moreover, the third party’s ruling is unambiguous and not open to interpretation since it invokes logic already present in the smart contract.

[0067] The description of the entry-level implementation in terms of smart-contract- like operations should not be confused with the smart contract scenario of the system-level implementation. More particularly, each of the system-level implementation and the entry-level implementation provide operations and functionality for both transactions scenarios and smart contract scenarios.

[0068] A third possible embodiment is a hybrid of the first and second embodiments. Like the first embodiment, the blockchain is structured initially or forked so that all entries are governed by a set of controls and enforcement of these controls lies in one or more third parties. However, the controls also apply to smart contracts on the blockchain even if these smart contracts do not have the pre-established conditions and associated remedial actions of the second embodiment. Nonetheless, like the second embodiment, the third parties can “modify”MBHB Docket No. 24-0791-WO smart contracts by adding new entries that trigger transactions or contain smart contracts themselves. Otherwise, operation takes place in a similar fashion to that of the second embodiment.

[0069] This embodiment avoids the users involved in each smart contract having to identify a third party that they mutually trust to enforce provisions of the contract – the third parties are determined by the blockchain. While this makes entry into smart contracts simpler, it also requires that the users rely on the blockchain’s established third parties. Similarly, this embodiment allows non-parties to the smart contract (such as a government agency or an aggrieved non-party) to “modify” smart contract execution where the designated third party approves.

[0070] In any of these embodiments, the entry that enforces the third party’s ruling may be placed on a different blockchain from the previous entry that it “modifies.” Thus, the same blockchain need not be used for both types of entry, or a transaction on one blockchain can be used to remedy disputes that arise in connection with transactions on another blockchain.

[0071] Notably, all three embodiments facilitate an operation that is not currently supported by blockchain-based technology – a third party adding an entry that compels a transaction from a sending user to a receiving user, or that compels a smart contract operation, without requiring that this transaction is digitally signed by the sending user or by the receiving user or of the owner of the smart contract (e.g., in the case of a smart contract or the like). Instead, so long as the entry from the third party can be validated as having been legitimately sourced by, and / or originated from, the third party, it is added to the blockchain. Advantageously, such functionality may elevate and advance blockchain-based technologies to become reliable enough for general use, while retaining all of their desirable decentralized and distributed features. II. Example Computing Devices and Cloud-Based Computing Environments

[0072] Figure 1 is a simplified block diagram exemplifying a computing device 100, illustrating some of the components that could be included in a computing device arranged to operate in accordance with the embodiments herein. Computing device 100 could be a client device (e.g., a device actively operated by a user), a server device (e.g., a device that provides computational services to client devices), or some other type of computational platform. Some server devices may operate as client devices from time to time in order to perform particular operations, and some client devices may incorporate server features.

[0073] In this example, computing device 100 includes processor 102, memory 104, network interface 106, and input / output unit 108, all of which may be coupled by system busMBHB Docket No. 24-0791-WO 110 or a similar mechanism. In some embodiments, computing device 100 may include other components and / or peripheral devices (e.g., detachable storage, printers, and so on).

[0074] Processor 102 may be one or more of any type of computer processing element, such as a central processing unit (CPU), a co-processor (e.g., a mathematics, graphics, or encryption co-processor), a digital signal processor (DSP), a network processor, and / or a form of integrated circuit or controller that performs processor operations. In some cases, processor 102 may be one or more single-core processors. In other cases, processor 102 may be one or more multi-core processors with multiple independent processing units. Processor 102 may also include register memory for temporarily storing instructions being executed and related data, as well as cache memory for temporarily storing recently-used instructions and data.

[0075] Memory 104 may be any form of computer-usable memory, including but not limited to random access memory (RAM), read-only memory (ROM), and non-volatile memory (e.g., flash memory, hard disk drives, solid state drives, compact discs (CDs), digital video discs (DVDs), and / or tape storage). Thus, memory 104 represents both main memory units, as well as long-term storage. Other types of memory may include biological memory.

[0076] Memory 104 may store program instructions and / or data on which program instructions may operate. By way of example, memory 104 may store these program instructions on a non-transitory, computer-readable medium, such that the instructions are executable by processor 102 to carry out any of the methods, processes, or operations disclosed in this specification or the accompanying drawings.

[0077] As shown in Figure 1, memory 104 may include firmware 104A, kernel 104B, and / or applications 104C. Firmware 104A may be program code used to boot or otherwise initiate some or all of computing device 100. Kernel 104B may be an operating system, including modules for memory management, scheduling, and management of processes, input / output, and communication. Kernel 104B may also include device drivers that allow the operating system to communicate with the hardware modules (e.g., memory units, networking interfaces, ports, and buses) of computing device 100. Applications 104C may be one or more user-space software programs, such as web browsers or email clients, as well as any software libraries used by these programs. Memory 104 may also store data used by these and other programs and applications.

[0078] Network interface 106 may take the form of one or more wireline interfaces, such as Ethernet (e.g., Fast Ethernet, Gigabit Ethernet, and so on). Network interface 106 may also support communication over one or more non-Ethernet media, such as coaxial cables or power lines, or over wide-area media, such as Synchronous Optical Networking (SONET) orMBHB Docket No. 24-0791-WO digital subscriber line (DSL) technologies. Network interface 106 may additionally take the form of one or more wireless interfaces, such as IEEE 802.11 (Wifi), BLUETOOTH®, global positioning system (GPS), or a wide-area wireless interface. However, other forms of physical layer interfaces and other types of standard or proprietary communication protocols may be used over network interface 106. Furthermore, network interface 106 may comprise multiple physical interfaces. For instance, some embodiments of computing device 100 may include Ethernet, BLUETOOTH®, and Wifi interfaces.

[0079] Input / output unit 108 may facilitate user and peripheral device interaction with computing device 100. Input / output unit 108 may include one or more types of input devices, such as a keyboard, a mouse, a touch screen, and so on. Similarly, input / output unit 108 may include one or more types of output devices, such as a screen, monitor, printer, and / or one or more light emitting diodes (LEDs). Additionally or alternatively, computing device 100 may communicate with other devices using a universal serial bus (USB) or high-definition multimedia interface (HDMI) port interface, for example.

[0080] In some embodiments, one or more computing devices like computing device 100 may be deployed to support a blockchain and / or blockchain-related architecture. The exact physical location, connectivity, and configuration of these computing devices may be unknown and / or unimportant to client devices. Accordingly, the computing devices may be referred to as “cloud-based” devices that may be housed at various remote data center locations.

[0081] Figure 2 depicts a cloud-based server cluster 200 in accordance with example embodiments. In Figure 2, operations of a computing device (e.g., computing device 100) may be distributed between server devices 202, data storage 204, and routers 206, all of which may be connected by local cluster network 208. The number of server devices 202, data storages 204, and routers 206 in server cluster 200 may depend on the computing task(s) and / or applications assigned to server cluster 200.

[0082] For example, server devices 202 can be configured to perform various computing tasks of computing device 100. Thus, computing tasks can be distributed among one or more of server devices 202. To the extent that these computing tasks can be performed in parallel, such a distribution of tasks may reduce the total time to complete these tasks and return a result. For purposes of simplicity, both server cluster 200 and individual server devices 202 may be referred to as a “server device.” This nomenclature should be understood to imply that one or more distinct server devices, data storage devices, and cluster routers may be involved in server device operations.MBHB Docket No. 24-0791-WO

[0083] Data storage 204 may be data storage arrays that include drive array controllers configured to manage read and write access to groups of hard disk drives and / or solid state drives. The drive array controllers, alone or in conjunction with server devices 202, may also be configured to manage backup or redundant copies of the data stored in data storage 204 to protect against drive failures or other types of failures that prevent one or more of server devices 202 from accessing units of data storage 204. Other types of memory aside from drives may be used.

[0084] Routers 206 may include networking equipment configured to provide internal and external communications for server cluster 200. For example, routers 206 may include one or more packet-switching and / or routing devices (including switches and / or gateways) configured to provide (i) network communications between server devices 202 and data storage 204 via local cluster network 208, and / or (ii) network communications between server cluster 200 and other devices via communication link 210 to network 212.

[0085] Additionally, the configuration of routers 206 can be based at least in part on the data communication requirements of server devices 202 and data storage 204, the latency and throughput of the local cluster network 208, the latency, throughput, and cost of communication link 210, and / or other factors that may contribute to the cost, speed, fault- tolerance, resiliency, efficiency, and / or other design goals of the system architecture.

[0086] As a possible example, data storage 204 may include any form of database, such as a structured query language (SQL) database. Various types of data structures may store the information in such a database, including but not limited to tables, arrays, lists, trees, and tuples. Furthermore, any databases in data storage 204 may be monolithic or distributed across multiple physical devices.

[0087] Server devices 202 may be configured to transmit data to and receive data from data storage 204. This transmission and retrieval may take the form of SQL queries or other types of database queries, and the output of such queries, respectively. Additional text, images, video, and / or audio may be included as well. Furthermore, server devices 202 may organize the received data into web page or web application representations. Such a representation may take the form of a markup language, such as HTML, the eXtensible Markup Language (XML), or some other standardized or proprietary format. Moreover, server devices 202 may have the capability of executing various types of computerized scripting languages, such as but not limited to Perl, Python, PHP Hypertext Preprocessor (PHP), Active Server Pages (ASP), JAVASCRIPT®, and so on. Computer program code written in these languages may facilitate the providing of web pages to client devices, as well as client device interaction with the webMBHB Docket No. 24-0791-WO pages. Alternatively or additionally, JAVA® may be used to facilitate generation of web pages and / or to provide web application functionality. III. Example System-Level Blockchain Embodiment

[0088] In accordance with example system-level embodiments, a designated, trusted off-chain authority may cause an entry to be made in a blockchain that compels a blockchain- recorded action between two or more parties to a previously-recorded entry on the blockchain. Conventionally, a blockchain entry that specifies an action or arrangement (such as an agreement or contract) between two or more parties requires some cryptographically-verifiable form of the users’ identities, such as a digital signature, to verify the action and validate the new entry. In contrast, the designated, trusted off-chain authority of the system-level implementation is a third party, and not one of the parties to the previous entry. Example system-level embodiments put in place a set of procedures and protocols that safeguard the integrity and validity of any directive to compel a blockchain-recorded action, while at the same time leaving in place and undisturbed the distributed and decentralized operating principles of the blockchain.

[0089] By way of example, a blockchain-recorded action may be a transaction that specifies a transfer of digital assets from a sending party, or sender, to a receiving party, or receiver. In order for the transaction to be considered valid, and thereby recorded as an entry in a block of the blockchain, a cryptographic key of the sender, or other form proof of ownership of the digital asset, must be involved in the transaction, such that any blockchain node can verify the sender’s right to the digital asset, and thus the sender’s right to transfer the digital asset. In an example use case of the system-level embodiment, the designated, trusted off-chain authority may be asked to reverse the effect of the transaction by causing a remedial action of a transfer of the digital assets back from the receiver to the sender to be entered into the blockchain.

[0090] Also by way of example, a blockchain-recorded arrangement (such as an agreement or contract) between two or more parties may be a smart contract that embeds one or more contingency action to be carried out if and when the any one or more of the contingency actions is or are invoke, or “called,” by a “designated caller” who is authorized in the smart contract to make the call (i.e., to invoke the contingency action(s)). The smart contact, which is recorded in as an entry in the blockchain, typically includes executable code of each contingency action, as well as the identity of the designated caller (or callers) authorized to call the contingency action(s) and cause the associated code to run. In order for a call to be considered valid, and thereby cause the contingency action to be executed, a request or orderMBHB Docket No. 24-0791-WO to make the call can be made in a submission to the blockchain. The request includes a link to the smart contract in question, an identification of the contingency action being requested, any parameters that the contingency action may take or require, and a cryptographic key of the caller (or some other form of authentication) that demonstrates the requestor’s authority to make the call. In an example use case of the system-level embodiment, blockchain operation may be configured to recognize the trusted off-chain authority as an “authorized alias” of the designated caller of a contingency action for the purpose of making a call, and thereby cause a contingency action of a smart contract to execute when asked or ordered to do so by the trusted off-chain authority.

[0091] Assuming the designated, trusted off-chain authority grants the request for an action or an aliased call, a specification of the action or call, authenticated by the trusted off- chain authority, may be electronically published or posted as a “trusted order” to a secure website or other server, and made available to a plurality of independent, trust verifiers. Each of the trust verifiers may then separately and independently retrieve the trusted order, and cryptographically sign it with a respective private cryptographic key, and separately and independently store their respective signed trusted order to a secure database. The plurality of signed trusted orders may then be retrieved from the secure database and provided, together with the specification of the remedial action, to the blockchain. For purposes of discussion, and by way of example, a trusted order may be created or generated as a hash of information that specifies the request embodied in the order. Similarly, the trust verifier function may be incorporated into the node protocols and thus allocated to all or a plurality of the nodes. Likewise, the secure database of signed trust orders can be housed on the blockchain or stored at another location.

[0092] Each of one or more nodes of the blockchain may then authenticate and decrypt the plurality of signed hashes using respective public keys of the trust verifiers, and verify that all of decrypted hashes are identical. This provides proof of validity of the hash. Each of the one or more nodes may then generate its own local version of the hash using the specification of the remedial action or of the requested aliased call. Upon verifying that the local version of the hash is identical to the retrieved, validated hash, each of the one or more nodes may thus be certain of the integrity and authenticity of the remedial action or aliased call, and proceed to encode it in a valid blockchain action according to usual blockchain procedures. Likewise, when the verification function is incorporated into the node protocols, a node may directly sign the remedial transaction on chain in lieu of signing and storing the trust order. Entry in aMBHB Docket No. 24-0791-WO blockchain then causes the remedial action or aliased call to be effectively carried out and recorded in the blockchain.

[0093] An example implementation of a system-level embodiment, referred to as a system-level implementation, is describe in more detail below. A. Example System Architecture and Technical Description

[0094] Figure 3 is a simplified block diagram showing an example arrangement of components of a system-level implementation of authenticated off-chain modification of blockchain-based transactions, in accordance with example embodiments. The block diagram of Figure 3 may also be considered as depicting aspects of an operational architecture of the system-level implementation. As shown, example embodiments can include various components, any one or more of which may be implemented as or in one or more computing devices. As such, components depicted in Figure 3 may themselves be or include hardware, software, firmware, or combinations thereof. Some of the components may be identified structurally, such as databases or other forms of data storage and management, and others may be identified in terms of their operation or function. Operational and / or functional components could be implemented as software and / or hardware modules, for example, and may also be referred to as “modules” for the purpose of the present discussion.

[0095] The example system-level implementation can also include one or more connection mechanisms that connect various components. By way of example, the connection mechanisms are depicted as arrows between components. The direction of an arrow may indicate a direction of information flow, though this interpretation should not be viewed as limiting. In this disclosure, the term “connection mechanism” means a mechanism that connects and facilitates communication between two or more components, devices, systems, or other entities. A connection mechanism can include a relatively simple mechanism, such as a cable or system bus, and / or a relatively complex mechanism, such as a packet-based communication network (e.g., the Internet). In some instances, a connection mechanism can include a non-tangible medium, such as in the case where the connection is at least partially wireless. A connection mechanism may also include programmed communication between software and / or hardware modules or applications, such as application program interfaces (APIs), for example. In this disclosure, a connection can be a direct connection or an indirect connection, the latter being a connection that passes through and / or traverses one or more entities, such as a router, switch, or other network device. Likewise, in this disclosure, communication (e.g., a transmission or receipt of data) can be a direct or indirect communication.MBHB Docket No. 24-0791-WO

[0096] By way of example, various components and entities of the example system- level implementation of Figure 3 includes a blockchain network 302 having connected nodes 302-1, 302-2, …, 302-N, where ellipses in the connections to node 302-N indicate possibly additional connected nodes. Other example components and entities of the example system- level implementation include an off-chain request application 304 with a user interface (UI) 304-I / F, an off-chain trusted-authority server 306, a published enforcement actions server 308, an event watcher 310, trust verifier A 312-A, trust verifier B 312-B, trust verifier C 312-C, verified request database 314, request poller 316, off-chain transaction server 318, and trust verifier public keys 320. The ellipses following the trust verifier C 312-C indicates that there could be addition trust verifiers. In an example embodiment, the off-chain request application 304 could be an application program configured for execution on a computing device, such as a PC, laptop, smartphone, or server, among other possible devices.

[0097] The computational and / or functional roles of the example components and entities may be understood by considering example operational scenarios involving transactions on the blockchain and smart contracts on the blockchain. Both types of scenarios involve similar, and in some respects the same, operations. However, in order to help keep the distinguishing aspects of the two scenarios clear, operational examples of the two scenarios are described separately below. 1. Example system-level scenario for transactions on the blockchain

[0098] In an example transaction scenario, the parties to a prior transaction may each be blockchain users, and the designated, trusted off-chain authority may be a judicial court represented by individual judges. A sender of prior transaction may claim to have been defrauded by a receiver of the transaction, and request a remedial action of a reverse transfer. The request for may be submitted by the sender or a legal representative of the sender (e.g., a lawyer), and may include specific information and evidence that enables a judge to render a decision to grant the request. Other transaction scenarios are possible as well.

[0099] More specifically to the example transaction scenario, a sender of a digital asset, such as digital currency, to a receiver may seek to reverse a transaction that transferred the digital asset from the sender’s account to the receiver’s account. For example, the sender may have been tricked or defrauded by the receiver, and thus may look to a judicial court for remediation. The sender or a legal representative of the sender (e.g., a lawyer) may enter a requested-action input 301 at the UI 304-I / F. The requested-action input 301 may include information identifying the sender, the receiver, details about the original transfer from the sender to the receiver, the remedial action being requested, and particular information thatMBHB Docket No. 24-0791-WO provides and / or serves as evidence that the sender was tricked or defrauded into entering in the original transaction. In accordance with example embodiments, the UI 304-I / F may be or include an online form with drop-down menus or the like, for example, that prompt the sender (or other more generally a user) for specific information required to construct a formal request and provide the court with requisite information for evaluating and granting or denying the request. It should be understood that the specific contents of the request-action input 301 listed above is just one example for purposes of the present illustration, and could include more, less, and / or different information in other usage scenarios and / or implementations.

[0100] The UI 304-I / F may provide the requested-action input 301 to the off-chain request application 304, which may then process the request for delivery to the judicial court, as well as (possibly conditionally) to the off-chain transaction server 318. Thus, in accordance with example embodiments, the off-chain request application 304 may arrange and / or format all or certain specific items or elements of the requested-action input 301 in a prescribed manner into a construct referred to for convenience herein as a “request specification,” and may then generate a one-way hash of the request specification. For purposes of clarity in the discussion, the one-way hash of the request specification is labeled in all capital letters as the “HASH” to identify it with a specific instance of a hash function, and to distinguish it from other general references to hashes, hash functions, and the like. By way of example the HASH could be encoded as text string or string of characters, such as the following: 0xc8c48f65db62af1cea5e804e99f0139d5173cb0f. Also for purposes of discussion, the HASH and request specification may be considered together as a data entity referred to as HASH plus request specification 303. It should be understood that this grouping is for convenience in the operational description and need not necessarily be implemented in practice (although the grouping is not necessarily excluded either). It should also be understood that other forms of encoding and / or representation of the request specification. Some non-limiting examples of alternatives are discussed below.

[0101] The HASH plus request specification 303 may then be provided to the off-chain trusted-authority server 306. In an example in which the trusted authority is a judicial court, the off-chain trusted-authority server 306 could be a server associated with the court and configured for receiving requests for compelling actions to be entered in a blockchain. For example, the off-chain trusted-authority server 306 may implement an API configured for receiving appropriately-formatted HASH plus request specification 303 messages or direct input. In other examples, the off-chain trusted-authority server 306 could be a more general server associated with the court and configured for receiving a variety of court / case-relatedMBHB Docket No. 24-0791-WO input such as filing pleadings, or it could be a separate server for communicating to a judge. Other arrangements are possible as well. In some examples, the HASH plus request specification 303 may be provided “manually” to a judicial court, optionally together with supporting evidence for the request, by a legal representative of the sender, for example.

[0102] After the HASH plus request specification 303 is received by the off-chain trusted-authority server 306, an evaluation may be made as to whether or not to grant the requested action. Again, considering the example in which the trusted authority is a judicial court, the evaluation may be made by a judge or other authorized representative of the court. This may entail the judge evaluating information and evidence, and then rendering a decision. In other examples, evaluation of the information provided in the HASH plus request specification 303 might be able to be carried out autonomously by a computer-based algorithm. How a decision is made, and whether or not it is favorable to the sender (requestor of the action), is not within the scope of example embodiments. However, the further processing of, and procedures relating to, an outcome that is a favorable decision are within the scope of example embodiments.

[0103] Assuming a decision (e.g., by a person or by an algorithm) is made to grant the request, a HASH plus enforcement specification 305 may be posted or published to the published enforcement actions server 308. In the judicial example, the HASH plus enforcement specification 305 may be a human-readable electronic file that articulates the decision and includes an embedded alpha-numeric representation of the HASH. For example, the HASH plus enforcement specification 305 could be a PDF file digitally signed by the court or uploaded by a court employee with authority to do so. The published enforcement actions server 308 could be a publically-accessible server to which such decisions, among other forms of court business, are posted. In the example of a judicial court, the published enforcement actions server 308 could be a server such as the Public Access to Court Electronic Records (PACER) server and the digital signature could be a clerk’s password for accessing PACER, for example. However, other arrangements are possible as well.

[0104] Also with a decision to grant the request, the off-chain trusted-authority server 306 may provide or send (e.g., transmit) a confirmation ID 307 to the off-chain request application 304, which may serve to inform the off-chain request application 304 of the decision, and provide it with identifying information for accessing the now-published HASH plus enforcement specification 305 at the published enforcement actions server 308.

[0105] In accordance with example embodiments, after the off-chain request application 304 receives the confirmation ID 307, it may in turn send the confirmation ID 307MBHB Docket No. 24-0791-WO to the event watcher 310. Doing so may alert the event watcher 310 to the availability of the HASH plus enforcement specification 305 at the published enforcement actions server 308. The off-chain request application 304 may then also provide or send (e.g., transmit) the HASH plus request specification 303 to the off-chain transaction server 318 to make it, too, aware of the availability of the HASH plus enforcement specification 305 at the published enforcement actions server 308 and to initiate creation of a formal request for a requested action to be entered into the blockchain 302. Similarly, a party or an attorney, having received notice of the decision, could prompt the event watcher, or could enter a message on the blockchain with the confirmation ID which transactions are monitored by the event watcher or by the trust verifiers directly.

[0106] The event watcher 310, having been alerted with the confirmation ID, may then independently notify each of the trust verifiers A, B, and C, 312-A, 312-B, and 312-C, as well as any additional trust verifiers, as indicated in Figure 3. Each trust verifier could be a secure server or other networked secure computing system associated with a respective organization or institution, such as an established bank, brokerage, or network service provider, for example. Although not necessarily shown in the figure, the notification to each of the trust verifiers may also include the confirmation ID or other information enabling access to the HASH plus enforcement specification 305 at the published enforcement actions server 308.

[0107] Having been notified, each of the trust verifiers A, B, and C, 312-A, 312-B, and 312-C, as well as any additional trust verifiers (which could, in some examples, be one more of the nodes of the blockchain network), may then independently retrieve the HASH from the published enforcement actions server 308 over respective secure links. Each independent retrieval is shown with a label HASH 309 for purposes of the present discussion; again, the ellipses indicate additional retrievals of HASH 309 from additional trust verifiers. The trusted nature of the trust verifiers, together with secure retrieval allows each trust verifier to independently vouch for the authenticity of the retrieved HASH 309. Each trust verifier may do this by encrypting its retrieved HASH 309 with a private cryptographic key that serves as well as an authenticating digital signature. Thus, the trust verifier A 312-A generates the A-Signed(HASH) 311-A; the trust verifier B 312-B generates the B-Signed(HASH) 311-B; and the trust verifier C 312-C generates the C-Signed(HASH) 311-C. Each trust verifier may then store or deposit its respectively signed HASH in the verified request database 314. Additional signed HASHes may be generated and stored in the verified request database 314, as indicated (once more) by the ellipses. Similarly, a node itself may serve as a trust verifierMBHB Docket No. 24-0791-WO and may be randomly selected to verify a given transaction (for example, the node that mined the last block or a random function based on data contained in the last block).

[0108] In further accordance with example embodiments, the off-chain transaction server 318 having received the HASH plus request specification 303, may communicate with the request poller 316 to monitor the verified request database 314 for the presence and / or availability of the signed HASHes from the trust verifiers. This may be done by polling the verified request database 314, or by some other arrangement or protocol. In some examples, the verified request database 314 could itself be a blockchain to which the HASHes are entered in blocks or housed on a blockchain or smart contract, and which may be monitored by the request poller 316 or a similar functional element. Likewise, the request could take the form of a message sent to the blockchain and the poller could be a node that monitors the messages in the blockchain’s message pool. Similarly, the verifiers could directly co-sign the message with their private keys.

[0109] Upon determining that the HASHes have been added to the verified request database 314 and are available, the request poller 316 may retrieve the A-Signed(HASH) 311- A, the B-Signed(HASH) 311-B, and the C-Signed(HASH) 311-C (as well any additional signed HASHes), and provide them to the off-chain transaction server 318, and indicated in Figure 3.

[0110] The off-chain transaction server 318 may then generate an action-entry request 313 and send it to the blockchain network 302. In practice, the action-entry request 313 may be delivered or sent to one of the nodes, and from there propagate to some or all of the other nodes. As described below, the action-entry request 313 may include the request specification and all retrieved cryptographically-signed HASHes, in addition to other information pertinent to the action being requested. In particular, each node of the blockchain network 302 that ultimately receives the action-entry request 313 may independently verify each signed HASH using publically-available trust verifier public keys 320 to decrypt each signed HASH. Each such node may then validate each HASH by ensuring that they are all identical. Any discrepant HASH value may indicate a breach or hack somewhere in the sequence so far described, and thereby cause further processing of the request to abort.

[0111] Each receiving node may further generate its own local version of the HASH by applying a one-way hash function to the request specification in the received action-entry request 313. By checking that its local version of the HASH is identical to the HASH from each of the verifiers, each node may now confirm that the requested action is not only authentic and authorized, but also comports exactly with the action requested and granted by the designated off-chain trusted authority. Each receiving node may then process the request andMBHB Docket No. 24-0791-WO submit the requested action for entry into the blockchain just as it would for any requested action or transaction submitted by blockchain users. In this way, the request action may be effectively carried out and recorded in the blockchain. Notably, each of the trust verifiers need not be individually trusted, as at least a majority of the trust verifiers agreeing on the value of HASH provides a collective level of trust across all of the trust verifiers.

[0112] Figure 4A illustrates a representation of example processing of a system-level action-entry request by a blockchain node for a transaction scenario, in accordance with example embodiments. For this example, the action-entry request is labeled 313-A. By way of example and for purposes of illustration, only one node, node 302-2, is considered. It should be understood that any node receiving the action-entry request 313-A would apply the same rules in processing the request. In the figure, an expanded but still simplified view of the action- entry request 313-A is presented. By way of example, the expanded action-entry request 313- A for the transaction scenario includes a request specification, an off-chain request indicator, an action date, and the signed HASHes A-Signed(HASH) 311-A, B-Signed(HASH) 311-B, the C-Signed(HASH) 311-C (as well any additional signed HASHes, as indicated by the vertical ellipses). It should be understood that there could be additional information included as well, and that the format of the request is conceptually representational, and does not necessarily correspond to that of an actual implementation.

[0113] Also by way of example, the request specification is shown as including an identity of an asset owner and a description of an action to be applied to the asset(s) of the owner; a receiver may optionally be supplied if the action is a transfer from the owner to the receiver, for example. An example action for a transfer of “X” from the owner to a receiver is illustrated. In this example request specification, it is assumed that the receiver previously transferred some portion of digital assets to the owner, and is now requesting X amount of that transfer to be returned via the requested action. As shown, the off-chain request indicator is set to “true,” signifying that this is an off-chain request that follows rules established in accordance with example embodiments of the system-level implementation.

[0114] The action date is a parameter that sets a future date / time at which to carry out the requested action. Stipulating a future date for carrying out the action may introduce a further safeguard against possible corruption or misuse of the system-level procedures that produced the action-entry request 313-A and delivered it to the blockchain network 302. For example, if an illegitimate request somehow gets validated and entered into the blockchain, a delay in carrying out the action built into the node protocol provides time to discover and correct the error before the action takes effect. A future date may also enable any party to the requestedMBHB Docket No. 24-0791-WO action to dispute the authorization to implement the action. For example, if an action aims to reverse the effect of a transfer from a receiver to an owner by compelling a future reverse transfer, and the owner wishes to dispute the terms or evidence presented to a court that rendered the decision to grant the request for the reverse transaction, a built-in delay provides time for the owner to present a case to deny the request. An action date could be specified as an amount of time past a particular date. By way of example, the amount of time could be 72 hours, seven days, or 30 days. Other amounts of time could be used.

[0115] In some usage scenarios, more than one action date may be specified. For example, an immediate freeze of 72 hours may be applied to a receiver’s account, with a follow- on date of an additional 30 days to fully resolve the correctness and / or legitimacy of an action request. Other timing arrangements are possible as well, and example embodiments are not limited to any particular timing arrangement. Rather, any variety of timing arrangements are within the scope of example embodiments.

[0116] As indicated in the box labeled “Notes,” the example action included in the request specification is non-limiting. Other non-limiting examples include freezing or unfreezing the owner’s access to X, transferring just a portion of X, and transferring X from the owner to an escrow account. Other actions may be possible as well. As also indicate in the Notes, the action date (or an actions date) could additionally or alternatively be included in the request specification. If additionally included in the request specification, a prescribed rule may be applied to determine which of multiple action dates takes precedence or an unalterable minimum delay may be required in the node protocol. Or multiple action dates could have different effects depending on whether they are included in, or place outside of, the request specification.

[0117] Example processing of the action-entry request 313-A by the node 302-2 is represented in a flow chart 400-A shown beneath the node 302-2. Upon receiving the action- entry request 313-A, the node 302-2 may not immediately know that the request is for creating a compulsory entry that implements a compulsory action. In accordance with example embodiments, an initial check is made to determine whether the request is an off-chain request or a conventional request. This could be done by checking the off-chain request indicator, for example. If it is false, then the node 302-2 may process the request in accordance with blockchain procedures. For this example, in which the off-chain request indicator is true, the node 302-2 may continue with off-chain request processing.

[0118] In accordance with example embodiments, for off-chain request processing, the node 302-2 may next determine if the action-entry request 313-A includes a required minimumMBHB Docket No. 24-0791-WO number of signed HASHes. More particularly, requiring the inclusion of a minimum number of signed HASHes can significantly reduce the probability of a successful hack or corruption of the trust verifiers. For example, in a simple analysis, if the probability of a successful hack of a trust verifier is 0.01 (1%), for example, then the probability that N of them are hacked is (0.01)N, which becomes vanishingly small as N increases. The minimum number requirement may therefore be considered one of multiple safeguards against successful hacking or other forms of corruption of the process. As indicated, if the minimum number requirement is not met, the request is considered “bad” and processing may be aborted. Otherwise, processing continues.

[0119] In further accordance with example embodiments, if the minimum number requirement is satisfied (met), the node 302-2 may then decrypt each signed HASH using the trust verifiers respective public keys 320, which are assumed to be known and / or available to the node 302-2. For the example illustrated in Figures 3 and 4A, the decrypted HASHes are expressed, as shown, as: HASHA = Decrypt[A-Signed(HASH), A-Key] HASHB = Decrypt[B-Signed(HASH), B-Key] HASHC = Decrypt[C-Signed(HASH), C-Key], where A-Key is the public key of trust verifier A 312-A, and likewise for trust verifiers B and C, 312-B and 312-C. The vertical ellipses indicate similar decryptions of additional signed HASHes that may be included in the action-entry request 313-A.

[0120] In accordance with example embodiments, the node 302-2 may next test to ensure that all of the decrypted HASHes are identical. That is, a check that: HASHA= HASHB= HASHC. Requiring that all the HASHes are identical even further reduces the likelihood of a successful hack or corruption of any of the trust verifiers. This is because a successful hack of the HASH provided by any less than all of the trust verifiers would cause this test to fail, thereby exposing the hack. Only an identical hack of all of the trust verifiers might enable the test to pass. However, as noted, the minimum number requirement helps make this extremely unlikely, if not virtually impossible. As indicated, if the identical HASH test fails, the request is considered “bad” and processing may be aborted. Otherwise, processing continues.

[0121] In further accordance with example embodiments, if the identical HASH test passes (i.e., if all the decrypted HASHes are identical), the node 302-2 may then take each identical decrypted value to be the true value of the HASH. Thus the node 302-2 may assignMBHB Docket No. 24-0791-WO the value of HASHA (or, equivalently, HASHB or HASHC, and so on) to a variable called, by way of example, “HASHis.”

[0122] In accordance with example embodiments, the node 302-2 may next carry out its own computation of the one-way hash function applied to the request specification in the action-entry request 313-A in order to determine a “local” value of the HASH. This computation is the same one performed by the off-chain request application 304 that initiated the off-chain request, as described above. The computation may utilize any standard and / or known one-way hash function that meets a specified level of complexity. Non-limiting examples of such one-way hash functions include SHA-256, SHA-512, RIPEMD-320, and Whirlpool. As indicated in the flow chart 400-A, the local HASH is referred to as “ThisHASH.”

[0123] In further accordance with example embodiments, the node 302-2 may then test that ThisHASH is identical to HASHis. That is, the locally-computed HASH is equal to the HASH provided independently by all of the trust verifiers. A successful outcome of this test now validates the request specification, since ThisHASH is verifiably derived from the request specification, and agrees with the HASH from each of the trust verifiers. As indicated, if ThisHASH does not equal HASHis, the request is considered “bad” and processing may be aborted. Otherwise, processing continues.

[0124] Finally, if ThisHASH is confirmed to be identical to HASHis, the node 302-2 may submit the requested compulsory entry to blockchain, with an effective date for the action as specified in the action-entry request 313-A.

[0125] While the above description applies to processing of just the one example node 302-2, when the action-entry request 313-A is submitted to the blockchain network 302 by way of one of the nodes, it may be propagated to all or some number of the node. Each node that receives the action-entry request 313-A may process it as described for node 302-2. If a majority of the nodes agree that the requested entry is valid, they may all submit it to a pool of “candidate” entries (e.g., candidate transactions). In conventional processing, the entry may be placed in a prospective new block processed by a miner. Successful mining may then record the action as effectively carried out in a new block of the blockchain. 2. Example system-level scenario for smart contracts on the blockchain

[0126] In an example smart contract scenario, the parties to a prior smart contract may, again, each be blockchain users, and the designated, trusted off-chain authority may, again, be a judicial court represented by individual judges. As a simple example for the purposes of illustration the parties may be “user A” and “user B,” and the prior smart contract may applyMBHB Docket No. 24-0791-WO an agreement of user A to supply a service to user B, and an agreement of user B to transfer digital asset money to user A upon delivery of the service. A first contingency action of the smart contract may be a notification that A has completed the service, and a second might be a transfer of funds from B to A. The designated caller of the first contingency action could be A, and the designated caller of the second contingency action could be B. In an example, after A calls the service-complete action, B may refuse call the payment action, thereby refusing to pay A for the service. User A or a legal representative of user A (e.g., a lawyer) may then request that the court act as an authorized alias for user B to cause the second contingency action to execute.

[0127] More specifically to the example transaction scenario, the requested-action input 301 may include a link to the smart contract, an identification of the contingency action requested, and an identification of the caller – user B in this example. User A’s identity may also be included, if necessary, as well as any parameters of the contingency action that may be needed. All of the operations of the transaction scenario described above in connection with Figure 3 may then apply as well to the smart contract scenario. Besides the requested-action input 301, the primary differences relate to content (and possibly format) of the request specification, the enforcement action specification, and the contents of the action-entry request 313.

[0128] In this example smart contract scenario, a court would be asked to issue an order compelling the payment contingency action of the smart contract. Assuming the court agrees, the verification procedures described above for the transaction scenario would be carried out in the same way. The action-entry request 313 generated and sent (input) to the blockchain network 302 would be configured to cause the node(s) of the blockchain 302 to accept or allow the court to act as an authorized alias for calling the payment contingency action.

[0129] Each node that receives the action-entry request 313 may further generate its own local version of the HASH by applying a one-way hash function to the request specification in the received action-entry request 313. Again, this allows the node to confirm that the requested action is not only authentic and authorized, but also comports exactly with the action requested and granted by the designated off-chain trusted authority. Each node may then process the request and submit the requested action for entry into the blockchain just as it would for any requested action or transaction submitted by blockchain users. In this way, the request action may be effectively carried out and recorded in the blockchain. Again, each of the trust verifiers need not be individually trusted, as at least a majority of the trust verifiers agreeing on the value of HASH provides a collective level of trust across all of the trust verifiers.MBHB Docket No. 24-0791-WO

[0130] Figure 4B illustrates a representation of example processing of a system-level action-entry request by a blockchain node for a smart contract scenario, in accordance with example embodiments. For the example smart contract scenario, the action-entry request is labeled 313-B. By way of example and for purposes of illustration, only one node, node 302- 2, is considered. It should be understood that any node receiving the action-entry request 313-B would apply the same rules in processing the request. In the figure, an expanded but still simplified view of the action-entry request 313-B is presented. By way of example, the expanded action-entry request 313-B for the smart contract scenario includes a request specification, an off-chain request indicator, an action date, and the signed HASHes A-Signed(HASH) 311-A, B-Signed(HASH) 311-B, the C-Signed(HASH) 311-C (as well any additional signed HASHes, as indicated by the vertical ellipses). It should be understood that there could be additional information included as well, and that the format of the request is conceptually representational, and does not necessarily correspond to that of an actual implementation.

[0131] By way of example, the request specification for the example smart contract scenario is shown as including a link to the smart contract, an identification of the contingency action, an identification of the designated caller of the contingency action, and (possibly optionally) parameters of the contingency action. Other information might be included as well, such as identification of one or more other parties to the smart contract, for example. An identity of an asset owner and a description of an action to be applied to the asset(s) of the owner, as well as a receiver, may optionally be supplied if the action is a transfer from the owner to the receiver, for example. As shown, the off-chain request indicator is set to “true,” signifying that this is an off-chain request that follows rules established in accordance with example embodiments of the system-level implementation.

[0132] The action date is a parameter that sets a future date / time at which to carry out the requested action. In the example smart contract scenario, the requested action is the contingency action. As indicated in the box labeled “Notes,” the action date (or dates of one or more actions) could additionally or alternatively be included in the request specification. If additionally included in the request specification, a prescribed rule may be applied to determine which of multiple action dates takes precedence. Or multiple action dates could have different effects depending on whether they are included in, or place outside of, the request specification.

[0133] Example processing of the action-entry request 313-B by the node 302-2 is represented in a flow chart 400-B shown beneath the node 302-2. In this example illustration, all of the steps of the flow chart 400-B for the smart contract scenario are the same as those inMBHB Docket No. 24-0791-WO the flow chart 400-A for the transaction scenario, except for the final step. Specifically, for the smart contract scenario, if ThisHASH is confirmed to be identical to HASHis, the node 302-2 may generate a transaction directing that the contingency action be called by the trusted entity (e.g., the court) acting as an authorized alias for the designated caller. The transaction may be placed in an entry, which may then be submitted for entry in the blockchain, with an effective date for the action as specified in the action-entry request 313-B. When the entry with the requested transaction is placed in the blockchain (e.g., after mining the block in which the entry is placed), the transaction will run, causing the contingency action to execute. 3. Example variations

[0134] As discussed above, the system-level implementation is designated as such because it entails modifying the behavior and / or operations of all blockchain nodes to be able to carry out the processing of action-entry requests just described by way of example. In the context of blockchain-based technologies, such modifications may involve adjusting and / or updating rules that all the nodes agree (or are bound) to follow. Accordingly, the introducing of the functions and operations of the system-level implementation to an existing blockchain may require a hard fork of the existing blockchain. The advantages and benefits of enabling a trusted off-chain entity, such as a judicial institution, to cause remedial actions that rectify otherwise irreversible blockchain actions and / or transactions, and to do so securely, reliably, and in a manner highly resistant to hacking or corruption, while also maintaining the decentralized, distributed nature of blockchain technology, may supply more than adequate impetus for such a hard fork to be adopted in favor of the pre-fork blockchain or for the community of miners to adopt the system-level implementation via a soft fork.

[0135] There may be a number of additional and / or alternative aspects of implementing a system-level embodiments. Some non-limiting examples are next described.

[0136] Instead of, or in addition to, using a hash of the request specification, the off- chain request application 304 or the off-chain trusted authority server 306 could create a form of encoded “action-payload” that represents the request action in some other way. Non-limiting examples include: a semantic representation of the request specification created by the off- chain trusted authority according to a prescribed formula or application program; and a semantic representation of the request specification generated by an artificial intelligence engine using the request specification as input, for example. More particularly, a semantic representation of the request specification could represent a requested action in a symbolic form that is interpretable by a computing device. By way of example a semantic representation could be encoded as text string or string of characters, such as the following:MBHB Docket No. 24-0791-WO {"judicialEventId":"0x4176cd550cb468ed686d0462df28b4a162c7a743", "judicialDistrict":"USDC-NDOI","caseNumber":"09-cv-05453", "judicialAction":"freeze", "fromWallet":"0xF0b874003ECF7fb973a71B2Dbd0F656666809F35", "toWallet":"0x05113E5A814b6162D85322f3D86868e36FB18E34", "coinId":"0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48", "amount":25.0}. In this illustrative example, which assumes the trusted authority is a judicial court, various identifiers that tag parameters of the request specification may be recognizable by node processing.

[0137] For the sematic representation embodiment, a node may not necessarily need to generate a hash, but instead confirm that it recreated the sematic representation. Once confirmed, the node may interpret the sematic representation to determine what action or actions are being requested and prepare a transaction accordingly.

[0138] As another example variation, instead of, or in addition to, the off-chain trust verifiers, each of one or more nodes may incorporate functionality of a trust verifier. In this embodiment, a node may be “self-trusting” such that its own retrieval of the HASH or other form of action-payload from the published enforcement actions server 308 suffices to verify the authenticity of the retrieved data. Consequently, the action-entry request 313 need not necessarily include multiple signed HASHes or other action-payloads. The effect of multiple retrievals from the published enforcement actions server 308 (or the like) by different entities may instead be realized by all or a threshold number of multiple nodes agreeing that their respective retrievals agree. This could follow from “majority” rules of blockchain nodes, for example.

[0139] In still another example variation, multiple retrievals of the HASH or other action-payload need not necessarily require unanimous agreement. Instead, majority agreement could suffice. Or a threshold number of agreements could be specified. The threshold could correspond to a majority number, or some other specific number. Still further, the particular trust verifiers (or other retrievers, such as nodes) whose retrieved, signed HASHes are compared to test for identical values could be identified specifically or chosen at random. Other arrangements are possible as well.

[0140] A further example variation may involve implementing the verification actions of the nodes, such as those described by way of example above, in one or more miners of a blockchain network. In this way, even though processing by miners occurs only after the nodesMBHB Docket No. 24-0791-WO or trust verifiers have verified and validated a requested action for entry in a block, the miner could perform another check before expending time and effort mining. This could serve as an additional safeguard against hacking or corruption. Since such validation / verification may be part of blockchain operation, the system-level operations for transactions and / or smart contract of example embodiments here would be at least as secure and safe against hacking and corruption such operation, if not more.

[0141] In still further example variations, authority to compel an entry on the blockchain could be vested in an entity that may initiate procedures for creating an action-entry request 313, or the like, independently of any request made by a blockchain user. Each such request would still be subject to the case-by-case safeguards described above, but could originate directly from the entity.

[0142] In yet another example variation, node procedures may be modified to autonomously insert a prescribed set of special contingency actions in all smart contracts. These could be actions deemed to be mandatory for all smart contracts, and would provide the ability to subject all smart contract to these contingencies.

[0143] It will be appreciated that the operations and procedures illustrated in Figures 3, 4A, and 4B may be straightforwardly modified, adapted, and / or extended to correspond to any one or more to the example variations described above. That is, the particular form and contents of Figures 3, 4A, and 4B apply to just one example of operation of a system-level embodiment, and not intended to be limiting with respect to other possible embodiments. B. Example Operations

[0144] Example operations of a system-level implementation may be illustrated in a message flow diagram. An example of such a diagram is depicted in Figure 5. More particularly, the message flow diagram of Figure 5 depicts example operational sequence timelines of the various components and elements of an example system-level implementation example system shown in Figure 3 in the context of information (e.g., messages) that passes between them. The example message flow diagram may be considered as applying to the system-level implementation examples of both the transaction scenario and the smart contract scenario. The differences, again, being the content and format of: the requested-action input 301, the request specification, the enforcement action specification, and the action-entry request 313.

[0145] Each component of Figure 3 is represented by a labeled box at the top of Figure 5. A vertical timeline extends below each component, with time increasing downward. The timelines are not intended to convey or represent precise timing, but rather an ordering or sequence of operations. The operations are shown as horizontal directed arrows between pairsMBHB Docket No. 24-0791-WO of components, and labeled as “S<n>” followed by a description of the information passed between the components (and where <n> is a numeric label). Some operations are shown as self-directed arrows for operations that are carried out at one component, without necessarily involving passing information to another component. It should be understood that the particular sequences shown in Figure 5 represent one example of operational flow, and should not be taken as limiting or as excluding other sequences or sequence orders that may achieve the same results.

[0146] An example usage scenario may begin with a user providing input, such as the requested-action input 301 of Figure 3, to the off-chain request application 304 (the UI 304-I / F has been omitted from Figure 5 for the sake of clarity). At step S1, the off-chain request application 304 generates a HASH plus request specification and at step S2 it sends (e.g., transmits or provides) the HASH plus the request specification to the off-chain trusted- authority server 306. Assuming the request is granted (e.g., after evaluation by a judge, for example; this action not explicitly shown in the figure), the off-chain trusted-authority server 306 may at step S3 post or publish a HASH plus enforcement action specification to the published enforcement actions server 308. At step S4, the off-chain trusted-authority server 306 may send or provide a confirmation ID to the off-chain request application 304.

[0147] The off-chain request application 304 may then send (or provide) the HASH plus request specification to the off-chain transaction server 318 at step S5, and send (or provide) the confirmation ID to the event watcher 310 at step S6.

[0148] In response to receiving the confirmation ID, the event watcher 310 may separately notify each of the trust verifiers A, B, and C, 312-A, 312-B, and 312-C, in steps S7-A, S7-B, and S7-C, respectively. Each notification may also include (or be) the confirmation ID, or some other identifier suitable for retrieving information from the published enforcement actions server 308.

[0149] At steps S8-A, S8-B, and S8-C, the trust verifiers A, B, and C separately and independently interact with the published enforcement actions server 308 to separately and independently retrieve the HASH. The double arrows of these interactions represent possible two-way communications involved in this retrieval process.

[0150] At step S9-A, the trust verifier A signs the HASH with its private key, and at step S10-A, it sends (provides) the A-signed(HASH) to the verified request database 314 for recording or storage. Similarly, at step S9-B, the trust verifier B signs the HASH with its private key, and at step S10-B, it sends (provides) the B-signed(HASH) to the verified request database 314 for recording or storage; and at step S9-C, the trust verifier C signs the HASH with itsMBHB Docket No. 24-0791-WO private key, and at step S10-C, it sends (provides) the C-signed(HASH) to the verified request database 314 for recording or storage. Since the trust verifiers act independently, the sequence ordering shown should be considered just one possible example. In terms of processing logic, it may only be required that cryptographic signing of the HASH at step S9-<A,B,C> precedes sending the signed HASH to the verified request database 314 at step S10-<A,B,C>.

[0151] Step S11 represents polling activities of the request poller 316 and its communications with the off-chain transaction server 318. Within this context, the off-chain transaction server 318 may advise the request poller 316 to poll the verified request database 314 for the presence and / or availability of the signed HASHes. Thus, at steps S12 and S13 the request poller 316 may engage in this polling and eventually determine when the signed HASHes are available for retrieval from the verified request database 314.

[0152] At step S14, the off-chain transaction server 318 may retrieve the signed HASHes from the verified request database 314 in a “pull” action, for example. It may be noted that this differs somewhat from Figure 3, which suggests that the request poller 316 retrieves the signed HASHes and provides them to the off-chain transaction server 318. This illustrates an example the types of variations in processing that may be used to achieve the same or similar results.

[0153] At step S15, the off-chain transaction server 318 creates (or generates) the off- chain action-entry request, and at step S16 sends the request to the blockchain network 302. The nodes of the blockchain network 302 may process the request as described by way of example above in connection with Figures 4A and / or 4B.

[0154] Although the structure and contents of the off-chain action-entry request, and the modifications to the blockchain rules and node operations incorporate particular novel aspects of example embodiments of the system-level implementation that introduce many of the advantages and benefits of the system-level implementation, the operations described by way of example above in connection with creating an off-chain action-entry request and delivering it to the blockchain network facilitate the security and safeguards at least equal to, if not surpassing, that of conventional blockchain operations. And as noted, this is achieved without sacrificing the distributed and decentralized operational architecture of blockchain- based technologies.

[0155] As with Figures 3, 4A, and 4B, Figure 5 may be modified, adapted, and / or extended to any one or more to the example variations described above. That is, the particular form and contents of Figure 5 apply to just one example of the operation of a system-levelMBHB Docket No. 24-0791-WO embodiment. But the particular form and contents of Figure 5 are not intended to be limiting with respect to other possible embodiments. IV. Example Entry-Level Implementation

[0156] In accordance with example entry-level embodiments, the functionality of contingency actions of blockchain smart contracts may be extended to take direction to execute by off-chain trigger codes supplied by a trusted off-chain authority, and authenticated, verified and stored in a trusted and secure database known to and accessible by nodes of the blockchain. In particular, the capabilities introduced in accordance with example entry-level embodiments do not involve or require modifying node operations at a system level. Rather, the capabilities are introduced by “connecting” certain node operations to trusted database that serves as a sort of repository of trigger codes supplied by the trusted off-chain authority. Example entry-level embodiments put in place a set of procedures and protocols that safeguard the integrity and validity of the trigger codes in the repository, while at the same time leaving node operation unchanged, leaving the distributed and decentralized operating principles of the blockchain in place and undisturbed.

[0157] As described above, the conventional model of a blockchain transaction involves some form of digital token(s) and an owner of the token(s) that has the authority to use – or “transact with” – the digital token(s). A token may have some inherent value, or be imbued with value, by virtue of its usefulness in transactions. For example, digital tokens may be traded for real goods and services. Non-limiting examples of digital tokens in this context include digital currency and NFTs. While the term “token” accommodates a level of generality in describing transactions on a blockchain, the illustrations herein are described by way of example mostly in terms more specifically suggestive of value. Accordingly, in the remaining discussion the term “asset” is used instead of “token” as a sort of reminder of the usefulness in transactions. It should be understood, however, that there is no loss in generality by this particular choice of terminology.

[0158] Thus, an owner of an asset or assets that has the authority to use those assets in transactions on the blockchain. That is, these assets – referred to herein as “conventional” (digital) assets – may hold or represent useable value, such as for making purchase, but are not themselves associated with any functionality. In accordance with example embodiments, conventional digital assets may effectively be “converted” in a form that retains its value and adds particular functional capabilities associated with transactions. The converted assets may thus be used in transactions in the same way as their unconverted, conventional instantiations can, but they may also be subject to one or another set of specific actions that are callable onlyMBHB Docket No. 24-0791-WO by applying authenticated, validated, and verified trigger codes. Further, all instances of actual trigger codes must be generated on a case-by-case basis by the off-chain trusted authority, and be specific to a particular owner of the converted assets.

[0159] The conventional digital assets may be converted by “wrapping” the conventional assets in executable code that implements the desired functionality. Accordingly, the converted digital assets are referred to herein as “wrapper assets,” and the actions that wrapper assets are subject to are referred to herein as “wrapper actions.” Non-limiting examples of wrapper actions include transferring from the owner to a specific receiver (e.g., another user or another account), freezing, and unfreezing. In accordance with example embodiments, an owner of conventional assets may convert any portion of them to wrapper assets, and thereafter use them in transactions in the same way as conventional assets may be used. This, then, corresponds to a transaction scenario of the entry-level embodiment.

[0160] Similarly to wrapper assets, any contingency action of a smart contract may be constructed to be executed by a specific trigger code. In this case, a trigger code may specify a link to the smart contract, an identification of a particular contingency action, and possible parameters of the contingency action. As in the transaction scenario of the entry-level embodiment, the smart contract scenario of the entry-level embodiment, the trigger codes must be generated on a case-by-case basis by the off-chain trusted authority, but in this case, specific to a particular smart contract. This, then, corresponds to a smart contract of the entry-level embodiment.

[0161] For both the transaction scenario and the smart contract scenario, implementations of example of the entry-level embodiments involve components and procedures for ensuring safe and secure creation and storage of authenticated, validated, and verified trigger codes. Thus, example embodiments ensure that the flexible and versatile functionality introduced by wrapper digital assets and triggered smart contracts is protected from hacking and / or other forms of misuse or corruption.

[0162] An example implementation of an entry-level embodiment, referred to as an entry-level implementation, is described in more detail below. A. Example System Architecture and Technical Description

[0163] Figure 6 is a simplified block diagram showing an example arrangement of components of an entry-level implementation of authenticated off-chain modification of blockchain-based transactions, in accordance with example embodiments. The block diagram of Figure 6 may also be considered as depicting aspects of an operational architecture of the entry-level implementation. As shown, example embodiments can include various components,MBHB Docket No. 24-0791-WO any one or more of which may be implemented as or in one or more computing devices. As such, components depicted in Figure 6 may themselves be or include hardware, software, firmware, or combinations thereof. Some of the components may be identified structurally, such as databases or other forms of data storage and management, and others may be identified in terms of their operation or function. Operational and / or functional components could be implemented as software and / or hardware modules, for example, and may also be referred to as “modules” for the purpose of the present discussion.

[0164] The example entry-level implementation can also include one or more connection mechanisms that connect various components. By way of example, the connection mechanisms are depicted as arrows between components. The direction of an arrow may indicate a direction of information flow, though this interpretation should not be viewed as limiting. In this disclosure, the term “connection mechanism” means a mechanism that connects and facilitates communication between two or more components, devices, systems, or other entities. A connection mechanism can include a relatively simple mechanism, such as a cable or system bus, and / or a relatively complex mechanism, such as a packet-based communication network (e.g., the Internet). In some instances, a connection mechanism can include a non-tangible medium, such as in the case where the connection is at least partially wireless. A connection mechanism may also include programmed communication between software and / or hardware modules or applications, such as application program interfaces (APIs), for example. In this disclosure, a connection can be a direct connection or an indirect connection, the latter being a connection that passes through and / or traverses one or more entities, such as a router, switch, or other network device. Likewise, in this disclosure, communication (e.g., transmission or receipt of data) can be direct or indirect communication.

[0165] By way of example, various components and entities of the example system- level implementation of Figure 3 includes a blockchain network 602 having connected nodes 602-1, 602-2, …, 602-N, where ellipses in the connections to node 602-N indicate possibly additional connected nodes. Other example components and entities of the example system- level implementation include an off-chain request application 604 with a user interface (UI) 604-I / F, an off-chain trusted-authority server 606, a published enforcement actions server 608, an event watcher 610, trust verifier A 612-A, trust verifier B 612-B, trust verifier C 612-C, request verification server 614, verified request database 616, and trust verifier public keys 620. The ellipses following the trust verifier C 612-C indicate that there could be additional trust verifiers. In an example embodiment, the off-chain request application 604 could be anMBHB Docket No. 24-0791-WO application program configured for execution on a computing device, such as a PC, laptop, smartphone, or server, among other possible devices.

[0166] The computational and / or functional roles of the example components and entities may be understood by considering example operational scenarios involving transactions on the blockchain and smart contracts on the blockchain. Both types of scenarios involve similar, and in some respects the same, operations. However, in order to help keep the distinguishing aspects of the two scenarios clear, operational examples of the two scenarios are described separately below. 1. Example entry-level scenario for transactions on the blockchain

[0167] In the example transaction scenario of the entry-level embodiment, a sender of a wrapper digital asset to a receiver may seek to reverse the effect of a transaction that transferred the wrapper digital asset from the sender’s account to the receiver’s account. As in the system-level illustration, the sender may have been tricked or defrauded by the receiver, and thus may look to a judicial court for remediation. In the example transaction scenario of the entry-level embodiment, a remedial action may be ordered by the generation or creation of a trigger code associated with an appropriate contingency action of the wrapper digital asset. For the current example, the remedial contingency action may be a transfer of the wrapper digital asset from the receiver back to the sender. Thus, a trigger code might specify the receiver as the owner of the wrapper digital asset, a transfer action as the contingency action, and the original sender as the target of the requested transfer. This information may be provided as the requested-action input 601, for example.

[0168] Thus, the sender or a legal representative of the sender (e.g., a lawyer) may enter a requested-action input 601 at the UI 604-I / F. The requested-action input 601 may include information identifying the sender, the receiver, details about the original transfer from the sender to the receiver, the remedial action being requested, and particular information that provides and / or serves as evidence that the sender was tricked or defrauded into entering in the original transaction. In accordance with example embodiments, the UI 604-I / F may be or include an online form with drop-down menus or the like, for example, that prompt the sender (or other more generally a user) for specific information required to construct a formal request and provide the court with requisite information for evaluating and granting or denying the request.

[0169] The UI 604-I / F may provide the requested-action input 601 to the off-chain request application 604, which may then process the request for delivery to the judicial court. Thus, in accordance with example embodiments, the off-chain request application 604 mayMBHB Docket No. 24-0791-WO arrange and / or format all or certain specific items or elements of the requested-action input 601 into request specification, and may then generate a one-way hash of the request specification. As in the discussion of the system-level embodiment, the one-way hash of the request specification is labeled in all capital letters as the HASH. Also for purposes of discussion, the HASH and request specification may be considered together as a data entity referred to as HASH plus request specification 603. It should be understood that this grouping is for convenience in the operational description and need not necessarily be implemented in practice (although the grouping is not necessarily excluded either).

[0170] The HASH plus request specification 603 may then be provided to the off-chain trusted-authority server 606. In an example in which the trusted authority is a judicial court, the off-chain trusted-authority server 606 could be a server associated with the court and configured for receiving requests for compelling actions to be entered in a blockchain. For example, the off-chain trusted-authority server 606 may implement an API configured for receiving appropriately-formatted HASH plus request specification 603 messages or direct input. In other examples, the off-chain trusted-authority server 606 could be a more general server associated with the court and configured for receiving a variety of court / case-related input, including the off-chain trusted-authority server 606. Other arrangements are possible as well. In some examples, the HASH plus request specification 603 may be provided “manually” to a judicial court, together with supporting evidence for the request, by a legal representative of the sender, for example.

[0171] After the HASH plus request specification 303 is received by the off-chain trusted-authority server 606, an evaluation may be made as to whether or not to grant the requested action. Again considering the example in which the trusted authority is a judicial court, the evaluation may be made by a judge or other authorized representative of the court. This aspect may be the same as that described for the system-level embodiment.

[0172] Assuming a decision (e.g., by a person or by an algorithm) is made to grant the request, a HASH plus enforcement specification 605 may be posted or published to the published enforcement actions server 608. In the judicial example, the HASH plus enforcement specification 605 may be a human-readable electronic file that articulates the decision and includes an embedded alpha-numeric representation of the HASH. For example, the HASH plus enforcement specification 605 could be a PDF file digitally signed by the court. The published enforcement actions server 608 could be a publically-accessible server to which such decisions, among other forms of court business, are posted. In the example of a judicial court,MBHB Docket No. 24-0791-WO the published enforcement actions server 608 could be a server such as the PACER server, for example. However, other arrangements are possible as well.

[0173] Also with a decision to grant the request, the off-chain trusted-authority server 606 may provide or send (e.g., transmit) a confirmation ID 607 to the off-chain request application 604, which may serve to inform the off-chain request application 604 of the affirmative decision, and provide it with identifying information for accessing the now- published HASH plus enforcement specification 605 at the published enforcement actions server 608.

[0174] In accordance with example embodiments, after the off-chain request application 604 receives the confirmation ID 607, it may in turn send the confirmation ID 607 to the event watcher 610. Doing so may alert the event watcher 610 to the availability of the HASH plus enforcement specification 605 at the published enforcement actions server 608. The off-chain request application 604 may then also provide or send (e.g., transmit) the HASH plus request specification 603 to the request verification server 614 to make it, too, aware of the availability of the HASH plus enforcement specification 605 at the published enforcement actions server 608 and to initiate creation of a corresponding trigger code.

[0175] The event watcher 610, having been alerted with the confirmation ID, may then independently notify each of the trust verifiers A, B, and C, 612-A, 612-B, and 612-C, as well as any additional trust verifiers, as indicated in Figure 6. Each trust verifier could be a secure server or other networked secure computing system associated with a respective organization or institution, such as an established bank, brokerage, or network service provider, for example. Although not necessarily shown in the figure, the notification to each of the trust verifiers may also include the confirmation ID or other information enabling access to the HASH plus enforcement specification 605 at the published enforcement actions server 608.

[0176] Having been notified, each of the trust verifiers A, B, and C, 612-A, 612-B, and 612-C, as well as any additional trust verifiers, may then independently retrieve the HASH from the published enforcement actions server 608 over respective secure links. Each independent retrieval is shown with a label HASH 609 for purposes of the present discussion; again, the ellipses indicate additional retrievals of HASH 609 from additional trust verifiers. The trusted nature of the trust verifiers, together with secure retrieval, allows each trust verifier to independently vouch for the authenticity of the retrieved HASH 609. Each trust verifier may do this by encrypting its retrieved HASH 609 with a private cryptographic key that serves as well as an authenticating digital signature. Thus, the trust verifier A 612-A generates the A-Signed(HASH) 611-A; the trust verifier B 612-B generates the B-Signed(HASH) 611-B;MBHB Docket No. 24-0791-WO and the trust verifier C 612-C generates the C-Signed(HASH) 611-C. Each trust verifier may then provide (e.g., send or transmit) its respectively signed HASH in the request verification server 614. Additional signed HASHes may be provided to the request verification server 614, as indicated (once more) by the ellipses.

[0177] The request verification server 614 may then carry out operations to verify and validate the HASH and an authenticated, verified, and validated trigger code, and store it in the verification request database. At this point, the trigger code is available triggering an action associated with the request-action input 601. For this example, the trigger code, as noted above, might specify the receiver as the owner of the wrapper digital asset, a transfer action as the contingency action, and the original sender as the target of the requested transfer. In an example embodiment, a verified HASH 613 may serve as the trigger code, and validation and verification processing by the request verification server 614 may be considered validation and verification of the trigger code.

[0178] An example subsequent scenario is shown in a box enclosing the blockchain network 602 in the upper right of Figure 6. In a first step, labeled “1,” a request action is made by providing node 602-2 with a HASH plus action request 615. The HASH plus action request 615 may alert the node 602-2 to the presence and availability of a trigger code associated with the wrapper assets of the owner as specified in the action request. At a second step, labeled “2,” the node 602-2 may then pull the trigger code, which in this example is the verified HASH 613, from the verified request database. Since the database is trusted by the blockchain network 602, the node 602-2 may execute the contingency action associated with the trigger code. In this example, the action causes a transfer of some amount of wrapper assets from the owner to the original sender in the disputed transaction. Some or all of the node processing may be according to blockchain operation. Thus, the HASH plus action request 615 may propagate to all or some number of the nodes, and all that receive it may engage in the processing just described.

[0179] Figure 7A illustrates a representation of example processing the request verification server 614 of an entry-level action-entry for a transaction scenario, in accordance with example embodiments. As indicated in Figure 6, and again in Figure 7A, the request verification server 614 also receives the signed HASHes A-Signed(HASH) 611-A, B-Signed(HASH) 611-B, the C-Signed(HASH) 611-C (as well any additional signed HASHes, as indicated by the vertical ellipses). In the figure, an expanded but still simplified view of the HASH plus request specification 603-A is presented. By way of example, the expanded HASH plus request specification 603-A for the transaction scenario includes a request specification, an off-chain request indicator, and an action date. It should be understood that there could beMBHB Docket No. 24-0791-WO additional information included as well, and that the format of the request is conceptually representational, and does not necessarily correspond to that of an actual implementation.

[0180] Also by way of example, the request specification is shown as including an identity of an asset owner and a description of an action to be applied to the asset(s) of the owner; a receiver may optionally be supplied if the action is a transfer from the owner to the receiver, for example. Again, the asset in this case is a wrapper asset. An example action for a transfer of “X” from the owner to a receiver is illustrated. In this example request specification, it is assumed that the receiver previously transferred some portion of digital assets to the owner, and is now requesting X amount of that transfer to be returned via the requested action. As shown, the off-chain request indicator is set to “true.”

[0181] The action date is a parameter that may be used to set a future date / time at which to carry out the requested action. Stipulating a future date for carrying out the action may introduce a further safeguard against possible corruption or misuse of the entry-level procedures that produced the trigger code (verified HASH 613 in this example) and delivered it to the verified request database 614. For example, if an illegitimate request somehow gets validated and entered a trigger code, a built-in delay in carrying out the action provides time to discover and correct the error before the action takes effect. A future date may also enable any party to the requested action to dispute the authorization to implement the action. For example, if an action aims to reverse the effect of a transfer from a receiver to an owner by compelling a future reverse transfer, and the owner wishes to dispute the terms or evidence presented to a court that rendered the decision to grant the request for the reverse transaction, a built-in delay provides time for the owner to present a case to deny the request. Similarly, stipulating a future date may also be a necessary procedure for the trusted authority to act, such as the time to lodge an appeal of a court order. An action date could be specified as an amount of time past a particular date. By way of example, the amount of time could be 72 hours, seven days, or 30 days. Other amounts of time could be used.

[0182] As indicated in the box labeled “Notes,” the example action included in the request specification is non-limiting. Other non-limiting examples include freezing or unfreezing the owner’s access to X, transferring just a portion of X, and transferring X from the owner to an escrow account. Other actions may be possible as well. As also indicated in the Notes, the action date (or an actions date) could additionally or alternatively be included in the request specification. If additionally included in the request specification, a prescribed rule may be applied to determine which of multiple action dates takes precedence. Or multiple actionMBHB Docket No. 24-0791-WO dates could have different effects depending on whether they are included in, or place outside of, the request specification.

[0183] Example processing by the request verification server 614 is represented in a flow chart 700 shown beneath the request verification server 614. In accordance with example embodiments, the request verification server 614 may determine if it has received a required minimum number of signed HASHes. As explained above, requiring the inclusion of a minimum number of signed HASHes can significantly reduce the probability of a successful hack or corruption of the trust verifiers. As indicated, if the minimum number requirement is not met, the request is considered “bad” and processing may be aborted. Otherwise, processing continues.

[0184] In further accordance with example embodiments, if the minimum number requirement is satisfied (met), the request verification server 614 may then decrypt each signed HASH using the trust verifiers respective public keys 620, which are assumed to be known and / or available to the request verification server 614. For the example illustrated in Figures 6 and 7A, the decrypted HASHes are expressed, as shown, as: HASHA = Decrypt[A-Signed(HASH), A-Key] HASHB = Decrypt[B-Signed(HASH), B-Key] HASHC = Decrypt[C-Signed(HASH), C-Key], where A-Key is the public key of trust verifier A 612-A, and likewise for trust verifiers B and C, 612-B and 612-C. The vertical ellipses indicate similar decryptions of additional signed HASHes that may be carried out.

[0185] In accordance with example embodiments, the request verification server 614 may next test to ensure that all of the decrypted HASHes are identical. That is, a check that: HASHA= HASHB= HASHC. Requiring that all the HASHes are identical even further reduces the likelihood of a successful hack or corruption of any of the trust verifiers. This is because a successful hack of the HASH provided by any less than all of the trust verifiers would cause this test to fail, thereby exposing the hack. Only an identical hack of all of the trust verifiers might enable the test to pass. However, as noted, the minimum number requirement helps make this extremely unlikely, if not virtually impossible. As indicated, if the identical HASH test fails, the request is considered “bad” and processing may be aborted. Otherwise, processing continues.

[0186] In further accordance with example embodiments, if the identical HASH test passes (i.e., if all the decrypted HASHes are identical), the request verification server 614 may then take each identical decrypted value to be the true value of the HASH. Thus the requestMBHB Docket No. 24-0791-WO verification server 614 may assign the value of HASHA (or, equivalently, HASHB or HASHC, and so on) to a variable called, by way of example, “HASHis.”

[0187] In accordance with example embodiments, the request verification server 614 may next carry out its own computation of the one-way hash function applied to the request specification in HASH plus request specification 603-A in order to determine a “local” value of the HASH. This computation is the same one performed by the off-chain request application 604 that initiated the off-chain request, as described above. The computation may utilize any standard and / or known one-way hash function that meets a specified level of complexity. Non- limiting examples of such one-way hash functions include SHA-256, SHA-512, RIPEMD-320, and Whirlpool. As indicated in the flow chart 700, the local HASH is referred to as “ThisHASH.”

[0188] In further accordance with example embodiments, the request verification server 614 may then test that ThisHASH is identical to HASHis. That is, the locally-computed HASH is equal to the HASH provided independently by all of the trust verifiers. A successful outcome of this test now validates the request specification, since ThisHASH is verifiably derived from the request specification, and agrees with the HASH from each of the trust verifiers. As indicated, if ThisHASH does not equal HASHis, the request is considered “bad” and processing may be aborted. Otherwise, processing continues.

[0189] Finally, if ThisHASH is confirmed to be identical to HASHis, the request verification server 614 may store the verified HASH 613 in the verified request database 616. 2. Example entry-level scenario for smart contracts on the blockchain

[0190] In an example smart contract scenario, a smart contract may be constructed so that the contingency actions may be triggered by trigger codes stored in the verified request database or otherwise provided to the contract. The parties to a prior smart contract may, again, each be blockchain users, and the designated, trusted off-chain authority may, again, be a judicial court represented by individual judges. As in the system-level example, a simple example is considered in which the parties may be “user A” and “user B,” and the prior smart contract may apply an agreement of user A to supply a service to user B, and an agreement of user B to transfer money to user A upon delivery of the service. A first contingency action of the smart contract may be a notification that A has completed the service, and a second might be a transfer of funds from B to A. The designated caller of the first contingency action could be A, and the designated caller of the second contingency action could be B. In an example, after A calls the service-complete action, B may refuse to call the payment action, thereby refusing to pay A for the service. User A or a legal representative of user A (e.g., a lawyer) mayMBHB Docket No. 24-0791-WO then request that the court act as an authorized alias for user B to cause the second contingency action to execute.

[0191] More specifically to the example transaction scenario, the requested-action input 601 may include a link to the smart contract, and an identification of the contingency action requested, as well as any parameters of the contingency action that may be needed. All of the operations of the transaction scenario described above in connection with Figure 6 may then apply as well to the smart contract scenario. Besides the requested-action input 601, the primary differences relate to content (and possibly format) of the request specification, the enforcement action specification, and the contents of the greater generality of contingency actions that may be called (for example a variable for the amount or a finding of fact).

[0192] In this example smart contract scenario, a court would be asked to issue an order compelling the payment contingency action of the smart contract. Assuming the court agrees, the verification procedures described above for the transaction scenario would be carried out in the same way. The verified HASH 613 would be a trigger for the contingency action requested. The example subsequent action shown in the box in the upper right of Figure 6 applies in the smart contract scenario as well.

[0193] Figure 7B illustrates a representation of example processing the request verification server 614 of an entry-level action-entry for a transaction scenario, in accordance with example embodiments. The discussion of Figure 7A applies identically to Figure 7B, except that the specification request supplies different information. Specifically in the HASH plus specification request 603-B, the request specification for the example smart contract scenario is shown as including a link to the smart contract, and an identification of the contingency action, and (possibly optionally) parameters of the contingency action. Other information might be included as well, such as identification of one or more other parties to the smart contract, for example. An identity of an asset owner and a description of an action to be applied to the asset(s) of the owner, as well as a receiver, may optionally be supplied if the action is a transfer from the owner to the receiver, for example. 3. Example variations

[0194] There may be a number of additional and / or alternative aspects of implementing entry-level embodiments. Most are the same as in the system-level embodiment and so are not repeated again here.

[0195] It will be appreciated that the operations and procedures illustrated in Figures 6, 7A, and 7B may be straightforwardly modified, adapted, and / or extended to correspond to any one or more to the example variations previously described. That is, the particular form andMBHB Docket No. 24-0791-WO contents of Figures 6, 7A, and 7B apply to just one example of operation of an entry-level embodiment and not intended to be limiting with respect to other possible embodiments. B. Example Operations

[0196] Example operations of an entry-level implementation may be illustrated in a message flow diagram. An example message flow diagram for entry-level implementation is depicted in Figure 8. The format is the same as that described in connection with Figure 5, except that some of the components are different.

[0197] Each component of Figure 6 is represented by a labeled box at the top of Figure 8. As in Figure 5, a vertical timeline extends below each component, with time increasing downward. The timelines are not intended to convey or represent precise timing, but rather an ordering or sequence of operations. The operations are shown as horizontal directed arrows between pairs of components, and labeled as “T<n>” followed by a description of the information passed between the components (and where <n> is a numeric label). Some operations are shown as self-directed arrows for operations that are carried out at one component, without necessarily involving passing information to another component. It should be understood that the particular sequences shown in Figure 8 represent one example of operational flow, and should not be taken as limiting or as excluding other sequences or sequence orders that may achieve the same results.

[0198] An example usage scenario may begin with a user providing input, such as the requested-action input 601 of Figure 6, to the off-chain request application 604 (the UI 304-I / F has been omitted from Figure 8 for the sake of clarity). At step T1, the off-chain request application 604 generates a HASH plus request specification and at step T2 it sends (e.g., transmits or provides) the HASH plus the request specification to the off-chain trusted- authority server 606. Assuming the request is granted (e.g., after evaluation by a judge, for example; this action not explicitly shown in the figure), the off-chain trusted-authority server 606 may at step T3 post or publish a HASH plus enforcement action specification to the published enforcement actions server 608. At step T4, the off-chain trusted-authority server 606 may send or provide a confirmation ID to the off-chain request application 604.

[0199] The off-chain request application 604 may then send (or provide) the HASH plus request specification to the request verification server 614 at step T5, and send (or provide) the confirmation ID to the event watcher 610 at step T6.

[0200] In response to receiving the confirmation ID, the event watcher 610 may separately notify each of the trust verifiers A, B, and C, 612-A, 612-B, and 612-C, in steps T7-A, T7-B, and T7-C, respectively. Each notification may also include (or be) the confirmation ID,MBHB Docket No. 24-0791-WO or some other identifier suitable for retrieving information from the published enforcement actions server 608.

[0201] At steps T8-A, T8-B, and T8-C, the trust verifiers A, B, and C separately and independently interact with the published enforcement actions server 608 to separately and independently retrieve the HASH. The double arrows of these interactions represent possible two-way communications involved in this retrieval process.

[0202] At step T9-A, the trust verifier A signs the HASH with its private key, and at step T10-A, it sends (provides) the A-signed(HASH) to the request verification server 614 for recording or storage. Similarly, at step T9-B, the trust verifier B signs the HASH with its private key, and at step T10-B, it sends (provides) the B-signed(HASH) to the request verification server 614 for recording or storage; and at step T9-C, the trust verifier C signs the HASH with its private key, and at step T10-C, it sends (provides) the C-signed(HASH) to the request verification server 614 for recording or storage. Since the trust verifiers act independently, the sequence ordering shown should be considered just one possible example. In terms of processing logic, it may only be required that cryptographic signing of the HASH at step T9-<A,B,C> precedes sending the signed HASH to the request verification server 614 at step T10-<A,B,C>.

[0203] At step T11 the request verification server 614 may verify the HASH as described above. At step T12, the request verification server 614 may store the verified HASH as the verified trigger code in the verified request database 616.

[0204] An example subsequent scenario is shown in the dashed box in the lower right of Figure 8. As shown, the input HASH plus requested action is input to the blockchain network 602 as step T13. This could represent a user or a user’s legal representative submitting an entry to the blockchain that alerts it to the presence and availability of a trigger code in the verified request database 616. Then at step T14, one or more nodes of the blockchain pull the trigger code (verified HASH in this example) and act on it as described above.

[0205] As with Figures 6, 7A, and 7B, Figure 8 may be modified, adapted, and / or extended to correspond to any one or more to the example variations described above. That is, the particular form and contents of Figure 8 apply to just one example of operation of an entry- level embodiment. But the particular form and contents of Figure 8 are not intended to be limiting with respect to other possible embodiments.MBHB Docket No. 24-0791-WO V. Secure Retrieval of Off-Chain Data by Trusted Chain Entities

[0206] In the example operation of a system-level implementation discussed above in connection with Figures 3 and 5, and also described in the discussion in International Patent App. No. PCT / US22 / 20033 (which is incorporated herein by reference in its entirety), the published enforcement actions server 308 stores and posts a HASH plus enforcement action specification 305 that is subsequently retrieved by the trust verifiers 312-A, 312-B, and 312-C. The HASH plus enforcement action specification 305 is an example of off-chain data that may be used in blockchain operations, such as causing a transaction to be entered in the blockchain. The trust verifiers 312-A, 312-B, and 312-C serve as trusted retriever’s of the off-chain data, and their digital signatures, together with the consistency of the retrieved HASHes serve as verification that the off-chain data has been faithfully retrieved and stored in verified request database 314, from which it may then be retrieved for its intended use in or by the blockchain network 302. In this example implementation, the trust verifiers 312-A, 312-B, and 312-C may be considered off-chain trusted retrievers of off-chain data, in the sense that they may be entities that are deployed and / or operated independently of the blockchain network 302. For example, one or more of the trust verifiers 312-A, 312-B, and 312-C could be servers operated by trusted institutions or organizations, such as banks, brokerages, or other regulated entities. In some examples, one or more trust verifiers could be nodes of the blockchain network (though not necessarily miner nodes selected or assigned in the manner described by way of example below).

[0207] In accordance with example embodiments, an alternative form of trusted retrieval of off-chain data may be implemented that may be used to augment and / or replace off-chain trusted retrievers with one or more blockchain entities. In particular, a miner-based retrieval system may be used that maintains a requisite level of trust and authenticity of the retrievers and retrieval process. More specifically, retrieval may be allocated or assigned to the miner(s) chosen or assigned to write a block under a consensus-proof method used by the underlying blockchain (e.g., proof of work or proof of stake). In the proof of work model, allocating or assigning retrieval to each miner that solves a block, or effectively only to the miner whose solved block is found to have joined the longest chain after a given number of confirmations, ensures that the retrieval is at least as secure and authentic as the process of mining itself, and correspondingly, as secure as the underlying blockchain.

[0208] Accordingly, a system that allocates or assigns retrieval to the miner chosen to write the block advantageously presents a different risk profile than using off-chain retrievers or a plurality of randomly selected nodes (and in longest chain consensus, also accounts for theMBHB Docket No. 24-0791-WO unknown liveliness of any given node at any given time). Miners may be considered entities of a blockchain, and thus this miner-based retrieval may be considered secure retrieval of off- chain data by trusted chain entities. Example embodiments and usage scenarios are described in the following discussion. A. Example judicial retrieval process

[0209] The example operation of a system-level implementation discussed above in connection with Figures 3 and 5 may be referred to “judicial retrieval” to the extent that the off-chain data to be retrieved represents a judicial enforcement action that ultimately directs an action that causes an entry to be added to a blockchain. It may serve as an example of secure retrieval of off-chain data by trusted chain entities and is described below. It should be understood that operations illustrated by way of example are not limited to judicial enforcement or off-chain data that originates or derives from a court or judicial process.

[0210] In accordance with example embodiments, each miner that was chosen to write a block for the blockchain may subsequently be selected, allocated, or assigned to perform honest retrieval from an off-chain source of off-chain data, and as condition for secure and authenticated retrieval, may receive an award or, more generally, a conveyance. In an example blockchain, the award or conveyance source may sometimes be referred to as a “coinbase.” However, other forms of award or conveyance may be used. A miner may be chosen to write a block for the blockchain upon having successfully solved or “mined” the block. In accordance with example embodiments, being chosen or winning the right to write a block may thus be an indication to a miner that it has been allocated, selected, or assigned to perform a secure off- chain retrieval. In this sense, the indication may be considered as having been received by the miner, at least implicitly.

[0211] Retrieval may be repeated N times (where N is an integer) by N different miners such that the chances of a single entity or coalition controlling N miners (chosen serially) without gaining control of the blockchain network may effectively be zero. Any system for importing off-chain data that meets this requirement may be considered one for which the imported data is as trustworthy as the blockchain network itself.

[0212] The forgoing state may be defined by an equilibrium between the effort needed to compromise the retrieval process and the effort needed to compromise the blockchain network. Referred to herein as an “Equilibrium State” or “ES,” it may be defined as: Effort needed to control data maliciously equals Effort needed to control blockchain network maliciously.MBHB Docket No. 24-0791-WO

[0213] In the ES condition, adding off-chain data may not increase the attack surface of the blockchain network so there may be no added risk to any user. Further, in the ES condition, a malicious actor who has already sufficiently compromised a blockchain network can double spend or even create a malicious soft fork by overriding protocols or adding new ones to accomplish any transaction the malicious actor desires and then include them into the longest chain. In other words, the mischief that the malicious actor seeks to accomplish by falsifying the imported data can be accomplished by other means. Thus, any work employed to make an off-chain data retrieval process more secure than it already is by current protocols (e.g., requiring unanimity of the nodes) may be considered wasted because it exceeds the trustworthiness of the blockchain network itself.

[0214] Further, once a malicious actor controls the entire blockchain network, incentives change such that the best economic outcome for the actor will likely be to operate the blockchain network virtuously so as to maintain the value of the coins the malicious actor is earning.

[0215] The example judicial retrieval scenario described below illustrates just one of multiple possible methods for using ES to secure retrieval of off-chain data. Additional methods and / or extensions to the examples herein will be readily apparent to those skilled in the art.

[0216] In the example of judicial retrieval, for each retrieval, a miner may access a specified database (which could be another distributed ledger), look at a text-processed file (e.g., PDF file) from the docket entry, and find a hash of the entry. In the example of Figure 3, the specified database may be the published enforcement actions server 308, and the docket entry may be the HASH plus enforcement action specification 305, where the hash of the entry is the HASH. In this retrieval example, the HASH may be referred to herein as a “first hash” or “Hash 1.” The miner may then apply a hash function to the entry to generate a second hash, referred to herein as a “second hash” or “Hash 2.” The miner may then write Hash 1 and Hash 2 to a database (which could be the network’s decentralized ledger, another network’s decentralized ledger, or a mempool). In accordance with example embodiments, the database to which the miner writes Hash 1 and Hash 2 may be a smart contract.

[0217] A blockchain network may have associated dynamic data storage, such as a queue, configured for holding data entries related to blockchain operations. Such a queue is commonly referred to as a “memory pool” or “mempool.” In example operations, a mempool may hold entries corresponding to pending transactions. A blockchain node may access the mempool from time to time, thereby discovering transactions that need to be entered in a newMBHB Docket No. 24-0791-WO block. If the entry representing such a transaction includes an appropriate form of authentication or verification, the node may then proceed with entering the transaction, otherwise, the node may decline to enter the transaction.

[0218] In the example of judicial retrieval, the mempool may include judicial transactions that are not initially verified. A judicial transaction may thus “sit” in the mempool unless and until N serially-signed entries have been written to a database or other storage location (which may include adding the signatures to the mempool transactions). In an example, the storage location may be a smart contract for the given docket entry. In accordance with example embodiments, a transaction in the mempool may be verified by an off-chain retrieval carried out by a threshold number of miners. In some examples, the threshold could be just one. However, a larger number N > 1 may help ensure enhanced security, such as that afforded by the ES condition. Thus, a transaction in the mempool may only be approved if signatures 1 though N contain the same Hash 1 and Hash 2. If any one of the N entries disagrees with the others, the transaction may be rejected because there is insufficient basis to conclude that the malicious actor has achieved ES (in other words the malicious actor effectively controls the blockchain network).

[0219] In judicial retrieval, or similarly modeled retrieval, the off-chain data may correspond to data used by a miner or miners to authenticate or validate a transaction in the mempool. That is, each miner’s digitally signed Hash 1 + Hash 2 may be considered a secure verification that an associated transaction in the mempool may be picked up by a node and entered into a new block of the blockchain. By requiring a threshold number (e.g., N) of such verifications, the retrieval process is thereby made at least as secure as the underlying blockchain, because it uses the same consensus protocols that ensure validity of the blockchain.

[0220] In some usage scenarios, off-chain data may include target content instead of, or in addition to, a hash or other authentication of the off-chain data at the data source. In such usage scenarios, a miner performing secure retrieval may retrieve the actual target content and deliver it to the mempool (or other storage), possibly in addition to any hash associated with the target content at the data source. The miner may then also provide a verification that it securely retrieved the target content. For example, the miner could apply a hash function to the target content at the off-chain data source, thereby generating a “source hash.” The miner may similarly generate a “destination hash” of the target content from the delivered target content at the mempool. The miner could then digitally sign a verification that the source and target hashes are identical.MBHB Docket No. 24-0791-WO

[0221] In accordance with example embodiments, each given miner’s entitlement to the coinbase for solving a block, possibly as well as for having been selected for writing the solved block to the blockchain, may be made contingent on the given miner’s participation in secure off-chain data retrieval. In particular, a blockchain network may maintain a retrieval- request queue of entries indicating off-chain data that needs to be retrieved. Upon solving a block and writing it to the blockchain, retrieval-based contingency of a coinbase award may incent a miner to examine the retrieval-request queue to determine if there are any outstanding requests. The miner may then be entitled to receive its coinbase conveyance upon demonstrating that it checked the queue, and if a request for off-chain retrieval was found, serviced the request according to one or more of the procedures described herein. The process of a miner checking the queue and retrieving data if a request found may be referred to as “allocating retrieval.” In this sense, allocation may also be considered selection or assignment.

[0222] In further accordance with example embodiments, when off-chain data with verification that it was securely retrieved by a given miner is found in the mempool (or other database) by a node undertaking to write a new block for the blockchain, the node may include an entry associated with the verified off-chain data in the new block. In the example of a verified judicial action, the node may enter a transaction or other specified entry according to the verified judicial action. The node may also take the presence of the verified judicial action (or other form of verified off-chain data) in the mempool as confirmation that the miner node carried out the secure retrieval task, and is therefore entitled to the coinbase conveyance. The node may therefore enter a pending transaction for the conveyance in the mempool, which may subsequently be included in a future block. In this way, the miner node may receive its conveyance for both solving the block, having the block written, and thereafter performing secure retrieval. In the event that the miner node, having been allocated a secure retrieval, found nothing to retrieve in a queue of retrieval requests, the miner node may provide some other form of proof that it did check the queue, and thus is still entitled to the conveyance for having at least solved the block, and having been chosen to write the block. For example, the retrieval request queue may include a known null entry that can be retrieved by miners as proof of having checked the queue and found it empty. Other forms of proof may be used as well.

[0223] There may be practical engineering considerations with allocating the retrieval process to unknown miners. Miners may retrieve a docket entry (e.g., verification according to Hash 1 and Hash 2) as a condition of being awarded from the coinbase. However, it might happen that a miner may have an incentive to get its coinbase by falsely claiming that it checked the docket and that the docket entry did not exist, when in fact it did not check. Any miner thatMBHB Docket No. 24-0791-WO followed such actions might conceivably get its coinbase without a pending judicial transaction going through.

[0224] In one approach to avoiding this situation, miners could be penalized for disagreeing with the majority on Hash 1. However this could be unfair, as the reporting majority might be the compromised nodes. Alternatively, the miners might not be penalized for disagreeing on Hash 1, so they would still get the coinbase. However, miners may be denied their coinbase if: (1) they fail to sign a smart contract indicating their verification at all (i.e., did not participate); (2) agree with the majority on Hash 1 but disagree with the majority of N on Hash 2 (i.e., tried to fake a retrieval); or (3) claim there is no docket entry when the majority of N report that there is a docket entry and agree on Hash 2.

[0225] Additionally or alternatively, a miner that claims the docket entry is empty could be required to give proof that it checked the docket entry by returning a hash of the page that an electronic docket generates when that search returns no answer. In another example non- miner retriever or retrievers may check the docket to see if they find a docket entry and write the result to the smart contract or database. One probably suffices since there is nothing to gain by hacking it. If the non-miner retriever is hacked and falsely reports seeing the docket entry when there is none then (a) the honest miners do not get paid, and (b) the transaction does not go through – i.e., the malicious actor achieved nothing for itself. If the non-miner retriever is hacked and falsely reports not seeing the docket entry when there is an entry then (a) the honest miners do not get paid and (b) the transaction does not go through – i.e., the malicious actor again achieved nothing for itself.

[0226] Another step for insuring that the miner did the work may involve the controller generating a transaction and inserting a special public key. The special public key may be generated by going to a judicial interface, downloading a text-processed (e.g., PDF) document, hashing the entire document, then deriving the public key from the associated hash (i.e., the hash is the private key). The special public key may then be added to the transaction payload, and submitted to the node. The miner may download the text-processed document, hash it, and then sign the hash using the special private key. Each full node may then be able to verify that the miner signature matches, check that the public address of the signature matches coinbase, and that the signed content (private key - i.e. the hash of the text-processed document) is an asymmetric cryptography pair of the public key that’s in the transaction payload. B. Other forms of secure off-chain retrieval

[0227] The example secure off-chain retrieval process illustrated above for the usage scenario of judicial docket retrieval case to the retrieval may be extended to any form of off-MBHB Docket No. 24-0791-WO chain digital data. Examples of such extensions are discussed below. The embodiments of these extensions may be combined with any of the features of International Patent App. No. PCT / US23 / 18635 (which is incorporated herein by reference in its entirety). 1. Miner-driven oracle function

[0228] In the context of blockchain networks, an entity that conveys data from a source location to a destination location (which may include verifying the fidelity of a data transfer, thereby ensuring that the source and destination copies of the data are identical and unchanged by the transfer) may be referred to as an “oracle” when the entity is the source of the data, or as a “witness,” when the entity is retrieving data from one location and delivering it to another. The term “oracle” is used herein to cover both of these functions. Example embodiments herein of miner-based secure off-chain retrieval may thus be considered a form of miner-driven oracle function. As described above, one aspect of the security afforded by this approach is the ES condition. Miner-driven oracle function is described in additional detail in the following.

[0229] Many decentralized networks may offer a feature of running computer code in a virtual machine or similar environment that is executed by the network nodes. These programs are sometimes referred to as smart contracts (note that use of off-chain data is not limited to smart contracts).

[0230] A feature of smart contracts is their ability to alter their operation based on data inputs. For example, a smart contract may be written to escrow a digital asset posted as collateral for a debt. The contract could release the digital asset to the lender if the price of the asset falls to a certain predetermined level. Such a contract may use data about the trading price of the underlying asset to know if the condition for release to the lender has been satisfied.

[0231] Generally, the data used by smart contracts may be considered as falling into two categories: blockchain native and off-chain. The trading price of a digital asset is an example of blockchain native data, as the data can be derived from other trading taking place on the blockchain network. Off-chain data may be any other form of data that is not generated on the blockchain, such as weather data, GPS location data, the results of sporting events, elections, etc. For example, a smart contract may be written to escrow payment for a shipment of widgets until the shipping container arrives at port. Such a contract could need to know the GPS location of the container. However, the GPS data is not blockchain native and, therefore, should and frequently will be brought on-chain.

[0232] One typical method for importing off-chain data is through an oracle, which may be considered a trusted source of the information. As described in general terms above, oracles may act conduits from a data source to a blockchain, gathering the data and then writingMBHB Docket No. 24-0791-WO it to the chain (directly or to a database used by another oracle). However, off-chain oracles may be susceptible to malicious actors. Therefore, the data may generally be bonded such that oracles stake assets and these can be partially or completely forfeited in the event the oracle supplies inaccurate information.

[0233] The secure off-chain retrieval process described above by way of example provides a new method of making off-chain data useable by decentralized networks. Network nodes can include software to allow them to directly access any off-chain data. For example, the nodes could be programed to directly access a database. Similarly, node operators can use the private key associated with their node to operate a separate software package.

[0234] Once the nodes are able to access this or other information, the network could make use of it in several ways. First, one or more nodes could retrieve the information and write it to the blockchain in similar fashion to the oracle. One advantage of using the blockchain network’s nodes for this function instead of off-chain oracles is that the data can be secured using the ES condition instead of the staking and slashing method. Depending upon the needs, retrieval could require a unanimity of nodes or a plurality of nodes (including a single node) selected so as to ensure the reliability of the data against malicious actors, such as a random method, the ES condition, or other method.

[0235] In situations where speed is not necessarily a primary consideration, the blockchain network could use serial retrieval by the block-writing nodes, discussed above, to achieve ES. Alternatively, the blockchain network could use a random selection method to choose among nodes to retrieve the data. Depending upon the number of active nodes in the blockchain network agreement among relatively few nodes could demonstrate the ES condition, or a given percentage of the ES condition, to a high degree of certainty. 2. Direct interaction with off-chain data by miners

[0236] In an alternative approach, a node may use off-chain data as a direct input. For example, a condition could be specified for a given transaction such that confirmation of the transaction requires each node to directly check the off-chain data. In smart contracting blockchain platforms, the conditions can be added via the native programming language, while in others (such as Bitcoin), a scripting language or some other set of programmatic instructions could be added to require such a condition. Additionally, blockchains could include layer-1 protocols that allow the use of this data by the network node itself, such as by accepting an unsigned transaction as valid or by altering its default rules or operations in response to the off- chain data.MBHB Docket No. 24-0791-WO

[0237] Such a method may be useful, inter alia, where there is no oracle service for the data (e.g., propriety, classified or other non-public data) or where a user does not wish to trust oracles. In an example usage scenario, a government database may be checked to confirm that a sending or receiving public key is not associated with a person or entity on a list of sanctioned otherwise controlled entities or sources (e.g., an Office of Foreign Assets Control list). In that case, each node may separately access the off-chain data source as part of the transaction confirmation process.

[0238] Another example use could be an ability to access a database about the status of the blockchain network itself (e.g., a Network Status Database, such as that discussed below). Any useful data could be included, such as the number of nodes awake, their respective IP addresses, their respective public keys, the IP addresses of the nodes to which they are then connected, the public key of each node that solves a block as it solves the block, the transactions that a block-solving node has chosen to include in that block, which nodes have accepted that block, etc. Such a database could be constructed by nodes self-reporting the data and would in turn be accessible by each node.

[0239] A Network Status Database could allow the nodes in a decentralized network to directly observe the present state of the network itself. Access to such data could provide a host of advantages such as dynamically altering the consensus method to optimize among trade-offs and informing system users of valuable data with which to assess transaction certainty and finality.

[0240] Additionally, the existence of such a database could allow use of a serial observation method of achieving ES without requiring the block-writing nodes to write the retrieved data to a smart contract. Rather, block-writing nodes could serially sign a transaction formulated as a multi-signature transaction. Confirmation of the signatures could be accomplished by reference to the Network Status Database to check that the signature is from nodes that serially reported solving a block. 3. Allowing miners that have successfully mined a recent block to retrieve and verify off-chain data

[0241] Some of the embodiments described above may be implemented by placing off- chain data (e.g., representations of state involving one or more parties or a transaction between two or more parties) in the mempool (or some other form of storage) for a blockchain. Then miners that successfully mine a block of the blockchain subsequent to this placement are trusted to independently obtain a copy of the off-chain data (e.g., from a network address) and (if this retrieval is successful) verify the trustworthiness of the off-chain data. This may involve theMBHB Docket No. 24-0791-WO miner signing a copy of the off-chain data or some other representation thereof (e.g., a hash of the off-chain data) with its private key and storing the digital signature in the mempool or another database or storage location. Once a threshold number of miners (e.g., N of M totalminers where 0<N M) have performed such a verification of the off-chain data, the off-chaindata is considered to be “trusted” sufficiently for it to be added to the blockchain. Then, one or more nodes of the blockchain may obtain the verified off-chain data from the mempool (possibly with copies of the verifying digital signatures of one or more miners) and place it in a transaction of a block that is then added to the blockchain. Notably, the variables N and M may be measured in terms of overall hashing power of the miners (e.g., number of hashes that the miners can calculate per second) rather than a count of the miners. Notably, multiple variations of this embodiment are contemplated above and therefore this summary should not be viewed as limiting.

[0242] While the forgoing embodiment solves problems relating to trustworthiness of off-chain data, it does so by requiring consensus among nodes prospectively selected to write blocks using the network’s selection protocol. This interjects a delay in the ability to trust retrieved data. For blockchains with a slow average block times it may take a relatively large amount of time (e.g., hours or days) for the off-chain data to be considered “trusted” and added to the blockchain.

[0243] In order to make this process faster and more efficient without sacrificing security, it can be expanded to also or exclusively include miners that have recently mined a block of the blockchain successfully. Here, “recently” may mean that a miner has mined a block within the last 1 minute, 10 minutes, hour, 6 hours, day, etc. Alternatively, “recently” may mean that the miner has successfully mined one of the k most-recently mined blocks, where k could be between 1 and n, for example between 1 and 100. A combination of these definitions may also be used, for example, a recently-mined block might be considered a block that has been mined within the last hour and was one of the last 10 mined. Other factors may be considered as well such as another representation of the trustworthiness of the miner, for example. Other configurations can be used as well, such as immediate retrieval by an independent oracle with a cross check by selected miners.

[0244] Accordingly, off-chain data may be verified by a number of miners. A count may be made of these verifying miners that also qualify as recently mining a block successfully. If the count meets the threshold number, the data may be considered to be verified, allowing a block containing the data to be written to the blockchain by a miner or added to a given node’s version of the ledger. If the count does not meet the threshold, then miners that subsequentlyMBHB Docket No. 24-0791-WO mine blocks successfully may also verify the off-chain data as discussed above until the threshold is met.

[0245] Following this procedure of trusting previously-successful miners reduces the amount of time that the off-chain data needs to remain in the mempool, which can for example free memory faster for other transactions and facilitate the addition of blocks to the blockchain faster and in a timelier fashion. Also, this allows the verification of off-chain data to occur more rapidly on blockchains with fewer miners and / or lower block times. Other technical advantages may be present as well. 4. Equilibrium state flexibility

[0246] Whether considering successful miners of previous blocks, subsequent blocks, or both, setting the threshold number of miners to the proper value makes the trustworthiness of this technique approach the trustworthiness of the blockchain itself. This Equilibrium State, as discussed above, may not be required in all situations. For example, a blockchain might be configured so that only a threshold of j successful miners, where j<N, are required. In some cases, this lower level of certainty may be a calculated factor on the part of the users of the blockchain or otherwise deemed acceptable. The value of j may be specified in a number of miners or based on a percentage of certainty that the blockchain is not corrupted (e.g., 30%, 50%, 70%, 90%).

[0247] In some cases, j is small enough such that j miners could conspire to subvert the blockchain (e.g., in a double-spend attack). Nonetheless, the users of the blockchain may agree to accept this potential risk, given the advantages of doing so. Notably, this lower level of trust allows the verification of off-chain data to occur faster on blockchains with even fewer miners and / or even a lower block time than previous embodiments. 5. Trusting miners of an extrinsic blockchain

[0248] In another alternative embodiment, miners of an extrinsic blockchain network may be used to verify off-chain data. This can be data from any source, including a third-party blockchain. For example, miners of blockchain network B (e.g., that are not also miners of blockchain network A) can be used to verify off-chain data before that off-chain data is added to blockchain A. Advantageously, this allows use of established miners of established blockchains (e.g., Bitcoin, Solana, or Ethereum) to boost the verification power of a blockchain that has less miners and / or less overall mining capacity (e.g., a lower hash rate). For example, a new blockchain could bootstrap its verification abilities by relying on miners of the Bitcoin blockchain, or a subset thereof). The established blockchains are generally believed to beMBHB Docket No. 24-0791-WO secure and reliable as it would be exceptionally expensive computationally for one or more parties to conspire to subvert such a blockchain.

[0249] This can be thought of as the miners of blockchain B digitally signing a representation that the off-chain data at location C (e.g., the mempool of blockchain A) can also be observed at location D (e.g., published enforcement actions server 308). Thus, this technique can supply verification to any entity that desires the security of multiple independent observations and which wants to leverage the proof of work or stake performed by a blockchain network. This technique is not limited to retrieving data for use with a blockchain and may also be used with other types of networks, e.g., to provide assurance to the recipient of a file that the file has not been corrupted in transit over the internet. Put another way, this technique could be used for the independent verification of a “fact” or of the trustworthiness of data, as well as for certifying the retrieval of data.

[0250] Here, the miners of blockchain B may be selected based on how recently they have successfully mined a block for blockchain B. For example, only miners that have successfully mined one of the most recent 100, 500, or 1000 blocks of Bitcoin may be considered or may be weighted more favorably. The identity of these miners can be established by having them digitally sign a copy of the off-chain data (or any representation thereof such as a hash) with their respective private key (confirming that they are one of the most recent successful miners and using their associated public key to verify the signature of the off-chain data). In some cases, only miners or groups of miners that have successfully mined a number of contiguous blocks of blockchain B (e.g., 2, 3, 5, 10) may be selected. 6. Reporting state and messaging between blockchains

[0251] The off-chain data retrieval described in the embodiments above extends not only to retrieving static data but also to reporting data, such as state, from one blockchain to another (e.g., cross-blockchain messaging). Doing so can also serve as the basis for messaging and / or moving state (e.g., assets) from one blockchain to another.

[0252] For example, a user may rely on two sets of blockchain miners as a “bridge” between two blockchains. When a user wants to move state (e.g., a unit of data) from blockchain A to blockchain B, the user may lock state on A, e.g., place the state in a smart contract on blockchain A. The miners of blockchain A then inform / confirm to a smart contract on blockchain B that the state is locked on blockchain A so that that the smart contract on blockchain B issues a new (“wrapped”) state on blockchain B. When the wrapped state is returned to the smart contract on blockchain B (i.e., redeemed) then the miners of blockchain B are used to retrieve that information for the smart contract on blockchain A. AlternativeMBHB Docket No. 24-0791-WO bridge configurations could have blockchain B miners supplying the information to the blockchain B smart contract (and vice versa) or both sets of miners confirming the information for both smart contracts. 7. Merge-mining enhancements

[0253] These embodiments could also enhance of replace merge-mining, also known as auxiliary proof-of-work (AuxPoW). It is a process where miners can simultaneously mine blocks of two different blockchains without the need for additional computational power. This technique allows adding blocks to blockchain A based on reusing the work done for mining blocks of blockchain B. For example, a miner engages in mining a block for blockchain B. Once a solution to that block is found, the solution can be submitted to both the blockchain B and blockchain A if it meets their respective difficulty requirements. This creates a scenario where the hashing power of blockchain B is effectively leveraged to mine for blockchain A, providing benefits such as enhanced security and reduced energy consumption for blockchain A.

[0254] To that point, successful miners of blockchain B could be used as a basis for maintaining an entirely separate blockchain (e.g., blockchain A) or state machine such that the successful miners from blockchain B have the right to add a new block to blockchain A simply by signing that block on blockchain A. This could be useful, for example, to create a layer 2 to blockchain B that is as secure as the layer 1. To propagate a new block on layer 2, a successful miner or sufficient set of successful miners would have to sign the new block. Once a sufficient number of signatures is added, the layer 2 protocol would accept the block as valid and the layer 2 nodes would add it to their copies of blockchain A. VI. Blockchain Network Status Database

[0255] Example operations for secure retrieval of off-chain data described above may involve blockchain nodes and / or miner both sending and receiving data off chain. These activities, as well as others carried out by network nodes in support of a blockchain, may be viewed as providing a sort of snapshot of the state of the blockchain. Accordingly, a Blockchain Network Status Database may be constructed for recording node activity, as well as other information about a blockchain that may enable any node authorized to access and / or view the Network Status Database to obtain useful (and possibly vital) information about the blockchain, and to adjust or adapt its operations in relation to the blockchain.

[0256] In accordance with example embodiments, a Blockchain Network Status Database may thus be configured for enabling nodes to report information about their activity. In further accordance with example embodiments, the Blockchain Network Status DatabaseMBHB Docket No. 24-0791-WO may be configured for also enabling nodes to access the database to obtain useful information about the present status of the blockchain network.

[0257] Conventional blockchain consensus protocols offer competing methods for creating a shared view of truth, while protecting that shared view from malicious actors. Each protocol attempts to optimize for a given set of circumstances and, in doing so, makes tradeoffs.

[0258] For example, under Nakamoto-type Longest Chain Consensus (LCC), the network can operate under conditions of low participation (e.g., nodes can come and go and so are not always online). A ledger maintained in a blockchain may be considered safe from malicious actors so long as fewer than 50% of the nodes participating at any given time are malicious. When additional nodes come online, they join the longest chain and accept the view of truth that has been created by the majority of active nodes in their absence.

[0259] A trade-off for LCC is that settlement is only probabilistic. Transactions lack finality because the network may temporarily partition into one or more separate branches. A transaction could be accepted by the parties to it before that partition was resolved by a majority of nodes perceiving a longest chain. Transactions on the rejected chain could become invalid.

[0260] Advantageously, a Blockchain Network Status Database could be configured to track which nodes have accepted which blocks and which transactions. Thus a blockchain network user could understand in real time whether a network partition has formed and, if so, the status of that user’s transaction. In this way, a node that becomes active – e.g., comes online – following a period of inactivity may consult the Blockchain Network Status Database and thereby obtain a current status of the blockchain, as well as a record of activity that occurred during the node’s absences (inactivity period).

[0261] Similarly, the blockchain network nodes could understand in real time how many other nodes are awake, whether a partition has formed, and where they are in it. This may allow the nodes to optimize block acceptance and achieve consensus more quickly.

[0262] Further, with a real time record of awake nodes, tasks can be allocated among nodes in ways that would not otherwise be impossible. For example, considering again the judicial docket retrieval usage scenario, a random selection procedure could be used to assign to awake nodes a task of retrieving a block. This could thus be an alternative serial observation by nodes that won the block. Practical certainty about the ES state could thus be reached far more quickly than by awaiting serial block production to choose the retrieving node.

[0263] In accordance with example embodiments, a server hosting or associated with a Blockchain Network Status Database may be configured to make a random selection among nodes reporting awakeness, as determined from the Status Database, and thereby assignMBHB Docket No. 24-0791-WO retrieval tasks via on-chain or off-chain messaging. Alternatively, a protocol could include a random selection method based on information reported by the Status Database. Further, other awake nodes could query the database to determine which nodes were randomly selected and their public keys to ensure that a judicial transaction within the mempool (or judicial docket retrieval reported to a database) has been properly signed.

[0264] In further accordance with example embodiments, a Blockchain Network Status Database may be used for recording activity of miners’ performance of secure off-chain retrievals. For example, a miner’s proof of having carried out a secure off-chain retrieval following allocation or assignment of the miner of the retrieval task may be recorded in the Status Database. By checking the Status Database for such proof, a node may thereby verify that the miner is entitled to its conveyance.

[0265] In some embodiments, a Blockchain Network Status Database may be implemented as an off-chain data source, and the records of the Status Database may be considered off-chain data. In such embodiments, read and / or write access by nodes to the Blockchain Network Status Database may be mediated or moderated by a secure off-chain retrieval procedure, such as the miner-based retrieval method described above. For example, a node may obtain a record from the Status Database by entering a request for secure retrieval of the record in a retrieval request queue, and thereafter wait for the record to be securely retrieved by a miner and placed in the mempool or other blockchain network storage location directly accessible to the node. Similarly, a node may write a record to the Status Database by entering the record in an accessible blockchain storage location, such as the mempool, that may be checked by miners allocated to perform a secure write to the Status Database. Thereafter, a miner may pick up the record and securely deliver and write it to the Status Database, following a procedure largely the inverse of the secure retrieval procedure described above. In this way, the Status Database may be made secure by virtue of read and / or write operations being allocated to miners of a blockchain network.

[0266] In accordance with example embodiments, a Blockchain Network Status Database may be configured to be a reliable source of truth. This may help ensure that the Status Database can be used dynamically. Two aspects may ensure the requisite reliability. A first aspect is implementing the database in a manner that makes it secure from malicious actors. Security can avoid and / or mitigate circumstances in which data used by nodes to adjust their consensus assumptions may be vulnerable or exposed to malicious corruption that might otherwise be used to manipulate the consensus process. An example would be to have the Status Database operate as its own distributed network.MBHB Docket No. 24-0791-WO

[0267] As a second, the nodes may be configured to reliably report their view of the state of the blockchain network. For example, each node could notify the database when it comes online but would also provide continuous proof of awakeness. This could avoid unreliability of assuming nodes remain online until they report going offline. In accordance with example embodiments, nodes may be required and / or configured to periodically report reconfirmation of awakeness. Such a proof method may include a procedure for preventing spoofing. For example, nodes may be required and / or configured to report the present state of a rapidly changing but mutually viewable fact, such as a random number generated and posted to a mutually accessible site. VII. Example Methods

[0268] Figures 9, 10, and 11 are flow charts illustrating respective example methods 900, 1000, and 1100 of one or more example embodiments. The methods illustrated by Figures 9, 10, and 11 may be carried out by a computing system or computing device configured for operating as a node of a network of nodes operating a blockchain or by an off- chain entity or system. Non-limiting examples of the computing system computing system or computing device include computing device 100 or server cluster 204, for example. However, the methods can be carried out by other types of devices or device subsystems. For example, the methods could be carried out by a portable computer, such as a laptop or a tablet device.

[0269] Step 902 of method 900 may involve receiving, by a computing device, verifications that a plurality of miners of a first backward-immutable distributed storage system have respectively obtained a unit of data from an entity that is not part of the first backward- immutable distributed storage system.

[0270] Step 904 may involve making, by the computing device, a first determination of a count related to the plurality of miners and a predetermined threshold.

[0271] Step 906 may involve making, by the computing device, a second determination that each of the plurality of miners has recently mined a respective block of the first backward- immutable distributed storage system with success, wherein recently mining the respective block includes one or more of: previously mining the respective block within j seconds from a current time, or previously mining one of k most-recently mined blocks.

[0272] Step 908 may involve, based on the first determination and the second determination, submitting, by the computing device, an entry for block processing to be added to the first backward-immutable distributed storage system or a second backward-immutable distributed storage system.MBHB Docket No. 24-0791-WO

[0273] In some embodiments, the first determination is that the count related to the plurality of miners exceeds the predetermined threshold.

[0274] In some embodiments, the first determination is that the count related to the plurality of miners does not exceed the predetermined threshold, the computer-implemented method further comprising: waiting until a further plurality of miners of the first backward- immutable distributed storage system have respectively obtained the unit of data, wherein a sum of the count and a further count related to the further plurality of miners exceeds the predetermined threshold, wherein submitting the entry for block processing is also based on the sum of the count and the further count exceeding the predetermined threshold.

[0275] In some embodiments, the predetermined threshold is based on a total number of miners of the first backward-immutable distributed storage system.

[0276] In some embodiments, the predetermined threshold is based on a total hashing power of miners of the first backward-immutable distributed storage system.

[0277] In some embodiments, the predetermined threshold is based on a probability that the plurality of miners are unable to collectively conspire to corrupt the first backward- immutable distributed storage system.

[0278] In some embodiments, the unit of data comprises a hash value retrieved from a file, a database, or another cryptographically-immutable distributed storage system.

[0279] In some embodiments, j is between 60 and 3600. Other values are possible.

[0280] In some embodiments, k is between 1 and 100. Other values are possible.

[0281] In some embodiments, the first backward-immutable distributed storage system comprises a blockchain.

[0282] In some embodiments, the entry for block processing is added to the first backward-immutable distributed storage system.

[0283] In some embodiments, the entry for block processing is added to the second backward-immutable distributed storage system.

[0284] In some embodiments, the first backward-immutable distributed storage system is separate and distinct from the second backward-immutable distributed storage system.

[0285] Step 1002 of method 1000 may involve locking, in a first cryptographically- immutable distributed storage system, a unit of data representing state of the first cryptographically-immutable distributed storage system.

[0286] Step 1004 may involve communicating, between a first set of one or more computing devices associated with the first cryptographically-immutable distributed storageMBHB Docket No. 24-0791-WO system and a second set of one or more computing devices associated with a second cryptographically-immutable distributed storage system, that the state is locked.

[0287] Step 1006 may involve generating, by the second set of one or more computing devices, a placeholder for the state in the second cryptographically-immutable distributed storage system.

[0288] Step 1008 may involve obtaining, by the second set of one or more computing devices, the state from the second cryptographically-immutable distributed storage system.

[0289] In some embodiments, locking the unit of data comprises placing the unit of data in a smart contract on the first cryptographically-immutable distributed storage system.

[0290] In some embodiments, communicating that the state is locked comprises informing a smart contract on the second cryptographically-immutable distributed storage system that the state is locked.

[0291] In some embodiments, generating the placeholder for the state in the second cryptographically-immutable distributed storage system comprises issuing a wrapped version of the state on the second cryptographically-immutable distributed storage system.

[0292] In some embodiments, obtaining the state from the second cryptographically- immutable distributed storage system comprises the state being redeemed.

[0293] Block 1102 of method 1100 may involve determining a plurality of miners of a backward-immutable distributed storage system, wherein each of the miners has recently written one or more respective blocks of the backward-immutable distributed storage system with success, wherein recently writing the respective blocks with success includes one or more of: previously writing the respective blocks within a period of j seconds from a current time, or previously writing one or more of k most-recently written blocks.

[0294] Block 1104 may involve determining weights respectively associated with the miners, wherein each of the weights is based on a number of the respective blocks written by the respective miner during the period of j seconds or the k most-recently written blocks.

[0295] Block 1106 may involve causing the plurality of miners to each perform a task, wherein performance of the task produces a respective result for each of the miners.

[0296] Block 1108 may involve determining that a set of the miners each produced a common result.

[0297] Block 1110 may involve determining that a sum of the weights respectively associated with miners that produced the common result exceeds a threshold value.

[0298] Block 1112 may involve modifying the backward-immutable distributed storage system based on the common result.MBHB Docket No. 24-0791-WO

[0299] In some embodiments, the task comprises retrieving data from a network address, wherein the respective results for each of the miners is based on the data.

[0300] In some embodiments, the task comprises performing a computation, wherein the respective results for each of the miners is based on an output of the computation.

[0301] In some embodiments, the task comprises writing data to a storage location.

[0302] In some embodiments, the common result is identical for each of the set of miners.

[0303] In some embodiments, the common result comprises a hash value retrieved from a file, a database, or another cryptographically-immutable distributed storage system.

[0304] In some embodiments, j is between 60 and 3600.

[0305] In some embodiments, k is between 1 and 100.

[0306] In some embodiments, the backward-immutable distributed storage system comprises a blockchain.

[0307] In some embodiments, modifying the backward-immutable distributed storage system based on the common result comprises writing to the backward-immutable distributed storage system based on the common result. VIII. Closing

[0308] The present disclosure is not to be limited in terms of the particular embodiments described in this application, which are intended as illustrations of various aspects. Many modifications and variations can be made without departing from its scope, as will be apparent to those skilled in the art. Functionally equivalent methods and apparatuses within the scope of the disclosure, in addition to those described herein, will be apparent to those skilled in the art from the foregoing descriptions. Such modifications and variations are intended to fall within the scope of the appended claims.

[0309] The above detailed description describes various features and operations of the disclosed systems, devices, and methods with reference to the accompanying figures. The example embodiments described herein and in the figures are not meant to be limiting. Other embodiments can be utilized, and other changes can be made, without departing from the scope of the subject matter presented herein. It will be readily understood that the aspects of the present disclosure, as generally described herein, and illustrated in the figures, can be arranged, substituted, combined, separated, and designed in a wide variety of different configurations.

[0310] With respect to any or all of the message flow diagrams, scenarios, and flow charts in the figures and as discussed herein, each step, block, and / or communication can represent a processing of information and / or a transmission of information in accordance withMBHB Docket No. 24-0791-WO example embodiments. Alternative embodiments are included within the scope of these example embodiments. In these alternative embodiments, for example, operations described as steps, blocks, transmissions, communications, requests, responses, and / or messages can be executed out of order from that shown or discussed, including substantially concurrently or in reverse order, depending on the functionality involved. Further, more or fewer blocks and / or operations can be used with any of the message flow diagrams, scenarios, and flow charts discussed herein, and these message flow diagrams, scenarios, and flow charts can be combined with one another, in part or in whole.

[0311] A step or block that represents a processing of information can correspond to circuitry that can be configured to perform the specific logical functions of a herein-described method or technique. Alternatively or additionally, a step or block that represents a processing of information can correspond to a module, a segment, or a portion of program code (including related data). The program code can include one or more instructions executable by a processor for implementing specific logical operations or actions in the method or technique. The program code and / or related data can be stored on any type of computer readable medium such as a storage device including RAM, a disk drive, a solid-state drive, or another storage medium.

[0312] The computer readable medium can also include non-transitory computer readable media such as non-transitory computer readable media that store data for short periods of time like register memory and processor cache. The non-transitory computer readable media can further include non-transitory computer readable media that store program code and / or data for longer periods of time. Thus, the non-transitory computer readable media may include secondary or persistent long-term storage, like ROM, optical or magnetic disks, solid-state drives, or compact disc read only memory (CD-ROM), for example. The non-transitory computer readable media can also be any other volatile or non-volatile storage systems. A non- transitory computer readable medium can be considered a computer readable storage medium, for example, or a tangible storage device.

[0313] Moreover, a step or block that represents one or more information transmissions can correspond to information transmissions between software and / or hardware modules in the same physical device. However, other information transmissions can be between software modules and / or hardware modules in different physical devices.

[0314] The particular arrangements shown in the figures should not be viewed as limiting. It should be understood that other embodiments could include more or less of each element shown in a given figure. Further, some of the illustrated elements can be combined orMBHB Docket No. 24-0791-WO omitted. Yet further, an example embodiment can include elements that are not illustrated in the figures.

[0315] While various aspects and embodiments have been disclosed herein, other aspects and embodiments will be apparent to those skilled in the art. The various aspects and embodiments disclosed herein are for purpose of illustration and are not intended to be limiting.

Claims

MBHB Docket No. 24-0791-WO CLAIMS What is claimed is:

1. A computer-implemented method comprising: determining a plurality of miners of a backward-immutable distributed storage system, wherein each of the miners has recently written one or more respective blocks of the backward- immutable distributed storage system with success, wherein recently writing the respective blocks with success includes one or more of: previously writing the respective blocks within a period of j seconds from a current time, or previously writing one or more of k most-recently written blocks; determining weights respectively associated with the miners, wherein each of the weights is based on a number of the respective blocks written by the respective miner during the period of j seconds or the k most-recently written blocks; causing the plurality of miners to each perform a task, wherein performance of the task produces a respective result for each of the miners; determining that a set of the miners each produced a common result; determining that a sum of the weights respectively associated with miners that produced the common result exceeds a threshold value; and modifying the backward-immutable distributed storage system based on the common result.

2. The computer-implemented method of claim 1, wherein the task comprises: retrieving data from a network address, wherein the respective results for each of the miners is based on the data.

3. The computer-implemented method of claim 1, wherein the task comprises: performing a computation, wherein the respective results for each of the miners is based on an output of the computation.

4. The computer-implemented method of claim 1, wherein the task comprises: writing data to a storage location.

5. The computer-implemented method of claim 1, wherein the common result is identical for each of the set of miners.MBHB Docket No. 24-0791-WO 6. The computer-implemented method of claim 1, wherein the common result comprises a hash value retrieved from a file, a database, or another cryptographically- immutable distributed storage system.

7. The computer-implemented method of claim 1, wherein j is between 60 and 3600.

8. The computer-implemented method of claim 1, wherein k is between 1 and 100.

9. The computer-implemented method of claim 1, wherein the backward- immutable distributed storage system comprises a blockchain.

10. The computer-implemented method of claim 1, wherein modifying the backward-immutable distributed storage system based on the common result comprises writing to the backward-immutable distributed storage system based on the common result.

11. A computer-implemented method comprising: receiving, by a computing device, verifications that a plurality of miners of a first backward-immutable distributed storage system have respectively obtained a unit of data from an entity that is not part of the first backward-immutable distributed storage system; making, by the computing device, a first determination of a count related to the plurality of miners and a predetermined threshold; making, by the computing device, a second determination that each of the plurality of miners has recently mined a respective block of the first backward-immutable distributed storage system with success, wherein recently mining the respective block includes one or more of: previously mining the respective block within j seconds from a current time, or previously mining one of k most-recently mined blocks; and based on the first determination and the second determination, submitting, by the computing device, an entry for block processing to be added to the first backward-immutable distributed storage system or a second backward-immutable distributed storage system.

12. The computer-implemented method of claim 11, wherein the first determination is that the count related to the plurality of miners exceeds the predetermined threshold.MBHB Docket No. 24-0791-WO 13. The computer-implemented method of claim 11, wherein the first determination is that the count related to the plurality of miners does not exceed the predetermined threshold, the computer-implemented method further comprising: waiting until a further plurality of miners of the first backward-immutable distributed storage system have respectively obtained the unit of data, wherein a sum of the count and a further count related to the further plurality of miners exceeds the predetermined threshold, wherein submitting the entry for block processing is also based on the sum of the count and the further count exceeding the predetermined threshold.

14. The computer-implemented method of claim 11, wherein the predetermined threshold is based on a total number of miners of the first backward-immutable distributed storage system.

15. The computer-implemented method of claim 11, wherein the predetermined threshold is based on a total hashing power of miners of the first backward-immutable distributed storage system.

16. The computer-implemented method of claim 11, wherein the predetermined threshold is based on a probability that the plurality of miners are unable to collectively conspire to corrupt the first backward-immutable distributed storage system.

17. The computer-implemented method of claim 11, wherein the unit of data comprises a hash value retrieved from a file, a database, or another cryptographically- immutable distributed storage system.

18. The computer-implemented method of claim 11, wherein j is between 60 and 3600.

19. The computer-implemented method of claim 11, wherein k is between 1 and 100.

20. The computer-implemented method of claim 11, wherein the first backward- immutable distributed storage system comprises a blockchain.MBHB Docket No. 24-0791-WO 21. The computer-implemented method of claim 11, wherein the entry for block processing is added to the first backward-immutable distributed storage system.

22. The computer-implemented method of claim 11, wherein the entry for block processing is added to the second backward-immutable distributed storage system.

23. The computer-implemented method of claim 11, wherein the first backward- immutable distributed storage system is separate and distinct from the second backward- immutable distributed storage system.

24. A computer-implemented method comprising: locking, in a first cryptographically-immutable distributed storage system, a unit of data representing state of the first cryptographically-immutable distributed storage system; communicating, between a first set of one or more computing devices associated with the first cryptographically-immutable distributed storage system and a second set of one or more computing devices associated with a second cryptographically-immutable distributed storage system, that the state is locked; generating, by the second set of one or more computing devices, a placeholder for the state in the second cryptographically-immutable distributed storage system; and obtaining, by the second set of one or more computing devices, the state from the second cryptographically-immutable distributed storage system.

25. The computer-implemented method of claim 24, wherein locking the unit of data comprises placing the unit of data in a smart contract on the first cryptographically- immutable distributed storage system.

26. The computer-implemented method of claim 24, wherein communicating that the state is locked comprises informing a smart contract on the second cryptographically- immutable distributed storage system that the state is locked.

27. The computer-implemented method of claim 24, wherein generating the placeholder for the state in the second cryptographically-immutable distributed storage systemMBHB Docket No. 24-0791-WO comprises issuing a wrapped version of the state on the second cryptographically-immutable distributed storage system.

28. The computer-implemented method of claim 24, wherein obtaining the state from the second cryptographically-immutable distributed storage system comprises the state being redeemed.

29. A non-transitory computer-readable medium, storing program instructions that, when executed by one or more processors of a computing system, cause the computing system to perform the operations of one or more of claims 1-28.

30. A computing system comprising: one or more processors; memory; and program instructions, stored in the memory, that upon execution by the one or more processors cause the computing system to perform the operations of one or more of claims 1- 28.

Images