Blockchain-based data authentication and modification method and system

Abstract

Example systems and methods for blockchain nodes are disclosed. The node may receive a request message for placing an entry on a blockchain, the message comprising: a request specification including an action and an identity of a party to be acted upon by the action; an indicator that the entry has been authorized by a trusted entity; and a plurality of cryptographic verification codes generated by a plurality of trust validators, each cryptographic verification code including an encoded action-payload from the trusted entity and cryptographically signed by one of the trust validators. The node may apply a public encryption key of each trust validator to its cryptographic verification code to decrypt the encoded action-payload, and then verify that at least a threshold number of the decrypted corresponding encoded action-payloads are identical. The node may then submit the entry to be added to the blockchain for processing in response to performing at least the verification.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to U.S. Provisional Patent Application No. 63 / 317,750 filed on March 8, 2022, U.S. Provisional Patent Application No. 63 / 317,370 filed on March 7, 2022, U.S. Provisional Patent Application No. 63 / 268,095 filed on February 16, 2022, U.S. Provisional Patent Application No. 63 / 263,789 filed on November 9, 2021, U.S. Provisional Patent Application No. 63 / 225,053 filed on July 23, 2021, and U.S. Provisional Patent Application No. 63 / 160,317 filed on March 12, 2021, all of which are incorporated herein by reference in their entirety. Background Art

[0003] A distributed, decentralized network is a network of entities, often referred to as "nodes," each of which stores or records the current state of the entire network and possibly other information. The state of the entire network may be composed of many individual states, each of which is associated with an entity that "owns" that individual state. The owning entity of a state is often referred to as an "owner." Among the characteristics and properties of a distributed, decentralized network is the principle that each node is subject to a set of rules and / or protocols that govern how and under what circumstances these individual states may change. For example, a proposed change may require the consent of a majority of nodes, and some form of proof or proof of work or stake may be required for any set of one or more proposed state changes. Another rule may require that only the owner of a state may invoke or initiate a proposed change to that state. Summary of the invention

[0004] 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 of which records the entire history of the state of the network up to the time a corresponding block was added to the sequence. The sequence of blocks forms a linked chain, and each block is encoded so that once it enters the chain, it is virtually (if not virtually) impossible to modify. New blocks that record updated state (temporary snapshots) can be added, but existing blocks cannot be altered. That is, the blockchain is backwards immutable.

[0005] The backward immutability of blockchains, as well as the distributed, decentralized nature of blockchains, can be an obstacle to correcting errors in blocks or other defective network states. The inventors have recognized that there is a need for the ability to remediate problematic network state records in a distributed, decentralized network, but this needs to be done without tampering with the distributed, decentralized nature. Therefore, the inventors have designed techniques, methods, and systems to achieve these desired goals.

[0006] Thus, a first example embodiment may involve a method performed by a computing system configured to operate as a node of a network of nodes operating a blockchain. The method may involve operations including: receiving a request message for placing an entry on a blockchain, wherein the request message includes: (i) a request specification for the entry, the request specification including an action and an identity of at least one party to be acted upon by the action, (ii) an indicator that the entry has been authorized by a trusted entity, (iii) a plurality of cryptographic verification codes generated by a respective plurality of trust verifiers, each cryptographic verification code including an encoded action-payload provided by the trusted entity and cryptographically signed by a respective one of the trust verifiers; applying a public encryption key of each respective trust verifier to the respective cryptographic verification code to decrypt the respective encoded action-payload; performing a first verification that at least a threshold number of the decrypted respective encoded action-payloads are identical; and in response to performing at least the first verification, submitting the entry to be added to the blockchain for block processing.

[0007] A second example embodiment may be directed to a method performed by a computing system configured to operate as a node of a network of nodes operating a blockchain. The method may involve operations including: receiving a request message for placing an entry on a blockchain, the entry being configured to invoke a contingency action of a smart contract previously entered into the blockchain, wherein the request message includes: (i) a request specification including a link to the smart contract, an identifier of the contingency action, and an identity of a designated action invoker authorized to invoke the contingency action; (ii) an indicator indicating that the entry has been authorized by a trusted entity; (iii) a plurality of encrypted verification codes generated by a corresponding plurality of trust verifiers, each encrypted verification code including an encoded action-payload provided by a trusted entity and cryptographically signed by a corresponding one of the trust verifiers; applying a public encryption key of each corresponding trust verifier to the corresponding encrypted verification code to decrypt the corresponding encoded action-payload; performing a first verification that at least a threshold number of the decrypted corresponding encoded action-payloads are identical; in response to performing at least the first verification, generating a transaction specification and placing it in the entry, wherein the generated transaction specification includes instructions for performing an identified contingency action authorized by a trusted entity that is an authenticated alias of the designated action invoker; and submitting an entry for block processing to be added to the blockchain.

[0008] A third example embodiment may involve a method performed by a computing system configured to operate as a database server to verify and store encoded action triggers for digital assets input to a blockchain network. The method may involve operations including: receiving a request message for verifying and storing a verified action trigger for a digital transaction input to the blockchain network, wherein the request message includes a request specification, the request specification including an action and an identity of at least one party associated with a digital asset affected by the action; receiving a plurality of encrypted verification codes independently generated by a plurality of corresponding trust verifiers, each encrypted verification code including a trigger code originating from a trusted entity and cryptographically signed by a corresponding one of the trust verifiers; applying a public encryption key of each corresponding trust verifier to the corresponding encrypted verification code to decrypt the corresponding trigger code; performing a first verification that at least a threshold number of decrypted corresponding trigger codes are identical; applying an encoder function to the request specification to derive a local version of the trigger code associated with the action; performing a second verification that the local version of the trigger code is identical to the local version of each of the at least threshold number of decrypted identical corresponding trigger codes; and storing the trigger code as a verified action trigger in a database associated with the computing system.

[0009] A fourth example embodiment may involve a method performed by a computing system configured to operate as a database server to verify and store encoded action triggers input to a smart contract on a blockchain network. The method may involve operations including: receiving a request message for verifying and storing a verified action trigger input to a smart contract on a blockchain network, wherein the request message includes a request specification, the request specification including a link to the smart contract and an identifier of an emergency action of the smart contract; receiving a plurality of encrypted verification codes independently generated by a plurality of corresponding trust verifiers, each encrypted verification code including a trigger code originating from a trusted entity and encrypted signed by a corresponding one of the trust verifiers; applying a public encryption key of each corresponding trust verifier to the corresponding encrypted verification code to decrypt the corresponding trigger code; performing a first verification that at least a threshold number of the decrypted corresponding trigger codes are the same; applying an encoder function to the request specification to derive a local version of the trigger code associated with the emergency action; performing a first verification that at least a threshold number of the decrypted corresponding trigger codes are the same; storing the trigger code as a verified action trigger in a database associated with the computing system.

[0010] In a fifth example embodiment, the computing system may include at least one processor, a memory, and program instructions. The program instructions may be stored in the memory, and when executed by the at least one processor, the computing system performs operations according to any one or more of the first, second, third, and fourth embodiments.

[0011] In a sixth embodiment, a product may include a non-transitory computer-readable medium having program instructions stored thereon, which, when executed by a computing system, cause the computing system to perform operations according to any one or more of the first, second, third, and fourth embodiments.

[0012] In the seventh exemplary embodiment, the system may include various means for performing each operation of any one or more of the first embodiment, the second embodiment, the third embodiment, and the fourth embodiment.

[0013] These and other embodiments, aspects, advantages and alternatives will become apparent to those of ordinary skill in the art by reading the following detailed description and referring to the accompanying drawings as appropriate. In addition, this summary and the other descriptions and drawings provided herein are only intended to illustrate the embodiments by way of example, and therefore, many variations are possible. For example, structural elements and process steps can be rearranged, combined, distributed, eliminated, or otherwise changed while still remaining within the scope of the claimed embodiments. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] Figure 1 A schematic diagram of a computing device according to an example embodiment is shown.

[0015] Figure 2 A schematic diagram of a server device cluster according to an example embodiment is shown.

[0016] Figure 3 A simplified block diagram of an example system is shown in which various operations of a system level implementation may be performed according to an example embodiment.

[0017] Figure 4A and Figure 4B Two representations of example processing performed by a system-level implementation of motion input requests according to example embodiments are shown.

[0018] Figure 5 An example message flow diagram associated with various aspects of system level operation according to an example embodiment is shown.

[0019] Figure 6 A simplified block diagram of another example system in which various operations of an entry-level implementation may be performed is shown according to an example embodiment.

[0020] Fig. 7A and Figure 7B Two representations of example processing performed by an entry-level implementation of action request validation according to example embodiments are shown.

[0021] Figure 8 An example message flow diagram associated with various aspects of entry-level operations according to an example embodiment is shown.

[0022] Fig. 9 A flow chart of an example system level method for transactions according to an example embodiment is shown.

[0023] Fig.10 A flow chart of an example system-level method for smart contracts according to an example embodiment is shown.

[0024] Fig.11 A flow chart of an example entry-level method for transactions is shown according to an example embodiment.

[0025] Fig.12 A flow chart of an example entry-level method for a smart contract according to an example embodiment is shown. DETAILED DESCRIPTION

[0026] Example methods, devices, and systems are described herein. It should be understood that the words "example" and "exemplary" as used herein mean "serving as an example, instance, or illustration." Unless expressly stated otherwise, any embodiment or feature described herein as "example" or "exemplary" is not necessarily to be construed as preferred or advantageous over other embodiments or features. Therefore, other embodiments can be used and other changes can be made without departing from the scope of the subject matter presented herein.

[0027] Therefore, the example embodiments described herein are not meant to be limiting. It will be readily appreciated that the various aspects of the present disclosure, as generally described herein, and as illustrated in the accompanying drawings, can be arranged, substituted, combined, separated, and designed in a variety of different configurations. For example, a feature separated into "client" and "server" components can occur in a variety of ways.

[0028] In addition, unless the context indicates otherwise, the features shown in each figure can be used in combination with each other. Therefore, these figures should be regarded as part of one or more integral embodiments, and it is understood that not all shown features are necessary for each embodiment.

[0029] In addition, any listing of elements, blocks or steps in this specification or claims is for clarity of description. Therefore, such listing should not be interpreted as requiring or implying that these elements, blocks or steps follow a specific arrangement or are performed in a specific order.

[0030] 1. Introduction

[0031] Blockchain-based technologies constitute and facilitate a new form of decentralized computing that has been used to provide cryptocurrencies, smart contracts, identity protection, and secure voting, among many other applications. At least from some sources, there is speculation that a new version of the World Wide Web (“web 3.0”) could be built on one or more blockchains. Regardless, blockchain-based technologies seem to have an indisputable impact on computer networks and other aspects of society, despite having only been around for a little over a decade.

[0032] As used herein, “blockchain-based” technology refers to any variant of blockchain technology or any technology that employs or relies on blockchain mechanisms. This includes current and future variants of blockchain technology.

[0033] In short, a blockchain is a list of entries stored as a distributed database that is able to grow over time based on a consensus protocol executed by blockchain nodes. Entries are grouped and added to a blockchain chain, a data structure in the form of blocks, and sequential blocks are cryptographically linked to each other. Blockchain nodes are computing devices or computing systems that can communicate with each other in a peer-to-peer fashion using blockchain software, and therefore they can reside in different locations and be operated by different entities. Blockchain nodes can form an overlay on existing computer networks (e.g., the Internet) and can be collectively referred to as a blockchain network. In order to maintain the independence and decentralized characteristics of the blockchain, each blockchain node can 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 can be generated by any one-way (hash) function (e.g., SHA-256) that is mathematically and / or computationally impossible to reverse. Sequentially linking blocks via a cryptographic hash chain makes it very difficult for any party to modify a recently placed block, and nearly impossible to modify an earlier block.

[0035] Each blockchain user has a unique address for use with the blockchain. Each user also has a cryptographically associated public / private key pair such that data encoded with the public key can only be decoded by the corresponding private key, and vice versa. Thus, data encoded using a user's public key are effectively encrypted such that they can only be decrypted by the user's private key, and data encoded using a user's private key produces a digital signature that can be verified using the user's public key.

[0036] An entry is usually some form of transaction between two or more users, which includes the address of the "sending" user, the information being "sent", and the addresses of one or more "receiving" users, all signed with the sending user's digital signature. Therefore, it is easy to verify that the entry comes from the sending user (the sending user is authenticated) and that the entry has integrity (the entry has not been changed after signing) and non-repudiation (the sender cannot later deny signing the entry). The information sent may be a certain amount of cryptocurrency, a smart contract.

[0037] The proposed new entry is received by one or more blockchain nodes and its digital signature is authenticated. In some cases, the validity of the entry can also be verified (for example, an entry on a cryptocurrency blockchain cannot cause the amount of cryptocurrency held by the sender to be less than zero). These entries are formed into blocks, which are then distributed to other blockchain nodes through the blockchain network. Each block can include one or more entries.

[0038] On the other hand, a deliberate fork can occur when the rules of at least some of the blockchain nodes change. A soft fork occurs when the rules of the majority of blockchain nodes change in a backwards-compatible way (e.g., adding a new type of entry). Thus, while the rules of the blockchain nodes have not been updated, a single blockchain still recognizes the new block as valid. Eventually, all blockchain nodes can be updated to the new rules.

[0039] A hard fork occurs when a majority of blockchain nodes adopt new rules such that blocks generated under the new rules are considered invalid under the old rules. Unless all blockchain nodes upgrade to the new rules, a permanent split will occur, with the single blockchain splitting into two independent blockchains, one running under the new rules and the other running under the old rules.

[0040] In addition to supporting cryptocurrencies, one of the main uses of blockchain technology is the formation and execution of smart contracts. A smart contract is executable logic (e.g., a program or code snippet) placed in an entry. The logic of a smart contract runs when certain predetermined conditions are met. A simple smart contract can 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 actions to be performed when X is true.

[0041] For example, the smart contract logic may specify that when the shipment arrives at the recipient's location (X), the recipient pays the sender a certain amount (Y). The smart contract may also specify one or more external data sources (e.g., outputs 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 called "oracles" and are trusted by all parties to the smart contract. For example, the oracle for the shipment described above may be a wireless location sensor attached to the shipment to provide global positioning system (GPS) data, or a representational state transfer (REST) ​​interface of a computing device that tracks the location of the shipment.

[0042] Since the entry containing the smart contract on the blockchain cannot be modified, the execution of the smart contract places further entries on the blockchain to perform action Y. Alternatively, an off-blockchain software tool can be used to inspect the state of the smart contract and then add entries for Y as needed. In some cases, these further entries may also be smart contracts with different sets of conditionally executable logic, so smart contracts can be chained to perform a complex series of actions.

[0043] Given all of this, current blockchains have a set of generally desirable properties. They are decentralized and therefore do not rely on a single government or social authority to operate. Blockchains are generally public documents that can be stored, viewed, and analyzed by anyone. Anyone can become a miner, but majority control of all mining entities is required to corrupt the blockchain. Any user can create a blockchain "account" by creating a unique address for themselves, allowing them to interact with other users through the blockchain without prior approval. Invalid transactions are automatically discarded by blockchain nodes. As mentioned earlier, once blocks are placed on the blockchain, they are effectively backwards immutable (existing blocks cannot be changed) and become more difficult to change over time as subsequent blocks are added.

[0044] Nonetheless, current blockchain technology is subject to a number of limitations. First, there is no built-in recourse for theft, fraud, money laundering, or deception. As a result, blockchains have become a host for these and other types of illegal activity, and there is evidence that criminals are actively attracted to blockchains due to the lack of a central authority. In addition, copyrighted or confidential information placed on a blockchain is virtually impossible to remove from the blockchain. Furthermore, lost, misplaced, or stolen private keys cannot be recovered, and the owner of such private keys will be unable to access their blockchain accounts. These factors ultimately present enough risks to the average user of blockchain-based technology that they could hinder its usefulness outside of a few niche areas.

[0045] For example, compare a blockchain user who mistakenly sends cryptocurrency to the wrong address (or is lured by a fraudster to submit such a transaction, or whose private keys are stolen by a hacker) to the situation where the same user sends fiat currency through traditional banking channels. In the case of the former, current blockchains do not provide any mechanism to restore the cryptocurrency to its rightful owner, even if the recipient has no legal right to the funds and may well have violated the law to obtain them. In contrast, the latter enjoy many protections, all because the transaction is conducted through a series of intermediary banks or other entities that can be located and enforced by the courts if they breach warranties or do not conduct transactions in accordance with local laws.

[0046] The example embodiments herein overcome these fundamental shortcomings of blockchain technology without changing its core principles of immutability and decentralized nature. In particular, third parties agreed in advance by blockchain users, or third parties that may be specified by law or regulation, may be allowed to modify certain blockchain transactions after the fact. These modifications are not to existing blocks, but rather allow third parties to add new blocks to the blockchain to implement and / or enforce pre-established agreements, regulations, or judicial decisions, for example. Therefore, even if the old blocks themselves are immutable, the effects and / or results of transactions or agreements represented in the old blocks can be modified (e.g., corrected, rectified, or reversed) by the addition of new blocks. At the same time, according to example embodiments, the procedures for third parties to take enforcement actions on the blockchain can ensure that the third party's authority to do so will not be abused or subverted. These procedures also operate in accordance with the distributed, decentralized nature of the blockchain, and therefore do not compromise or lose the ideal aspects of blockchain-based technology.

[0047] The 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 enforced by blockchain nodes). This may involve deploying a new blockchain or a soft or hard fork of an existing blockchain. All users participating in the blockchain may explicitly (or implicitly through the use of the blockchain) agree that their entries are subject to a set of controls, and that enforcement of these controls is the responsibility of one or more third parties (e.g., an arbitration institution, a court, other government agency, or simply another person or entity that is trusted by the public). For example, the third party may be a judicial court.

[0048] For example, if one or more users have a dispute regarding an entry with which they are associated, any of these users may request that the third party make an adjudication. The third party may consider the request in light of the group's control and / or applicable legal principles. If the third party determines that an entry needs to be amended, it records a representation of such amendment. Such a representation may be a new entry submitted directly to the blockchain, or a code, token, or other document published at a specific location (e.g., on a website or REST interface). The representation may identify the disputed entry, the users involved, the specific location (e.g., in the form of a uniform resource locator (URL)), and the transaction determined by the third party to be appropriate to correct or mitigate any damage to one or more users. The representation may be digitally signed by the third party to establish its legitimacy, although a digital signature may not necessarily be required in all implementations and / or usage scenarios.

[0049] If the representation is not provided directly to the blockchain, an intermediate off-chain entity that controls one or more server devices can obtain the representation from the third party and submit the representation to the blockchain on behalf of the third party. For example, the intermediate entity can subscribe to notifications of new representations from the third party and / or periodically poll the third party (e.g., crawl its website or REST interface).

[0050] Once submitted to the blockchain nodes, they can authorize the block and implement the consensus protocol described above. Other authentication steps can verify the third party's digital signature, verify that the representation actually exists at a specific location, and / or that the identified third party does have the authority to modify the entry on this blockchain. The blockchain nodes mine the block in the entry in the usual way, and if the majority of nodes agree that the block is valid and the mining is successful, the block will be added to the blockchain.

[0051] For example, suppose an entry on a blockchain involves user A transferring C units of cryptocurrency to user B. User A later discovers that their blockchain account was hacked to make this transaction. User A can then contact a third party (e.g., a court) and provide evidence of the hack (e.g., server logs, witness testimony, expert testimony, etc.). The third party can then rule in favor of user A and publish a statement of that ruling at a specific URL on its website.

[0052] The representation may indicate that user B is forced to transfer C units of cryptocurrency to user A on the blockchain (or an amount higher than C if user B is the perpetrator and punitive damages are included). The representation may include a URL, an effective date, and the identity of the third party, and may be digitally signed by the third party, if necessary. The effective date may be the date when the block containing the representation is mined.

[0053] The effective date may be specified in the blockchain protocol and followed automatically. In some cases, the representation may temporarily freeze or seize user B’s assets on the blockchain, making it impossible for user B to liquidate those assets until user B is forced to make user A whole.

[0054] Once published, the representation can be obtained by an intermediary entity, formed into an entry, and submitted to the blockchain. During the mining process, the blockchain node can independently determine that the third party has the authority to enforce the action (for example, such a third party's ability can be built into the blockchain operation), and can also verify that the information stored at the URL matches the representation. As mentioned earlier, once the majority of blockchain nodes agree that the block is valid and the mining is successful, the block is added to the blockchain.

[0055] Advantageously, this mechanism does not require blockchain nodes, blockchain users, or third parties to trust an intermediary entity. Furthermore, the blockchain may grant only certain powers to third parties relative to the types of disputes that the blockchain can resolve, the remedial actions used, and the users that the blockchain has authorized. Furthermore, the use of a consensus protocol ensures that an attempt to corrupt or use third-party authorizations in an illicit manner requires control of a majority of blockchain nodes. As discussed above, the mining process makes this computationally infeasible for most participants.

[0056] While the above examples illustrate the case of transactions, the system-level implementation also provides operations for smart contract situations. More specifically, in scenarios involving smart contracts, such as disputes regarding the performance of an obligation action specified in a smart contract, the system-level implementation provides a trusted third party (such as a judicial court) as an "authorized alias" for invoking the obligation action. As with the transaction case, these processes ensure that any instance of executing this new functionality is secure and cannot be hacked, damaged, or any other form of abuse.

[0057] The second possible embodiment is referred to as an "entry-level" implementation, as it involves encoding predetermined contingency actions into individual blockchain entries on an entry-by-entry basis, subject only to the prior approval of the parties to the agreement or transaction recorded in each such respective entry. The entry-level implementation may also be referred to as a "smart contract" implementation, as it may include smart contract-like features of embedding encoded actions in individual blockchain entries, but by authorizing a third party trusted by the parties to the agreement in a given entry to execute the encoded actions to strengthen confidence that the encoded actions in any given entry will be executed in accordance with the agreement. Unlike the first embodiment, the entry-level implementation is capable of being deployed utilizing an existing blockchain with smart contract support. Nonetheless, this embodiment may be implemented via a new blockchain or a fork of an existing blockchain.

[0058] Here, the entire blockchain is not necessarily subject to the authorization of any third party. Instead, pairs or groups of users can multilaterally determine to be bound by a smart contract that provides two new mechanisms: (i) a list of one or more remedial (or possible) actions to be taken if certain conditions are true, and (ii) third parties that the users agree will have authority over the smart contract. Thus, control can be granted to third parties on an entry-by-entry basis of the blockchain, and not all blockchain entries are subject to such control. A remedial action can be any type of state change that can be represented on the blockchain.

[0059] 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 may be a unique binary string of numbers, a QR code, or in other forms. For example, user A and user B may participate in a smart contract where user A will provide user B with 10 widgets and user B will provide user A with $500 (reflected in digital assets) in return. The users may agree that the smart contract is also subject to two conditions, each with a remedial action: (i) if the widgets are not all delivered to user B by a specific time and date, user A will refund user B $100, and (ii) if the widgets do not meet the quality of workmanship as understood in the industry, user A will refund the entire $500 to user B. Similarly, the amount paid to A may be retained as a variable that can be assigned by a third party. In some cases, users may include clauses in the smart contract so that any other unspecified circumstances that give rise to a dispute are remedied by a third party.

[0060] This smart contract is submitted to the blockchain and then validated and mined as described above. Assume that User B claims that the first remedial action has been triggered and that the users are unable to resolve the dispute on their own. User B can then ask the pre-established third party to join and provide the third party with evidence of the delayed delivery (e.g., a bill of lading indicating that the widgets were delivered one week late). The third party can make a ruling in favor of User B and publish a statement of that ruling at a specific URL on its website.

[0061] The representation may include the smart contract, URL, effective date, identity of the third party, and 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 in the first embodiment. Here, the blockchain node may further verify that the code matches the code in the smart contract. Once placed on the blockchain, this entry will be used to "modify" the smart contract - in particular, the presence of this code in an entry signed by a third party will result in the invocation of a remedial condition in the smart contract: transferring $100 from user A to user B.

[0062] This mechanism also does not require blockchain nodes, blockchain users, or third parties to trust intermediary entities. In addition, each group of users involved in the smart contract can independently choose its own third party, further decentralizing the authorization of different smart contracts. In addition, the third party's ruling is clear and does not require interpretation because it calls the logic that already exists in the smart contract.

[0063] The description of the item-level implementation in terms of smart contract-like operations should not be confused with the smart contract scenarios of the system-level implementation. More specifically, each of the system-level implementation and the item-level implementation provides operations and functions for transaction scenarios and smart contract scenarios.

[0064] A third possible embodiment is a hybrid of the first and second embodiments. As with the first embodiment, the blockchain is initially structured or forked so that all entries are governed by a set of controls, and these controls are enforced by one or more third parties. However, these 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. Nevertheless, as with the second embodiment, third parties can "modify" smart contracts by adding triggering transactions or new entries containing the smart contract itself. Otherwise, operations are performed in a similar manner to the second embodiment.

[0065] This embodiment avoids the need for users participating in each smart contract to identify a third party they mutually trust to enforce the terms of the contract - the third party is determined by the blockchain. While this makes entry into a smart contract simpler, it also requires users to rely on the third party that the blockchain has established. Likewise, this embodiment allows non-parties to the smart contract (such as government agencies or injured non-parties) to "modify" the smart contract execution with the approval of the designated third party.

[0066] In either of these implementations, the entry executing the third-party adjudication may be placed on a different blockchain than the previous entry it "modifies." Thus, the same blockchain need not be used for both types of entries, or a transaction on one blockchain could be used to correct a dispute related to a transaction on another blockchain.

[0067] Notably, all three embodiments facilitate operations that are not currently supported by blockchain-based technologies—the addition of entries by third parties that force transactions from a sending user to a receiving user or force smart contract operations without requiring that the transaction be digitally signed by the sending user or by the owner of the smart contract (e.g., in the case of smart contracts and the like). Instead, as long as the entry from the third party can be verified as legitimately sourced from and / or originating from the third party, it will be added to the blockchain. Advantageously, these features can enhance and advance blockchain-based technologies, making them reliable enough for general use while retaining all of their desirable decentralized and distributed characteristics.

[0068] II. Example computing devices and cloud-based computing environments

[0069] Figure 11 is a simplified block diagram illustrating a computing device 100, which shows some components that can be included in the computing device to operate according to the embodiments of the present invention. The computing device 100 can be a client device (e.g., a device actively operated by a user), a server device (e.g., a device that provides computing services to client devices), or some other type of computing platform. Some server devices may operate as client devices from time to time to perform certain operations, and some client devices may contain features of servers.

[0070] 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 via system bus 110 or similar mechanism. In some embodiments, computing device 100 may include other components and / or peripherals (e.g., removable storage, printer, etc.).

[0071] Processor 102 may be one or more of any type of computer processing element, such as a central processing unit (CPU), a coprocessor (e.g., a math, graphics, or cryptographic coprocessor), a digital signal processor (DSP), a network processor, and / or some 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 associated data and cache memory for temporarily storing recently used instructions and data.

[0072] 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 drive, solid-state drive, compact disk (CD), digital video disk (DVD), and / or tape storage). Thus, memory 104 represents both a primary memory unit and long-term storage. Other types of memory may include biological memory.

[0073] The memory 104 may store program instructions and / or data that the program instructions may operate on. As an example, the memory 104 may store these program instructions on a non-transitory computer-readable medium so that these instructions are executed by the processor 102 to perform any method, process or operation disclosed in this specification or drawings.

[0074] like Figure 1As shown, the memory 104 may include firmware 104A, a kernel 104B, and / or an application 104C. The firmware 104A may be a program code for loading (boot) or otherwise starting (initiate) part or all of the computing device 100. The kernel 104B may be an operating system, which includes modules for memory management, scheduling and process management, input / output, and communication. The kernel 104B may also include a device driver that allows the operating system to communicate with the hardware modules (e.g., memory units, network interfaces, ports, and buses) of the computing device 100. The application 104C may be one or more user space software programs, such as a web browser or an email client, and any software libraries used by these programs. The memory 104 may also store data used by these and other programs and applications.

[0075] The network interface 106 may be in the form of one or more wired interfaces, such as Ethernet (e.g., Fast Ethernet, Gigabit Ethernet, etc.). The network interface 106 may also support communication via one or more non-Ethernet media, such as coaxial cable or power line, or via wide area media (e.g., Synchronous Optical Network (SONET) or Digital Subscriber Line (DSL) technology). The network interface 106 may also be in the form of one or more wireless interfaces, such as IEEE802.11 (Wifi), Global Positioning System (GPS) or wide area wireless interface. However, other forms of physical layer interfaces and other types of standard or proprietary communication protocols may be used on network interface 106. In addition, network interface 106 may include multiple physical interfaces. For example, some embodiments of computing device 100 may include an Ethernet interface, interface and Wifi interface.

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

[0077] In some embodiments, one or more computing devices similar to computing device 100 may be deployed to support blockchain and / or blockchain-related architectures. For client devices, the exact physical location, connections, and configuration of these computing devices may be unknown and / or unimportant. Therefore, the computing devices may be referred to as "cloud-based" devices that may be located at various remote data center locations.

[0078] Figure 2 A cloud-based server cluster 200 is depicted according to an example embodiment. Figure 2 In the server cluster 200, the operation of a computing device (e.g., computing device 100) can be distributed among server devices 202, data storage 204, and routers 206, all of which can be connected via a local cluster network 208. The number of server devices 202, data storage 204, and routers 206 in the server cluster 200 can depend on the computing tasks and / or applications assigned to the server cluster 200.

[0079] For example, server device 202 can be configured to perform various computing tasks of computing device 100. Therefore, computing tasks can be distributed between one or more server devices 202. To some extent, these computing tasks can be performed in parallel, and such task allocation can reduce the total time to complete these tasks and return results. For simplicity, server cluster 200 and each server device 202 can be referred to as "server device". This nomenclature should be understood to refer to one or more different server devices, data storage devices and cluster routers that may be involved in the operation of the server device.

[0080] The data storage 204 may be a data storage array that includes drive array controllers configured to manage read and write access to a set of hard disk drives and / or solid state drives. The drive array controllers may also be configured, alone or in conjunction with the server devices 202, to manage backup or redundant copies of data stored in the data storage 204 to prevent one or more server devices 202 from being prevented from accessing cells of the data storage 204 due to a drive failure or other type of failure. Other types of storage besides drives may be used.

[0081] The router 206 may include a network device configured to provide internal and external communications for the server cluster 200. For example, the router 206 may include one or more packet switching and / or routing devices (including switches and / or gateways) configured to: (i) provide network communications between the server devices 202 and the data storage 204 via the local cluster network 208; and / or (ii) provide network communications between the server cluster 200 and other devices via the communication link 210 to the network 212.

[0082] In addition, the configuration of router 206 can be based at least in part on data communication requirements of server device 202 and data storage 204, latency and throughput of local cluster network 208, latency, throughput, and cost of communication link 210, and / or other factors that may have an impact on the cost, speed, fault tolerance, resilience, efficiency and / or other design goals of the system architecture.

[0083] 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 information in such a database, including but not limited to tables, arrays, lists, trees, and tuples. In addition, any database in data storage 204 may be integrated or distributed across multiple physical devices.

[0084] The server device 202 may be configured to send data to and receive data from the data storage 204. Such transmission and retrieval may take the form of SQL queries or other types of database queries, and the output of such queries. Additional text, images, video, and / or audio may also be included. In addition, the server device 202 may organize the received data into a web page or web application representation. Such a representation may take the form of a markup language, such as HTML, extensible markup language (XML), or some other standardized or proprietary format. In addition, the server device 202 may have the ability to execute various computerized scripting languages, such as, but not limited to, Peri, Python, PHP hypertext preprocessor (PHP), Active Server Pages (ASP), The computer program code written in these languages ​​is conducive to providing web pages to client devices, and the interaction between client devices and web pages. Optionally or alternatively, the computer program code written in these languages ​​is conducive to providing web pages to client devices, and the interaction between client devices and web pages. To facilitate the generation of web pages and / or provide web application functionality.

[0085] III. Example System-Level Blockchain Implementation

[0086] According to an example system-level embodiment, a designated, trusted off-chain authority can create an entry in a blockchain that forces a blockchain-recorded action between two or more parties on an entry previously recorded on the blockchain. Conventionally, blockchain entries that specify an action or arrangement (e.g., an agreement or contract) between two or more parties require some form of cryptographic verification of the user's identity (e.g., a digital signature) to verify the action and authenticate the new entry. In contrast, the designated, trusted off-chain authority of the system-level implementation is a third party, not a party to the previous entry. The example system-level embodiment establishes a set of procedures and protocols that protect the integrity and validity of any instructions that enforce blockchain-recorded actions, while keeping the distributed and decentralized operating principles of the blockchain intact.

[0087] As an example, the action recorded by the blockchain may be a transaction that specifies the transfer of a digital asset from a sender or sender to a receiver or recipient. In order for the transaction to be considered valid and thus recorded as an entry in a block of the blockchain, the sender's cryptographic key, or other form of proof of ownership of the digital asset, must participate in the transaction so that any blockchain node can verify the sender's right to the digital asset, thereby verifying the sender's right to transfer the digital asset. In an example use case of a system-level embodiment, a designated, trusted off-chain authority may be required to reverse the effectiveness of the transaction by causing a remedial action to be entered into the blockchain that causes the digital asset to be transferred from the recipient back to the sender.

[0088] Also as an example, a blockchain-recorded arrangement (e.g., an agreement or contract) between two or more parties may be a smart contract that embeds one or more emergency actions, and when any one or more emergency actions are activated or "called" by a "designated caller" in the smart contract that is authorized to call (i.e., activate the emergency action), the one or more emergency actions are executed. The smart contract recorded as an entry in the blockchain typically includes the executable code for each emergency action, and the identity of the designated caller (or multiple callers) that is authorized to call the emergency action and cause the relevant code to run. In order for the call to be considered valid and thus execute the emergency action, a request or command to call can be issued in a submission to the blockchain. The request includes a link to the relevant smart contract, an identification of the requested emergency action, any parameters that the emergency action may use or require, and an encryption key (or some other form of authentication) of the caller that proves that the requester is authorized to make the call. In an example use case of a system-level embodiment, the blockchain operation can be configured to identify a trusted off-chain authority as an "authorized alias" of a designated caller of an emergency action in order to make a call, thereby executing the emergency action of the smart contract when the trusted off-chain authority requires or commands it.

[0089] Assuming that a designated, trusted off-chain authority approves the request for the action or alias invocation, the specification of the action or invocation certified by the trusted off-chain authority can be electronically published or posted as a "trust list" to a secure website or other server and made available to a plurality of independent trust validators. Each of the trust validators can then individually and independently retrieve the trust list and cryptographically sign it using their respective private encryption keys and individually and independently store their respective signed trust lists in a secure database. The multiple signed trust lists can then be retrieved from the secure database and provided to the blockchain along with the specification of the remedial action. For purposes of discussion, for example, a trust list can be created or generated as a hash of information that specifies the requests contained in the list. Similarly, the trust validator functionality can be incorporated into the node protocol and distributed thereby to all nodes or multiple nodes. Similarly, the secure database of signed trust lists can be stored on the blockchain or in another location.

[0090] Each of the one or more nodes of the blockchain can then use the corresponding public key of the trust verifier to authenticate and decrypt the hash of the multiple signatures and verify that all decrypted hashes are the same. This provides proof of the validity of the hash. Each of the one or more nodes can then generate its own local version of the hash using the specification of the remedial action or the specification of the requested alias call. Upon verifying that the local version of the hash is the same as the retrieved, verified hash, each of the one or more nodes can therefore determine the integrity and authenticity of the remedial action or alias call and encode it in a valid blockchain action according to the usual blockchain procedures. Similarly, when the verification function is incorporated into the node protocol, the node can sign the remedial transaction directly on the chain instead of signing and storing the trust list. The entry in the blockchain then causes the remedial action or alias call to be effectively executed and recorded in the blockchain.

[0091] An example implementation of a system level embodiment, referred to as a system level implementation, will be described in more detail below.

[0092] A. Example System Architecture and Technical Description

[0093] Figure 3 is a simplified block diagram illustrating an arrangement of components for a system-level implementation of authenticated off-chain modification of blockchain-based transactions, according to an example embodiment. Figure 3 The block diagram of can also be viewed as describing various aspects of the operational architecture of the system-level implementation. As shown, the example embodiments can include various components, any one or more of which can be implemented as or in one or more computing devices. Therefore, Figure 3The components depicted in the examples may themselves be or include hardware, software, firmware, or a combination thereof. Some of the components may be identified structurally, such as a database or other form of data storage and management, while other components may be identified based on their operation or functionality. For example, operational components and / or functional components may be implemented as software and / or hardware modules, which may also be referred to as "modules" for purposes of this discussion.

[0094] Example system-level implementations can also include one or more connection mechanisms connecting each component. For example, these connection mechanisms are depicted as arrows between components. The direction of the arrow can represent the direction of information flow, but this interpretation should not be considered as a limitation. In the present disclosure, the term "connection mechanism" refers to a mechanism that connects and promotes communication between two or more components, devices, systems or other entities. The connection mechanism can include relatively simple mechanisms such as cables or system buses and / or relatively complex mechanisms such as data packet-based communication networks (e.g., the Internet). In some cases, the connection mechanism can include an intangible medium, such as when the connection is at least partially wireless. The connection mechanism can also include programming communication between software and / or hardware modules or applications, such as an application program interface (API). In the present disclosure, the connection can be a direct connection or an indirect connection, and an indirect connection is a connection that passes through and / or passes through one or more entities (e.g., routers, switches or other network devices). Similarly, in the present disclosure, communication (e.g., the transmission or reception of data) can be direct communication or indirect communication.

[0095] As an example, Figure 3 Various components and entities of an example system-level implementation include a blockchain network 302 with connection nodes 302-1, 302-2, .... 302-N, where the connected ellipses represent possible additional connection 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 action server 308, an event observer 310, a trust verifier A 312-A, a trust verifier B 312-B, a trust verifier C 312-C, a verification request database 314, a request poller 316, an off-chain transaction server 318, and a trust verifier public key 320. The ellipses after the trust verifier C 312-C indicate that there may be other trust verifiers. In an example embodiment, the off-chain request application 304 can be an application configured to execute on a computing device such as a PC, a laptop, a smartphone, or a server.

[0096] The computational and / or functional roles of example components and entities can be understood by considering example operational scenarios involving blockchain transactions and blockchain smart contracts. Both scenarios involve similar operations and, in some respects, identical operations. However, to help clarify the distinction between the two scenarios, operational examples for both scenarios are presented below.

[0097] 1. Example system-level scenario of blockchain transactions

[0098] In an example transaction scenario, all parties to a previous transaction may be blockchain users, and the designated, trusted off-chain authority may be a judicial court represented by an individual judge. The sender of a previous transaction may claim to have been deceived by the recipient of that transaction and request remedial action to reverse the transfer. The request may be submitted by the sender or the sender's legal representative (e.g., an attorney) and may include specific information and evidence to enable the judge to make a decision to grant the request. Other transaction scenarios are also possible.

[0099] More specifically, taking the example transaction scenario as an example, a sender who sends a digital asset (e.g., digital currency) to a recipient may seek to revoke a transaction that transfers the digital asset from the sender's account to the recipient's account. For example, the sender may be deceived or defrauded by the recipient, and therefore may seek redress in a judicial court. The sender or the sender's legal representative (e.g., a lawyer) may enter a request-action input 301 in UI 304-I / F. The request-action input 301 may include information used to identify the sender, the recipient, detailed information related to the original transfer from the sender to the recipient, the requested remedial action, and specific information provided and / or as evidence that the sender was deceived or defrauded into the original transaction. According to an example embodiment, UI 304-I / F may be or include an online form with a drop-down menu, etc., for example, prompting the sender (or more generally other user) to provide specific information required to construct a formal request and provide the court with the necessary information to evaluate and approve or deny the request. It should be understood that the specific content of the request-action input 301 listed above is only an example for illustrative purposes, and more, less and / or different information may be included in other usage scenarios and / or implementations.

[0100] The UI 304-I / F can provide the request-action input 301 to the off-chain request application 304, which can transmit the request to the judicial court and (possibly conditionally) the off-chain transaction server 318. Therefore, according to an example embodiment, the off-chain request application 304 can arrange and / or format all or some specific items or elements of the request-action input 301 in a prescribed manner into a structure referred to as a "request specification" herein, and can then generate a one-way hash of the request specification. For clarity in the discussion, the one-way hash of the request specification is marked as "HASH" in all uppercase letters to identify it with a specific instance of the hash function and distinguish it from other general references to hashes, hash functions, etc. For example, the HASH can be encoded as a text string or string, such as 0xc8c48f65db62aflcea5e804e99f0139d5173cb0f. Also for the purpose of discussion, the HASH and the request specification can be considered together as a data entity referred to as HASH+request specification 303. It should be understood that this grouping is for convenience of operational description and does not necessarily need to be implemented in practice (although such grouping is not necessarily excluded). It should also be understood that there are other forms of encoding and / or representing request specifications. Some non-limiting alternative examples will be discussed below.

[0101] The HASH+ request specification 303 can then be provided to the off-chain trusted authority server 306. In an example where the trusted authority is a judicial court, the off-chain trusted authority server 306 can be a server associated with the court and configured to receive a request for mandatory action input into the blockchain. For example, the off-chain trusted authority server 306 can implement an API that is configured to receive a HASH+ request specification 303 message in an appropriate format or directly input. In other examples, the off-chain trusted authority server 306 can be a more general server associated with the court and configured to receive various court / case-related inputs, such as filing a complaint, or it can be a separate server for communicating with a judge. Other arrangements are also possible. In some examples, the HASH+ request specification 303 can be "manually" provided to the judicial court, optionally with supporting evidence for the request, such as provided by the sender's legal representative.

[0102] After the trusted authority server 306 receives the HASH+ request specification 303 off the chain, an assessment can be made as to whether the requested action is approved. Similarly, considering that the trusted authority is an example of a judicial court, the assessment can be made by a judge or other authorized representative of the court. This may require the judge to evaluate the information and evidence and then make a decision. In other examples, the information provided in the HASH+ request specification 303 may be evaluated and performed autonomously by a computer-based algorithm. How to make a decision, and whether it is beneficial to the sender (the requester of the action), is not within the scope of the example embodiment. However, further processing as a favorable decision result and processes related to the favorable decision result are within the scope of the example embodiment.

[0103] Assuming that a decision to approve the request is made (e.g., by a person or an algorithm), the HASH+ enforcement specification 305 can be published or posted to a published enforcement action server 308. In the judicial example, the HASH+ enforcement specification 305 can be a human-readable electronic file that sets forth the decision and includes an embedded alphanumeric representation of the HASH. For example, the HASH+ enforcement specification 305 can be a PDF file digitally signed by the court or uploaded by a court employee authorized to do so. The published enforcement action server 308 can be a publicly accessible server to which such decisions are published, in addition to other forms of court affairs. In the example of a judicial court, the published enforcement action server 308 can be a server such as a public access court electronic record (PACER) server, and the digital signature can be, for example, a password for a clerk to access PACER. However, other arrangements are also possible.

[0104] In addition, in the event that a decision is made to approve 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 to notify the off-chain request application 304 of the decision and provide it with identification information for accessing the now-published HASH+ enforcement specification 305 at the published enforcement action server 308.

[0105] According to an example embodiment, after the off-chain request application 304 receives the confirmation ID 307, it may in turn send the confirmation ID 307 to the event observer 310. Doing so may alert the event observer 310 of the availability of the HASH+ enforcement specification 305 at the published enforcement action server 308. The off-chain request application 304 may then also provide or send (e.g., transmit) the HASH+ request specification 303 to the off-chain transaction server 318 to also make it aware of the availability of the HASH+ enforcement specification 305 at the published enforcement action server 308 and initiate the creation of a formal request for the request action to be entered into the blockchain 302. Similarly, a party or attorney who receives a decision notification may prompt the event observer, or may enter a message with the confirmation ID on the blockchain, which transactions are directly monitored by the event observer or trust verifier.

[0106] After receiving the prompt of the confirmation ID, the event observer 310 can independently notify the trust verifier A 312-A, the trust verifier B 312-B, the trust verifier C 312-C and any other attached trust verifiers, such as Figure 3 As shown. Each trust verifier can be a secure server or other networked secure computing system associated with a corresponding organization or institution (e.g., an established bank, brokerage firm, or network service provider). Although not necessarily shown in the figure, the notification to each trust verifier can also include a confirmation ID or other information to enable access to the HASH+ enforcement specification 305 at the published enforcement action server 308.

[0107] After being notified, each of the trust verifier A 312-A, the trust verifier B 312-B, the trust verifier C 312-C, and any additional trust verifiers (which in some examples may be one or more of the nodes of the blockchain network) can then independently retrieve the HASH from the published enforcement action server 308 through their respective secure links. For ease of discussion, each independent retrieval is shown with the label HASH 309; similarly, the ellipses represent other retrievals of HASH 309 by other trust verifiers. The trusted nature of the trust verifiers together with the secure retrieval enables each trust verifier to independently guarantee the authenticity of the retrieved HASH 309. Each trust verifier can do this by encrypting its retrieved HASH 309 using a private encryption key used as an identity authentication digital signature. Therefore, trust verifier A 312-A generates an A signature (HASH) 311-A; trust verifier B 312-B generates a B signature (HASH) 311-B; trust verifier C 312-C generates a C signature (HASH) 311-C. Each trust verifier may then store or deposit its respective signature HASH in the verification request database 314. Additional signature HASHes may be generated and stored in the verification request database 314, as indicated (again) by the ellipses. Similarly, nodes themselves may serve as trust verifiers and may be randomly selected to verify a given transaction (e.g., the node that mined the last block or a random function based on data contained in the last block).

[0108] Further in accordance with the example embodiment, after receiving the HASH+request specification 303, the off-chain transaction server 318 can communicate with the request poller 316 to monitor the verification request database 314 to determine whether the signature HASH from the trusted verifier exists and / or is available. This can be done by polling the verification request database 314, or by some other arrangement or protocol. In some examples, the verification request database 314 itself can be a blockchain, where the HASH is entered into a block or placed on a blockchain or smart contract, and it can be monitored by the request poller 316 or a similar functional element. Similarly, the request can take the form of a message sent to the blockchain, and the poller can be a node that monitors messages in the blockchain message pool. Similarly, the verifier can directly use its private key to co-sign the message.

[0109] Upon determining that HASH has been added to the verification request database 314 and is available, the request poller 316 can retrieve the A signature (HASH) 311-A, the B signature (HASH) 311-B, and the C signature (HASH) 311-C (and any other signature HASHes) and provide them to the off-chain transaction server 318, as shown. Figure 3 shown.

[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 passed or sent to one of the nodes and propagated from there to some or all other nodes. As described below, the action-entry request 313 may also include a request specification and all retrieved encrypted signature HASHes, in addition to other information related to the requested action. In particular, each node of the blockchain network 302 that ultimately receives the action-entry request 313 may independently verify the HASH of each signature by decrypting each signed HASH using the publicly available trust verifier public key 320. Each such node may then verify each HASH by ensuring that they are all the same. Any inconsistent HASH value may indicate a violation or hack somewhere in the sequence described so far, resulting in further processing of the request being aborted.

[0111] Each receiving node can also 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 whether its local version of the HASH is the same as the HASH from each validator, each node can now confirm that the requested action is not only authentic and authorized, but also completely consistent with the action requested and approved by the designated off-chain trusted authority. Each receiving node can then process the request and submit the requested action to enter the blockchain, just like any requested action or transaction submitted by a blockchain user. In this way, the requested action can be efficiently executed and recorded in the blockchain. It is worth noting that each trust validator does not need to be trusted individually, because at least the majority of trust validators reach a consensus on this point: the HASH value provides a collective trust level between all trust validators.

[0112] According to an example embodiment, Figure 4AA representation of an example processing of a system-level action-entry request for a transaction scenario by a blockchain node is shown. For this example, the action-entry request is labeled 313-A. As an example and for illustrative purposes, only one node, node 302-2, is considered. It should be understood that any node that receives the action-entry request 313-A will apply the same rules when processing the request. In the figure, an expanded but still simplified view of the action-entry request 313-A is shown. For example, the extended action-entry request 313-A for the transaction scenario includes a request specification, an off-chain request indicator, an action date, and a signed HASH: A signature (HASH) 311-A, B signature (HASH) 311-B, C signature (HASH) 311-C (and any other signature HASH, as shown by the vertical ellipsis). It should be understood that other information may also be included, and the format of the request is conceptually representative and does not necessarily correspond to the format actually implemented.

[0113] Also as an example, a request specification is shown to include the identity of the asset owner and a description of the action to be applied to the owner's asset; for example, if the action is a transfer from the owner to the recipient, the recipient may optionally be provided. An example action of transferring "X" from the owner to the recipient is shown. In this example request specification, it is assumed that the recipient previously transferred a portion of the digital asset to the owner and now requests that the X amount of the digital asset that was transferred be returned through the request action. As shown, the off-chain request indicator is set to "true", indicating that this is an off-chain request that follows the rules established according to the example embodiment of the system-level implementation.

[0114] The action date is a parameter used to set a future date / time for executing the requested action. Specifying a future date for executing the action can introduce further safeguards against possible corruption or abuse of the system-level program that generates the action-entry request 313-A and transmits it to the blockchain network 302. For example, if an illegal request is somehow verified and entered into the blockchain, then the delay in executing the action built into the node protocol provides time to discover and correct the error before the action takes effect. The future date also enables any party involved in the requested action to dispute the authorization to perform the action. For example, if the action is intended to reverse the effectiveness of a transfer from the recipient to the owner by enforcing a future reverse transfer, and the owner wishes to dispute the terms or evidence submitted to the court making the decision to approve the reverse transaction request, then the built-in delay provides the owner with time to file a case to deny the request. The action date can be specified as an amount of time after a specific date. For example, the amount of time can be 72 hours, 7 days, or 30 days. Other amounts of time can also be used.

[0115] In some use scenarios, more than one action date may be specified. For example, the recipient's account may be immediately frozen for 72 hours and then frozen for 30 days to fully resolve the correctness and / or legality of the action request. Other timing arrangements are also possible, and the example embodiments are not limited to any particular timing arrangement. Instead, any type of timing arrangement is within the scope of the example embodiments.

[0116] As indicated in the box labeled "Note," the example actions included in the request specification are non-limiting. Other non-limiting examples include freezing or unfreezing the owner's access to X, transferring only a portion of X, and transferring X from the owner to an escrow account. Other actions are possible. As also noted in the note, an action date may be included in the request specification in addition to or in lieu of the request specification. If included in addition to the request specification, prescribed rules may be applied to determine which of multiple action dates takes precedence, or an unchangeable minimum delay that may be required in the node agreement. Alternatively, multiple action dates may have different effects depending on whether they are included in the request specification or located outside of the request specification.

[0117] An example processing process of the action-entry request 313-A by node 302-2 is shown in the flowchart 400-A shown below node 302-2. Upon receiving the action-entry request 313-A, node 302-2 may not immediately know that the request is for creating a mandatory entry to implement a mandatory action. According to an example embodiment, an initial check is performed to determine whether the request is an off-chain request or a regular request. For example, this can be done by checking the off-chain request indicator. If it is false, node 302-2 can process the request according to the blockchain program. For this example, where the off-chain request indicator is true, node 302-2 can continue with the off-chain request processing.

[0118] According to an example embodiment, for off-chain request processing, node 302-2 may then determine whether action-entry request 313-A includes the minimum number of signature HASHes required. More specifically, requiring the minimum number of signature HASHes to be included can significantly reduce the likelihood of a hacker successfully attacking or damaging a trust verifier. For example, in a simple analysis, if the probability of a trust verifier being successfully hacked is 0.01 (1%), then the probability of N of them being hacked is (0.01) N , this probability becomes very small as N increases. Therefore, the minimum number requirement can be seen as one of many protections to prevent hackers from successfully attacking or otherwise damaging the process. As mentioned earlier, if the minimum number requirement is not met, the request is considered "bad" and processing may be aborted. Otherwise, processing will continue.

[0119] Further in accordance with an example embodiment, if the minimum number requirement is met (achieved), node 302-2 may then decrypt each signature HASH using the trust verifier's respective public keys 320, which are assumed to be known and / or available to node 302-2. Figure 3 and Figure 4A For the example shown in , the decrypted HASH is represented as:

[0120] HASH A =Decryption [A-Signature (HASH), A-Key]

[0121] HASH B =Decryption [B-Signature (HASH), B-Key]

[0122] HASH C =Decryption [C-Signature (HASH), C-Key]

[0123] Where A-Key is the public key of trust verifier A 312-A, and similarly for trust verifier B 312-B and trust verifier C 312-C. The vertical ellipses represent similar decryptions of other signature HASHes that may be included in the action-entry request 313-A.

[0124] According to an example embodiment, node 302-2 may next test to ensure that all decrypted HASHes are identical. That is, check:

[0125] HASH A =HASH B =HASHc

[0126] Requiring all HASHes to be identical even further reduces the likelihood of a hacker successfully attacking or compromising any trusted validator. This is because a successful hack of any HASH provided by fewer than all trusted validators will cause this test to fail, revealing the hack. Only an identical hack of all trusted validators will cause the test to pass. However, as previously stated, the minimum number requirement makes this scenario extremely unlikely, if not nearly impossible. As previously stated, if the identical HASH test fails, the request is considered "bad" and processing may be aborted. Otherwise, processing will continue.

[0127] Further according to an example embodiment, if the same HASH test passes (ie, if all decrypted HASHes are the same), then node 302-2 may take each identical decrypted value as the true value of the HASH. Thus, node 302-2 may take the HASH A (or equivalently, HASH B or HASHc, etc.) is assigned to a variable called, for example, "HASHis".

[0128] According to an example embodiment, node 302-2 may then perform its own calculation of a one-way hash function applied to the request specification in action-entry request 313-A to determine a "local" value of HASH. As described above, this calculation is the same as the calculation performed by the off-chain request application 304 that initiated the off-chain request. The calculation 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 shown in flowchart 400-A, the local HASH is referred to as "ThisHASH".

[0129] Further in accordance with the example embodiment, node 302-2 may then test whether ThisHASH is the same as HASHis. That is, whether the locally calculated HASH is equal to the HASH provided independently by all trust validators. A successful result of this test now verifies the request specification, because ThisHASH is verifiably derived from the request specification and is consistent with the HASH of each of the trust validators. As previously described, if ThisHASH is not equal to HASHis, the request is considered "bad" and processing may be aborted. Otherwise, processing will continue.

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

[0131] While the above description applies only to processing by one example node 302-2, when an action-entry request 313-A is submitted to the blockchain network 302 by one of the nodes, it can be propagated to all or some of the nodes. Each node that receives the action-entry request 313-A can process it as described for node 302-2. If a majority of nodes agree that the requested entry is valid, they can submit it to a pool of "candidate" entries (e.g., candidate transactions). In conventional processing, the entry may be placed in an expected new block to be processed by miners. Successful mining can then cause the action to be recorded as validly executed in a new block of the blockchain.

[0132] 2. Example system-level scenario for smart contracts on blockchain

[0133] In an example smart contract scenario, the parties to the previous smart contract may still be blockchain users, and the designated, trusted off-chain authority may still be a judicial court represented by an individual judge. To simplify the explanation, as an example, the parties may be "User A" and "User B", and the previous smart contract may reach an agreement for User A to provide services to User B, and for User B to transfer digital asset funds to User A upon service delivery. The first emergency action of the smart contract may be to notify User A that the service has been completed, and the second emergency action may be to transfer funds from B to A. The designated caller of the first emergency action may be A, and the designated caller of the second emergency action may be B. For example, after A calls the service completion action, B may refuse to call the payment action, thereby refusing to pay A for the service. User A or User A's legal representative (e.g., a lawyer) may then request the court to act as an authorized alias for User B to perform the second emergency action.

[0134] More specifically for the example transaction scenario, the request-action input 301 may include a link to the smart contract, the identifier of the requested emergency action, and the identity of the caller (in this example, user B). If necessary, it may also include the identity of user A, and any parameters of the emergency action that may be required. Figure 3 All operations of the relevant transaction scenario can also be applied to the smart contract scenario. In addition to the request action input 301, the main difference lies in the content (and possible format) of the request specification, the mandatory action specification, and the content of the action-entry request 313.

[0135] In this example smart contract scenario, the court is asked to issue an order to enforce the smart contract payment contingency action. Assuming the court agrees, the verification process described above for the transaction scenario will be performed in the same manner. The action-entry request 313 generated and sent (input) to the blockchain network 302 will be configured to cause the nodes of the blockchain 302 to accept or allow the court to act as an authorized alias to invoke the payment contingency action.

[0136] Each node that receives the action-entry request 313 can 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 fully consistent with the action requested and approved by the designated off-chain trusted authority. Each receiving node can then process the request and submit the requested action to enter the blockchain, just like any requested action or transaction submitted by a blockchain user. In this way, the requested action can be effectively executed and recorded in the blockchain. Likewise, there is no need to trust each trust validator individually, because at least the majority of trust validators reach a consensus on this point: the HASH value provides the collective trust level of all trust validators.

[0137] Figure 4B A representation of an example processing of a system-level action-entry request for a smart contract scenario by a blockchain node according to an example embodiment is shown. For the example smart contract scenario, the action-entry request is labeled 313-B. As an example and for the purpose of illustration, only one node, node 302-2, is considered. It should be understood that any node receiving the action-entry request 313-B will apply the same rules when processing the request. In the figure, an expanded but still simplified view of the action-entry request 313-B is shown. For example, the extended action-entry request 313-B for the smart contract scenario includes a request specification, an off-chain request indicator, an action date, and a signed HASH: A signature (HASH) 311-A, B signature (HASH) 311-B, C signature (HASH) 311-C (and any other signature HASH, as shown by the vertical ellipsis). It should be understood that other information may also be included, and the format of the request is conceptually representative and does not necessarily correspond to the format actually implemented.

[0138] As an example, a request specification for an example smart contract scenario is shown to include a link to the smart contract, an identification of an emergency action, the identity of the designated caller of the emergency action, and (possibly optional) parameters for the emergency action. Other information may also be included, such as the identification of one or more parties associated with the smart contract. For example, if the operation is a transfer from an owner to a recipient, then it may be optional to provide the identity of the asset owner and a description of the actions to be applied to the asset owner and the recipient. As shown, the off-chain request indicator is set to "true", indicating that this is an off-chain request that follows the rules established according to the example embodiment of the system-level implementation.

[0139] An action date is a parameter used to set a future date / time for performing the requested action. In the example smart contract scenario, the requested action is a contingency action. As shown in the box labeled "Note", an action date (dates for one or more actions) may be included in addition or in lieu of the request specification. If an action date is additionally included in the request specification, the prescribed rules may be applied to determine which of the multiple action dates takes precedence. Alternatively, multiple action dates may have different effects depending on whether they are included in the request specification or are outside of the request specification.

[0140] An example processing process of node 302-2 for action-entry request 313-B is shown in flowchart 400-B shown below node 302-2. In this example illustration, all steps of flowchart 400-B for the smart contract scenario are the same as all steps in flowchart 400-A for the transaction scenario, except for the last step. Specifically, for the smart contract scenario, if ThisHASH is confirmed to be the same as HASHis, node 302-2 can generate a transaction indicating that a contingency action is called by a trusted entity (e.g., a court) acting as an authorized alias of the specified caller. The transaction can be placed in an entry, and the entry can then be submitted to the blockchain with an action effective date as specified in action-entry request 313-B. When an entry with the request transaction is placed in the blockchain (e.g., after mining the block in which the entry is placed), the transaction will run, resulting in the execution of the contingency action.

[0141] 3. Example Variations

[0142] As described above, the system-level implementation is specified as such because it requires modifying the behavior and / or operation of all blockchain nodes in order to be able to perform the processing of the action-entry request just described by way of example. In blockchain-based technologies, such modifications may involve adjusting and / or updating the rules that all nodes agree to (or must) follow. Therefore, introducing the functionality and operation of the system-level implementation into an existing blockchain may require a hard fork of the existing blockchain. The benefit and advantage of introducing a trusted off-chain entity (e.g., a judicial body) is the ability to take remedial action to correct otherwise irreversible blockchain actions and / or transactions, and to do so in a secure, reliable, and highly resistant to hacking or corruption, while maintaining the decentralized, distributed nature of blockchain technology, which can provide sufficient motivation for adopting such a hard fork to support a pre-forked blockchain, or for the miner community to adopt the system-level implementation through a soft fork.

[0143] There may be many additional and / or alternative aspects of implementing the system level embodiments. Some non-limiting examples are described below.

[0144] As an alternative 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 can create an encoded "action-payload" form 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; and a semantic representation of the request specification generated by an artificial intelligence engine, for example, using the request specification as input. More specifically, the semantic representation of the request specification can represent the requested action in a symbolic form that can be interpreted by a computing device. For example, the semantic representation can be encoded as a text string or string, as shown below:

[0145] {"judicialEventId":"0x4176cd550cb468ed686d0462df28b4a162c7a743",

[0146] "judicialDistrict"; "USDC-NDOI", "caseNumber": "09-cv-05453",

[0147] "judicialAction": "freeze",

[0148] "fromWallet": "0xF0b874003ECF7fb973a71B2Dbd0F656666809F35",

[0149] "toWallet": "0x05113E5A814b6162D85322f3D86868e36FB18E34",

[0150] "coinld": "0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48",

[0151] "amount": 25.0}.

[0152] In this illustrative example, assuming that the trusted authority is a judicial court, various identifiers marking the parameters of the request specification may be identified by the node process.

[0153] For this semantic representation embodiment, the node may not necessarily need to generate a hash, but rather confirm that it has recreated the semantic representation. Once confirmed, the node can interpret the semantic representation to determine the one or more actions being requested and prepare the transaction accordingly.

[0154] As another example variation, instead of or in addition to an off-chain trust verifier, each of one or more nodes may include the functionality of a trust verifier. In this embodiment, a node may be "self-trusted" such that a HASH or other form of action-payload retrieved by itself from a published enforcement action server 308 is sufficient to verify the authenticity of the retrieved data. Therefore, the action-entry request 313 does not necessarily need to include a HASH or other action-payload with multiple signatures. The effect of multiple retrievals by different entities from a published enforcement action server 308 (or the like) may be achieved by all nodes or a threshold number of multiple nodes reaching agreement on their respective retrievals instead. For example, this may follow a "majority" rule of blockchain nodes.

[0155] In another example variation, multiple retrievals of a HASH or other action-payload do not necessarily require unanimous agreement. Instead, majority agreement is sufficient. Or a threshold number of consensuses may be specified. The threshold may correspond to a majority or some other specific number. Further, signature HASHes retrieved by a particular trust verifier (or other retriever, such as a node) are compared to test for identical values, which may be specifically identified or randomly selected. Other arrangements are also possible.

[0156] Another example variation may involve implementing a node's validation actions in one or more miners of a blockchain network, such as those described in the examples above. In this way, even if the miner only processes the requested action for the entry of the block after the node or trust verifier verifies and confirms that it is valid, the miner can perform another check before spending time and energy on mining. This can serve as an additional safeguard against hacking or damage. Since such confirmation / verification can be part of the operation of the blockchain, the system-level operation of the transactions and / or smart contracts used in the example embodiments herein is at least as secure as such operations against hacking and damage, or even more secure.

[0157] In other example variations, the authority to enforce entries on the blockchain may be granted to an entity that can initiate the process of creating an action-entry request 313 or similar process 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 come directly from the entity.

[0158] In another example variation, the node process may be modified to autonomously insert a set of prescribed special emergency actions in all smart contracts, which may be actions that are considered mandatory for all smart contracts and will provide the ability to subject all smart contracts to these emergency actions.

[0159] It should be understood that it is possible to directly Figure 3 , Figure 4A and Figure 4B The operations and processes shown are modified, adjusted and / or expanded to correspond to any one or more of the above-mentioned example variations. Figure 3 , Figure 4A and Figure 4B The specific form and content of the system level embodiments are merely used as an operational example and are not intended to limit other possible embodiments.

[0160] B. Example Operation

[0161] Example operations of a system level implementation may be illustrated in a message flow diagram. Figure 5 An example of such a diagram is depicted. More specifically, Figure 5 The message flow diagram describes Figure 3 The example system-level implementation example system's various components and elements are shown as example operation sequence timeline when passing information (e.g., messages) between each other. This example message flow diagram can be considered as a system-level implementation example applicable to both transaction scenarios and smart contract scenarios. Similarly, the difference lies in: the content and format of the request action input 301, the request specification, the enforcement action specification, and the action-entry request 313.

[0162] Figure 3 Each component of Figure 5 The labeled box at the top. Vertical timelines extend below each component with time increasing downward. These timelines are not intended to convey or represent precise moments, but rather to represent the order or sequence of operations. These operations are shown as horizontal directional arrows between pairs of components and are labeled "S <n>", followed by a description of the information passed between components (where <n>are numeric labels). Some operations are shown as arrows pointing toward themselves, indicating that these operations are performed on one component and do not involve passing information to another component. Figure 5 The particular sequence shown represents one example of an operational flow and should not be construed as limiting or excluding other sequences or sequence orders that may achieve the same results.

[0163] An example use case could be a request from a user to an off-chain application 304 (for clarity, Figure 5 UI304-I / F is omitted) to provide input to start, for example, Figure 3 Request-action input 301. In step S1, the off-chain request application 304 generates a HASH+ request specification and sends (e.g., transmits or provides) the HASH+ request specification to the off-chain trusted authority server 306 in step S2. Assuming that the request is approved (e.g., after evaluation by a judge, e.g., this action is not explicitly shown in the figure), the off-chain trusted authority server 306 can publish or publish the HASH+ enforcement action specification to the published enforcement action server 308 in step S3. In step S4, the off-chain trusted authority server 306 can send or provide a confirmation ID to the off-chain request application 304.

[0164] The off-chain request application 304 may then send (or provide) the HASH+ request specification to the off-chain transaction server 318 in step S5 and send (or provide) the confirmation ID to the event observer 310 in step S6.

[0165] In response to receiving the confirmation ID, the event observer 310 may notify each of the trust verifier A 312-A, the trust verifier B 312-B, and the trust verifier C 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 issued enforcement action server 308.

[0166] In steps S8-A, S8-B and S8-C, the trust verifier A, the trust verifier B and the trust verifier C interact with the published enforcement action server 308 to retrieve the HASH independently. The double arrows of these interactions represent the two-way communication that may be involved in this retrieval process.

[0167] In step S9-A, trust verifier A signs HASH with its private key, and in step S10-A, it sends (provides) the A-signature (HASH) to the verification request database 314 for recording or storage. Similarly, in step S9-B, trust verifier B signs HASH with its private key, and in step S10-B, it sends (provides) the B-signature (HASH) to the verification request database 314 for recording or storage; in step S9-C, trust verifier C signs HASH with its private key, and in step S10-C, it sends (provides) the C-signature (HASH) to the verification request database 314 for recording or storage. Since these trust verifiers operate independently, the sequence order shown should be regarded as only one possible example. In terms of processing logic, it may only be necessary to perform the steps in step S9-<A,B,C> The HASH is encrypted and signed in step S10-<A,B,C> The signed HASH is sent to the verification request database 314 .

[0168] Step S11 represents the polling activity of the request poller 316 and its communication with the off-chain transaction server 318. In this context, the off-chain transaction server 318 may suggest that the request poller 316 poll the verification request database 314 to determine the existence and / or availability of the signed HASH. Therefore, in steps S12 and S13, the request poller 316 may participate in this polling and ultimately determine when the signed HASH can be retrieved from the verification request database 314.

[0169] In step S14, the off-chain transaction server 318 may retrieve the signed HASH from the verification request database 314, for example, in a "pull" action. Figure 3 Somewhat different, Figure 3 It is shown that the request poller 316 retrieves the signed HASHes and provides them to the off-chain transaction server 318. This illustrates an example of the types of variations of the process that can be used to achieve the same or similar results.

[0170] In step S15, the off-chain transaction server 318 creates (or generates) an off-chain action-entry request and sends the request to the blockchain network 302 in step S16. The nodes of the blockchain network 302 can be combined as above. Figure 4A and / or Figure 4B The request is processed as described in the example.

[0171] While the structure and content of off-chain action-entry requests and modifications to blockchain rules and node operations comprise certain novel aspects of example embodiments of system-level implementations that introduce many advantages and benefits of system-level implementations, the operations described above by way of example in connection with creating and delivering off-chain action-entry requests to a blockchain network promote security and safeguards that are at least equal to, if not greater than, those of conventional blockchain operations. As previously described, this is achieved without sacrificing the distributed and decentralized operational architecture underlying blockchain technology.

[0172] and Figure 3 , Figure 4A and Figure 4B Same, you can Figure 5 Modifications, adjustments and / or extensions may be made to correspond to any one or more of the above exemplary variations. Figure 5 The specific form and content of the system level embodiments are merely used as an operational example and are not intended to limit other possible embodiments.

[0173] IV. Example entry-level implementation

[0174] According to the example entry-level embodiment, the functionality of the emergency action of the blockchain smart contract can be extended to execute off-chain trigger code, which is provided by a trusted off-chain authority and is authenticated, verified and stored in a trusted secure database known and accessible to the blockchain node. In particular, the capabilities introduced according to the example entry-level embodiment do not involve or require modification of node operations at the system level. Instead, these capabilities are introduced by "connecting" certain node operations to a trusted database, which serves as a repository for trigger codes provided by trusted off-chain authorities. The example entry-level embodiment sets up a set of procedures and protocols that protect the integrity and validity of the trigger code in the repository while keeping the node operation unchanged, so that the distributed and decentralized operating principles of the blockchain remain unchanged and undisturbed.

[0175] As a result, the asset owner has the right to use these assets in blockchain transactions. That is, these assets, referred to herein as "conventional" (digital) assets, may have or represent usable value, such as for purchase, but are not themselves associated with any functionality. According to example embodiments, conventional digital assets can be effectively "converted" into a form that retains their value and has added specific functionality related to transactions. Thus, the converted assets can be used in transactions like unconverted conventional instances, but they may also be subject to one or another set of specific actions that can only be invoked by applying authenticated, verified, and confirmed trigger codes. In addition, all instances of actual trigger codes must be generated on a case-by-case basis by an off-chain trusted authority and are specific to the specific owner of the converted asset.

[0176] Traditional digital assets can be converted by "wrapping" the traditional assets in executable code that implements the desired functionality. Therefore, the converted digital assets are referred to herein as "wrapped assets" and the actions on the wrapped assets are referred to herein as "wrapping actions". Non-limiting examples of wrapping actions include transfers from an owner to a specific recipient (e.g., other users or other accounts), freezing, and unfreezing. According to example embodiments, owners of conventional assets can convert any portion of their assets into wrapped assets and thereafter use them in transactions in the same manner as conventional assets. This corresponds to the transaction scenario of the entry-level embodiment.

[0177] Similar to wrapped assets, any emergency action of a smart contract can be constructed to be executed by a specific trigger code. In this case, the trigger code can specify the link to the smart contract, the identity of the specific emergency action, and the possible parameters of the emergency action. As with the transaction scenario of the entry-level embodiment, for the smart contract scenario of the entry-level embodiment, the trigger code must be generated on a case-by-case basis by an off-chain trusted authority, but in this case, the trigger code is specific to a specific smart contract. This then corresponds to the smart contract of the entry-level embodiment.

[0178] For transaction scenarios and smart contract scenarios, example implementations of the entry-level embodiments involve components and procedures to ensure that authenticated, verified, and validated trigger codes are created and stored securely and reliably. Thus, example embodiments ensure the flexibility and versatility introduced by the wrapped digital assets and ensure that the triggered smart contracts are protected from hacker attacks and / or other forms of abuse or damage.

[0179] An example implementation of an entry-level embodiment, referred to as an entry-level implementation, will be described in more detail below.

[0180] A. Example System Architecture and Technical Description

[0181] Figure 6 is a simplified block diagram illustrating an example arrangement of components for an entry-level implementation of authenticated off-chain modification of blockchain-based transactions, according to an example embodiment. Figure 6 The block diagram of can also be viewed as describing various aspects of the operational architecture of the entry-level implementation. As shown, the example embodiments can include various components, any one or more of which can be implemented as or in one or more computing devices. Therefore, Figure 6 The components depicted in the examples may themselves be or include hardware, software, firmware, or a combination thereof. Some of the components may be determined structurally, such as a database or other form of data storage and management, while other components may be determined based on their operation or functionality. For example, operational components and / or functional components may be implemented as software and / or hardware modules, which may also be referred to as "modules" for purposes of this discussion.

[0182] Example entry level implementation can also include one or more connection mechanisms connecting each component. For example, these connection mechanisms are depicted as arrows between components. Although this interpretation should not be considered as a limitation, the direction of the arrow can represent the direction of information flow. In the present disclosure, the term "connection mechanism" refers to a mechanism that connects and promotes communication between two or more components, devices, systems or other entities. The connection mechanism can include relatively simple mechanisms such as cables or system buses and / or relatively complex mechanisms such as data packet-based communication networks (e.g., the Internet). In some cases, the connection mechanism can include intangible media, such as when the connection is at least partially wireless. The connection mechanism can also include programming communication between software and / or hardware modules or applications, such as application program interfaces (APIs). In the present disclosure, the connection can be a direct connection or an indirect connection, and an indirect connection is a connection through and / or through one or more entities (e.g., routers, switches or other network devices). Similarly, in the present disclosure, communication (e.g., the transmission or reception of data) can be direct communication or indirect communication.

[0183] As an example, Figure 3 Various components and entities of an example system-level implementation of include a blockchain network 602 having connection nodes 602-1, 602-2, .... 602-N, where the connected ellipsis indicates possible additional connection 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 action server 608, an event observer 610, a trust verifier A 612-A, a trust verifier B 612-B, a trust verifier C 612-C, a request verification server 614, a verification request database 616, and a trust verifier public key 620. The ellipsis after the trust verifier C 612-C indicates that there may be other trust verifiers. In an example embodiment, the off-chain request application 604 can be an application configured to execute on a computing device such as a PC, a laptop, a smartphone, or a server.

[0184] The computational and / or functional roles of example components and entities can be understood by considering example operational scenarios involving blockchain transactions and blockchain smart contracts. Both scenarios involve similar operations and, in some respects, identical operations. However, to help clarify the distinction between the two scenarios, operational examples for both scenarios are presented below.

[0185] 1. Example entry-level scenario of blockchain transactions

[0186] In an example transaction scenario of an entry-level embodiment, a sender who sends a packaged digital asset to a recipient may seek to revoke the effectiveness of a transaction that transfers the packaged digital asset from the sender's account to the recipient's account. As with the system-level description, the sender may be deceived or defrauded by the recipient, so it can seek redress in a judicial court. In an example transaction scenario of an entry-level embodiment, a remedial action can be formulated by generating or creating a trigger code associated with the correct emergency action for the packaged digital asset. For the current example, the remedial emergency action can be to transfer the packaged digital asset from the recipient back to the sender. Therefore, the trigger code can designate the recipient as the owner of the packaged digital asset, the transfer operation as an emergency action, and the initial sender as the target of the requested transfer. For example, this information can be provided as a request action input 601.

[0187] Thus, the sender or the sender's legal representative (e.g., an attorney) can enter a request-action input 601 at UI 604-I / F. The request-action input 601 may include information used to identify the sender, the recipient, details about the original transfer from the sender to the recipient, the requested remedial action, and specific information that provides and / or serves as evidence that the sender was deceived or defrauded into the original transaction. According to an example embodiment, UI 604-I / F can be or include an online form with a drop-down menu or the like, for example, prompting the sender (or more generally other user) to provide specific information required to construct a formal request and provide the court with the necessary information to evaluate and approve or deny the request.

[0188] The UI 604-I / F can provide the request-action input 601 to the off-chain request application 604, and the off-chain request application 604 can transmit the request to the judicial court. Therefore, according to the example embodiment, the off-chain request application 604 can arrange and / or format all or some specific items or elements of the request-action input 601 into a request specification, and can then generate a one-way hash of the request specification. As with the discussion of the system-level embodiment, the one-way hash of the request specification is marked in all uppercase letters as HASH. Also for the purpose of discussion, the HASH and the request specification can be referred to together as the data entity of HASH+request specification 603. It should be understood that this grouping is for the convenience of operational description and does not necessarily need to be implemented in practice (although grouping is not necessarily excluded).

[0189] Then, the HASH+ request specification 603 can be provided to the off-chain trusted authority server 606. In the example where the trusted authority is a judicial court, the off-chain trusted authority server 606 can be a server associated with the court and configured to receive a request for mandatory action input into the blockchain. For example, the off-chain trusted authority server 606 can implement an API that is configured to receive a HASH+ request specification 603 message in an appropriate format or directly input. In other examples, the off-chain trusted authority server 606 can be a more general server associated with the court and configured to receive various court / case-related inputs, including the off-chain trusted authority server 606. Other arrangements are also possible. In some examples, the HASH+ request specification 603 can be "manually" provided to the judicial court together with the supporting evidence of the request, such as provided by the sender's legal representative.

[0190] After the off-chain trusted authority server 606 receives the HASH+Request Specification 603, an evaluation may be made as to whether the requested action is approved. Again, considering the example of the trusted authority being 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 described in the system-level embodiment.

[0191] Assuming that a decision to approve the request is made (e.g., by a person or an algorithm), the HASH+ enforcement specification 605 can be published or posted to a published enforcement action server 608. In the judicial example, the HASH+ enforcement specification 605 can be a human-readable electronic file that sets forth the decision and includes an embedded alphanumeric representation of the HASH. For example, the HASH+ enforcement specification 605 can be a PDF file digitally signed by the court. The published enforcement action server 608 can be a publicly accessible server to which such decisions are published, in addition to other forms of court affairs. In the example of a judicial court, the published enforcement action server 608 can be a server such as a PACER server. However, other arrangements are possible.

[0192] In addition, in the event that a decision is made to approve the request, the off-chain trusted authority server 606 may provide or send (e.g., transmit) a confirmation ID 607 to the off-chain requesting application 604 to notify the off-chain requesting application 604 of the decision and provide it with identification information for accessing the now-published HASH+ enforcement specification 605 at the published enforcement action server 608.

[0193] According to an example embodiment, after the off-chain request application 604 receives the confirmation ID 607, it may in turn send the confirmation ID 607 to the event observer 610. Doing so may alert the event observer 610 to the availability of the HASH+ enforcement specification 605 at the published enforcement action server 608. The off-chain request application 604 may then also provide or send (e.g., transmit) the HASH+ request specification 603 to the request verification server 614 so that it is also aware of the availability of the HASH+ enforcement specification 605 at the published enforcement action server 608 and initiate the creation of the corresponding trigger code.

[0194] Upon receiving the prompt for the confirmation ID, event observer 610 may independently notify each of trust verifier A 612-A, trust verifier B 612-B, trust verifier C 612-C, and any other trust verifiers, such as Figure 6 As shown. Each trust verifier can be a secure server or other networked secure computing system associated with a corresponding organization or institution (e.g., an established bank, brokerage firm, or network service provider). Although not necessarily shown in the figure, the notification to each trust verifier can also include a confirmation ID or other information to enable access to the HASH+ enforcement specification 605 at the published enforcement action server 608.

[0195] After being notified, each of the trust verifier A 612-A, trust verifier B 612-B, trust verifier C 612-C, and any other trust verifiers can then independently retrieve the HASH from the published enforcement action server 608 through their respective secure links. For ease of discussion, each independent retrieval is labeled HASH 609; similarly, ellipses represent other retrievals of HASH 609 by other trust verifiers. The trusted nature of the trust verifiers, together with the secure retrieval, enables each trust verifier to independently guarantee the authenticity of the retrieved HASH 609. Each trust verifier can do this by encrypting its retrieved HASH 609 using a private encryption key used as an identity authentication digital signature. Therefore, trust verifier A 612-A generates an A signature (HASH) 611-A; trust verifier B 612-B generates a B signature (HASH) 611-B; trust verifier C 612-C generates a C signature (HASH) 611-C. Each trust verifier may then store or deposit the respective signature HASH in the request verification server 614. Other signature HASHes may be provided to the request verification server 614, as (again) indicated by ellipses.

[0196] The request verification server 614 can then perform operations to verify and confirm the HASH and the authenticated, verified and confirmed trigger code, and store it in the verification request database. At this point, the trigger code can be used to trigger the action associated with the request-action input 601. For this example, as described above, the trigger code can specify the recipient as the owner of the packaged digital asset, the transfer action as an emergency action, and the initial sender as the target of the request transfer. In an example embodiment, the verified HASH 613 can be used as a trigger code, and the confirmation and verification process of the request verification server 614 can be regarded as the confirmation and verification of the trigger code.

[0197] The example follow-up scenario is in Figure 6 The block diagram of the block chain network 602 is shown in the box surrounding the block chain network 602 in the upper right corner. In the first step marked "1", the action is requested by providing a HASH+action request 615 to the node 602-2. The HASH+action request 615 can alert the node 602-2 to the existence and availability of the trigger code associated with the owner's packaging asset specified in the action request. In the second step marked "2", the node 602-2 can then extract the trigger code from the verification request database, which is the verified HASH 613 in this example. Since the database is trusted by the block chain network 602, the node 602-2 can perform the emergency action associated with the trigger code. In this example, the action will result in a certain amount of packaging assets being transferred from the owner to the original sender in the disputed transaction. Some or all nodes can process according to the block chain operation. Therefore, the HASH+action request 615 can be propagated to all nodes or a certain number of nodes, and all nodes that receive it can participate in the processing just described.

[0198] According to an example embodiment, Fig. 7A FIG. 6 shows an example process of requesting verification server 614 for an item-level action-item transaction scenario. Figure 6 as well as Fig. 7A As shown, the request verification server 614 also receives the signed HASH: A signature (HASH) 611-A, B signature (HASH) 611-B, C signature (HASH) 611-C (and any other signature HASH, as shown by the vertical ellipsis). In the figure, an extended but still simplified view of the HASH+ request specification 603-A is shown. For example, the extended HASH+ request specification 603-A for a transaction scenario includes a request specification, an off-chain request indicator, and an action date. It should be understood that other information may also be included, and the format of the request is conceptually representative and does not necessarily correspond to the format actually implemented.

[0199] Also as an example, a request specification is shown as including the identity of the asset owner and a description of the action to be applied to the owner's asset; for example, if the action is a transfer from the owner to a recipient, the recipient may optionally be provided. Again, in this case, the asset is a wrapped asset. An example action is shown that transfers "X" from the owner to the recipient. In this example request specification, it is assumed that the recipient previously transferred a portion of the digital asset to the owner and now requests that the X amount of the digital asset that was transferred be returned via the request action. As shown, the off-chain request indicator is set to "true".

[0200] The action date is a parameter for setting a future date / time for executing the requested action. Specifying a future date for executing the action can introduce further safeguards to prevent possible damage or abuse of the entry-level program that generates the trigger code (in this example, the verified HASH613) and transmits it to the verification request database 614. For example, if an illegal request is somehow verified and entered into the trigger code, the built-in delay in executing the action provides time for discovering and correcting the error before the action takes effect. The future date can also enable any party involved in the request action to object to the authorization to implement the action. For example, if the action is intended to reverse the effectiveness of the transfer from the recipient to the owner by enforcing a future reverse transfer, and the owner wishes to object to the terms or evidence submitted to the court that makes the decision to approve the reverse transaction request, then the built-in delay provides the owner with time to file a case to reject the request. The action date can be specified as a time amount after a specific date. For example, the time amount can be 72 hours, 7 days, or 30 days. Other time amounts can also be used.

[0201] As indicated in the box labeled "Note," the example actions included in the request specification are non-limiting. Other non-limiting examples include freezing or unfreezing the owner's access to X, transferring only a portion of X, and transferring X from the owner to an escrow account. Other actions are possible. As also noted in the note, an action date may be included in addition to or in the alternative to the request specification. If included in addition to the request specification, the specified rules may be applied to determine which of multiple action dates takes precedence. Alternatively, multiple action dates may have different effects depending on whether they are included in the request specification or located outside of the request specification.

[0202] An example process of requesting verification server 614 is shown in flowchart 700 shown below requesting verification server 614. According to an example embodiment, requesting verification server 614 can determine whether it has received the required minimum number of signature HASHes. As described above, requiring the inclusion of a minimum number of signature HASHes can significantly reduce the likelihood of a hacker successfully attacking or damaging a trust verifier. As previously described, if the minimum number requirement is not met, the request is considered "bad" and processing may be terminated. Otherwise, processing will continue.

[0203] Further in accordance with an example embodiment, if the minimum number requirement is met (achieved), the request verification server 614 may then decrypt each signature HASH using the trust verifier's respective public keys 620, which are assumed to be known and / or available to the request verification server 614. Figure 6 and Fig. 7A For the example shown in , the decrypted HASH is represented as:

[0204] HASH A =Decryption [A-Signature (HASH), A-Key]

[0205] HASH B =Decryption [B-Signature (HASH], B-Key]

[0206] HASH C =Decryption [C-Signature (HASH], C-Key]

[0207] Where A-Key is the public key of trust verifier A 612-A, and similarly for trust verifier B 612-B and trust verifier C 612-C. The vertical ellipsis indicates similar decryption of other signature HASHs that may be performed.

[0208] According to an example embodiment, the request verification server 614 may then test to ensure that all decrypted HASHes are the same. That is, check:

[0209] HASH A =HASH B =HASHc

[0210] Requiring all HASHes to be identical even further reduces the likelihood of a hacker successfully attacking or compromising any trusted validator. This is because a successful hacking attempt by any HASH provided by less than all trusted validators will cause the test to fail, thereby exposing the hacking attempt. Only by performing the same hacking attempt on all trusted validators can the test pass. However, it should be noted that the minimum number requirement makes this situation extremely unlikely, if not nearly impossible. As previously mentioned, if the identical HASH test fails, the request is considered "bad" and processing may be aborted. Otherwise, processing will continue.

[0211] Further according to an example embodiment, if the same HASH test passes (i.e., if all decrypted HASHes are the same), the request verification server 614 may take each identical decrypted value as the true value of the HASH. A (or equivalently, HASH B or HASHc, etc.) is assigned to a variable called, for example, "HASHis".

[0212] According to an example embodiment, the request verification server 614 may then perform its own calculation of the one-way hash function applied to the request specification in the HASH+request specification 603-A to determine the "local" value of HASH. As described above, the calculation is the same as the calculation performed by the off-chain request application 604 that initiated the off-chain request. The calculation can utilize any standard and / or known one-way hash function that meets the specified complexity. Non-limiting examples of such one-way hash functions include SHA-256, SHA-512, RIPEMD-320, and Whirlpool. As shown in flowchart 700, the local HASH is referred to as "ThisHASH".

[0213] Further in accordance with an example embodiment, the request verification server 614 can then test whether ThisHASH is the same as HASHis. That is, whether the locally calculated HASH is equal to the HASH provided independently by all trust verifiers. A successful result of this test now verifies the request specification because ThisHASH is verifiably derived from the request specification and is consistent with the HASH of each trust verifier in the trust verifier. As previously described, if ThisHASH is not equal to HASHis, the request is considered "bad" and processing may be aborted. Otherwise, processing will continue.

[0214] Finally, if it is confirmed that ThisHASH is the same as HASHis, the request verification server 614 can store the verified HASH 613 in the verification request database 616.

[0215] 2. Example entry-level scenario for smart contracts on the blockchain

[0216] In an example smart contract scenario, a smart contract can be constructed so that emergency actions can be triggered by trigger codes stored in a verification request database or otherwise provided to the contract. The parties to the previous smart contract can still be blockchain users, and the designated, trusted off-chain authority can still be a judicial court represented by an individual judge. As with the system-level example, in a simple example, the parties can be "user A" and "user B", and the previous smart contract can reach an agreement for user A to provide services to user B, and for user B to transfer money to user A when the service is delivered. The first emergency action of the smart contract can be to notify user A that the service has been completed, and the second emergency action can be to transfer funds from B to A. The designated caller of the first emergency action can be A, and the designated caller of the second emergency action can be B. For example, after A calls the service completion action, B may refuse to call the payment operation, thereby refusing to pay A for the service. User A or user A's legal representative (such as a lawyer) can then request the court to act as an authorized alias for user B to perform the second emergency action.

[0217] More specifically for the example transaction scenario, the request-action input 601 may include a link to the smart contract, an identifier of the requested emergency action, and any parameters of the required emergency action. Figure 6 All operations related to the transaction scenario can also be applied to the smart contract scenario. In addition to the request-action input 601, the main difference is the content (and possible format) of the request specification, the mandatory action specification, and the more general content of the emergency action that may be called.

[0218] In this example smart contract scenario, the court is asked to issue an order to enforce a smart contract payment contingency action. Assuming the court agrees, the verification process described above for the transaction scenario will be performed in the same manner. The verified HASH613 will be the trigger for the requested contingency action. Figure 6 The example follow-up actions shown in the upper right box also apply to smart contract scenarios.

[0219] Figure 7B A representation of an example processing procedure of the request verification server 614 for an item-level action-item for a transaction scenario is shown according to an example embodiment. Fig. 7A The discussion also applies to Figure 7B , it's just that the request specification provides different information. In particular, in HASH+ request specification 603-B, the request specification for the example smart contract scenario is shown as including a link to the smart contract, an identification of the emergency action, and (possibly optional) parameters for the emergency action. Other information may also be included, such as the identity of one or more parties to the smart contract. For example, if the action is a transfer from an asset owner to a recipient, then one may choose to provide the identities of the asset owner and recipient and a description of the action that applies to the asset owner and recipient.

[0220] 3. Example Variations

[0221] There may be many additional and / or alternative aspects to implementing the item level embodiment, most of which are the same as the system level embodiment, so they will not be described in detail here.

[0222] It should be understood that it is possible to directly Figure 6 , Fig. 7A and Figure 7B The operations and processes shown are modified, adjusted and / or expanded to correspond to any one or more of the above-mentioned example variations. Figure 6 , Fig. 7A and Figure 7B The specific form and content of is merely used as an operational example of an entry-level embodiment and is not intended to limit other possible embodiments.

[0223] B. Example Operation

[0224] Example operations of item-level implementation can be illustrated in a message flow diagram. Figure 8 Depicts an example message flow diagram for item-level implementation. Its format is similar to Figure 5 The format is the same as described in , only some components are different.

[0225] Figure 6 Each component of Figure 8 The top box indicates that Figure 5 As with the Components, vertical timelines extend below each component, with time increasing downward. These timelines are not intended to convey or represent precise moments in time, but rather to represent a sequence or order of operations. These operations are shown as horizontal arrows between pairs of components and are labeled "T <n>", followed by a description of the information passed between components (where <n>are numeric labels). Some operations are shown as arrows pointing to themselves, which indicates that these operations are performed on one component and do not involve passing information to another component. It should be understood that Figure 8 The particular sequence shown represents one example of an operational flow and should not be construed as limiting or excluding other sequences or sequence orders that may achieve the same results.

[0226] An example use case could be a request from a user to an off-chain application 604 (for clarity, Figure 8 UI304-I / F is omitted) to provide input to start, for example, Figure 6 Request-action input 601. In step T1, the off-chain request application 604 generates a HASH+ request specification and sends (e.g., transmits or provides) the HASH+ request specification to the off-chain trusted authority server 606 in step T2. Assuming that the request is approved (e.g., after evaluation by a judge, e.g., this action is not explicitly shown in the figure), the off-chain trusted authority server 606 can publish or publish the HASH+ enforcement action specification to the published enforcement action server 608 in step T3. In step T4, the off-chain trusted authority server 606 can send or provide a confirmation ID to the off-chain request application 604.

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

[0228] In response to receiving the confirmation ID, event observer 610 may notify each of trust verifier A 612-A, trust verifier B 612-B, and trust verifier C 612-C in steps T7-A, T7-B, and T7-C, respectively. Each notification may also include (or be) the confirmation ID or some other identifier suitable for retrieving information from the published enforcement action server 608.

[0229] In steps T8-A, T8-B and T8-C, trust verifier A, trust verifier B and trust verifier C interact with the published enforcement action server 608 and retrieve HASH independently. The double arrows of these interactions represent the two-way communication that may be involved in this retrieval process.

[0230] In step T9-A, trust verifier A signs HASH with its private key, and in step T10-A, it sends (provides) the A-signature (HASH) to the request verification server 614 for recording or storage. Similarly, in step T9-B, trust verifier B signs HASH with its private key, and in step T10-B, it sends (provides) the B-signature (HASH) to the request verification server 614 for recording or storage; in step T9-C, trust verifier C signs HASH with its private key, and in step T10-C, it sends (provides) the C-signature (HASH) to the request verification server 614 for recording or storage. Since these trust verifiers operate independently, the sequence order shown should be regarded as only one possible example. In terms of processing logic, it may only be necessary to perform the steps in step T9-<A,B,C> The HASH is encrypted and signed in step T10-<A,B,C> The signed HASH is sent to the request verification server 614.

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

[0232] exist Figure 8 An example subsequent scenario is shown in the dashed box in the lower right corner. As shown, in step T13, the input HASH+request action is input to the blockchain network 602. This can represent a user or a legal representative of the user submitting an entry to the blockchain, alerting it to the existence and availability of the trigger code in the verification request database 616. Then in step T14, one or more nodes of the blockchain extract the trigger code (in this case, the verified HASH) and operate on it as described above.

[0233] and Figure 6 , Fig. 7A and Figure 7B Same, you can Figure 8 Modifications, adjustments and / or extensions may be made to correspond to any one or more of the above exemplary variations. Figure 8 The specific form and content of is merely used as an operational example of an entry-level embodiment and is not intended to limit other possible embodiments.

[0234] V. Example Method

[0235] A. Example System-Level Approach

[0236] Fig. 9 and Fig.10 are flow charts illustrating respective example methods 900 and 1000 of example system level embodiments. Fig. 9 and Fig.10 The methods shown can all be performed by a computing system or computing device that is configured to operate as a node of a node network operating a blockchain. For example, non-limiting examples of the computing system or computing device include computing device 100 or server cluster 204. However, the method can be performed by other types of devices or device subsystems. For example, the method can be performed by a portable computer (e.g., a notebook computer or a tablet device).

[0237] The embodiments of Figures 900 and 1000 may be simplified by removing any one or more of the features shown therein. In addition, these embodiments may be combined with the features, aspects and / or implementations described herein or in any of the previous figures.

[0238] Example methods 900 and 1000 may also be expressed as instructions that can be executed by one or more processors of one or more server devices of a system or virtual machine or container. For example, these instructions may take the form of software and / or hardware and / or firmware instructions. In an example embodiment, these instructions may be stored on a non-transitory computer-readable medium. When these instructions are executed by one or more processors of the one or more servers, the instructions cause the one or more servers to perform various operations of the example methods.

[0239] An example method 900 for a transaction scenario for a system level embodiment is first described.

[0240] Block 902 of example method 900 may involve receiving a request message for placing an entry on a blockchain. For example, the request message may be received at UI 304-I / F. The request message may include (i) a request specification for the entry, the request specification including an action and an identity of at least one party to be acted upon by the action, (ii) an indicator that the entry has been authorized by a trusted entity, (iii) a plurality of cryptographic verification codes generated by a corresponding plurality of trust verifiers, each of which may include an encoded action-payload provided by a trusted entity and cryptographically signed by a corresponding one of the trust verifiers. In some examples, the actual identity of the at least one party may not be known. Instead, other forms of links to the party may be used, such as an address or cryptographic key. These may be used in place of the actual identity.

[0241] Block 904 of the example method 900 may involve applying a public encryption key of each respective trust verifier to the respective encrypted verification code to decrypt the respective encoded action-payload.

[0242] Block 906 of the example method 900 may involve performing a first verification that at least a threshold number of decrypted corresponding encoded action-payloads are identical.

[0243] Finally, block 908 of the example method 900 may involve, in response to performing at least the first validation, submitting an entry for block processing to be added to the blockchain.

[0244] According to an example embodiment, the example method 900 may also involve applying the payload-encoder function to the request specification to derive a local version of the encoded action-payload, and then performing a second verification to verify that the local version of the encoded action-payload is identical to the local version of each of the at least threshold number of identical decrypted corresponding encoded action-payloads. In such an arrangement, submitting the entry for block processing may require submitting the entry for block processing to be added to the blockchain in response to performing both the first verification and the second verification.

[0245] According to example embodiments, the threshold number may be the total number of the plurality of numbers, a majority of the total number of the plurality of numbers, or an integer closest to a specified proportion of the total number of the plurality of numbers.

[0246] According to an example embodiment, performing a first verification that at least a threshold number of decrypted corresponding encoded action-payloads are identical may require selecting a predetermined number of decrypted corresponding encoded action-payloads for comparison. Furthermore, the threshold number may be equal to the predetermined number. With this arrangement, the selection may be random and / or based on one of the specified identities of a particular trust verifier in the corresponding plurality of trust verifiers.

[0247] According to an example embodiment, the encoded action-payload provided by the trusted entity may be a hash, and the payload-encoder function may be a hash function. In this arrangement, each corresponding encoded action-payload may be a corresponding hash value, and the local version of the encoded action-payload may be a local hash value. In addition, in this arrangement, a first verification that verifies that at least a threshold number of decrypted corresponding encoded action-payloads are identical may involve verifying that at least a threshold number of corresponding hash values ​​are identical, and a second verification that verifies that the local version of the encoded action-payload is identical to the local version of each of the at least threshold number of identical decrypted corresponding encoded action-payloads may involve verifying that the local hash value is identical to at least a threshold number of identical corresponding hash values.

[0248] According to an example embodiment, the encoded action-payload provided by the trusted entity may include a semantic representation of the request specification that was created by the trusted entity and that can be interpreted by the computing device.

[0249] According to an example embodiment, the encoded action-payload provided by the trusted entity may include a semantic representation of the request specification, which is generated by an artificial intelligence engine based on a natural language description of the request specification and can be interpreted by a computing device.

[0250] According to example embodiments, submitting an entry for addition to the blockchain for block processing may involve including the entry in a candidate block that is input into a mining process.

[0251] According to an example embodiment, the at least one party may be associated with a specific digital asset recorded in a blockchain. The action may be: transferring a specified amount of a specific digital asset from the at least one party to another party associated with the blockchain; freezing a specified amount of a specific digital asset; unfreezing a specified amount of a specific digital asset; transferring a specified amount of a specific digital asset from the at least one party to a custodial account associated with the blockchain; and / or transferring a specified amount of a specific digital asset from the at least one party to a specific account associated with the blockchain.

[0252] According to an example embodiment, performance of an action may be delayed a specified amount of time from a specified date and time, or scheduled for a specific date and time.

[0253] Next, an example method 1000 for a smart contract scenario for a system-level embodiment is described.

[0254] Box 1002 of example method 1000 may involve receiving a request message for placing an entry on the blockchain, the entry being configured to invoke an emergency action of a smart contract previously entered on the blockchain. For example, the request message may be received at UI 304-I / F. The request message may include: (i) a request specification including a link to the smart contract, an identification of the emergency action, and an identity of a designated action caller authorized to invoke the emergency action, (ii) an indicator indicating that the entry has been authorized by a trusted entity, and (iii) a plurality of encrypted verification codes generated by corresponding plural trust verifiers. Each encrypted verification code may include an encoded action-payload provided by a trusted entity and cryptographically signed by a corresponding one of the trust verifiers. Non-limiting examples of links to smart contracts include: an address of a location (e.g., a URL), a pointer to a database entry, and an address on the blockchain. In some examples, the actual identity of the designated action caller may not be known. Instead, other forms of links to the designated action caller, such as an address or an encryption key, may be used. These may be used in place of the actual identity. In some examples, the identity of the designated action caller may be ignored.

[0255] Block 1004 of the example method 1000 may involve applying a public encryption key of each respective trust verifier to the respective encrypted verification code to decrypt the respective encoded action-payload.

[0256] Block 1006 of the example method 1000 may involve performing a first verification that at least a threshold number of decrypted corresponding encoded action-payloads are identical.

[0257] Block 1008 of the example method 1000 may involve, in response to performing at least the first authentication, generating a transaction specification and placing it in the entry. The generated transaction specification may include instructions for performing the identified contingency action, the contingency action being authorized by a trusted entity that is an authentication alias of the specified action invoker.

[0258] Finally, block 1010 of the example method 1000 may involve submitting an entry for block processing to be added to the blockchain.

[0259] According to an example embodiment, the example method 1000 may also involve applying the payload-encoder function to the request specification to derive a local version of the encoded action-payload, and then performing a second verification to verify that the local version of the encoded action-payload is identical to the local version of each of the at least threshold number of identical decrypted corresponding encoded action-payloads. In such an arrangement, generating the transaction specification and placing it in the entry may require generating the transaction specification and placing it in the entry in response to performing both the first verification and the second verification.

[0260] According to an example embodiment, the example method 1000 may also involve executing an identified contingency action previously input into the smart contract on the blockchain.

[0261] According to an example embodiment, the request specification may also include one or more parameters of the identified emergency action.

[0262] According to example embodiments, the threshold number may be the total number of the plurality of numbers, a majority of the total number of the plurality of numbers, or an integer closest to a specified proportion of the total number of the plurality of numbers.

[0263] According to an example embodiment, performing a first verification that at least a threshold number of decrypted corresponding encoded action-payloads are identical may require selecting a predetermined number of decrypted corresponding encoded action-payloads for comparison. Furthermore, the threshold number may be equal to the predetermined number. With this arrangement, the selection may be random and / or based on one of the specified identities of a particular trust verifier in the corresponding plurality of trust verifiers.

[0264] According to an example embodiment, the encoded action-payload provided by the trusted entity may be a hash, and the payload-encoder function may be a hash function. In this arrangement, each corresponding encoded action-payload may be a corresponding hash value, and the local version of the encoded action-payload may be a local hash value. In addition, in this arrangement, a first verification that verifies that at least a threshold number of decrypted corresponding encoded action-payloads are identical may involve: verifying that at least a threshold number of corresponding hash values ​​are identical, and a second verification that verifies that the local version of the encoded action-payload is identical to the local version of each of the at least threshold number of identical decrypted corresponding encoded action-payloads may involve: verifying that the local hash value is identical to at least a threshold number of identical corresponding hash values.

[0265] According to an example embodiment, the encoded action-payload provided by the trusted entity may include a semantic representation of the request specification that was created by the trusted entity and that can be interpreted by the computing device.

[0266] According to an example embodiment, the encoded action-payload provided by the trusted entity may include a semantic representation of the request specification, which is generated by an artificial intelligence engine based on a natural language description of the request specification and can be interpreted by a computing device.

[0267] According to example embodiments, submitting an entry for addition to the blockchain for block processing may involve including the entry in a candidate block input into a mining process.

[0268] According to example embodiments, executing an identified contingency action previously input into a smart contract on the blockchain may entail delaying its execution by a specified amount of time from a specified date and time, or scheduling its execution for a specific date and time.

[0269] B. Example Item-Level Method

[0270] Fig.11 and Fig.12 are flow charts illustrating respective example embodiments of methods 1100 and 1200 of example entry-level embodiments. Fig.11 and Fig.12 The methods shown can all be performed by a computing system or computing device that is configured to operate as a database server to verify and store encoded action triggers of digital assets input to a blockchain network. For example, non-limiting examples of the computing system or computing device include computing device 100 or server cluster 104. However, the method can be performed by other types of devices or device subsystems. For example, the method can be performed by a portable computer (e.g., a notebook computer or a tablet device).

[0271] The embodiments of Figures 1100 and 1200 may be simplified by removing any one or more of the features shown therein. In addition, these embodiments may be combined with the features, aspects and / or implementations described herein or in any of the previous figures.

[0272] Example methods 1100 and 1200 may also be expressed as instructions that can be executed by one or more processors of one or more server devices of a system or virtual machine or container. For example, these instructions may take the form of software and / or hardware and / or firmware instructions. In an example embodiment, these instructions may be stored on a non-transitory computer-readable medium. When these instructions are executed by one or more processors of the one or more servers, the one or more servers are caused to perform various operations of the example methods.

[0273] First, an example method 1100 for a transaction scenario of an item-level embodiment is described.

[0274] Block 1102 of example method 1100 may involve receiving a request message for an action trigger for verifying and storing a verification of a digital transaction input onto the blockchain network. The request may include a request message containing a request specification including an action and an identity of at least one party associated with a digital asset acted upon by the action. Non-limiting examples of links to smart contracts include an address of a location (e.g., a URL), a pointer to a database entry, and an address on a blockchain. In some examples, the actual identity of at least one party may not be known. Instead, other forms of links to the party, such as an address or an encryption key, may be used. These may be used in lieu of an actual identity.

[0275] Block 1104 of the example method 1100 may involve receiving a plurality of encrypted verification codes independently generated by a corresponding plurality of trust verifiers. Each encrypted verification code may include a trigger code originating from a trusted entity and cryptographically signed by a corresponding one of the trust verifiers.

[0276] Block 1106 of the example method 1100 may involve applying a public encryption key of each respective trust verifier to the respective encrypted verification code to decrypt the respective trigger code.

[0277] Block 1108 of the example method 1100 may involve performing a first verification that at least a threshold number of decrypted corresponding trigger codes are the same.

[0278] Block 1110 of the example method 1100 may involve applying an encoder function to the request specification to derive a local version of a trigger code associated with the action.

[0279] Block 1112 of the example method 1100 may involve performing a second verification that the local version of the trigger code is identical to the local version of each of the at least threshold number of identical decrypted corresponding trigger codes.

[0280] Finally, block 1114 of the example method 1100 may involve storing the trigger code as a validated action trigger in a database associated with the computing system.

[0281] According to example embodiments, the threshold number may be the total number of the plurality of numbers, a majority of the total number of the plurality of numbers, or an integer closest to a specified proportion of the total number of the plurality of numbers.

[0282] According to an example embodiment, performing a first verification that at least a threshold number of decrypted corresponding trigger codes are the same may require selecting a predetermined number of decrypted corresponding encoded action-payloads for comparison. Furthermore, the threshold number may be equal to the predetermined number. With this arrangement, the selection may be random and / or based on one of the specified identities of a particular trust verifier in the corresponding plurality of trust verifiers.

[0283] According to an example embodiment, the trigger code provided by the trusted entity may be a hash, and the encoder function may be a hash function. In this arrangement, each corresponding trigger code may be a corresponding hash value, and the local version of the trigger code may be a local hash value. In addition, in this arrangement, a first verification that verifies that at least a threshold number of decrypted corresponding trigger codes are the same may involve verifying that at least a threshold number of corresponding hash values ​​are the same, and a second verification that verifies that the local version of the trigger code is the same as the local version of each of the at least threshold number of identical decrypted corresponding trigger codes may involve verifying that the local hash value is the same as at least a threshold number of identical corresponding hash values.

[0284] According to an example embodiment, the trigger code provided by the trusted entity may include a semantic representation of the request specification that is created by the trusted entity and can be interpreted by the computing device.

[0285] According to an example embodiment, the trigger code provided by the trusted entity may include a semantic representation of the request specification, which is generated by an artificial intelligence engine according to a natural language description of the request specification and can be interpreted by a computing device.

[0286] According to an example embodiment, the at least one party may be associated with a specific digital asset recorded in a blockchain. The action may be: transferring a specified amount of a specific digital asset from the at least one party to another party associated with the blockchain; freezing a specified amount of a specific digital asset; unfreezing a specified amount of a specific digital asset; transferring a specified amount of a specific digital asset from the at least one party to a custodial account associated with the blockchain; and / or transferring a specified amount of a specific digital asset from the at least one party to a specific account associated with the blockchain.

[0287] According to an example embodiment, performance of an action may be delayed a specified amount of time from a specified date and time, or scheduled for a specific date and time.

[0288] According to an example embodiment, example method 1100 may further involve, in response to receiving a request from a node device of the blockchain network, sending a copy of the verified trigger code to the node device.

[0289] Next, an example method 1200 for a smart contract scenario for an entry-level implementation is described.

[0290] Block 1202 of the example method 1200 may involve receiving a request message for verifying and storing a verified action trigger input to a smart contract on a blockchain network. The request message may include a request specification including a link to the smart contract and an identifier of a contingency action for the smart contract. Non-limiting examples of a link to a smart contract include: an address of a location (e.g., a URL), a pointer to a database entry, and an address on a blockchain.

[0291] Block 1204 of the example method 1200 may involve receiving a plurality of encrypted verification codes independently generated by a respective plurality of trust verifiers, each encrypted verification code including a trigger code originating from a trusted entity and cryptographically signed by a respective one of the trust verifiers.

[0292] Block 1206 of the example method 1200 may involve applying a public encryption key of each respective trust verifier to the respective encrypted verification code to decrypt the respective trigger code.

[0293] Block 1208 of the example method 1200 may involve performing a first verification that at least a threshold number of decrypted corresponding trigger codes are the same.

[0294] Block 1210 of the example method 1200 may involve applying an encoder function to the request specification to derive a local version of a trigger code associated with the emergency action.

[0295] Block 1212 of the example method 1200 may involve performing a second verification that the local version of the trigger code is identical to the local version of each of the at least threshold number of identical decrypted corresponding trigger codes.

[0296] Finally, block 1214 of the example method 1200 may involve storing the trigger code as a verified action trigger in a database associated with the computing system.

[0297] According to example embodiments, the threshold number may be the total number of the plurality of numbers, a majority of the total number of the plurality of numbers, or an integer closest to a specified proportion of the total number of the plurality of numbers.

[0298] According to an example embodiment, performing a first verification that at least a threshold number of decrypted corresponding encoded action-payloads are identical may require selecting a predetermined number of decrypted encoded action-payloads for comparison. Furthermore, the threshold number may be equal to the predetermined number. With this arrangement, the selection may be random and / or based on one of the specified identities of a particular trust verifier in the corresponding plurality of trust verifiers.

[0299] According to an example embodiment, the trigger code provided by the trusted entity may be a hash, and the encoder function may be a hash function. In this arrangement, each corresponding trigger code may be a corresponding hash value, and the local version of the trigger code may be a local hash value. In addition, in this arrangement, a first verification that verifies that at least a threshold number of decrypted corresponding trigger codes are the same may involve verifying that at least a threshold number of corresponding hash values ​​are the same, and a second verification that verifies that the local version of the trigger code is the same as the local version of each of the at least threshold number of identical decrypted corresponding trigger codes may involve verifying that the local hash value is the same as at least a threshold number of identical corresponding hash values.

[0300] According to an example embodiment, the trigger code provided by the trusted entity may include a semantic representation of the request specification that is created by the trusted entity and can be interpreted by the computing device.

[0301] According to an example embodiment, the trigger code provided by the trusted entity may include a semantic representation of the request specification, which is generated by an artificial intelligence engine according to a natural language description of the request specification and can be interpreted by a computing device.

[0302] According to an example embodiment, performance of an action may be delayed a specified amount of time from a specified date and time, or scheduled for a specific date and time.

[0303] According to an example embodiment, example method 1100 may further involve, in response to receiving a request from a node device of the blockchain network, sending a copy of the verified trigger code to the node device.

[0304] VI. Conclusion

[0305] The present disclosure is not limited to the specific embodiments described in the present application, which are intended to illustrate various aspects. Many modifications and changes can be made to it without departing from its scope, which is obvious to those skilled in the art. According to the foregoing description, in addition to those described herein, methods and devices that are functionally equivalent within the scope of the present disclosure are also obvious to those skilled in the art. Such modifications and changes are intended to belong to the scope of the appended claims.

[0306] The above detailed description describes various features and operations of the disclosed systems, devices and methods with reference to the accompanying drawings. The example embodiments described herein and in the accompanying drawings 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 is readily understood that the various aspects of the present disclosure as generally described herein and shown in the accompanying drawings can be arranged, replaced, combined, separated and designed in a variety of different configurations.

[0307] For any or all message flow diagrams, scenarios and flow charts discussed in the figure and this article, each step, frame and / or communication can represent information processing and / or information transmission according to the example embodiment. Alternative embodiments are included in the scope of these example embodiments. For example, in these alternative embodiments, the operation described as step, frame, transmission, communication, request, response and / or message can be performed in a sequence not shown or discussed, including substantially parallel execution or reverse execution, depending on the function involved. In addition, more or less frames and / or operations can be used in any message flow diagram, scenario and flow chart discussed herein, and these message flow diagrams, scenarios and flow charts can be combined with each other in part or in whole.

[0308] The steps or blocks representing information processing can correspond to circuits that can be configured to perform specific logical functions of methods or technologies described herein. Alternatively or additionally, the steps or blocks representing information processing can correspond to modules, segments or parts of program code (including related data). The program code can include one or more instructions that can be executed by a processor to implement specific logical operations or actions in a method or technology. The program code and / or related data can be stored on any type of computer-readable medium, such as on a storage device, including RAM, a disk drive, a solid-state drive or other storage media.

[0309] Computer readable media can also include non-transient computer readable media that store data in a short time, such as register memory and processor cache. Non-transient computer readable media can also include non-transient computer readable media that stores program code and / or data for a longer time. Therefore, the non-transient computer readable medium can include auxiliary or persistent long-term storage, such as ROM, optical disk or disk, solid-state drive or read-only optical disk memory (CD-ROM). Non-transient computer readable media can also be any other volatile or non-volatile storage system. Non-transient computer readable media can be considered as computer readable storage media, for example, or tangible storage devices.

[0310] In addition, the steps or boxes representing one or more information transfers can correspond to information transfers between software and / or hardware modules in the same physical device. However, other information transfers may be performed between software modules and / or hardware modules in different physical devices.

[0311] The specific arrangement shown in the figures should not be considered as limiting. It should be understood that other embodiments can include elements that can be more or less than each element shown in a given figure. In addition, some of the elements shown can be combined or omitted. In addition, the example embodiments can include elements not shown in the figures.

[0312] Although various aspects and embodiments are disclosed herein, other aspects and embodiments will be apparent to those skilled in the art. The various aspects and embodiments disclosed herein are intended to be illustrative and not limiting, with the true scope being indicated by the appended claims.< / n> < / n> < / n> < / n>

Claims

1. A method performed by a computing system, the computing system being configured to operate as a node of a node network operating a blockchain, the method include: receiving a request message for placing an entry on the blockchain, wherein the request message comprises: (i) a request specification for the entry, the request specification comprising an action and an identity of at least one party to be acted upon by the action; (ii) an indicator that the entry has been authorized by a trusted entity; and (iii) a plurality of cryptographic verification codes generated by respective ones of the plurality of trusted verifiers, each cryptographic verification code comprising an encoded action-payload provided by the trusted entity and cryptographically signed by respective one of the trusted verifiers; applying the public encryption key of each respective trust verifier to the respective encrypted verification code to decrypt the respective encoded action-payload; Performing a first verification that at least a threshold number of decrypted corresponding encoded action-payloads are identical; applying a payload-encoder function to the request specification to derive a local version of the encoded action-payload; and performing a second verification that the local version of the encoded action-payload is identical to the local version of each of at least a threshold number of identical decrypted corresponding encoded action-payloads; and In response to performing both the first verification and the second verification, submitting an entry for block processing to be added to the blockchain.

2. The method according to claim 1, in, The threshold number is equal to one of: the total number of the plurality of numbers, a majority of the total number of the plurality of numbers, or an integer closest to a specified proportion of the total number of the plurality of numbers.

3. The method according to claim 1, in, Performing a first verification of verifying that at least a threshold number of decrypted corresponding encoded action-payloads are identical comprises: selecting a predetermined number of decrypted corresponding encoded action-payloads for comparison, wherein the threshold number is equal to a predetermined number, And wherein the selection is random or based on one of the specified identities of a particular trust verifier among the corresponding plurality of trust verifiers.

4. The method according to claim 1, in, the encoded action-payload provided by the trusted entity comprises a hash, and the payload-encoder function comprises a hash function, wherein each respective encoded action-payload comprises a respective hash value, and the local version of the encoded action-payload comprises the local hash value, wherein performing a first verification that at least a threshold number of decrypted corresponding encoded action-payloads are identical comprises: verifying that at least a threshold number of corresponding hash values ​​are identical, And wherein, the second verification of verifying that the local version of the encoded action-payload is the same as the local version of each of at least a threshold number of identical decrypted corresponding encoded action-payloads includes: verifying that the local hash value is the same as at least a threshold number of identical corresponding hash values.

5. The method according to claim 1, in, The encoded action-payload provided by the trusted entity includes a semantic representation of the request specification, the semantic representation of the request specification being created by the trusted entity and capable of being interpreted by a computing device.

6. The method according to claim 1, in, The encoded action-payload provided by the trusted entity includes a semantic representation of the request specification, which is generated by an artificial intelligence engine based on a natural language description of the request specification and can be interpreted by a computing device.

7. The method according to claim 1, in, Submitting an entry for addition to the blockchain for block processing includes including the entry in a candidate block input to a mining process.

8. The method according to claim 1, in, The at least one party is associated with a specific digital asset recorded in the blockchain, And wherein the action is at least one of the following: transferring a specified amount of a specific digital asset from the at least one party to another party associated with the blockchain; Freeze a specified amount of a specific digital asset; Unfreeze a specified amount of a specific digital asset; transferring a specified amount of a particular digital asset from the at least one party to an escrow account associated with the blockchain; or Transferring a specified amount of a specific digital asset from the at least one party to a specific account associated with the blockchain.

9. The method according to claim 1, in, The performance of the action is one of: delayed a specified amount of time from a specified date and time, or scheduled for a specific date and time.

10. A computing system configured to operate as a node of a node network operating a blockchain, the computing system include: at least one processor; and A memory storing instructions, which, when executed by the at least one processor, causes the node to perform the method according to any one of claims 1 to 9.

11. An article comprising a non-transitory computer-readable medium having program instructions stored thereon, which, when executed by a computing system configured to operate as a node of a node network operating a blockchain, causes the node to perform the method as described in any one of claims 1 to 9.

12. A method performed by a computing system, the computing system being configured to operate as a node of a node network operating a blockchain, the method include: Receiving a request message for placing an entry on the blockchain, the entry being configured to invoke a contingency action of a smart contract that has been previously entered into the blockchain, wherein the request message comprises: (i) a request specification comprising a link to the smart contract, an identifier of the contingency action, and an identity of a designated action invoker that is authorized to invoke the contingency action; (ii) an indicator that the entry has been authorized by a trusted entity; (iii) a plurality of cryptographic verification codes generated by a corresponding plurality of trust verifiers, each cryptographic verification code comprising an encoded action-payload provided by the trusted entity and cryptographically signed by a corresponding one of the trust verifiers; applying the public encryption key of each respective trust verifier to the respective encrypted verification code to decrypt the respective encoded action-payload; Performing a first verification that at least a threshold number of decrypted corresponding encoded action-payloads are identical; applying a payload-encoder function to the request specification to derive a local version of the encoded action-payload; and performing a second verification that the local version of the encoded action-payload is identical to the local version of each of at least a threshold number of identical decrypted corresponding encoded action-payloads; generating a transaction specification and placing it in the entry in response to performing both the first authentication and the second authentication, wherein the generated transaction specification includes instructions for performing the identified contingency action, the contingency action being authorized by a trusted entity acting as an authentication alias for the invoker of the specified action; Submit an entry for block processing to be added to the blockchain.

13. The method of claim 12, further comprising: include: Execute an identified contingency action previously entered into a smart contract on the blockchain.

14. The method according to claim 12, in, The request specification also includes one or more parameters for the identified emergency action.

15. The method according to claim 12, in, The threshold number is equal to one of: the total number of the plurality of numbers, a majority of the total number of the plurality of numbers, or an integer closest to a specified proportion of the total number of the plurality of numbers.

16. The method of claim 12, in, Performing a first verification of verifying that at least a threshold number of decrypted corresponding encoded action-payloads are identical comprises: selecting a predetermined number of decrypted corresponding encoded action-payloads for comparison, wherein the threshold number is equal to a predetermined number, And wherein the selection is random or based on one of the specified identities of a particular trust verifier among the corresponding plurality of trust verifiers.

17. The method of claim 12, in, the encoded action-payload provided by the trusted entity comprises a hash, and the payload-encoder function comprises a hash function, wherein each respective encoded action-payload comprises a respective hash value, and the local version of the encoded action-payload comprises the local hash value, wherein performing a first verification that at least a threshold number of decrypted corresponding encoded action-payloads are identical comprises: verifying that at least a threshold number of corresponding hash values ​​are identical, And wherein, the second verification of verifying that the local version of the encoded action-payload is the same as the local version of each of at least a threshold number of identical decrypted corresponding encoded action-payloads includes: verifying that the local hash value is the same as at least a threshold number of identical corresponding hash values.

18. The method of claim 12, in, The encoded action-payload provided by the trusted entity includes a semantic representation of the request specification, the semantic representation of the request specification being created by the trusted entity and capable of being interpreted by a computing device.

19. The method of claim 12, in, The encoded action-payload provided by the trusted entity includes a semantic representation of the request specification, which is generated by an artificial intelligence engine based on a natural language description of the request specification and can be interpreted by a computing device.

20. The method of claim 12, in, Submitting an entry for addition to the blockchain for block processing includes including the entry in a candidate block input to a mining process.

21. The method of claim 13, in, Executing an identified contingency action previously input into the smart contract on the blockchain includes causing it to be executed one of: delayed a specified amount of time from a specified date and time, or scheduled for a specific date and time.

22. A computing system configured to operate as a node of a node network operating a blockchain, the computing system include: at least one processor; and A memory storing instructions, which, when executed by the at least one processor, cause the node to perform the method according to any one of claims 12 to 21.

23. An article comprising a non-transitory computer-readable medium having program instructions stored thereon, which, when executed by a computing system configured to operate as a node of a node network operating a blockchain, causes the node to perform the method as described in any one of claims 12 to 21.

Images