Digital signature algorithm for verifying revised data

Abstract

Embodiments of the present disclosure provide a solution for protecting, sharing, verifying, and / or generating data resources (e.g., but not limited to documents). In an exemplary embodiment, the data resource is expressed, expressed, or defined as a plurality of component segments, which are then subjected to hash processing. A Merkel tree representing a complete original version of the data resource is generated, wherein the hash of the segment is a leaf of the Merkel tree. A signer is authorized to sign the root of the tree. The trimmed version of the data resource may then be shared, thereby omitting one or more segments that a data controller wishes to secure or not share in the original form. To verify the authenticity and / or integrity of the revised data resource, sufficient data (e.g., respective hash of the one or more non-shared segments) is provided to a verifier to verify whether the one or more non-shared segments are present in the tree representing the original complete version, and whether there is the authorization signature that signs the root. In some embodiments, the data resource is a code library, and the segment is a portion of computer code that performs a particular subtask. Shared code segments may be selected such that when executed on a processor, the shared code segments in combination perform a larger task.

Description

Technical Field

[0001] This disclosure provides systems and methods for securely distributing data, verifying data authenticity and integrity, and protecting data security. Additionally or alternatively, embodiments provide improved digital signature algorithms for sharing, providing, storing, protecting, and / or processing data resources. Embodiments utilize cryptographic techniques to enforce data security and access control, and are particularly suitable, but not limited to, for use when redaction, anonymization, and / or sanitation of data to be shared with one or more parties.

[0002] Other technical effects include, but are not limited to, the ability to scale data storage solutions, provide secure and verifiable documents formatted for revision (e.g., templates, forms, etc. that can be filled out by one or more users), and represent data hierarchies as verifiable storage resources without revealing or providing the content itself. Such solutions can be combined with blockchain technology to further enhance the verification of data integrity and authenticity.

[0003] These aspects will be described and explained in more detail below. Background Technology

[0004] Throughout history, humanity has discovered the need or desire to keep partially shared information confidential—that is, to reveal only certain parts without disclosing the rest. A simple, traditional method involves creating a document on a surface such as paper and then somehow covering or obscuring one or more sensitive sections, for example, by using dark ink to smear these sensitive sections or by placing masking objects such as tape or paper over them.

[0005] However, such techniques are not easy to apply (especially for lengthy documents) and can sometimes inadvertently reveal sensitive content underneath. For example, if the ink is not dark enough to adequately cover the underlying content, or if the mask moves accidentally during subsequent copying or transmission.

[0006] While computer-based technologies have provided numerous devices designed to facilitate the revision of electronic data resources, technical challenges remain, particularly those related to large datasets. These challenges include how to verify the authenticity and integrity of shared data resources (e.g., documents), even if one or more parts have been removed.

[0007] Therefore, there is a need to provide improved solutions for verifying revised electronic data resources. Such improved solutions have now been designed. Summary of the Invention

[0008] Any feature mentioned herein with respect to one or more aspects is not intended to be limited to that aspect. The features disclosed herein are interchangeable with various embodiments and aspects.

[0009] According to one aspect, embodiments provide schemes for securely and cryptographically enforcing access to and controlling data to be transmitted or shared between a data controller and at least one data receiver. Specifically, preferred embodiments may provide techniques and systems for revising one or more portions of a data resource to be shared, processed, or stored with or by one or more receivers. As used herein, “redact” is intended to include (but is not limited to) obscuring, masking, removing, retaining (i.e., not sharing or disclosing), deleting, and / or replacing one or more selected portions of a data resource. Revision may also include not sharing the one or more selected portions at all, or not sharing the one or more selected portions in a meaningful form. For example, the revised one or more portions may be shared with the one or more receivers, but in a form that obscures or alters their original state, such as by hashing, masking, or otherwise encoding the one or more selected portions, so that the one or more receivers cannot derive the original state or form. Providing one or more revised portions in a hashed form has the advantage that the verifier can compute the Merkle tree (and its Merkle root) of the entire data resource by hashing the unrevised portion and combining it with the hashed revised portion, based on known Merkle tree construction techniques.

[0010] In one form of wording, preferred embodiments may involve applying a signature algorithm to a data resource using a Merkle tree, such that one or more segments (i.e., portions) of the data resource can be modified without losing the ability to verify the authenticity or integrity of the data resource. Advantageously, embodiments may enable modification of the one or more selected portions of the data resource without affecting or negating the validity of the signature applied to the data resource by the data controller.

[0011] In such embodiments, data resources can be broken down into multiple segments. The size, number, or other attributes of the segments can be determined based on criteria or objectives selected by the data controller.

[0012] The segments can then be used to construct a tree structure representing the data resource. Preferably, the tree structure is a hash tree (also known as a Merkle tree), wherein the leaf nodes at the bottom of the tree are hashed in pairs to provide the hash of the parent node that acts as the next higher (i.e., the next higher) level in the tree. This pairwise hashing continues until the hash of the root of the tree is calculated.

[0013] After data segments from the data resource have been hashed to form a Merkle tree, the one or more data controllers may cryptographically sign the root to prove (verify) the authenticity and / or integrity of the data contained within / represented by the tree. The one or more signatures provide evidence that the data controller has authorized, created, and / or processed the data resource.

[0014] The data controller may then select one or more segments to be modified from the data resource before storing, processing, accessing, and / or sharing the data resource.

[0015] The revision of one or more selected segments may include one or more of hiding, altering, masking, removing, or replacing the original version of one or more selected segments from the data resource (or a copy thereof).

[0016] The data controller may share or present one or more of the following to one or more recipients:

[0017] - The Merkle tree of the entire raw (pre-redaction) data resource;

[0018] - One or more public keys corresponding to one or more private keys used to sign the root hash to facilitate the verification of the signature;

[0019] - The unedited segment of the data resource.

[0020] The one or more recipients may use the one or more public keys to verify that the data resource represented in the Merkle tree was indeed generated and / or authorized by the one or more data controllers who possess the corresponding private keys.

[0021] Therefore, the verifier can perform verification in the following ways:

[0022] Construct a tree representing the unedited version of the data resource;

[0023] Check whether the root of the constructed tree matches the root of the tree already shared by the data controller; and / or

[0024] Check whether the signature of the signed Merklegen application provided by the data controller has been generated / authorized by the data controller.

[0025] The construction of the tree representing the unrevised version of the data resource can be performed by the validator using the revised version of the data resource plus the hash of one or more revised segments. Therefore, the validator can perform verification on the signed Merkle root of the constructed instance of the Merkle tree, which represents the unrevised original version of the data resource.

[0026] In some embodiments, the one or more data controllers may retain the revised segments (e.g., in encrypted form). Additionally or alternatively, the one or more data controllers may destroy / delete original copies of one or more of their revised segments.

[0027] According to one or more aspects, this disclosure may provide means (e.g., a stand-alone device or system) to facilitate computer implementation of one or more of the steps indicated above. The means may include hardware, software, and / or firmware for performing one or more of the method steps disclosed herein.

[0028] In one embodiment, the apparatus may include software, firmware, and / or hardware configured to facilitate or implement one or more of the following:

[0029] - Decompose the data resources into the multiple segments;

[0030] - Generate a Merkle tree representing the plurality of segments;

[0031] - Perform an encrypted signature on the root hash of the tree;

[0032] - Select one or more segments from the data resource or a copy thereof for editing;

[0033] - Share, store, or otherwise process the signed hash root, the Merkle tree of the data resource, the original data resource, and / or the original segment selected for revision.

[0034] In another embodiment, the apparatus may include software and / or hardware configured to facilitate or enable a recipient to display, reproduce, or present the revised data resource. Such an apparatus may include a browser, wallet, word processing software, or any other software application operable to process (e.g., display, print, audio reproduction, etc.) the data resource minus the selected revised segment.

[0035] In some cases, this can be achieved by simply providing a predetermined marker (e.g., an audible sound, one or more visual symbols, tactile vibrations, or other signals) indicating that a portion of the data has been revised at that location within the data resource. In this sense, the marker can replace the one or more revised segments in the revised version of the data resource when reproduced by the one or more receivers.

[0036] Compared to existing methods that provide selective disclosure techniques involving providing Merkel proofs (paths) to specific data slices, embodiments of this disclosure may involve signing the root of the tree of the entire data resource. After signing, the verifier can check whether the entire document is legitimate, authentic, and unaltered, even though a revised version of the original data resource has been provided.

[0037] Additional technical effects include, but are not limited to, the ability to extend data storage solutions, provide secure and verifiable documents formatted for revision (e.g., templates, forms, etc. that can be filled out by one or more users), and the ability to represent data hierarchies as verifiable storage resources without revealing or providing the content itself.

[0038] Additionally or alternatively, one or more embodiments of this disclosure provide novel solutions for one or more of the following:

[0039] - To build or provide functional software products, which are constructed from software elements that are selectively disclosed / provided using Merkelized structures and digital signature algorithms as disclosed herein;

[0040] - Manage, implement, and / or control one or more software repositories. One or more repositories may include Merkle-based structures and digital signature algorithms as disclosed herein, wherein the leaves of the Merkle tree include software elements that can be selectively combined to provide a software product.

[0041] In some implementations, the disclosed technology may utilize one or more of the following:

[0042] 1. A consumable on-chain code (e.g., script) segment configured for assembly and processing as a blockchain transaction; the term "on-chain" may include the meaning of "on a ledger, such as, but not limited to, a blockchain ledger".

[0043] 2. One or more on-chain outputs, which can be assembled as (off-chain) executable code; the executable code can be executed in or by a microcontroller (e.g., a MISC instruction set), or contain outputs generated from a compilation process.

[0044] 3. A private code repository, which requires successful license / user authentication before granting access to the code segments necessary to build the software product. In some embodiments, the authentication may include verifying a valid license or other permission-related mechanisms, such as a valid password, authorization encryption key, etc.

[0045] Embodiments of this type can provide computer-implemented methods and systems for designing, assembling, or otherwise creating software (programs) using at least one structured (code) element set contained in a Merkle tree, the root of which is published on a blockchain ledger. This can be a public or private ledger. The elements can be referred to as sub-parts of code, code components, or partial code elements, etc. The software can be a fully functional program capable of executing on a processor. The software can be provided in a native language, a low-level language (e.g., assembly code), or object code (e.g., code set up for execution by an interpreter or virtual machine). In other examples, the code can be provided as source code and / or formed in a higher-level programming language such that it needs to be translated, for example, by a compiler and / or interpreter, before execution on a given processor / system architecture.

[0046] In some embodiments, the leaves of the Merkle tree may correspond to blockchain transactions or transaction outputs, each blockchain transaction or each transaction output containing partial software elements that, when assembled or combined, provide a set of instructions for constructing more complex and functional software. In other embodiments, the elements may provide additional, enhanced, or revised code elements to improve or update existing software.

[0047] In some embodiments, the leaves of the Merkle tree correspond to portions of software elements with applied access permissions stored in a private database. In some embodiments, the Merkle tree contains more sub-elements than are required to build the software, and a separate list of assembly instructions must be obtained to determine which leaves of the Merkle tree must be assembled in which order.

[0048] In some embodiments, the referenced code segment performs calculations on the input values ​​and generates output results that are directly used in the software being assembled.

[0049] In some embodiments, the output is directly logged to the transaction output so that it can be read by viewing the public ledger. In some embodiments, the output is retained in the processing stack when the script terminates, which requires the process that built the software to execute the script to calculate the value.

[0050] In some embodiments, a single Merkle tree may contain elements that can be used to build multiple software systems. In some embodiments, the resulting software is an application or program for installation into an operating system environment.

[0051] In some embodiments, the resulting software is a complete program that controls an embedded system, a control system, or hardware.

[0052] In some embodiments, the code extracted from an item or transaction referenced in the Merkle tree can be represented as Minimal Instruction Set Computer (MISC) instructions. For example, in some embodiments, these instructions may be provided in a language (e.g., but not limited to) Bitcoin scripting) used for transactions on the (Bitcoin) blockchain. However, in other examples, the instructions may be provided in any language suitable for use with a particular blockchain and its associated protocols. In some embodiments, multiple Merkle trees may be formed, and these multiple Merkle trees may reference the same code elements.

[0053] In some embodiments, the leaves on the Merkle tree can reference a complete software product / version, which is itself an instruction set that references a separate Merkle tree containing its own child elements. Attached Figure Description

[0054] To aid in understanding embodiments of this disclosure and to show how such embodiments can be implemented, descriptions will now be provided by way of example only, with reference to the accompanying drawings, in which:

[0055] Figure 1 This is a schematic block diagram of a system used to implement blockchain;

[0056] Figure 2 The illustration shows some examples of transactions that can be recorded in a blockchain;

[0057] Figure 3A A schematic block diagram of the client application is shown;

[0058] Figure 3B It shows that it can be made by Figure 3A A schematic model of an exemplary user interface represented by a client application;

[0059] Figure 4 A schematic block diagram of some node software used for processing transactions is shown;

[0060] Figure 5 An exemplary embodiment of this disclosure is shown, in which a data resource (a document in this example) is created and divided into multiple segments;

[0061] Figure 6 An exemplary embodiment of this disclosure is shown, wherein... Figure 5 The segments are hashed and used to construct a Merkle tree representing multiple segments;

[0062] Figure 7 An exemplary embodiment of this disclosure is shown, wherein a suitable digital signature algorithm (e.g., but not limited to ECDSA) is used to sign the Merkel root;

[0063] Figure 8 An exemplary embodiment of this disclosure is shown, wherein the required data is provided to the verifying party (e.g., Bob) so that he can calculate the remaining data himself and then check whether the signed Merkle root he has obtained matches the result he calculated himself;

[0064] Figure 9 An exemplary embodiment of this disclosure is shown, in which the verifier uses Figure 5 The data provided in the document is used to perform the verification process;

[0065] Figure 10 An exemplary embodiment of this disclosure is shown, wherein a Merkle tree is used to verify a large segment of the same file or a single copy of the entire file as a separate segment;

[0066] Figure 11 and Figure 12 An exemplary embodiment of this disclosure is shown, wherein a Merkel path is provided for optimizing custom documents (e.g., contracts);

[0067] Figures 13 to 26 Illustrations and examples of various embodiments in use are provided, as well as how this disclosure can be implemented in an exemplary file system (in this example, a VAST file system). Specifically:

[0068] Figure 13 and Figure 14 Illustrations are provided of how a data controller (e.g., a database administrator) can use the embodiments disclosed herein to create and add to a VAST file system;

[0069] Figure 15 It shows Figure 13 and Figure 14 An example of an embodiment where a user generates a VAST file system record and attributes ownership of the file system to an identity;

[0070] Figures 16 to 18 Provides users with how to... Figure 13 , Figure 14 and Figure 15 The diagram shows the VAST file system requesting and receiving files;

[0071] Figure 19 This demonstrates how a user can verify implementations based on embodiments of this disclosure and... Figures 13 to 18 The file requested and retrieved by the VAST file system is shown in the figure;

[0072] Figure 20 It shows how to change Figures 13 to 19 The entries in the exemplary use cases may be one or more times;

[0073] Figure 21 Examples are shown on how to perform scalable updates to information and data (e.g., data recorded and processed in the illustrative system provided herein);

[0074] Figure 22 This demonstrates how subtrees can be used within Merkle trees in various embodiments disclosed herein;

[0075] Figures 23 to 26 Various embodiments of this disclosure are shown, illustrating how to implement it. Figure 22 The subtrees of a larger tree, and how to use the exemplary system provided in this article to create subtrees of a larger tree to represent more complex hierarchical editable documents;

[0076] Figure 27 A Merkle tree containing elements of a software library is shown according to an illustrative embodiment of the present disclosure;

[0077] Figure 28 A Merkle tree containing elements of a software library is shown to illustrate an embodiment of this disclosure, wherein each leaf of the Merkle tree is a transaction ID of a blockchain transaction from which the associated software element can be extracted;

[0078] Figure 29 This shows the hashes of a series of software configurations published in a Merkle tree;

[0079] Figure 30 This illustrates how to create a blockchain transaction according to one possible embodiment to implement a software compilation process for generating firmware for an embedded computer;

[0080] Figures 31a to 31f Expanded Figure 30 The use of blockchain transactions demonstrates how to create multiple transaction outputs that perform different functions;

[0081] Figure 32 A Merkle tree is shown, which includes a series of software elements that together are used to construct a software configuration, which is revised by updated software elements and / or additional software elements to achieve a new or updated software configuration. Detailed Implementation

[0082] Invent specific materials

[0083] For illustrative purposes, examples of preferred embodiments of the present disclosure are now provided.

[0084] According to a preferred embodiment, this disclosure provides a method and corresponding system for revising one or more portions of data from a data resource (which may sometimes be referred to below as a “document” for illustrative and illustrative purposes only).

[0085] Embodiments of this disclosure may provide schemes (methods and systems) for secure and verifiable modification of data resource 510, expansion of systems for data storage and / or verification, and improved systems for storing hierarchical data on computer-based storage resources. References Figure 5 and Figure 6 At least one data resource 510 can be decomposed into multiple segments 520, which are then represented in a tree structure with a root 610. The root 610 can be signed by the authorizing party to verify the authenticity of the data contained in the tree. For ease of reference, the authorizing party may be referred to as the controller of the data resource. The signature can then be used by another party to verify the legitimacy of document 510, even if one or more portions of document 520 have been modified from a version already provided to that party. Advantageously, the disclosed techniques do not compromise or diminish the integrity of the digital signature applied to the entire content of the data resource. In the following exemplary embodiments, the data resource is referred to as a "document" for ease of illustration only and does not limit the nature, purpose, or type of the resource or its digital content. For example, a data resource may be a computer program or a collection of computer program or code snippets, or a digital image or a collection thereof, or multimedia content, etc.

[0086] A document 510 can be created and then broken down into smaller elements (segments) 520. These segments can be as small as the smallest divisible unit (e.g., a single character) or contain a larger portion of the data. In some cases, a segment can be an entire file or a set of files. In other words, a segment is a logical or other part of a data entity / resource.

[0087] A tree is created having internal nodes 620 and using the hash of segment 520 as leaves 630 in the tree. In a preferred embodiment, the tree is a Merkle tree, and the term will be referred to below for ease of reference.

[0088] To authorize document 510 and verify its origin, authenticity, and / or integrity, one or more data controllers sign the Merkle root 610. The signature can be generated using a cryptographic key and can be referred to as a digital signature or a cryptographic signature. Advantageously, the signature is applied to the Merkle root that includes the document, rather than to the document itself. In a preferred embodiment, the individual hashes 630 are not signed.

[0089] In some examples, the data controller can be the creator of the document, or on behalf of, or some other party with legitimate or authorized control over the document. In some cases, "control" can include "ownership" of the document. If the verifying party obtains the minimum necessary data from (or on behalf of) the data controller, the verifying party (also referred to as the "validator") can calculate the root and check the signature.

[0090] In the following example, the data controller is referred to as Alice, and the other (verifying) party is referred to as Bob. Bob could also be an end user / consumer using or viewing a revised version of the document, or in some cases, Bob might simply perform the verification process and then, after ensuring its legitimacy, pass the revised data resource to the end user. More specifically, preferred embodiments may include at least one or more of the following steps. One or more steps listed below may be provided by a single party, a group of parties, or multiple separate parties. The process may be a distributed process.

[0091] Step 1:

[0092] refer to Figure 5 Alice creates her document 510 and then breaks it down into multiple segments 520. This can include a logical definition of how these segments are generated, rather than a physical breakdown of the data. Alice's decision on how to break down the document is an implementation choice. The breakdown can be based on criteria that Alice has chosen or acquired (e.g., size, number, or one or more other segment attributes), or it can be determined using criteria that Alice has chosen or acquired. For example, she could decide to break the document down into the smallest divisible units, such as individual bits, or individual (e.g., ASCII) characters, or single / multiple byte segments, or any other criteria chosen by Alice.

[0093] These segments can include any part of a document, ranging from a single character to an entire chapter or passage. By breaking the document into smaller segments, Alice is able to have fine control over which parts of the document she wants to edit.

[0094] Step 2:

[0095] refer to Figure 6 Alice hashes each segment 520 and uses them to represent document 510a in a tree structure. Alice inserts the hash 630 of each segment 520 into the Merkle tree as a leaf node 630 (which may also be called a leaf element, or simply a "leaf").

[0096] Although segment 520 can be further decomposed into sub-segment 2610 (e.g., see...) Figure 26However, segment 630 is the smallest single editable component in the document. In other words, once the Merkle tree is constructed using segments as leaves in steps 2 and 3, it is impossible to edit any part of document 510 smaller than segment 630. Therefore, the segment can also be referred to as the "smallest editable element" 630.

[0097] like Figure 6 As illustrated, the order and structure of segments, as well as the relationships between them, are preserved and represented in a Merkle tree. This can be crucial for subsequent use of processed data, such as reorganizing segments in a viewable / usable form so that a revised version of a document can be read or otherwise manipulated by a user. However, in other embodiments, the original order or structure of segments may not need to be preserved, or may be intentionally randomized when constructing the tree, depending on the implementation and use case requirements involved.

[0098] Step 4:

[0099] refer to Figure 7 Alice signs the hash at the top of the tree (i.e., the root). Signature 710 can be generated using the following:

[0100] 1. The signer's private key (e.g., Alice's private key), which is associated with the public key;

[0101] 2. K value — This is usually a random value;

[0102] 3. Message hash.

[0103] Advantageously, the hashed message can include other data elements 720. These can be hashes of other documents or data items, or other Merkle root trees, thus allowing a single signature to be applied across multiple documents.

[0104] Step 5:

[0105] refer to Figure 8 Alice edits at least one segment in the document by selecting one or more segments to omit from the version of the document that will be provided to Bob. This may include the step of selecting at least one segment that will be provided only in a hashed form, rather than in the original unimage version.

[0106] Step 6:

[0107] refer to Figure 8 Alice provides the root 610, the unedited segment, and the hash of any edited segment required for Bob's verification.

[0108] In other words, Alice provided the non-secret parts of the documents she was willing to share with Bob, as well as the data Bob needed to perform the verification process because he couldn't calculate that data himself.

[0109] If Bob is both the verifier and the end user who will consume (i.e., use, store, or otherwise process) the revised data, Alice can provide Bob with all the unrevised segments. Alternatively, Bob may simply be performing the verification function, rather than being the end consumer. In such a case, Alice might choose to provide Bob with a sample of the unrevised segments solely for verification purposes, rather than all of them.

[0110] In a simple case (Case 1), such as Figure 8 As shown, the document information provided to the verifier (i.e., Bob) may include:

[0111] Digital signature;

[0112] Merkelgen;

[0113] • At least one unedited document chapter;

[0114] • Points to the Merkel path to the unedited section of the document being provided.

[0115] In more complex situations (Case 2), Alice can provide one or more additional data items in the signed message, as well as the signed Merkle root as mentioned above.

[0116] In addition, such as Figure 8 As shown, in this situation, Alice offers Bob:

[0117] • Her digital signature;

[0118] Merkelgen;

[0119] • Additional hashes of the additional data (e.g., metadata) in the signed message. One or more complete preimages must be provided to Bob so that he can calculate one or more hashes and perform one or more necessary checks;

[0120] • At least one unedited document chapter;

[0121] • Points to the Merkel path to the unedited document section being provided to Bob.

[0122] from Figure 8As can be seen, Alice does not need to send the entire Merkle tree to Bob. Alice only needs to provide Bob with one or more unedited portions of the document she wants to share, along with any data he needs to verify that a signature has been applied to the signed data. The signed message 710 can include only the Merkle root (Case 1) or the Merkle root plus additional data 720 (Case 2).

[0123] Step 7:

[0124] refer to Figure 9 Even if one or more sections of a document have been revised, Bob will still verify the document's authenticity / completeness. The verification process may include at least the following steps, in which Bob:

[0125] 1. Check if the key / digital signature / message matches;

[0126] 2. Check if the Merklegen version matches the version provided in the message;

[0127] 3. Access a minimum editable segment of 630;

[0128] 4. Perform hashing on the smallest editable element:

[0129] a. Calculate the root using the provided Merkel path elements;

[0130] b. Hash of the unedited portion of the document;

[0131] c. Merkel path to an unrevised document section (i.e., the minimum number of additional nodes in the tree required to compute the root hash starting from a given leaf).

[0132] exist Figure 9 In the example, Bob performs the verification process by executing the following calculations:

[0133] 1. Hash the document title to generate "16";

[0134] 2. Hash 16 and 17 to calculate 8 (this involves concatenating 16 and 17 and hashing the result);

[0135] 3. Hash 8 and 9 to calculate 4;

[0136] 4. Hash clause 1 of section 2 to calculate 19;

[0137] 5. Hash 18 and 19 to calculate 10;

[0138] 6. Hash 10 and 11 to calculate 5;

[0139] 7. Hash 4 and 5 to calculate 2;

[0140] 8. Hash clause 3 of section 4 to calculate 21;

[0141] 9. Hash 20 and 21 to calculate 13;

[0142] 10. Hash 12 and 13 to calculate 6;

[0143] 11. Hash "Name and Role 1" to calculate 23;

[0144] 12. Hash 22 and 23 to calculate 14;

[0145] 13. Hash 14 and 15 to calculate 7;

[0146] 14. Hash 6 and 7 to calculate 3;

[0147] 15. Hash 2 and 3 to compute 1 (i.e., the root).

[0148] It should be noted that Bob does not need the entire Merkle tree or all the hashes of one or more revised segments. Once the Merkle root is calculated (step 15), it can be checked against the hash value used to generate the signature to see if it matches what Alice provided to him. If the hash matches and the signature is valid, it proves that the revised segments constitute part of the entire document, and the signature has been applied to all items in the leaves of the tree. In other words, Bob can prove that Alice used her secret private key to generate the signature applied to the Merkle tree root representing the entire unrevised document.

[0149] Step 8:

[0150] The revised document may be provided by the end user / consumer (as explained above, which could be Bob or at least one other party), for example, by displaying or outputting it in some way. For convenience, we will assume it is Bob here.

[0151] In some cases, Bob may use a browser, wallet, word processor, image display application, or other software application configured to output or otherwise process unedited data. The output of unedited data may be provided in a visual, auditory, or tactile form, or in electronic form, such as digital resources that can be stored or otherwise processed. For example, an audio or video file may be played, or a document may be displayed on a screen or printed to some type of output device, or at least one data file may be output, then stored, and / or transmitted to at least one recipient.

[0152] In some embodiments, one or more of the revised segments can be replaced with alternative markers or indicators. For example, the revised portion of a text file can be displayed on the screen, with a blank box or an "X" indicating the location of the revised data. In the case of an audio file, a beep or other indicative sound can be played. This informs the viewer / listener / end user that a portion of the data at that location has been removed.

[0153] Variations and use cases

[0154] Secure distributed storage technology

[0155] In some embodiments, Alice may retain one or more revised segments. Additionally or alternatively, she may destroy / delete the original copy of one or more revised segments.

[0156] In some examples, revised segments can be sent to different storage facilities for secure storage. One or more segments can be encrypted using different algorithms and / or keys. Advantageously, anyone wanting to recover the entire document must access the individual revised segments from different (preferably secret) locations and know the multiple encryption algorithms and keys used. This can make accessing the complete document more difficult, thus providing a more secure data storage scheme that is less susceptible to unauthorized access. Highly sensitive, personal, commercially valuable, or security-related data may benefit from storage using such methods.

[0157] Large data resources

[0158] exist Figure 10 As can be seen, the use of Merkle trees can be extended to include larger segments of the same file or single copies of the entire file as individual elements. For large items with many minimally editable segments, this can make document sharing more efficient, as Alice needs to provide Bob with fewer Merkle paths and less data to share larger unedited segments. Aside from a slight increase in the amount of Merkle path data that must be shared per segment, all attributes remain unaffected.

[0159] Templates and forms:

[0160] refer to Figure 11 and Figure 12 Merkel paths can be used to optimize customized documents. In such cases, revised sections can be used as "blank" sections of a document that the user can complete. For example, the document can be a contract, form, template, payment authorization, or any other type of document that the user needs to complete, perform, adapt, or modify in some way. For simplicity, a well-known contract example will be used.

[0161] For contracts that will be used repeatedly by different parties in different contexts, the contract can be broken down into chapters, forming a Merkle tree of 2^N leaves, such as... Figure 11 As shown. If a contract has fewer than 2^N segments, blank leaves can be used to fill the contract, such as... Figure 11 and Figure 12 As shown, the Merkel branch can be reused multiple times to create individual contracts, each using the same template protocol. In this way, contract creators (e.g., Alice) can add personalized sections to their contracts in separate branches without having to modify any hashes in the template branch's hash.

[0162] like Figure 12 As shown, when signing a copy of a document, names, roles, and any special conditions can be added to the Merkle tree without changing the hash of any existing branches in the tree. Figure 12 In the example, a standard employment document containing a set of standard sections and terms is created. Anyone with the same contract can use the same Merkel path to verify the static (unrevised) sections of their document according to the template, but any custom sections provided by the user will have different hashes, different Merkel paths, and generate a unique Merkel root.

[0163] Therefore, according to one or more embodiments, the improved scheme is used to acquire or provide forms, templates, or other types of data resources that require or facilitate completion by one or more users. The completion action may include contributing at least one (digital, encrypted, or otherwise formed) signature and / or contributing one or more data fragments. A revised version of the data resource may be formed according to any embodiment disclosed herein and provided to one or more users.

[0164] One or more users may contribute responses or input to replace, provide, change, modify, or otherwise process at least one revised segment.

[0165] In this way, the modified segment can serve as a placeholder for input provided by one or more users.

[0166] In some embodiments, users can complete a revised version of a document (i.e., a template) by filling in missing data, and the completed version of the template can then be verified by the previous verifier (Bob) or another party.

[0167] For example, consider a scenario where a data controller (e.g., an organization like a passport office, a company employing one or more people, an airline, etc.) wants to send forms to users for them to fill out. In these examples, users could be passport applicants, employees, passengers, etc. The examples of passport offices and passport applicants will be used to illustrate this.

[0168] Passport offices have standard forms that applicants are required to complete. These forms can be in various formats, including those tailored to deaf, blind, or other vulnerable applicants. The forms include data sections that need to be transmitted to the applicant via screen, paper, vibration, or sound. They also include blank sections where applicants must enter data within the document to complete these sections.

[0169] However, it is permissible to assume that an unauthorized entity is known or suspected of distributing illegitimate versions of forms to potential fraud victims, impersonating a passport office and soliciting the completion of forged forms in exchange for valuable personal data, financial information, and / or incidental payments.

[0170] In such cases, the passport office may provide a hardware- and / or software-based verification component that the applicant and / or the passport office can use to verify the authenticity of the forms provided by the applicant. This verification component may be provided in various forms, such as via internet-based resources (e.g., a website or cloud-based facilities), or via an installable application and / or digital wallet, or any other type of computer-based device.

[0171] When providing a valid version of the application form, the passport office may amend one or more sections of its form for completion by one or more applicants. Hidden codes, watermarks, verification identifiers, timestamps, etc., may also be inserted into one or more unamended sections. This can be done using any suitable known method that facilitates watermarking (e.g., using steganography). Essentially, one or more of these sections can be configured to include (preferably) a hidden identifier or code that can be checked using the verification process described herein. Identifiers / codes / watermarks / timestamps / references, etc., can be selected to uniquely identify an event, a party associated with a data resource, at least one blockchain transaction, a version number and / or data, a cryptographic key, or any other type or form of data that the data controller wishes to include in the data resource. The term “identifier” will be used to include codes / watermarks / timestamps / references, etc. Identifiers may be obtained using at least one random or pseudo-random operation, or as the result of a mathematical operation, but selected / generated by one or more human individuals or processor-based means.

[0172] Where the identifier is associated with a blockchain transaction, the identifier may include or provide a transaction ID, block ID, the transaction / block itself or a portion thereof, and / or a hash of any of these items. One or more transactions may include data associated with data resources and / or data controllers. In other cases, alternative storage locations for the associated data may be used, such as the cloud, websites, servers, etc., although storage within the blockchain has the benefits of providing immutable, timestamped, and cryptographically protected copies of the data.

[0173] In some cases, a verification identifier can be provided in one or more revised sections because verification proves that the revised section is part of the entire original document by using a signed Merkle root. This has the advantage that while the data controller can verify the copy returned to them, an unauthorized party cannot forge the verification identifier because it is not included in the shared revised version received by the user. In this way, embodiments can provide security measures that allow users to verify, together with the data controller, whether the data resources they receive are indeed legitimate and / or up-to-date.

[0174] The Merkel root can be digitally signed by the Passport Office as described above, and the selected unedited segment can be provided to the end user as previously explained. When an applicant submits a form to the Passport Office through an authorized route, the completed form (or the signed Merkel root of that form) can be appended to or provided with the user-completed data. This allows verification of the application form used by the user according to the embodiments disclosed herein. If the form submitted by the user to the Passport Office has been modified in any way compared to the authorized version, the hash and signature will not match a valid hash and signature. Therefore, the Passport Office can notify or remind applicants who submit forms to the Passport Office electronically (e.g., by completing an online form or downloading an authorized "Application Submission" application) whether their submitted data is valid. Applicants may receive a verification notification indicating that the form they received and completed has been checked by the Passport Office and verified as valid.

[0175] Similarly, one or more sections may include the form's version number. If the law changes, the version number of the valid passport form will also be updated. If a user fills out an application form that is valid but outdated, verification software can be set up to identify this and send an alert and / or reject the application.

[0176] Therefore, embodiments can provide methods and systems that not only provide verifiable forms and templates for users to fill out, but also provide secure methods and systems for checking whether such forms have been modified, corrupted, or fraudulently provided when received by a data controller. Embodiments can also provide version control schemes for shared data, including documents, digital content, executable code, and other similar data.

[0177] Example use cases: VAST file system and database snapshots

[0178] For illustrative purposes, please refer to the following: Figures 13 to 24 Exemplary use cases are provided on how to implement embodiments of this disclosure. Files can be viewed as segments. Files can be added or modified within the system.

[0179] For example, consider a scenario where an item (record) is created in a database. Files are created on one or more storage modules at one or more locations, and the file system can be accessed on one or more devices or from one or more locations. A VAST file system is a file system composed of files stored in multiple locations. Using the techniques disclosed herein, the file system is represented as a Merkle tree (which includes each file as a leaf) and may include information such as routing data and database storage locations to facilitate file accessibility.

[0180] The leaves in a Merkel tree can also be the roots of another Merkel tree, which represents a document that can be modified according to one or more methods disclosed herein.

[0181] One or more signatures are generated by one or more data controllers and applied to the Merkle root of the VAST file system, and thus to the total contents of the database. This provides a secure and verifiable snapshot of the file system at the time of signature generation. Any file can be proven to be part of the VAST file system if the Merkle root of the file and its leaves are available. If the file is in a editable format, the recipient must be provided with a Merkle path pointing to the file's Merkle root and a Merkle path pointing to the unedited file segment being shared, to demonstrate that 1) the file being provided or the editable elements of the file are correct, and 2) the file has been incorporated into the VAST file system.

[0182] Figure 13 and Figure 14 Illustrations are provided showing how a data controller (e.g., database administrator Alice) can use the embodiments disclosed herein to create and add data to a VAST file system. Figure 13 As shown, each entry / item has a unique position in the Merkle tree.

[0183] Figure 15This illustrates the process by which Alice generates VAST file system records and attributes, or assigns ownership of the file system to identities (e.g., owner, organization, department, etc.). Figure 15 As shown, Alice can publish Merklegen to a blockchain. In some examples, this could be a public blockchain, such as, but not limited to, the Bitcoin blockchain. Additionally or alternatively, Alice can publish Merklegen as a Metanet child node of a Metanet node owned by a party controlling the database (basically according to one or more of the following: WO2020 / 109910, WO202 / 110025, WO2021 / 229334, WO2022 / 200193, WO2020 / 109908, the entire text of which is incorporated herein by reference). The advantages of publishing Merklegen to a blockchain include the ability to provide timestamped, immutable records for verifying snapshots.

[0184] All files in the VAST file system can now be traced back to their original Merklegen origin via the VAST file system owner's signature. Furthermore, from... Figure 15 It should be noted that Merkelgen data may be made public for Bob's verification purposes, but the actual content remains private. Therefore, for example, Bob can verify the continued existence and integrity of the database content for security purposes without disclosing sensitive, private, valuable, or security information, such as military-related data or commercially valuable data.

[0185] refer to Figures 16 to 18 It provides illustrations of how users can request and retrieve files in various ways. Figure 16 When a file is requested, the service verifies the user's access permissions. If valid, it locates the file in the storage unit that holds the information and provides it to the user's device. Users can submit user account information, device-specific identifiers, etc. In all cases, gating is applied, responding only to valid requests from parties with the correct permission levels.

[0186] exist Figure 17 In this context, when a file is requested, the service provides the user with the hash of that file. The user and the database owner / controller (Alice) collaborate to create a secret key pair using the service's public key (e.g., a key provided in their Metanet root node), the user's account key, and the file's hash.

[0187] exist Figure 18 In the middle, two components are provided to pass files from Alice to Bob:

[0188] 1. Files. To transfer files, the service creates an HMAC (Hash-Based Authentication Code) using existing technology and encrypts the file using the generated secret key before transmission; and

[0189] 2. Simultaneously, the Merkel path from the file hash to the Merkel root of the published file system is also transmitted. This enables the verification described above.

[0190] Figure 19 The process for verifying files is illustrated. Users (e.g., Bob) use the following steps to verify one or more files:

[0191] 1. The entire contents of that leaf in the Merkle tree must be transmitted;

[0192] 2. The receiver performs hash processing on the file;

[0193] 3. Check the hash based on the provided Merkel path;

[0194] 4. Check the Merkel path according to the Merkel root published on the public ledger.

[0195] If the check results match, the verification is successful. If the check results do not match, the verification fails. Using this process, Bob can verify whether the file is the same file that was added to the file system when the entry was created.

[0196] exist Figure 20 The documentation provides a diagram illustrating how entries in the VAST file system are handled (e.g., modified). An entry can be modified once or multiple times. Each modification requires calculating a new set of N hashes, where N is the depth of the Merkle tree. To limit the number of modifications that can be performed within a block of N entries to N, a redirection can be published. This pushes all changes to the active end of the Merkle tree (i.e., the part being performed and modified), thus limiting the complexity and resource cost involved in performing updates.

[0197] Scalable Updates

[0198] Use now Figures 13 to 24 The illustrative VAST file system is used to demonstrate how embodiments of this disclosure can be used to achieve scalable updates of information and data. Specifically, refer to... Figure 21 To scale efficiently, each leaf can be limited to a single change to a new hash representing the updated information. Leaf updates can also include hashes of previous documents (i.e., versions of the document before the update, previous versions, and / or the original version).

[0199] When a file is modified, a new leaf containing the new file hash and information is created. The Merkel path to the top of the nearest related branch from the original position can be recalculated.

[0200] Then, a redirect can be published at the leaf position where the previous version registered, and the Merkel path to the Merkel root can be recalculated. Then, the root can be published.

[0201] subtree

[0202] Specifically, refer to Figures 22 to 26 Subtrees can be added to implement, represent, and / or act as subdirectory structures. This enables hierarchical data structures to be implemented in an efficient and verifiable manner. In some embodiments, a subtree can represent a separate database as a whole. Subtrees can inherit the same functionality as the main tree and are created through entries in the main tree. Advantageously, one or more subtrees can be added that are Merkle trees of documents that have been formed into segments according to the embodiments outlined above.

[0203] Figures 23 to 26 An example of a subtree in use is provided. Consider a scenario where an organization creates a contract terms tree in a contract document, as shown in the attached diagram and described above. In this example, these contract terms reside in a subtree of the company's overall on-chain ledger. The first N entries are a list of contract terms that can be used to construct the entire contract. In some embodiments, this can be implemented in a commercial format such as EBRL, FPML, or other suitable formats.

[0204] The N+1th entry is the transaction identifier (TXID) of the blockchain transaction, which includes a subtree (or the Merkle root of that subtree) that stores the contract generated from the upper-level tree, along with any associated user data and signatures. The hash of the complete document is added to the Merkle tree and published.

[0205] Advantageously, logic code can be provided to automate the fulfillment and use of contracts. For example, the software can include rules prohibiting the use of contracts with clauses appearing later in the Merkle tree within valid contracts. This can allow for database updates and the application of permissions to specific versions of documents. In some embodiments, the contract can be implemented on a blockchain as a "smart contract." In some embodiments, the smart contract can be associated with a tokenized asset. This can be a non-fungible token (NFT) as known in the art.

[0206] In some embodiments, the contract can be generated based on segments hashed to leaf elements in the upper-level tree. The entire contract is delivered sequentially via HMAC, and the user can then hash the entire document to check if it matches the expected hash in the contract ledger. This ensures that the user is always viewing the correct version of the contract. For example, as... Figure 26 As shown, a contract using the terms in position 13 is invalid in the subtree at position 10, but valid in the subtree at position 16.

[0207] Therefore, subsequent embodiments may include steps of providing, obtaining, processing, and / or using smart contracts to automatically fulfill contracts set up substantially as disclosed in any of the embodiments provided herein.

[0208] As shown above, the embodiments provide a scheme for verifying electronic data resources even when a subset of the data has been revised / removed. Preferred embodiments utilize the properties of Merkle trees to provide such a scheme.

[0209] Although Merkle trees are known, the disclosed embodiments differ in important and inventive ways.

[0210] Merkle trees and software provision / verification

[0211] Now for special reference Figures 27 to 32 The advantages of this disclosure are described below. The technologies and systems described above can be used to provide and / or verify software products to end users. End users can be individuals or groups of individuals operating electronic devices (e.g., laptops, mobile devices such as mobile phones or tablets), vehicles, IoT devices (e.g., home appliances), or military equipment (e.g., drones or tanks).

[0212] According to this aspect of the disclosure, embodiments can be used to provide systems and computer implementations for accessing, verifying, designing, and / or building software packages / products from (potentially distributed) repositories. Repositories can include individual code elements that perform a given function upon execution. Thus, elements in a repository can be described as modules or building blocks, and a repository can be described as a (code) library or collection of elements. A code library may correspond to the “data resource” described above. Code elements can include sections or fragments of code that provide specific, predefined functionality. Preferably, code elements can be used to perform small, simple tasks. These tasks can be described as “subtasks” because they can be combined to provide more complex parts of the computer code (software product) that perform larger, desired tasks. Tasks can be defined as one or more specified functions.

[0213] Using the Merkle tree technique described above, (hash-processed) code elements can be provided as leaves in the Merkle tree. The preimage of the selected code element (leaf) can then be provided to a specific user based on the following:

[0214] 1) User needs, such as installing and performing required functions on one or more of the user's devices; and / or

[0215] 2) User access permissions; for example, these permissions may be based on the user's ability to provide an authorization identifier (e.g., license key, password, PIN, etc.) or on the user's role in the organization.

[0216] Using the disclosed techniques, it is possible to select software functionality to provide to users from multiple software elements in the tree, while restricting access to elements that are not needed or unauthorized to be shared with users. In other words, one or more parts of the codebase can be modified so that the modified parts are not shared with specific users or user groups as described above. For verification purposes, the modified parts are only provided in a hashed form.

[0217] It should be noted that user needs or access permissions may change over time. For example, a user might pay for an upgrade to their electric vehicle and request access to the software that enhances its performance, or a user might be promoted to a higher role within the organization, allowing them to perform a wider range of tasks and operations on their computing device, or a manufacturer might need to deploy an operating system upgrade to implement bug fixes or security patches. Therefore, data controllers may need to allow different users access to different code elements at different times. This can be achieved securely, quickly, and reliably by modifying the code elements shared with users.

[0218] Such embodiments may include the use of blockchain transactions incorporating Merkel roots to allow end users to independently verify the authenticity of portions of software published or shared by a provider. In such embodiments, the software provider may be the creator or distributor of the software and may be referred to as a “data controller” as described above. Software may be described as “part of (computer) code” and / or a “software package” or “software product.” A software product may include multiple software items or components. For consistency with the terminology used above, these may be referred to as “elements.” Additionally or alternatively, depending on the examples used above, these elements may also be referred to as “computer code elements” or “code elements,” “software elements,” or “segments.” Code elements may include a complete executable program or a code fragment contained within a complete executable program. Preferably, code elements are stored as a collection in a repository or otherwise associated with each other in a repository, which may be referred to as a “data resource” or “codebase,” or simply a “library.”

[0219] In some embodiments, the software product can be created as code executable via a blockchain. In this example, for illustrative purposes only, the software product can be generated as blockchain executable code (e.g., a Bitcoin script) from multiple blockchain executable code portions provided in multiple corresponding blockchain transaction outputs. The blockchain (e.g., Bitcoin) transaction outputs are processed in a specific order to achieve a desired result. However, in other embodiments, the software product can be generated as other types of executable machine code. For example, the software can be generated as native code for use in embedded system controllers or systems with a specific architecture.

[0220] Other embodiments may involve:

[0221] • Propagate the processed data items for use as variables in subsequent software product items; and / or

[0222] • Distribute software stored in a private database or storage resource, where the published Merkle root or root acts as an anchor point from which any element of the software product can be verified.

[0223] An overview of methods for building software products using Merkle roots and data contained in blockchain transaction output sets.

[0224] Now for special reference Figure 27 and Figure 28 . Figure 27 The diagram illustrates a Merkle tree containing elements of a codebase, where the Merkle root of the tree is published in a blockchain transaction. This transaction can be formed according to protocols of the Bitcoin blockchain, the Ethereum ledger, or any other blockchain ledger implemented using associated protocols and node networks. Figure 28 Other embodiments are shown, in which the Merkle tree contains elements of a codebase, and each leaf of the Merkle tree is a transaction ID (TxID) or other identifier that can be used to identify a blockchain transaction through which related, associated code elements can be extracted, located, or accessed.

[0225] More in detail, Figure 27 The diagram illustrates a software repository (“codebase”) mapped to or represented in a Merkle tree as described above. The (signed) root of the Merkle tree representing the entire repository is stored in a blockchain transaction. This can be performed using any suitable transaction identifier. For example, the identifier could be a transaction ID formed according to a blockchain protocol implemented by all nodes in the blockchain network, or it could be pre-defined metadata or a flag provided in a script within the transaction. The root can be stored in the transaction in any suitable manner, such as as a fragment of metadata in a script, or as a fragment of data provided, for example, in a non-executable portion of the output following an OP_RETURN statement.

[0226] Hash each code element (optionally, along with any additional data, such as version data, copyright data, encryption keys, or metadata) to provide the leaves of the tree.

[0227] exist Figure 28 In this representation, each code element is shown as multiple blockchain transactions, each associated with a corresponding code element in the library. In some embodiments, each leaf is a hash of its entire blockchain transaction, or simply its identifier, or a combination of data items that can identify a specific location on the blockchain, such as a combination of block ID, transaction ID, and / or output number (VOUT). Although Figure 28 A code element is shown that is stored in, mapped to, or otherwise associated with a specific blockchain transaction, but this disclosure is not limited thereto. In other embodiments, one or more code elements may be stored in or mapped to the same transaction. The mapping or other association of code elements to a specific transaction can be performed in a variety of ways. For example, in some embodiments, code elements may be directly inserted into a transaction within a script. In other examples, a reference or pointer to a storage location that houses one or more associated code elements may be used, such as a URL of an internet site, or an IP address, or a DHT table, a record identifier in a database, etc. Thus, code elements can be accessed from an off-chain location or from the blockchain ledger itself.

[0228] In some embodiments, the library may be accessed via an application installed on an end-user's device and used to download and reproduce the software product to be distributed according to this disclosure. This program is referred to as a "verifier" to distinguish it from a software product downloaded and built with multiple code elements that have never been modified, and if verification is successful, it is installed on one or more devices.

[0229] In one example, the verifier can provide a signed Merkle root for the codebase and at least one public key associated with at least one authorizing party. Verification of the code segment can be performed as described above, since the verifier can provide hashed leaves of other (modified) parts of the codebase to verify the entire tree. The verifier can compute the hash of the received code element and combine it with the hash of the modified leaves to compute the entire Merkle tree and the Merkle root. This can be compared to the Merkle root already signed by the authorizing party. If the computed root matches the signed root, the received code element must exist in the Merkle tree with the signed root. Therefore, the verifier can verify whether the code element it receives belongs to the Merkle tree representing a legitimate codebase.

[0230] To enhance security, the data controller / authorizing party may include at least one verification or "watermark" element as a leaf in the tree. One or more watermark leaves may include hashes of any one or more selected data items known only to the data controller / authorizing party. For example, this could be a random number, or a selected image or message. Over time, to ensure security is not compromised, the watermark can be changed, and the data controller can accordingly calculate a new Merkle root of the tree and sign it. The new Merkle root and watermark leaves can then be distributed to the verifying party.

[0231] The data controller / authorizer can sign the new Merkle root using a subkey generated from its master key. This can be performed essentially as disclosed in WO2017 / 145016 and may include:

[0232] • The data controller has an asymmetric encryption key pair, which can be referred to as the data controller's master key pair. This asymmetric encryption key pair includes a master public key and a master private key.

[0233] • The parties agreed on a universal elliptic curve cryptography (ECC) system and a universal generator (G); the universal generator can be selected, randomly generated, or assigned.

[0234] • Users and data controllers agree to share a message (M). M can be anything chosen by one or both parties, such as a random number or string, or a pre-selected code, the output of a mathematical operation, etc.; the message can be shared between the parties using any suitable method (e.g., via internet communication or telecommunications transmission, downloaded or viewed from a remote store, etc.).

[0235] • Use the message (M) to generate a deterministic key (DK). The DK can be generated by using M as input to a cryptographic hash function (e.g., SHA-256), resulting in: H(M).

[0236] • Data controllers generate subkey pairs based on their master key pairs in the following ways:

[0237] i) Generate a private key subkey using scalar addition of the master private key and the deterministic key; and

[0238] ii) Use the following equation to generate the public subkey:

[0239] MasterPubKey+H(M)x G

[0240] Where: + represents elliptic curve addition, x represents elliptic curve dot multiplication, and MasterPubKey is the master public key.

[0241] This makes it possible to generate subkey pairs from an existing (master) key pair, so that the new subkey pairs are provably linked to the master key.

[0242] The verification process also provides inputs that enable the identification of the initial transaction, which includes one or more outputs (e.g., UTXOs) of one or more library roots located on the blockchain. The verification process is used to analyze the blockchain to determine whether the software product for which access is requested is:

[0243] 1) Published by the licensor; and / or

[0244] 2) The format is correct so that it can be interpreted and installed in the way the device expects.

[0245] In some embodiments, application-level protocols can be used to build on-chain libraries. An example of this could be the Metanet protocol, essentially as described in WO2020 / 109908, to allow for simplified and rapid verification of deep and complex on-chain hierarchies containing multiple code elements. These code elements may be provided by multiple individual developers or vendors and / or approved by a parent organization that controls the device or parent software system being installed. An example of such an ecosystem could be a mobile phone operating system with a built-in app store. The mobile device can provide an identifier for a blockchain transaction (e.g., TxID) containing the root node of the app store and can independently verify the signature of any package within the app store to check if the package is an approved application that can be securely installed on the user's device.

[0246] In the illustrative embodiment, when instructed which software product to install (e.g., which app to access and install from an app store), the verification program downloads:

[0247] 1) Merkelgen;

[0248] 2) A list of transaction IDs for the required code elements (only);

[0249] 3) A list of specific data to be extracted from each transaction, which may include one or more parts or all of the output script, or at least one stack item on any of the one or more processing stacks available in the blockchain's evaluation environment at the end of the transaction verification; and / or 4) A description of the order in which the code elements of the specified transaction are assembled into the desired software product.

[0250] In some embodiments, the validator accesses a website or other software repository and downloads the listed items off-chain. Additionally or alternatively, the validator may access some or all of the data listed above from at least one blockchain transaction by spending (or consuming) one or more outputs of at least one transaction. For example, the validator might need to use a pre-authorized or provided key to spend one or more outputs containing the required data, thereby revealing the necessary data, for example, using a Pay-to-Script Hash (P2SH). The spending on the outputs is recorded on the blockchain ledger, providing an immutable, timestamped, and irrefutable record indicating that the end-user's device has been granted permission to access a specific segment of data.

[0251] Upon access, the software build component assembles the downloaded code elements and uses these elements to build a complete software product. This build component can be installed on the end-user's device and / or can form part of a verification process. If the downloaded code is not natively executable relative to the architecture of one or more processors on the device, the build component will compile and / or interpret the instructions accordingly and verify all elements required to build the software product. Some or all of the build, assembly, interpretation, and / or execution steps can be performed within a secure component of the device (e.g., a secure enclave, TEE, or HSM).

[0252] An overview of methods for creating multiple different software products using code elements contained in a Merkle tree.

[0253] For illustration, consider a scenario where the data controller is a mobile device, such as a phone / tablet manufacturer providing an app store from which users can choose apps to download and install on their mobile devices. In another example, the data controller could be an equipment manufacturer that provides end users with a range of devices or systems (e.g., kitchen appliances, vehicles, control systems, etc.). Depending on the product model, version, or range, a particular device may share some code elements with other models / versions / ranges of devices from the same manufacturer. However, a particular model or version may not allow or require all code elements to be implemented. Suppose a user wants to upgrade their device to a more advanced version; they might need to access and install additional software elements from the manufacturer's software repository.

[0254] Using this technology, data controllers can design and build different software product configurations for different users or user groups, depending on whether the software elements specified by the data controller from the tree are downloadable or non-downloadable for the user (i.e., modifying a given user from the repository). Figure 29As shown, hashes of software configurations can be published in a Merkle tree, where each hash represents a fully constructed executable code element, which is constructed wholly or partially from code elements contained in the library's Merkle tree. Each configuration can be unique within the Merkle tree, using distinct elements selected from the entire set of code elements in the library.

[0255] exist Figure 29 In the diagram, configuration 1 specifies the selection and combination of code elements 1, 3, and 5 of the Merkle tree. Configuration 2 specifies the selection and combination of code elements 4, 6, and 11 of the Merkle tree. Configuration 3 specifies the selection and combination of code elements 7, 9, and 12 of the Merkle tree. Different configurations can be distributed to different devices of end users, for example, based on the device model or version, or whether the user has subscribed to premium services from the provider.

[0256] Therefore, according to the disclosed embodiments, a Merkle tree can contain multiple code elements that, when assembled in a prescribed order, can be used to build different software products. Each code element provides a building block or functional component that performs a corresponding function (i.e., task). When combined, the tasks of the code elements act as subtasks within a more complex task. In some examples, instructions are distributed instructing the end-user's computing device on how to build the software product to be installed and executed on the device. The device can take any form, such as a mobile phone, laptop, server, vehicle, IoT device, distributed system, parallel processing system, etc.

[0257] Therefore, the instructions determine, guide, and control which software products a user device accesses and builds. The advantage of using a Merkle tree is that the end-user's device cannot see all code elements, but only the elements needed to build one or more software products for which access has been granted.

[0258] In these embodiments, it is also reasonable that a single leaf of the same Merkle tree can contain references to code elements that are used multiple times during software assembly, such as creating software where functions must repeat operations, or creating software with several similar functions (each containing the same sub-elements / tasks). In these embodiments, the purpose of the Merkle tree is to improve the efficiency of software release because it eliminates the need to release the same instruction set multiple times.

[0259] This method of assembling elements from a single Merkle tree into multiple different software products can be applied to situations where code is included in blockchain transactions, or where code is stored in a private database or other storage facility outside the blockchain. Advantageously, Merkle trees allow any party to obtain instructions for assembling any desired software package and to verify that all components have been correctly downloaded and assembled, from the correct source, and have not been compromised by an unauthorized party.

[0260] Overview of methods for controlling updates to a Merkle tree containing software elements from a software repository

[0261] In some embodiments, when a software repository (codebase) is created, an initialization process must be performed, during which a blockchain transaction output is generated. This output contains a script that updates the correct set of permission controls required by the repository by adding leaves to the Merkle tree. This script can be formed in various ways, and the structure of any particular script may depend entirely on the permissions and authorization structure of the repository in which its Merkle resides.

[0262] For example, consider a codebase created and managed by two developers, both of whom can add content to a Merkle tree. In a Bitcoin-based implementation, for illustrative purposes only, such output could be represented using a 1 / 2 multisignature evaluation script snippet with the following structure:

[0263] 1 <pubkey1> <pubkey2>2OP_CHECKMULTISIG

[0264] In this way, either party can spend the transaction output containing the Merkle root to publish the updated Merkle root. The publishing party can also change existing permissions by solving this puzzle. Developers may leave the project, or new developers may join, so the output must be spent in a new version of the unlock script that takes into account the modified permission structure.

[0265] In this way, scripts can also be published that enforce rules to ensure that any published Merkle root is purely additive, verifying that the existing hashes of previously added data items are still contained in the tree and have a path leading to the new Merkle root value. Such scripts take the new Merkle root and the Merkle path connecting the previously existing hashes to that updated root as input, allowing the party submitting the updated Merkle tree to provide proof that the previous hashes remain in the same position throughout the tree. Such scripts are particularly advantageous in large open-source projects, as they ensure that references to previously valid code are never removed from the Merkle tree, where anonymous parties can submit code. This ensures code integrity.

[0266] Figure 32 This illustrates a scenario where additional code elements are used to update or enhance an existing software product (selected code element + configuration). For example... Figure 32 As shown, a Merkle tree comprises a series of code elements that together are used to build a software product with an initial configuration v1.0. At subsequent points in time, this configuration needs to be updated or enhanced to provide a new configuration v2.0. The code elements are not replaced by other elements of the Merkle tree; rather, they are added to the tree, preserving the previous version in its existing leaf position and adding new leaves for the updated configuration. The monitoring process (by...) Figure 32 (The number 1 next to the eye symbol in the image) monitors transactions that include updates on the blockchain, and then (by...) Figure 32 (As shown by the number 2 next to the processor symbol) The new version of the software assembly instructions is accessed from update transaction 2, and then the updated configuration is downloaded to the processor.

[0267] Overview of methods used by end users to update software verified and released using Merkle trees

[0268] In some embodiments, a Merkle root containing a tree of code elements is published. End users of software built for use on their devices can access: 1) blockchain transactions containing the Merkle root; 2) instructions detailing the order in which the leaves should be assembled; and 3) the code elements represented by the Merkle leaves and their corresponding Merkle paths.

[0269] At some point after the software is built and running, the software publisher can release an update that can update existing code elements used in the package or add new code elements to the software product. In either scenario, a new Merkle root will be released.

[0270] Publishers achieve this by spending existing outputs of transactions containing the Merkle tree into new blockchain transactions containing the new Merkle tree and updated locking conditions associated with any subsequent updates. End-user devices can be configured to monitor updates to existing outputs so that action can be taken immediately upon publication. Alternatively, end-user devices can be configured to monitor outputs periodically (e.g., weekly / monthly) or not at all, allowing users to determine when to check for updates. In either case, the process of accessing and building the updated software remains the same.

[0271] The process can be summarized as follows:

[0272] 1. The user's device checks the root's previously known latest transaction output and determines if it has been spent. If it hasn't been spent, this is the latest version. If this is an already installed version, no further action is taken.

[0273] 2. If the output has been spent, the device requests and / or obtains information about the transaction in which the output was spent, and determines which output of that transaction represents the updated Merkle root.

[0274] 3. Repeat steps 1 and 2 on the user's device until the latest version of Merklegen is found.

[0275] 4. Instructions for users' devices to access the latest version of the software product they are using. This could mean accessing a private database or a separate transaction on a blockchain containing the instructions.

[0276] 5. Using the instructions, the user's device downloads any code elements required to build the updated software product and uses the provided proof to verify that the code element is part of a Merkle tree.

[0277] 6. Assemble a new version of the equipment software product and use it to replace the existing version, thereby providing users with an updated version of the application or utility.

[0278] Figure 30 An example of creating a blockchain (e.g., Bitcoin) transaction (Tx) is illustrated, which implements a software compilation process to generate hardware for embedded computing resources. At the end of the processing script, the transaction (Tx) generates executable code as a stack item. The transaction also generates output containing a copy of the script that executed the compilation process. When a firmware update is needed, the newly created output (e.g., UTXO) is consumed, and a new firmware configuration is generated in the update transaction. This update transaction is a new transaction that is written to the ledger and consumes the previous transaction. Advantageously, the embedded system can view and access the updated firmware without logging into any platform or service.

[0279] Used to generate output based on variable inputs, using blocks obtained from a list of possible subsequent steps. Summary of chain output methods

[0280] In some embodiments, a set of script outputs can be created, which perform different types of operations based on the data being generated. In this case, a functional layer with proxy capabilities can be implemented, dynamically selecting the next step to take from a list of valid subsequent steps based on the data output generated from the previous state. This type of processing can be defined as a finite state machine, where a dynamic and changing set of inputs drives the operation of the entire system through a set of states until the final result.

[0281] In this configuration, each possible state is contained within the entire Merkle tree and can be downloaded and verified independently as part of a corresponding package, ensuring that the finite state machine will only transition to predetermined states system-wide. The states and / or triggering events / conditions used to move the machine from its current state to a new state can be defined in a stored record (e.g., the machine's state transition table). The finite state machine can be a deterministic finite state automaton (DFA) and can be implemented on computational resources executed separately from the blockchain, but can be configured to interact with or monitor its state.

[0282] These embodiments refer to Figures 31a to 31f The diagram illustrates the creation of multiple blockchain transaction outputs, each performing a different corresponding function. These outputs are executed sequentially by a higher-level program to compute the desired result, such as calculating the volume of a cylinder in this example. In Figure 31.e, these outputs are processed through a series of separate blockchain transactions (Tx), while in Figure 31.f, they are processed sequentially within a single transaction (Tx).

[0283] the term

[0284] It should be noted that the terms "redaction", "adaptive redaction", and "sanitisation" used in the prior art are slightly fluent and inconsistent. Here, the term "redaction" is used for convenience of reference, but its intent includes "adaptive redaction" and "sanitisation", and its intent includes "hiding", "masking", "removing" and / or "replacing" one or more selected portions of a data resource.

[0285] In addition, the following terms are used in this article:

[0286] "Sharing" includes one or more of the following: displaying, transmitting, distributing, presenting, streaming, printing, providing, granting access to, or otherwise providing from one entity to at least one other entity. An entity can be any human individual, or a machine-based resource or group thereof. Preferably, "sharing" includes providing the content of a segment to at least one other entity in a manner that meaningfully reveals the segment's content, such as in a way that can be read, processed, performed, and / or understood by a human or machine, possibly for a given purpose;

[0287] • "Data resource" can include any part of (preferably electronic or digital) data, such as, but not limited to: a file or set of documents, videos or other content provided electronically or digitally; the term can be used to include a single content item or multiple data items that can be collectively regarded as a single entity / resource; additionally, a single data resource can be owned and / or controlled by one or more data controllers; in some cases, a data resource can be a computer program or part thereof, an executable file or source code, or a complete software product.

[0288] A "data controller" refers to any entity or group of entities that has control and / or authorization over a data resource. A data controller may be the producer or owner of the data resource or a portion thereof, or may be authorized to access and / or control access to the data resource on behalf of that party. A data controller may include more than one entity or sub-entity; for example, more than one organization, individual, or entity may share control / ownership of the data resource. In some cases, if more than one party constitutes a data controller, a signature threshold may be applied; for example, n out of m signatures or authorizations may be required to consider an action as approved by the data controller. Here, for convenience, one or more data controllers may be referred to as "Alice."

[0289] • "Acquisition" includes any method of possessing an entity, and includes generating, calculating, selecting one or more sources, or receiving from one or more sources;

[0290] The terms "validation" and "verification" (and their corresponding "verifier") are used interchangeably in this document.

[0291] • "Processing" includes, but is not limited to, one or more of the following: generating, storing, transmitting (via electronic networks), transferring control, accessing, viewing or modifying;

[0292] • The term "blockchain" is intended to encompass any form of ledger executed in a cryptographic manner, regardless of its associated implementation, network, or protocol, or any type of cryptocurrency that may be associated with it, whether it is private or public, or utilizes proof-of-work, proof-of-stake, or any other type of consensus mechanism; in some cases, the ledger may be implemented in a distributed and / or peer-to-peer architecture or manner; the terms "blockchain" and "ledger" are used interchangeably in this document;

[0293] The term "Bitcoin" as used herein is intended to include all protocols and implementations that originate from or deviate from the original protocol described by Satoshi Nakamoto in the Bitcoin white paper "Bitcoin: A Peer-to-Peer Electronic Cash System"

[2008] . Since the Bitcoin blockchain is the most widely known, it may be referred to herein for convenience and ease of reference / illustration. However, the embodiments of this disclosure are not limited in this respect, and other blockchain protocols and implementations, whether or not they originate from the original Bitcoin protocol, are within the scope of this disclosure.

[0294] • "On-chain" can include being stored, executed, or processed on, in, or through a cryptographically executed ledger (e.g., a blockchain ledger). Conversely, "off-chain" can include being stored, processed, or executed separately from a cryptographically executed ledger (e.g., a blockchain ledger).

[0295] Enumeration Clauses of the Embodiments Shown

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

[0297] Any features provided in this section regarding a particular set of terms, embodiments, or aspects are not thereby limited and may be used or incorporated with respect to any one or more other sets of terms, embodiments, or aspects.

[0298] Embodiments of this disclosure provide computer-implemented systems and methods. Additionally or alternatively, embodiments of this disclosure may provide methods and systems for one or more of the following: protecting data; revising electronic data; (encryptively) controlling access to (preferably, digital) data resources or at least a portion thereof; revising (preferably, digital) data resources; securely transmitting / distributing (preferably, digital) data resources; and controlling selective access to (preferably, digital) data resources.

[0299] Additionally or alternatively, embodiments of this disclosure may provide one or more of the following:

[0300] • Improved digital signature algorithm;

[0301] • Improved smart contract solutions;

[0302] • Improved schemes for obtaining or providing forms, templates, or data resources for one or more users to fill out;

[0303] Completion may include contributing a signature (digital, encrypted, or otherwise formed) and / or contributing one or more data fragments. A revised version of the data resource may be provided, in which one or more users contribute responses or input to replace, alter, modify, or otherwise process one or more revised portions. In this way, the revised portions may serve as placeholders for input provided by one or more users.

[0304] Examples of systems and methods, including those substantially as described herein, particularly in the section entitled "Templates and Tables," are provided.

[0305] The technical benefits derived from the embodiments may include, but are not limited to: protecting or enhancing privacy and / or anonymity; protecting data; improving selective sharing of data; and improving the verification of the authenticity and / or integrity of data resources.

[0306] In a preferred embodiment, this disclosure can provide solutions for protecting, sharing, verifying, and / or generating data resources (e.g., but not limited to documents, files, code repositories, executable code, media, or multimedia files). In an exemplary embodiment, the data resource is expressed, represented, or defined as a plurality of component segments, which are then hashed. A Merkle tree representing the complete original version of the data resource is generated, wherein the hashes of the segments serve as the leaves of the Merkle tree. An authorized signatory signs the root of the tree. A revised version of the data resource can then be shared, omitting one or more segments that the data controller wishes to keep confidential or not share in their original form. These steps can be performed by an authorized party authorized to verify the authenticity of the data resource, such as a data controller, resource creator, or owner, or any party authorized on their behalf.

[0307] To verify the authenticity and / or integrity of the revised data resource, sufficient data (e.g., the corresponding hashes of the one or more non-shared segments) is provided to the verifier to verify the presence of the one or more non-shared segments in the tree representing the original complete version, and the presence of the authorized signature that signs the root. In some embodiments, the data resource is a codebase, and the segments are portions of computer code that perform specific subtasks. The code can be represented in any form of artificial language and / or may include one or more of source code, object code, binary instructions, OP_code, assembly code, native code, executable code, virtual machine code, firmware code, etc. Shared code segments may be selected such that when executed on a processor, the shared code segments are combined to perform larger tasks.

[0308] Additionally or alternatively, according to one form of wording, an embodiment may be described as including a computer-implemented method comprising:

[0309] Sharing and / or providing at least one segment of a data resource comprising multiple segments;

[0310] Merkle trees are used to facilitate or perform verification of the data resources, the Merkle tree comprising the corresponding hashes of the plurality of segments that serve as leaf nodes of the tree.

[0311] Verification of the data resources may include verifying the authenticity, ownership, origin, integrity, and / or source-related data associated with the data resources.

[0312] Additionally or alternatively, according to another form of wording, the embodiment can be described as including a computer-implemented method comprising:

[0313] The data resources are represented as a Merkle tree, where:

[0314] i) The data resource includes multiple segments; and

[0315] ii) The Merkle tree comprises a root and a plurality of leaves, each of the plurality of leaves comprising a hash of a corresponding segment of the plurality of leaves.

[0316] The method may include the following steps: the authorizing party signs the root of the Merkle tree. The method may also include the following steps: sharing or sending one or more of the following from the controller of the data resource to the recipient:

[0317] i) The signed root of the Merkel tree;

[0318] ii) the preimage of the hash of at least one of the plurality of leaves; and

[0319] iii) The hash of any other leaf among the plurality of leaves required by the receiver (or the other party) in order to reconstruct the Merkle tree and calculate its root.

[0320] In some embodiments, step iii may include sending the hashes of all other leaves among the plurality of leaves except those that have shared one or more preimages. In other words, the controller may share all leaves of the Merkle tree, but some leaves are shared in their preimage (unedited) form, while other leaves (i.e., edited segments) are shared only in their hashed form. The method may include the steps of selecting which segments(i.e., unedited) will be shared in their preimage (i.e., unedited) form, and which segments(i.e., edited) will be shared only in their hashed (i.e., edited) form.

[0321] The preimage can be a non-hash version of at least one of the plurality of leaves.

[0322] In one or more embodiments, the data controller and the authorizing party may be or include the same entity / action performer / party.

[0323] Reconstructing the Merkle tree may include hashing pairwise hashes to reach the Merkle root of the tree.

[0324] The recipient and the other party may be or include the same entity / action performer / parties.

[0325] The hash of any other leaf sent by the controller to the receiver may be the corresponding hash of one or more modified segments of the data resource that the data controller does not wish to share with the receiver in its original (or meaningful) form.

[0326] The method may further include the following steps: verifying the authenticity and / or integrity of the data resources in the following ways:

[0327] The Merkle tree is reconstructed and its root is calculated using one or more preimages and one or more hashes received from the data controller.

[0328] The signed root of the Merkle tree received from the data controller is compared with the calculated root of the reconstructed Merkle tree.

[0329] If the signed root matches the calculated root, the data resource can be considered verified / authentic / not leaked; if they do not match, the data resource cannot be considered verified / authentic / not leaked.

[0330] Additionally or alternatively, according to another form of wording, the embodiment can be described as including a computer-implemented method comprising:

[0331] Obtain (e.g., generate) a first version of a Merkle tree comprising multiple segments of a digital resource, wherein the (leaf) nodes in the Merkle tree comprise the corresponding hashes of the multiple segments;

[0332] Sign the root of the Merkle tree;

[0333] The signed Merkel root is used to verify the first and / or second versions of the digital resource.

[0334] Technicians should understand that all tree structures, including Merkle trees, include roots. Therefore, the term "root" in the above definition does not require any antecedents.

[0335] The first version may be the unedited and / or original version of the data resource.

[0336] The second version may be a revised version of the data resource, wherein one or more parts / segments / elements of the first version have been omitted, replaced, and / or altered in some way relative to their original state. The second version may be provided or obtained by selecting sub-parts of the plurality of segments (i.e., the plurality of segments minus at least one segment).

[0337] A digitally signed message may include one or more additional data items. The digital signature can be generated using a key owned, controlled, or operated by the controller / owner of the data resource.

[0338] Signing the root can include signing a message that includes the root or its hash.

[0339] The root can be signed by one or more controllers / owners / administrators of the data resource.

[0340] Verifying the first and / or second version of the digital resource may include any one or more "verification / authentication" process steps disclosed herein. This may include one or more of the following:

[0341] • Check if the key, digital signature, and / or message match;

[0342] • Check whether the calculated Merkle root matches the version provided in the data controller and / or signed message;

[0343] • Access one or more (minimally editable) segments / elements of the data resource;

[0344] • Hash at least one minimal editable element (segment);

[0345] • Use the provided Merkel path elements to compute the root;

[0346] • Provide or obtain one or more Merkel paths pointing to an unmodified resource segment (i.e., the minimum number of additional nodes in the tree required to compute the root hash starting from a given leaf).

[0347] Additionally or alternatively, according to another form of wording, the embodiment can be described as including a computer-implemented method comprising:

[0348] Provide or obtain the root of a Merkle tree, the Merkle tree representing at least one data resource, wherein each segment of the at least one data resource is provided as a corresponding leaf of the Merkle tree;

[0349] The signed message, including the root of the Merkel tree, is used to facilitate or perform verification of the revised version of the at least one data resource.

[0350] Additionally or alternatively, according to another form of wording, the embodiment can be described as including a computer-implemented method comprising:

[0351] A computer-implemented apparatus for verifying revised subsets of various parts of a data resource; and / or

[0352] Verify or facilitate the verification of revised subsets of various parts of a data resource.

[0353] The method may be combined with any one or more features / steps disclosed herein.

[0354] The term "part" can be replaced with "segment".

[0355] Additionally or alternatively, according to another form of wording, the embodiment can be described as including a computer-implemented method comprising the steps of providing the following from a sender (e.g., a data controller) or on behalf of the sender (e.g., a data controller) to a receiver (e.g., a data verifier):

[0356] A revised version of a data resource comprising multiple segments, wherein the data resource is revised relative to its original (first / initial) state because at least one of the multiple segments has been revised;

[0357] The revised segment or the (corresponding) hash of each revised segment; and / or

[0358] The original version of the Merkle tree of the data resource, the Merkle tree comprising:

[0359] i) leaf nodes including the corresponding hashes of the plurality of segments in the original version of the data resource; and / or

[0360] ii) A root signed by the data controller or on behalf of the data controller.

[0361] Revising the at least one paragraph may include omitting, replacing, or changing the at least one paragraph from / in the revised version.

[0362] Additionally or alternatively, according to another form of wording, the embodiment can be described as including a computer-implemented method comprising the steps of receiving by a receiver (e.g., a data validator) from a sender (e.g., a data controller or a party representing the data controller) the following:

[0363] A revised version of a data resource comprising multiple segments, wherein the data resource is revised relative to its original (first / initial) state because at least one of the multiple segments has been revised;

[0364] The revised segment or the (corresponding) hash of each revised segment; and / or

[0365] The original version of the Merkle tree of the data resource, the Merkle tree comprising:

[0366] i) leaf nodes including the corresponding hashes of the plurality of segments in the original version of the data resource; and / or

[0367] ii) A root signed by the data controller or on behalf of the data controller.

[0368] The method may also include one or more of the following:

[0369] A new instance of the Merkle tree of the original version of the data resource is constructed by the recipient or on behalf of the recipient using the revised version of the data resource and one or more hashes of the at least one revised segment;

[0370] The root of the new instance of the Merkle tree of the original version of the data resource is compared with the root of the Merkle tree provided by the sender;

[0371] Verify the digital signature of the root of the Merkle tree provided by the sender.

[0372] Verifying the digital signature of the root of the Merkle tree provided by the sender may include one or more steps to check whether the signature of the provided Merkle root was generated using or derived from an encryption key known to be associated with the data controller.

[0373] The step of constructing the new instance of the Merkle tree of the original version of the data resource can be performed by combining the revised version of the data resource with the hash of the revised segment or each revised segment. The Merkle tree can be constructed using known techniques for hashing hash pairs to derive the root of the entire data resource.

[0374] This step may include inserting the hash of the one or more revised segments, or each hash, into the revised data resource, and / or replacing the revised segments of the revised version of the data resource with the corresponding hash of the revised segments or each revised segment. In other words, the one or more revised segments may be replaced with their corresponding hashes to enable the construction of the new instance of the Merkle tree.

[0375] The revised version of the data resource can be considered verified and / or legitimate if the following conditions are met:

[0376] - The signed Merkelgen digital signature has been confirmed or verified as being generated using or derived from an encryption key known to be associated with the data controller; and / or

[0377] - The root of the new instance of the Merkle tree (constructed by the receiver) matches the signed root of the Merkle tree (provided by the sender).

[0378] Additionally or alternatively, according to another form of wording, the embodiment can be described as a method for verifying a revised version of a data resource, the method comprising obtaining from the source:

[0379] The signed root of the Merkle tree, which represents the original version of the data resource comprising multiple segments, wherein each leaf in the tree includes a hash of the corresponding segment, and the signed root includes or is associated with a digital signature associated with an authorized entity of the data resource;

[0380] The hash of at least one of the plurality of segments.

[0381] Such methods may also include one or more of the following steps:

[0382] Obtain the Merkel path and / or the revised version of the data resource from the source;

[0383] Verify the revised version of the data resource;

[0384] Obtain an indication or identifier for one or more of the modified segments among the plurality of segments.

[0385] Additionally or alternatively, according to another form of wording, the embodiment can be described as a computer-implemented method comprising the following steps:

[0386] Provide or obtain:

[0387] i) A Merkle tree, the Merkle tree representing at least one data resource, wherein each of a plurality of segments of the at least one data resource is provided as a representative leaf of the Merkle tree, and a signed Merkle root, the signed Merkle root being signed by or on behalf of at least one authorized or controlling entity.

[0388] ii) a revised version of the at least one data resource, the revised version comprising a subset of the plurality of segments; and

[0389] iii) The hash of each segment in the subset of the plurality of segments.

[0390] The provisioning and / or the acquisition can be performed by nodes on a computer network. The provisioning can be performed by at least one (first) sending node / computing resource, and the acquisition can be performed by at least one (second) receiving node / computing resource.

[0391] Clause Set 1:

[0392] Any features provided with respect to Clause Set 1 are not thereby limited and may be used or incorporated with respect to any one or more other Clause Sets included herein.

[0393] Clause 1.1. A computer-implemented method, the method comprising the following steps:

[0394] Provide or obtain the root of a Merkle tree, the Merkle tree representing at least one data resource, wherein each of a plurality of segments of the at least one data resource is provided as a corresponding leaf of the Merkle tree;

[0395] Use the signed version of the Merklegen data to perform or facilitate verification of the revised version of the at least one data resource.

[0396] Clause 1.2. The method described in Clause 1, wherein:

[0397] The Merkelgen was signed by or on behalf of at least one authorized or controlling entity; and / or

[0398] The revised version of the at least one data resource includes a subset of the plurality of segments.

[0399] Clause 1.3. The method described in accordance with Clause 2 includes one or more of the following:

[0400] Select the plurality of segments and / or the subset of the plurality of segments that specify or otherwise define the at least one data resource;

[0401] At least one segment is selected from the data resource for modification to obtain the subset of the plurality of segments.

[0402] Clause 1.4. The method described in accordance with Clause 2 or 3, wherein the method includes the step of providing one or more of the following to at least one recipient:

[0403] i) the revised version of the at least one data resource;

[0404] ii) Digitally signed messages;

[0405] ii) A digitally signed copy of the Merkelgen signature;

[0406] iii) Merkel proof derived from the Merkel tree;

[0407] iv) The hash of at least one of the plurality of segments of the data resource;

[0408] v) Additional data.

[0409] Clause 1.5 The method described pursuant to any of the preceding clauses, wherein:

[0410] The revised version of the at least one data resource includes or provides templates, forms or other resources for one or more users to complete or input.

[0411] Clause 1.6 The method described pursuant to any of the preceding clauses, wherein:

[0412] i) The data resources include contracts; and / or

[0413] ii) A computer program is provided in association with the at least one data resource, and the computer program is operable to control or influence the use of the data resource; and / or

[0414] iii) At least one segment of the at least one data resource includes or is used as a watermark, version identifier, authentication code, or security mechanism, which is arranged to enable verification of the authenticity, integrity, origin, or legality of the data resource.

[0415] Clause 1.7. The method described under any of the preceding clauses includes one or more of the following:

[0416] Hash one, some, or each of the multiple segments;

[0417] The Merkle tree is obtained using the multiple segments;

[0418] Performing or facilitating the verification of the revised version of the at least one data resource includes one or more of the following:

[0419] a) Perform a comparison operation on or using one or more of the following: the acquired encryption key, digital signature, and / or message, to see if they match the corresponding calculated encryption key, digital signature, and / or message;

[0420] b) Check whether the obtained Merkle root matches the calculated Merkle root;

[0421] c) Accessing or otherwise processing at least one of the plurality of segments;

[0422] d) Hash at least one of the plurality of segments;

[0423] e) Use one or more Merkel path components to compute the Merkel root.

[0424] Clause 1.8. The method according to any of the preceding claims, the method further comprising the step of the sender providing the revised version of the at least one data resource to at least one receiver;

[0425] Optionally, the step of providing the revised version includes generating a shared secret between the sender and the at least one receiver.

[0426] Clause 1.9. The method according to any of the preceding clauses, the method further comprising the step of providing a computer-based system to output the revised version of the at least one data resource;

[0427] Optionally, the system includes one or more of the following:

[0428] Cloud-based services or executable resources;

[0429] Internet-based services or resources;

[0430] Software applications configured to run on mobile, portable, or desktop-based systems;

[0431] Digital wallet;

[0432] Browser;

[0433] Word processing applications or PDF / document viewers;

[0434] Software used to provide audio and / or video output;

[0435] Computer-based electronic storage resources;

[0436] Software used for scanning, copying, or capturing images of resources;

[0437] Software used to generate electronic signatures and / or bind said electronic signatures to a portion of data;

[0438] Software and / or hardware used to perform or facilitate financial transactions and / or asset exchanges;

[0439] Cryptocurrency platform.

[0440] Clause 1.10. A method for verifying a revised document, the method comprising the following steps:

[0441] Obtain from source:

[0442] The root of a Merkle tree, which represents a data resource comprising multiple segments, wherein each leaf in the tree includes the hash of the corresponding segment;

[0443] The hash of at least one of the plurality of segments;

[0444] Merkel's path;

[0445] A digital signature associated with the authorized entity of the at least one data resource.

[0446] Clause 1.11 A computer system comprising:

[0447] The memory includes one or more memory cells; and

[0448] A processing apparatus comprising one or more processing units, wherein the memory stores or executes code set to run on the processing apparatus, the code being configured to perform a method according to any one of clauses 1 to 10 when run on the processing apparatus.

[0449] Clause 1.12. The computer system pursuant to Clause 1.11, wherein said system further comprises one or more of the following:

[0450] Storage or file system, wherein the file system is or includes a VAST file system;

[0451] database;

[0452] Components used to interact with blockchain networks and / or blockchain ledgers.

[0453] Clause 1.13. A computer program contained on a computer-readable storage medium and configured to perform the method according to any one of Clauses 1.1 to 1.10 when run on one or more processors.

[0454] Clause Set 2:

[0455] Any features provided with respect to Clause Set 2 are not thereby limited and may be used or incorporated with respect to any one or more other Clause Sets included herein.

[0456] Clause 2.1

[0457] According to illustrative clause set 2, a method may be provided, the method comprising:

[0458] Obtain (e.g., generate) a first version of a Merkle tree comprising multiple segments, wherein one, some, or all (leaf) nodes of the Merkle tree comprise the corresponding hashes of the multiple segments;

[0459] Sign the root of the Merkle tree;

[0460] The signed Merkel root is used to verify the first and / or second versions of the digital resource.

[0461] The second version may be referred to as a revised version of the data resource. The second version may include at least one fewer segment than the first version.

[0462] Clause 2.2: The method described in accordance with Clause 2.1 further includes one or more of the following:

[0463] i) Use a Merkle tree of digital signatures to verify the authenticity and / or integrity of the first or second version of the digital resource;

[0464] ii) The source provides a second version of the digital resource to the receiver, the digital resource comprising a subset of the plurality of segments.

[0465] The term "subset" can refer to one or more fewer sets than the original set.

[0466] Clause 2.3. The method described pursuant to Clause 2.1 or 2.2, wherein:

[0467] Verifying the authenticity and / or integrity of the first or second version of the digital resource includes checking the digital signature of one or more hashes (including messages containing one or more hashes of the root and / or segments of at least the Merkle tree) that have been applied to the Merkle tree.

[0468] Clause 2.4. The method described pursuant to any of the preceding clauses of Clause Set 2, the method comprising:

[0469] ii) Hash the plurality of segments to provide the corresponding nodes of the Merkle tree;

[0470] ii) Select a subset of the plurality of segments.

[0471] Any method according to any one of Clause Set 1 or 2, wherein and / or includes:

[0472] The first (i.e., unedited / original) version of the data resource comprises N segments.

[0473] • Hash the multiple N segments to provide the corresponding (leaf) nodes in the Merkle tree;

[0474] The Merkle tree has a root signed by an authorizing party (e.g., by or on behalf of at least one data controller / owner).

[0475] • Sign via any electronic / encryption method (optionally, using a key generated using a public secret);

[0476] The step of providing the Merkle tree includes hashing each of the N segments to provide a corresponding (leaf) node in the Merkle tree;

[0477] • View or otherwise present the revised version of the data, i.e., output the plurality of segments minus x selected revised segments, where x =>= 1;

[0478] • The shared (nx) segments include preimages of the hashes of the corresponding (nx) segments;

[0479] • The step of sharing one or more replacement segments of the one or more revised segments, which may be from the same entity (e.g., Alice) and / or may be to at least one other entity (e.g., Bob);

[0480] • Select x segments to exclude in the sharing step;

[0481] Verification involves hashing some or preferably all of the n segments and comparing each hash with the corresponding node in the Merkle tree.

[0482] "Sharing" can include any available method. This can include, but is not limited to, sending, transmitting, displaying, outputting, or providing access (e.g., downloading by a user).

[0483] Clause Set 3:

[0484] Any features provided with respect to Clause Set 3 are not thereby limited and may be used or incorporated with respect to any one or more other Clause Sets included herein.

[0485] Clause 3.1 A computer-implemented method, the method comprising:

[0486] Insert or otherwise provide at least one identifier / code / watermark / timestamp / reference in at least one of the multiple segments of the data resource.

[0487] The plurality of segments can then be processed according to any of the embodiments disclosed herein. For example, the method may include one or more of the following:

[0488] - Define, select, calculate, or otherwise acquire the multiple segments of the data resource;

[0489] - Perform hash processing on the multiple segments;

[0490] - Obtain a Merkle tree representing the data resource, wherein the hash of the segment provides the leaves of the tree;

[0491] - Sign the root of the Merkle tree (and / or the message including the root);

[0492] Selecting one or more segments for modification means that the one or more segments are designated as "not for sharing" / omitted from one or more sharing operations in their original, unobfuscated form. It should be noted that the one or more modified segments can be shared in an obfuscated form. For example, the one or more modified segments can be provided in a hashed, masked, and / or encoded form. By providing a hashed version of the modified segments, the hashed version of the modified segments can be used in the verification process used to compute the Merkle root without revealing the modified data in its original, meaningful form.

[0493] - Share one or more unedited segments (i.e. segments that have been designated as "permitted or allowed to be shared") with at least one recipient;

[0494] - Share with the at least one recipient one or more of the following: a public key associated with a private key used to sign the root; the signed Merkle root; and a Merkle path / hash to enable verification of the unedited segment by: the at least one recipient calculating one or more Merkle proofs; comparing the calculated root with the obtained / shared root; and using the public key to check whether the signature and the Merkle root and signature calculated by the one or more recipients match the Merkle root and signature obtained from the sharer / one or more senders.

[0495] The code, the identifier, and / or the watermark may be inserted into one or more revised and / or unrevised segments. The code, the identifier, and / or the watermark may include data used to uniquely verify the authenticity, source, version, or ownership of the data resource, or indicate or include other data.

[0496] Clause Set 4

[0497] Any features provided with respect to Clause Set 4 are not thereby limited and may be used or incorporated with respect to any one or more other Clause Sets included herein.

[0498] Clause 4.1. A computer-implemented method for providing partial computer code configured (when executed on one or more processors) to perform a given task, said task comprising a plurality of subtasks; and said method comprising:

[0499] i) A Merkle tree is used to represent a (code) library, the (code) library comprising (multiple) computer code elements, each computer code element being configured to execute a corresponding subtask (among the multiple subtasks); and

[0500] ii) Select multiple computer code elements from the library to provide the portion of computer code.

[0501] In step 1), the leaves of the Merkle tree may include hashes of the computer code elements. In other words, each computer code element can be hashed to provide a corresponding leaf of the Merkle tree representing the codebase.

[0502] The computer code elements selected in step ii) may be referred to as "the selected multiple code elements", and any unselected computer code elements may be referred to as "unselected computer code elements". Furthermore, the phrase "provide the portion of computer code" may include "provide the functionality of the portion of computer code".

[0503] Preferably, the method further includes: providing code from the code provider to the code recipient:

[0504] The corresponding preimage of each of the selected multiple computer code elements; and

[0505] The corresponding hash of any unselected computer code element.

[0506] Therefore, the method may include: sharing non-hash versions of code elements from a plurality of selected computer code elements; and sharing hash versions of one or more unselected computer code elements. In this way, the selected elements can provide unmodified code elements, and the hashed (leaf) elements can be modified. Thus, in other words, the codebase can be modified according to embodiments of this disclosure.

[0507] Clause 4.2. As described in Clause 4.1, each computer code element in said library:

[0508] i) represents a leaf in the Merkel tree; and / or

[0509] ii) Includes code that can be executed on a processor or that can be processed to be executed on a processor.

[0510] Clause 4.3. The method described according to Clause 1 or 2, wherein the method comprises:

[0511] The root of the Merkle tree is signed by the licensor or on behalf of the licensor in order to verify the computer code elements in the Merkle tree.

[0512] Clause 4.4. The method described under any of the preceding clauses, the method comprising:

[0513] Use the root of the Merkle tree to verify the integrity or authenticity of the following items:

[0514] The computer code mentioned above; or

[0515] One or more of the plurality of computer code elements.

[0516] Clause 4.5. The method described in accordance with Clause 4.4, the method comprising:

[0517] Install or execute the portion of computer code on at least one processor.

[0518] Clause 4.6. The method described under any of the preceding clauses, the method comprising:

[0519] The plurality of computer code elements are combined to provide the portion of computer code.

[0520] Clause 4.7. The method described under any of the preceding clauses, the method comprising:

[0521] The plurality of computer code elements and / or portions of the computer code are provided to the user from the provider.

[0522] Clause 4.8. The method described pursuant to any of the preceding clauses, wherein:

[0523] The plurality of computer code elements are selected from the library in such a way that, when combined or executed in combination with each other and / or any other additional code elements, the plurality of computer code elements provide the portion of computer code and perform the given task.

[0524] Clause 4.9. The method according to any of the preceding clauses, the method comprising the steps of: verifying the authenticity and / or integrity of the partial code or at least one of the plurality of computer code elements by:

[0525] The code recipient receives from the code provider:

[0526] i) A signed copy of the Merkle root of the Merkle tree, wherein the signed copy of the root is signed by the authorizing party or on behalf of the authorizing party.

[0527] ii) the corresponding preimage of each of the selected multiple computer code elements, and

[0528] iii) The corresponding hash of any or all of the unselected computer code elements;

[0529] The code recipient and / or verifier calculate:

[0530] i) The hash of each preimage received from the code provider,

[0531] ii) the Merkle tree of the library, and

[0532] iii) The root of the Merkel tree;

[0533] The signature copy of the Merkle root received from the code provider is compared with the root of the Merkle tree calculated by the code recipient and / or the verifier.

[0534] Clause 4.10. The method described in Clause 4.9, the method comprising the following steps:

[0535] The authenticity and / or integrity of the partial code or at least one of the plurality of computer code elements is considered verified if and only if the signed copy of the Merkle root received from the code provider matches the root of the Merkle tree calculated by the code receiver and / or verifier.

[0536] Clause 4.11. The method according to Clause 4.9 or 4.10, the method comprising the following steps:

[0537] The code recipient or verifier obtains the public key associated with or provided by the code provider.

[0538] Clause 4.12. The method described in Clause 4.11, the method comprising the following steps:

[0539] The code recipient or verifier uses the public key associated with or provided by the code provider to sign the root of the Merkle tree calculated by the code recipient and / or verifier.

[0540] Clause 4.13. The method according to Clauses 4.9 to 4.11, the method comprising the following steps:

[0541] The plurality of computer code elements are installed and / or executed on one or more processors, provided that the authenticity and / or integrity of the partial code or at least one of the plurality of computer code elements are deemed to have been verified.

[0542] Clause 4.14. A computer system comprising:

[0543] The memory includes one or more memory cells; and

[0544] A processing apparatus comprising one or more processing units, wherein the memory stores or executes code set to run on the processing apparatus, the code being configured to perform a method according to any one of clauses 4.1 to 4.13 when run on the processing apparatus.

[0545] Clause 4.15. A computer program contained on a computer-readable storage medium and configured to perform the method according to any one of Clauses 4.1 to 4.13 when run on one or more processors.

[0546] According to another aspect disclosed herein, a system may be provided that includes a computer device as claimed or described herein and / or capable of performing any of the methods disclosed herein.

[0547] Exemplary System Overview

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

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

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

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

[0552] Another transaction model is the account-based model. In this case, the amount of each transaction is not defined by referring to the UTXO of previous transactions in the past transaction sequence, but by referring to the absolute account balance. The current state of all accounts is stored individually in the blockchain by the nodes and is continuously updated.

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

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

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

[0556] Blockchain node 104 can be configured to forward transaction 152 to other blockchain nodes 104, thereby propagating transaction 152 throughout the network 106. Blockchain node 104 can be configured to create block 151 and store a corresponding copy of the same blockchain 150 in its corresponding memory. Blockchain node 104 can also maintain an ordered set (or "pool") 154 of transactions 152 waiting to be incorporated into block 151. The ordered pool 154 is often referred to as a "mempool." In this document, the term is not intended to be limited to any particular blockchain, protocol, or model. The term refers to a set of transactions that node 104 has accepted as valid, and for that set of transactions, node 104 is forced not to accept any other transactions attempting to spend the same output.

[0557] In a given current transaction 152j, the inputs (or each input) include a pointer that references the output of a previous transaction 152i in the transaction sequence, specifying that the output will be redeemed or "spent" in the current transaction 152j. Spending or redeeming does not necessarily mean transferring financial assets, although this is certainly a common application. More generally, spending can be described as consuming an output or allocating it to one or more outputs in another subsequent transaction. Typically, the previous transaction can be any transaction in the ordered set 154 or any block 151. Although the existence and verification of the validity of the previous transaction 152i are required to ensure the validity of the current transaction, the existence of the previous transaction 152i is not necessary when the current transaction 152j is created or even sent to network 106. Therefore, in this document, "previous" refers to the predecessor in the logical sequence linked by pointers, and not necessarily the creation or sending time in the time series; thus, the possibility of creating or sending transactions 152i or 152j out of order is not necessarily excluded (see the discussion of isolated transactions below). The previous transaction 152i can also be referred to as the preceding transaction or predecessor transaction.

[0558] Due to the resources involved in transaction verification and publication, each blockchain node 104 typically takes the form of a server comprising one or more physical server units, or even an entire data center. However, in principle, any given blockchain node 104 can take the form of a single user terminal or a networked set of user terminals.

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

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

[0561] The computer devices 102 of each of the multiple parties 103, acting as consumer users, are also connected to the network 101. These users can interact with the blockchain network 106 but do not participate in verifying transactions or constructing blocks. Some of these users or agents 103 can act as senders and receivers in transactions. Other users can interact with the blockchain 150 without having to act as senders or receivers. For example, some parties can act as storage entities storing copies of the blockchain 150 (e.g., having already obtained a copy of the blockchain from blockchain node 104).

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

[0563] Each party 103's computer device 102 includes a corresponding processing means, which includes one or more processors, such as one or more CPUs, graphics processing units (GPUs), other accelerator processors, application-specific processors, and / or FPGAs. Each party 103's computer device 102 also includes memory, i.e., computer-readable storage in the form of a non-transitory computer-readable medium. The memory may include one or more memory cells in the form of one or more memory media, such as magnetic media like hard disks, electronic media such as SSDs, flash memory, or EEPROMs, and / or optical media such as optical disc drives. The memory on each party 103's computer device 102 stores software including corresponding instances of at least one client application 105 configured to run on the processing means. It should be understood that any action attributed herein to a given party 103 can be performed by software running on the processing means of the respective computer device 102. Each party 103's computer device 102 includes at least one user terminal, such as a desktop or laptop computer, tablet computer, smartphone, or wearable device such as a smartwatch. The computer device 102 of the given party 103 may also include one or more other network resources, such as cloud computing resources accessed through a user terminal.

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

[0565] The client application 105 includes at least a "wallet" function. This has two main functions. One function is to enable the respondent 103 to create, authorize (e.g., sign) transactions 152 and send them to one or more blockchain nodes 104, which then propagate through the network of blockchain nodes 104, thus including them in blockchain 150. The other function is to report to the respondent the amount of digital assets they currently possess. In an output-based system, this second function includes organizing the amounts defined in the outputs of the various transactions 152 belonging to the relevant parties scattered across blockchain 150.

[0566] Note: While various client functionalities can be described as being integrated into a given client application 105, this is not necessarily limiting. Rather, any client functionality described herein can be implemented in a suite of two or more different applications, such as through an API interface or as a plugin for one application. More colloquially, client functionalities can be implemented at the application layer or at a lower layer such as the operating system, or any combination of these layers. The following description is based on client application 105, but it should be understood that this is not limiting.

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

[0568] As part of an account-based transaction model, another type of transaction protocol operated by some blockchain networks can be called an "account-based" protocol. In the account-based case, each transaction does not define the amount transferred by referencing the UTXO of previous transactions in a sequence of past transactions, but rather by referencing the absolute account balance. The current state of all accounts is stored individually in the blockchain by the network's nodes and is continuously updated. In such systems, transactions are ordered using the account's running transaction record (also known as a "position" or "nonce"). This value is signed by the sender as part of its cryptographic signature and hashed as part of the transaction reference calculation. Furthermore, optional data fields can also be used to sign transactions. For example, if a data field contains the ID of a previous transaction, that data field can point to that previous transaction.

[0569] Some account-based transaction models share similarities with the output-based transaction model described in this paper. For example, as mentioned above, the data fields of an account-based transaction can point to the previous transaction, which is equivalent to the input of an output-based transaction referencing the output point of the previous transaction. Therefore, both models support chaining between transactions. As another example, an account-based transaction includes a "recipient" field (specifying the account's receiving address) and a "value" field (specifying a certain amount of digital assets). The recipient and value fields together are equivalent to the output of an output-based transaction, which can be used to allocate a certain amount of digital assets to a blockchain address. Similarly, account-based transactions have a "signature" field, which includes the transaction's signature. This signature is generated using the sender's private key and confirms that the sender has authorized the transaction. This is equivalent to the input / unlock script of an output-based transaction, which typically includes the transaction's signature. When both types of transactions are submitted to their respective blockchain networks, the signature is checked to determine if the transaction is valid and can be recorded on the blockchain. On an account-based blockchain, a "smart contract" refers to a transaction containing a script configured to perform one or more actions (e.g., sending or "releasing" digital assets to a recipient address) in response to one or more inputs (provided by the transaction) that satisfy one or more conditions defined in the smart contract's script. Smart contracts exist as transactions on the blockchain and can be invoked (or triggered) by subsequent transactions. Therefore, in some examples, a smart contract can be viewed as equivalent to a locking script for an output-based transaction (which can be triggered by a subsequent transaction) that checks whether the inputs of the subsequent transaction satisfy one or more conditions defined in the locking script.

[0570] UTXO-based model

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

[0572] In the UTXO-based model, each transaction ("Tx") 152 includes a data structure comprising one or more inputs 202 and one or more outputs 203. Each output 203 may include an unspent transaction output (UTXO), which can be used as a source of input 202 for another new transaction (if the UTXO has not yet been redeemed). The UTXO includes a value specifying the amount of digital assets. This represents a set of tokens on the distributed ledger. The UTXO may also contain the transaction ID of its source transaction and other information. The transaction data structure may also include a header 201, which may include size indicators for the input fields 202 and the output fields 203. The header 201 may also include the transaction ID. In this embodiment, the transaction ID is a hash of the transaction data (excluding the transaction ID itself) and is stored in the header 201 of the original transaction 152 committed to node 104.

[0573] For example, Alice 103a wants to create transaction 152j to transfer a certain amount of related digital assets to Bob 103b. Figure 2 In the sequence, Alice's new transaction 152j is marked "Tx1". This new transaction acquires the amount of digital assets locked to Alice in the output 203 of the previous transaction 152i in the sequence, and transfers at least a portion of such an amount to Bob. Figure 2 In this context, the previous transaction 152i is marked as "Tx0". Tx0 and Tx1 are just arbitrary markers, and they do not necessarily mean that Tx0 refers to the first transaction in blockchain 151 and Tx1 refers to a subsequent transaction in pool 154. Tx1 can point to any previous (i.e., preceding) transaction that still has an unspent output 203 locked to Alice.

[0574] As used in the context of transaction sequences in this article, the terms "previous" and "subsequent" refer to the order of transactions in the sequence defined by the transaction pointers specified within the transaction (which transaction points to which other transaction, etc.). They can also be replaced with "predecessor" and "successor," "ancestor" and "descendant," or "parent" and "child," etc. This does not necessarily refer to the order in which they are created, sent to network 106, or arrive at any given blockchain node 104. However, subsequent transactions (descendant transactions or "children") that point to a previous transaction (ancestor transaction or "parent") are not valid unless the parent transaction is valid. Children that arrive at blockchain node 104 before their parents are considered orphaned. Depending on the node protocol and / or node behavior, they may be discarded or buffered for a period of time to wait for their parents.

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

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

[0577] Therefore, in the example shown, UTXO0 in the output 203 of Tx0 includes the locking script [Checksig P] A This locking script requires Alice's signature (Sig P). A This is to redeem UTXO0 (strictly speaking, to make subsequent transactions attempting to redeem UTXO0 valid). [Checksig P] A [Contains the public key P in Alice's public-private key pair] A The representation (i.e., hash) of Tx1. Input 202 of Tx1 includes a pointer to Tx1 (e.g., by its transaction ID (TxID0), which in this embodiment is the hash value of the entire transaction Tx0). Input 202 of Tx1 includes an index identifying UTXO0 in Tx0, to identify it in any other possible output of Tx0. Input 202 of Tx1 further includes an unlock script. <Sig P A The unlocking script includes Alice's cryptographic signature, which she creates by applying the private key from her key pair to a predetermined portion of data (sometimes referred to in cryptography as a "message"). The data (or "message") that Alice needs to sign to provide a valid signature can be defined via a locking script, a node protocol, or a combination thereof.

[0578] When a new transaction Tx1 arrives at blockchain node 104, that node applies the node protocol. This includes running a locking script and an unlocking script together to check if the unlocking script meets the conditions defined in the locking script (wherein the conditions may include one or more criteria).

[0579] It should be noted that script code is typically represented graphically (i.e., using a non-precise language). For example, opcodes can be used to represent specific functions. "OP_..." refers to a specific opcode in the scripting language. For instance, OP_RETURN is a scripting language opcode. When OP_FALSE is added before the opcode at the beginning of the locking script, the opcode creates a non-spendable output for the transaction. This output can store data within the transaction, thus immutably recording the data in the blockchain. For example, the data may include files that need to be stored in the blockchain.

[0580] Typically, the input to a transaction contains a digital signature corresponding to the public key PA. In this embodiment, this is based on ECDSA using the elliptic curve secp256k1. The digital signature signs a specific segment of data. In this embodiment, for a given transaction, the signature will sign part of the transaction input and part or all of the transaction output. Signing a specific portion of the output depends on the SIGHASH flag. The SIGHASH flag is typically a 4-byte code included at the end of the signature to select the output to be signed (and is therefore fixed at the time of signing).

[0581] Locking scripts are sometimes called "scriptPubKey," referring to the fact that they typically include the public keys of the parties to whom the corresponding transaction is locked. Unlocking scripts are sometimes called "scriptSig," referring to the fact that they typically provide the corresponding signature. However, more generally speaking, in all applications of Blockchain150, the conditions for UTXO redemption do not necessarily include signature verification. Furthermore, scripting languages ​​can be used to define any one or more conditions. Therefore, the more general terms "locking script" and "unlocking script" are preferable.

[0582] Further comments

[0583] Once the disclosure herein is given, other variations or use cases of the disclosed technology may become apparent to those skilled in the art. The scope of this disclosure is not limited to the described embodiments, but only to the appended claims.

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

[0585] In a preferred embodiment of the invention, the blockchain network 106 is a Bitcoin network, and the Bitcoin node 104 performs at least all of the described functions of creating, publishing, propagating, and storing blocks 151 of the blockchain 150. It is not excluded that other network entities (or network elements) may perform only one or some of these functions, but not all of them. That is, network entities may perform the function of propagating and / or storing blocks without creating and publishing blocks (please remember that these entities are not considered nodes of the preferred Bitcoin network 106).

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

[0587] To put it even more colloquially, any reference above to the term "Bitcoin node" 104 can be replaced by the terms "network entity" or "network element," where such an entity / element is configured to perform some or all of the roles in creating, publishing, propagating, and storing blocks. The functionality of such a network entity / element can be implemented in hardware in the same manner as described above with reference to blockchain node 104.

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

[0589] Any references to "Bitcoin," "cryptocurrency," or a particular cryptocurrency protocol in this specification and accompanying drawings may be replaced with the terms "blockchain," "blockchain network," or "blockchain protocol" appropriate for the specific context in which these terms are used.

[0590] statement

[0591] The inclusion of the aforementioned documents by way of introduction is limited to the following: the incorporated subject matter must not contradict the express disclosure herein. The inclusion of the aforementioned documents by way of introduction is further limited to the following: any claims contained in the documents are not incorporated by way of introduction. The inclusion of the aforementioned documents by way of introduction is again limited to the following: any definitions provided in the documents are not incorporated by way of introduction unless expressly included herein. < / pubkey1>

Claims

1. A computer-implemented method for providing partial computer code configured to perform a given task comprising multiple subtasks; the method comprising: i) A Merkle tree is used to represent a library containing computer code elements, each of which is set to perform a corresponding subtask; as well as ii) Select multiple computer code elements from the library to provide the portion of computer code; iii) From code provider to code recipient, providing: The corresponding preimage of each of the selected multiple computer code elements, and The corresponding hash of any unselected computer code element.

2. The method of claim 1, wherein each computer code element in the library: i) represents a leaf in the Merkel tree; and / or ii) Includes code that can be executed on a processor or that can be processed to be executed on a processor.

3. The method according to claim 1 or 2, wherein the method comprises: The root of the Merkle tree is signed by the licensor or on behalf of the licensor in order to verify the computer code elements in the Merkle tree.

4. The method according to any one of the preceding claims, wherein the method comprises: Use the roots of the Merkle tree to verify the integrity or authenticity of the following items: The computer code described above; or One or more of the plurality of computer code elements.

5. The method according to claim 4, wherein the method comprises: Install or execute the portion of computer code on at least one processor.

6. The method according to any one of the preceding claims, wherein the method comprises: The plurality of computer code elements are combined to provide the portion of computer code.

7. The method according to any one of the preceding claims, wherein the method comprises: The plurality of computer code elements and / or portions of the computer code are provided to the user from the provider.

8. The method according to any one of the preceding claims, wherein: The plurality of computer code elements are selected from the library in such a way that, when combined or executed in combination, the plurality of computer code elements provide the portion of computer code and perform the given task.

9. The method according to any one of the preceding claims, the method comprising the following steps: The authenticity and / or integrity of the partial code or at least one of the plurality of computer code elements shall be verified by the following methods: The code recipient receives from the code provider: iv) A signed copy of the Merkel root of the Merkel tree, wherein the signed copy of the root is signed by the authorizing party or on behalf of the authorizing party. v) The corresponding preimage of each of the selected multiple computer code elements, and vi) The corresponding hash of any or all of the unselected computer code elements; The code recipient and / or verifier calculate: iv) The hash of each preimage received from the code provider, v) The Merkle tree of the library, and vi) The root of the Merkel tree; The signature copy of the Merkle root received from the code provider is compared with the root of the Merkle tree calculated by the code receiver and / or the verifier.

10. The method according to claim 9, wherein the method comprises the following steps: The authenticity and / or integrity of the partial code or at least one of the plurality of computer code elements is considered verified if and only if the signed copy of the Merkle root received from the code provider matches the root of the Merkle tree calculated by the code receiver and / or verifier.

11. The method according to claim 9 or 10, wherein the method comprises the following steps: The code recipient or verifier obtains the public key associated with or provided by the code provider.

12. The method according to claim 11, wherein the method comprises the following steps: The code recipient or verifier uses the public key associated with or provided by the code provider to sign the root of the Merkle tree calculated by the code recipient and / or verifier.

13. The method according to claims 9 to 11, wherein the method comprises the following steps: The plurality of computer code elements are installed and / or executed on one or more processors, provided that the authenticity and / or integrity of the partial code or at least one of the plurality of computer code elements are deemed to have been verified.

14. A computer system, the computer system comprising: The memory includes one or more memory units; as well as A processing apparatus comprising one or more processing units, wherein the memory stores or executes code set to run on the processing apparatus, the code being configured to perform the method according to any one of claims 1 to 13 when run on the processing apparatus.

15. A computer program, the computer program being contained on a computer-readable storage medium and configured to perform the method according to any one of claims 1 to 13 when executed on one or more processors.

Images