Digital signature algorithm for verifying edited data

Abstract

Embodiments of this disclosure provide, but are not limited to, solutions for protecting, sharing, verifying, and / or generating data resources such as documents. In exemplary embodiments, a data resource is represented, expressed, or defined as a plurality of hashed constituent segments. Using the segment hashes as leaves, a Merkle tree is generated representing the complete original version of the data resource. An edited version of the data resource can be shared, omitting one or more segments that the data administrator wishes to keep secret or does not wish to share in its original form. To verify the authenticity and / or completeness of the edited data resource, a validator is provided with sufficient data (e.g., the hash of each of the non-shared segments) to verify the presence of non-shared segments in the tree representing the complete original version, and an authorized signature that signed the root. In some embodiments, the data resource is a code library, and the segments are parts of computer code that perform specific subtasks. Shared code segments, when executed on a processor, may be selected to combine to perform larger tasks.

Description

Technical Field

[0001] The present disclosure provides systems and methods for secure distribution of data, verification of data authenticity and integrity, and maintenance of data security. Additionally or alternatively, embodiments provide an improved digital signature algorithm for sharing, providing, storing, protecting, and / or processing data resources. Embodiments utilize cryptographic techniques to enhance data security and access control, and are particularly suitable for use in, but not limited to, redaction, anonymization, and / or sanitization of data shared with one or more parties.

[0002] Other technical effects include scalability of data storage solutions, provision of secure and verifiable documents with editable formats (e.g., templates, forms that can be input by users), and the ability to represent the hierarchical structure of data in a verifiable storage resource without making the content itself publicly available or accessible, but are not limited thereto. These solutions can be combined with blockchain technology to further enhance the verification of data integrity and authenticity.

[0003] These aspects will be described and illustrated in more detail below.

Background Art

[0004] Throughout history, humanity has had the need and desire to keep some of the shared information secret, some public, and some not publicly available. Simple and traditional methods include creating a document on a surface such as paper and then covering or masking it in some way, such as blotting out the confidential parts with thick ink, or applying a masking material such as tape or paper over the top.

[0005] However, such techniques are not easy to apply (especially with long documents), and in some cases, highly confidential content underneath may be unintentionally revealed. For example, the ink may not be dark enough to adequately conceal the content underneath, or the mask may be unintentionally moved during subsequent copying or transmission. Computer-based technologies have provided various mechanisms to facilitate the editing of electronic data resources, but technical challenges remain, especially with large datasets. These include methods for verifying the authenticity and integrity of shared data resources, such as when parts of a document are deleted.

[0006] Therefore, there is a need to provide an improved solution for verifying edited electronic data resources. Such an improved solution has been devised. [Overview of the Initiative]

[0007] Features referred to in this specification in relation to one or more embodiments are not intended to be limiting. Features disclosed herein may be used interchangeably in various embodiments and configurations.

[0008] In one embodiment, the embodiment provides a solution for secure, cryptographically enhanced access control of data transmitted or shared between a data administrator and at least one data recipient. In particular, preferred embodiments can provide techniques and systems for redacting one or more portions of a data resource shared, processed, or stored with a recipient. As used herein, “redacting” includes, but is not limited to, concealing, masking, removing, retaining (i.e., not sharing or disclosing), deleting, and / or replacing one or more selected portions of a data resource. Redacting also includes not sharing the selected portion at all, or not sharing it in a meaningful form. For example, the redacted portion may be shared with the recipient, but in a form that edits or alters the original state by hashing, masking, or otherwise encoding the selected portion, so that the recipient cannot infer the original state or form. Providing the redacted portion in hash form has the advantage that a verifier can hash the unredacted portion and combine it with the redacted portion hashed according to known Merkle tree construction techniques to compute the Merkle tree (and Merkle root) of the entire data resource. In one representation, a preferred embodiment may include a method for applying a signature algorithm to a data resource using a Merkle tree such that editing one or more segments (i.e., parts) of the data resource does not result in a loss of the ability to verify the authenticity or completeness of that data resource. Advantageously, the embodiment can allow editing of selected parts of a data resource without affecting or invalidating the validity of the signature applied to the data resource by the data controller.

[0009] In such embodiments, data resources may be divided into multiple segments. The size, number, and other attributes of the segments can be determined based on criteria or goals selected by the data administrator.

[0010] These segments can be used to construct a tree structure representing the data resources. This tree structure is preferably a hash tree (also called a Merkle tree), in which the leaf nodes at the bottom of the tree are hashed in pairs to generate a hash that acts as the parent node at the previous (i.e., immediately above) level of the tree. This hashing of pairs continues until the hash of the root of the tree is computed.

[0011] After the data segments of a data resource have been hashed to form a Merkle tree, the data administrator can cryptographically sign the root hash to prove (verify) the authenticity and / or completeness of the data contained in / represented in the tree. This signature provides proof that the data resource was approved, created, and / or processed by the data administrator.

[0012] Next, the data administrator can select one or more segments from the data resource that should be edited before storing, processing, accessing, and / or sharing the data resource.

[0013] Editing a selected segment may involve one or more actions such as hiding, modifying, masking, deleting, or replacing the original version of the selected segment from the data resource (or a copy thereof).

[0014] A data administrator may share or present one or more of the following to one or more recipients: - The Merkle tree of the entire original (pre-edited) data resource; - The public key corresponding to the private key used to sign the root hash, to facilitate signature verification; - Unedited segments of data resources.

[0015] The recipient can use the public key to verify whether the data resources represented in the Merkle tree were actually generated and / or authorized by the data controller who possesses the corresponding private key.

[0016] Therefore, the verifier, Construct a tree representing the unedited version of the data resource, Verify that the root of the constructed tree matches the root of the tree shared by the data administrator. Verify that the signature applied to the signed Merkle root provided by the data controller was generated / approved by the data controller. Verification can be performed by doing so. The construction of a tree representing the unedited version of a data resource can be performed by a verifier using the edited version of the data resource and the hash values ​​of the edited segments. Thus, the verifier can perform verification against the signed Merkle root of the Merkle tree instance that represents the unedited original version of the constructed data resource.

[0017] In some embodiments, the data administrator may retain the edited segments (for example, in an encrypted format). In addition, or alternatively, the data administrator may discard / delete original copies of one or more edited segments.

[0018] In one or more embodiments, the Disclosure may provide a computer implementation device (e.g., a standalone device or system) that facilitates one or more of the steps described above. This device may comprise hardware, software, and / or firmware for performing one or more of the method steps disclosed herein.

[0019] In one embodiment, the apparatus is - Decomposing data resources into multiple segments, - Generating a Merkle tree representing a plurality of segments, - Cryptographically signing the root hash of the tree, - Selecting one or more segments for editing from a data resource or a copy thereof, - Sharing, storing, or otherwise processing the signed hash root, the Merkle tree of the data resource, the original data resource, and / or the original segments selected for editing. Software, firmware, and / or hardware configured to facilitate or enable one or more of the above may be provided.

[0020] <​​​​​​​​​​​ Additional technical effects include, but are not limited to, scalability of data storage solutions, provision of secure and verifiable documents formatted for editing (e.g., templates, forms that can be input by a user), and the ability to represent the data hierarchy in a verifiable storage resource without publishing or making the content itself available.

[0024] In addition or alternatively, one or more embodiments of the present disclosure provide a new solution for one or more of: - Construction or provision of a functional software product constructed from software elements selectively disclosed / provided using the Merkleized structures and digital signature algorithms disclosed herein. - Management, implementation, and / or control of one or more software repositories. One or more repositories may comprise the Merkleized structures and digital signature algorithms disclosed herein, and the leaves of the Merkle tree may include software elements that can be selectively combined to provide a software product.

[0025] In some embodiments, the disclosed technology may utilize one or more of the following. 1. A consumable on-chain code (e.g., script) segment assembled and configured to be processed as a blockchain transaction. "On-chain" may include, but is not limited to, "on a ledger such as a blockchain ledger". 2. An on-chain output that can be assembled for use as (off-chain) execution code. The execution code can include output executable within or by a microcontroller (e.g., MISC instruction set) or generated from a compilation process. 3. A private code repository that requires authorization / user authentication before granting access to the code segments necessary for building the software product. In some embodiments, authentication may include verification of a valid license or other authorization-related mechanisms such as a valid password or authorized cryptographic key.

[0026] Embodiments relating to this aspect may provide computer implementations and systems for designing, assembling, or creating software (programs) using at least one set of structured (code) elements contained in a Merkle tree whose root is publicly accessible on a blockchain ledger. This may be a public or private ledger. The elements may be referred to as sub-parts of code, code components, or sub-code elements. The software may be a complete functional program executable on a processor. The software may be provided in a native machine language, a low-level language such as assembly code, or object code such as code configured for execution by an interpreter or virtual machine. In other examples, the code may be provided as source code and / or formed in a high-level programming language, requiring translation by, for example, a compiler and / or interpreter before it can be executed on a particular processor / system architecture.

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

[0028] In some embodiments, the leaves of the Merkle tree correspond to partial software elements held in a private database to which access rights are applied. 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 know which leaves of the Merkle tree should be assembled and in what order.

[0029] In some embodiments, the referenced code segment performs calculations on the input values ​​and produces output results that are used directly by the assembled software.

[0030] In some embodiments, the output results are written directly to the transaction output and become readable in the public ledger. In some embodiments, the output results are left on the processing stack when the script finishes, and the process building the software needs to run the script and calculate the values.

[0031] In some embodiments, a single Merkle tree may include elements that can be used to build multiple software systems. In some embodiments, the generated software is an app or program that is installed in an operating system environment.

[0032] In some embodiments, the generated software is a complete program that controls an embedded system, a control system, or a portion of hardware.

[0033] In some embodiments, the code extracted from items or transactions referenced in a Merkle tree may be represented as minimal instruction set (MISC) instructions. For example, in some embodiments, these may be provided as instructions written in a language (but not limited to) such as Bitcoin Script, used in transactions on the Bitcoin blockchain. However, in other examples, the instructions may be provided in any language suitable for use in conjunction with a particular blockchain and its associated protocols. In some embodiments, multiple Merkle trees may be formed that reference the same code sub-elements.

[0034] In some embodiments, a leaf of a Merkle tree may refer to an entire software product / build, which is an instruction set that references another Merkle tree containing its own sub-elements.

[0035] To aid in understanding the embodiments of this disclosure and to illustrate how such embodiments are carried out, the accompanying drawings are referenced as examples. [Brief explanation of the drawing]

[0036] [Figure 1] This is a schematic block diagram of a system for implementing blockchain. [Figure 2] This diagram schematically illustrates an example of a transaction that can be recorded on the blockchain. [Figure 3A] This is a schematic block diagram of the client application. [Figure 3B] Figure 3A is a schematic mockup of an example user interface that may be presented by the client application. [Figure 4] This is a schematic block diagram of a node software that processes transactions. [Figure 5]This figure illustrates an exemplary embodiment of the present disclosure, in which a data resource (in this example, a document) is created and divided into multiple segments. [Figure 6] This figure shows an exemplary embodiment of the present disclosure, which is used to hash the segments in Figure 5 and construct a Merkle tree that represents multiple segments. [Figure 7] This figure shows an exemplary embodiment of the present disclosure in which the root of the Merkle tree is signed using an appropriate digital signature algorithm such as ECDSA, rather than a limited signature. [Figure 8] This figure illustrates an exemplary embodiment of the present disclosure, in which the necessary data is provided to a verifier (such as Bob), who then calculates the remaining data himself and can then verify whether the provided signed Merkle root matches what he calculated. [Figure 9] Figure 5 illustrates an exemplary embodiment of the present disclosure, and the validator uses the data provided in Figure 5 to perform the verification process. [Figure 10] This figure illustrates an exemplary embodiment of the present disclosure, in which a Merkle tree is used to verify a larger segment of the same file or a single copy of the entire file as separate segments. [Figure 11] This figure shows an exemplary embodiment of the present disclosure in which MerklePath is provided to optimize customized documents such as contracts. [Figure 12] This figure shows an exemplary embodiment of the present disclosure in which MerklePath is provided to optimize customized documents such as contracts. [Figure 13] This figure shows how a data administrator, such as a database administrator, can create and add a VAST file system using the embodiments disclosed herein. Figures 13 to 26 illustrate examples of use of various embodiments and how this disclosure applies to a VAST file system as an example. [Figure 14]This figure shows how a data administrator, for example, a database administrator, can create and add a VAST file system using the embodiments disclosed herein. [Figure 15] Figures 13 and 14 illustrate examples of embodiments in which the user generates a VAST file system record and assigns ownership of the file system to an identifier. [Figure 16] Figures 13, 14, and 15 illustrate how a user requests and receives files from the VAST file system shown. [Figure 17] Figures 13, 14, and 15 illustrate how a user requests and receives files from the VAST file system shown. [Figure 18] Figures 13, 14, and 15 illustrate how a user requests and receives files from the VAST file system shown. [Figure 19] These figures show how files can be verified when a user requests and retrieves files from the VAST file system shown in Figures 13 to 18, as implemented according to the embodiments of this disclosure. [Figure 20] Figures 13 to 19 show how to modify the entries in the usage examples once or multiple times. [Figure 21] This figure shows how embodiments are used to perform scalable updates of information and data, such as data recorded and processed by the exemplary systems provided herein. [Figure 22] This figure shows how subtrees are used within Merkle trees in various embodiments disclosed herein. [Figure 23] Figure 22 shows how the subtree is executed and how the exemplary systems provided herein can be used to create subtrees of larger trees to represent more complex and hierarchical editable documents according to various embodiments of the present disclosure. [Figure 24]Figure 22 shows how the subtree is executed and how the exemplary systems provided herein can be used to create subtrees of larger trees to represent more complex and hierarchical editable documents according to various embodiments of the present disclosure. [Figure 25] Figure 22 shows how the subtree is executed and how the exemplary systems provided herein can be used to create subtrees of larger trees to represent more complex and hierarchical editable documents according to various embodiments of the present disclosure. [Figure 26] Figure 22 shows how the subtree is executed and how the exemplary systems provided herein can be used to create subtrees of larger trees to represent more complex and hierarchical editable documents according to various embodiments of the present disclosure. [Figure 27] This figure shows a Merkle tree containing elements of a software library, according to an exemplary embodiment of the present disclosure. [Figure 28] To illustrate an embodiment of the present disclosure, the diagram shows a Merkle tree containing elements of a software library, where each leaf of the Merkle tree is a transaction ID of a blockchain transaction from which the associated software element can be extracted. [Figure 29] This figure shows the hashes of a series of software configurations that are publicly available within the Merkle tree. [Figure 30] This figure shows a method for creating a blockchain transaction that implements a software compilation process to generate firmware for an embedded computer, according to one possible embodiment. [Figure 31a] Figure 30 expands on the use of blockchain transactions, illustrating how multiple transaction outputs can be created that perform different functions. [Figure 31b]Figure 30 expands on the use of blockchain transactions, illustrating how multiple transaction outputs can be created that perform different functions. [Figure 31c] Figure 30 expands on the use of blockchain transactions, illustrating how multiple transaction outputs can be created that perform different functions. [Figure 31d] Figure 30 expands on the use of blockchain transactions, illustrating how multiple transaction outputs can be created that perform different functions. [Figure 31e] Figure 30 expands on the use of blockchain transactions, illustrating how multiple transaction outputs can be created that perform different functions. [Figure 31f] Figure 30 expands on the use of blockchain transactions, illustrating how multiple transaction outputs can be created that perform different functions. [Figure 32] This diagram shows a Merkle tree, which consists of a series of software elements. These software elements are used to build a revised software configuration with updated or additional software elements, enabling the implementation of a new or updated software configuration. [Modes for carrying out the invention]

[0037] Material specific to the invention For illustrative purposes, examples of preferred embodiments of this disclosure are provided.

[0038] In a preferred embodiment, the present disclosure provides a method and corresponding system for editing one or more portions of data from a data resource, the data resource may hereafter be referred to as “document” for ease of explanation and reference.

[0039] Embodiments of this disclosure can provide solutions (methods and systems) for secure and verifiable editing of data resources 510, extension of data storage and / or data verification systems, and improvement of hierarchical data storage systems on computer-based storage resources. Referring to Figures 5 and 6, at least one data resource 510 is broken down into a plurality of segments 520 and represented in a tree structure having a root 610. The root 610 can be signed by an authorized party to prove the authenticity of the data contained in the tree. For convenience, the authorized party may be referred to as the administrator of the data resource. This signature can then be used by another party to verify the authenticity of the document 510, even if one or more parts of the document 510 have been edited from a version provided to that party. The advantage of the disclosed technology is that it does not impair or degrade the integrity of the digital signature applied to the entire content of the data resource. In the following embodiments, for ease of explanation, the data resource will be referred to as a “document,” but this is not limited to the nature, purpose, or type of the resource or its digital content. For example, data resources include computer programs, collections of computer programs or code snippets, digital images or collections thereof, and multimedia content.

[0040] A document 510 is created and can then be divided into smaller elements (segments) 520. Segments may be as small as the smallest division unit (e.g., a single character) or they may consist of larger data portions. In some cases, a segment may even be an entire file or a group of files. In other words, a segment is a part of a data entity / resource, whether logical or not.

[0041] A tree is created that has an internal node 620 and uses the hash of segment 520 as a leaf 630. In a preferred embodiment, this tree is a Merkle tree, and for convenience, we will refer to it as a Merkle tree below.

[0042] To approve document 510 and to prove its origin, authenticity, and / or completeness, one or more data controllers sign the Merkle tree root 610. The signature is generated using a cryptographic key and is sometimes called a digital signature or cryptographic signature. It is preferable that the signature be applied to the root of the Merkle tree that constitutes the document, rather than to the document itself. In a preferred embodiment, individual hashes 630 are not signed.

[0043] In some cases, the data controller may be the creator, agent, or other party with legitimate or control over the document. In some cases, “control” may include “ownership” of the document. The authenticity verifier (sometimes called the “verifier”) can calculate the root and verify the signature if the data controller provides (or on behalf of) the minimum necessary data.

[0044] In the following example, we will refer to the data controller as Alice and the other party (the one performing the legitimacy verification) as Bob. Bob may be an end-user / consumer who uses or views the edited version of the document, or Bob may only perform the verification process, confirm its legitimacy, and then deliver the edited data resource to the end-user. More specifically, a preferred embodiment may include at least one or more of the following steps. One or more of the following steps may be provided by a single party or group of parties, or by several separate parties. The process may be distributed.

[0045] Step 1: Referring to Figure 5, Alice creates a document 510 and divides it into multiple segments 520. This involves generating logical definitions of segments rather than physically dividing the data. How Alice divides the document is an implementation choice. The division is determined based on, or using, criteria selected or acquired by Alice (such as size, number, or other segment attributes). For example, Alice may decide to divide the document into the smallest possible division units, such as individual bits, individual characters (e.g., ASCII), single-byte / multi-byte segments, or according to other criteria selected by Alice.

[0046] A segment can consist of any part of a document, from a single character to an entire section or even an entire chapter. By dividing a document into small segments, Alice can have fine-grained control over which parts of the document she wants to edit.

[0047] Step 2: Referring to Figure 6, Alice hashes each of the individual segments 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 (sometimes called a leaf element, or simply a "leaf").

[0048] Segment 520 can be further broken down into subsegments 2610 (see, for example, Figure 26), but segment 630 is the smallest individual editable component of the document. In other words, after building the Merkle tree with segments as leaves in steps 2 and 3, it is not possible to edit any part of document 510 smaller than segment 630. Thus, the segment is also called the “smallest editable element” 630.

[0049] As can be seen from the explanation in Figure 6, the order and structure of segments, as well as the relationships between segments, are preserved and represented in the Merkle tree. This can be important when processing the data later. For example, the segments may be reorganized into a viewable / usable format so that a user can read an edited version of the document or process it in other ways. However, in other embodiments, depending on the requirements of the relevant implementation and use case, it may not be necessary to preserve the original order or structure of the segments, or they may be intentionally randomized during tree construction.

[0050] Step 4: Referring to Figure 7, Alice signs the hash of the tree's vertex (i.e., root). Signature 710 can be generated using the following steps: 1. The signer's private key (for example, Alice's private key) is associated with the public key. 2. K value - This is usually a random value. 3. Message Hash A hashed message has the advantage of being able to include other data elements. These can be hashes of other documents, data items, or other Merkle tree roots, allowing a single signature to be applied to multiple documents.

[0051] Step 5: Referring to Figure 8, Alice edits at least one segment from the document by selecting one or more segments to omit from the version of the document she provides to Bob. This may include the step of selecting at least one segment that is provided only in hash format, rather than the original pre-image version.

[0052] Step 6: Referring to Figure 8, Alice provides the tree root 610, the unedited segment, and the hash of the edited segment that Bob needs for verification.

[0053] In other words, Alice provides Bob with the non-confidential parts of the documents she shares with him, as well as the data Bob needs to perform the verification process (which he cannot calculate himself).

[0054] If Bob is both the validator and the end-user who consumes (uses, stores, and processes) the edited data, Alice can provide Bob with all the unedited segments. Alternatively, Bob may simply perform validation functions and not be an end-user. In this case, Alice can provide Bob with a sample for validation purposes only, rather than all the unedited segments.

[0055] In a simple case, Case 1, the document information provided to the verifying party (i.e., Bob) would be as follows, as shown in Figure 8. • Digital signature • Markle Route • At least one unedited document section • Markle path to the provided unedited document section

[0056] In the more complex Case 2, as mentioned above, Alice may provide additional data items in the signed message along with the signed Merkle root. As shown in Figure 8, in such a case, Alice provides Bob with the following information: • Your own digital signature • Markle Route • The hash of any additional data (e.g., metadata) within the signed message. You need to provide Bob with the entire pre-image so that he can calculate the hash and perform any necessary checks. • At least one unedited document section • Markle path to unedited document sections provided to Bob

[0057] Figure 8 shows that Alice does not need to send Bob the entire Merkle tree. Alice only needs to provide Bob with the unedited portion of the document she is sharing and the data necessary to verify the signature attached to the signed data. The signed message 710 may contain only the Merkle root (Case 1), or the Merkle root with the additional data 720 added (Case 2).

[0058] Step 7: Referring to Figure 9, Bob verifies the authenticity / completeness of a document even if some or more parts of it have been edited. The verification process consists of at least the following steps, and Bob performs the following steps: 1. Verify that the key / digital signature / message matches. 2. Verify that the Merkle root matches the version provided in the message. 3. Access the single smallest editable segment 630. 4. Hash the smallest editable element. a. Calculate the route using the provided Merkle path elements. b. Hash the unedited document section. c. The Merkle path to an unedited document section (i.e., the minimum number of additional nodes in the tree required to calculate the root hash, starting from a specific leaf).

[0059] In the example in Figure 9, Bob performs the following calculation to execute the verification process: 1. Hash the document title to generate "16". 2. Hash 16 and 17 to calculate 8 (this involves concatenating 16 and 17 and hashing the result). 3. Hash 8 and 9 to calculate 4. 4. Hash Section 2 Clause 1 to calculate 19. 5. Hash 18 and 19 to calculate 10. 6. Hash 10 and 11 to calculate 5. 7. Hash 4 and 5 to calculate 2. 8. Hash Section 4 Clause 3 to calculate 21. 9. Hash 20 and 21 to calculate 13. 10. Hash 12 and 13 to calculate 6. 11. Hash "Name and Role 1" to calculate 23. 12. Hash 22 and 23 to calculate 14. 13. Hash 14 and 15 to calculate 7. 14. Hash 6 and 7 to calculate 3. 15. Hash 2 and 3 to find 1 (i.e., the root).

[0060] It should be noted that Bob does not need the entire Merkle tree or all the hashes of the edited segments. Once the Merkle root is computed (step 15), it can be checked whether the hash value used to generate the signature matches the one provided by Alice. If the hashes match and the signature is valid, it proves that the edited segments form part of the whole document and that the signature is applied to all items on the leaves of the tree. In other words, Bob can prove that Alice used her private key to generate a signature applied to the root of the Merkle tree representing the whole unedited document.

[0061] Step 8: The edited document may be provided by the end user / consumer (Bob or at least one other party, as described above) in some way, such as by being displayed or output. For convenience, we will assume here that this is Bob.

[0062] In some cases, Bob may use a browser, wallet, word processor, image display application, or other software application configured to output or process unedited data. The output of unedited data may be provided in a visual, auditory, or tactile format, or in an electronic format such as a storable or processable digital resource. For example, this might involve playing an audio or video file, displaying a document on a screen, printing to some output device, or outputting and storing at least one data file, or sending it to at least one recipient.

[0063] In some embodiments, one or more edited segments can be replaced with alternative markers or indicators. For example, an edited portion of a text file might be displayed on the screen as a blank box or an "X" instead of the edited data. In the case of an audio file, a sound such as a beep might be emitted. This allows the viewer / listener / end user to know that a portion of the data has been deleted at that location.

[0064] Variations and Use Cases Secure distributed storage technology In some embodiments, Alice can retain the edited segments. In addition, or alternatively, Alice can also discard / delete original copies of one or more edited segments.

[0065] In some cases, edited segments can be sent to different storage facilities for secure storage. It's also possible to encrypt one or more segments using different algorithms and keys. The advantage of this method is that anyone attempting to duplicate the entire document would need to access the individual edited segments from different (preferably secret) locations and know the multiple encryption algorithms and keys used. This makes accessing the entire document significantly more difficult, resulting in a more secure data storage solution with lower vulnerability to unauthorized access. Highly sensitive data, such as confidentiality, personal information, commercial value, or security-related data, can benefit from being stored in this manner.

[0066] Large-scale data resources Figure 10 shows that by extending the scope of the Merkle tree, larger segments of the same file, or even a single copy of the entire file, can be included as individual elements. For large items containing many small editable segments, this makes document sharing more efficient because it reduces the amount of Merkle path and data that Alice provides to Bob to share the larger, unedited section. There is no impact on any properties, except that the amount of Merkle path data that needs to be shared per segment may increase slightly.

[0067] Templates and forms: Referring to Figures 11 and 12, Merkle paths can be used to optimize customized documents. In such cases, the edited segments can be used as "empty" sections of the document that the user can fill in. For example, the document could be a contract, form, template, payment authorization form, or any other type of document that the user needs to fill in, perform, adapt, or modify in some way. For convenience, we will use the example of a widely known contract. In the case of a contract that is reused by different contracting parties on various occasions, the contract can be divided into sections to form a Merkle tree with 2AN leaves, as shown in Figure 11. The number of segments in the contract is 2N If there are fewer items, you can pad them using blank leaves, as shown in Figures 11 and 12. This Merkle branch can be reused multiple times to create individual contracts that use the same template contract. In this way, the contract creator (e.g., Alice) can add individual sections to the contract in a different branch without changing the hash in the template branch.

[0068] As shown in Figure 12, signing a copy of a document allows you to add names, roles, special conditions, etc., to the Merkle tree without changing the hashes of existing branches in the tree. In the example in Figure 12, a provisional employment document is created containing a standard set of sections and clauses. Anyone with the same contract can use the same Merkle path to match the static (unedited) sections of the document against the template, but user-customized sections will use different hashes and different Merkle paths, generating unique Merkle roots.

[0069] Accordingly, one or more embodiments provide an improved solution for obtaining or providing forms, templates, or other types of data resources that require or facilitate completion by one or more users. The act of completion may include providing at least one signature (digital, encrypted, or otherwise formed) and / or providing one or more pieces of data. An edited version of the data resource may be formed according to any embodiment disclosed herein and provided to one or more users. Users may provide responses or inputs to replace, supply, change, modify, or otherwise process at least one edited segment. Thus, the edited segment may function as a placeholder for inputs provided by one or more users.

[0070] In some embodiments, the user can complete the edited document (i.e., template) by entering missing data, and the completed template is verified by a previous verifier (Bob) or another party.

[0071] For example, consider a scenario where a data administrator, such as a passport office, a company employing one or more employees, or an airline wants to send a form to a user for them to fill out. In these examples, the user could be a passport applicant, an employee, or a passenger. For illustrative purposes, we will use the examples of a passport office and a passport applicant.

[0072] Passport offices have standard forms that applicants must complete. These forms are provided in various formats, including those for applicants with hearing or visual impairments. The forms consist of data segments that are output to the applicant via screen, paper, vibration, sound, etc. There are also blank sections that applicants must fill in by entering data in those locations on the document.

[0073] However, it has been found, or is suspected, that unauthorized entities are impersonating passport offices, soliciting completion of forged forms, and distributing fraudulent versions of these forms to potential victims of fraud with the aim of obtaining valuable personal information, financial data, and / or associated payments.

[0074] In such circumstances, the Passport Office may provide hardware-based and / or software-based verification components that applicants and / or the Passport Office can use to verify the authenticity of documents submitted by the applicant. These verification components may be provided in various forms, including internet-based resources such as websites and cloud-based facilities, installable applications, digital wallets, and other computer-based mechanisms.

[0075] The Passport Office may edit some or more segments of an application form for completion by the applicant when a valid application is submitted. It may also insert hidden codes, watermarks, verification identifiers, timestamps, etc., into some or more segments that have not been edited. This can be done using appropriate known methods that facilitate watermarking, such as steganography. Essentially, one or more segments may be arranged to (preferably) contain a hidden identifier or code, which can be verified using the verification processes described herein. Identifiers / codes / watermarks / timestamps / references, etc., may be chosen 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 phrase “identifier” is used to include codes / watermarks / timestamps / references, etc. Identifiers are obtained using at least one random or pseudo-random operation, or as a result of a mathematical operation, but are obtained by selection / generation by one or more people or processor-based means.

[0076] When an identifier is associated with a blockchain transaction, it may include or provide the transaction ID, block ID, the transaction / block itself or a part thereof, and / or hashes thereof. The transaction may include data related to data resources and / or data controllers. In other cases, alternative locations such as the cloud, websites, or servers may be used to store this associated data, but storing it on the blockchain has the advantage of providing an immutable, timestamped, and cryptographically protected copy of the data.

[0077] In some cases, a verification identifier may be provided for one or more edited segments, as verification using a signed Merkle root proves that the edited segment is part of the entire original document. This has the advantage that data administrators can verify the returned copy, while the shared edited version received by the user does not include the verification identifier, thus preventing unauthorized third parties from forging it. In this way, the embodiment can provide a security measure that allows users to verify with data administrators whether the data resources they receive are indeed legitimate and up-to-date.

[0078] The Merkle Tree root is digitally signed by the Passport Office as described above, and the selected, unedited segments are made public to the end user as described above. When an applicant submits a form to the Passport Office through an authorized root, the completed form (or the signed Merkle root of that form) is attached to or provided with the user's completed data. This ensures that the application form used by the user is verified in accordance with the embodiments disclosed herein. If the form submitted by the user to the Passport Office is altered in any way compared to the authorized version, the hash and signature will not match the legitimate one. Therefore, the Passport Office may notify or warn applicants who submit a form to the Passport Office through electronic means, such as completing an online form or downloading an authorized “Application Submission” app, about the validity of the submitted data. The applicant may receive a verification notice indicating that the completed form received has been reviewed by the Passport Office and verified as legitimate.

[0079] Similarly, segments may include the form version number. If the law changes, the version number of the official passport form will be updated. If a user fills out an older version of an official application form, the verification software can identify this and be configured to send a warning or reject the application.

[0080] Therefore, the embodiments can provide not only verifiable forms and templates for user input, but also security methods and systems for data administrators to verify that such forms have not been tampered with, corrupted, or provided improperly upon receipt. Furthermore, they can also provide version control solutions for shared data such as documents, digital content, and executable code.

[0081] Example use case: VAST file system and database snapshots For illustrative purposes, use case examples illustrating how embodiments of this disclosure are performed are shown with particular reference to Figures 13 to 24. Files can be considered segments. Files can be added or modified within the system.

[0082] As an example, consider a scenario in which items are created (recorded) in a database. Files are created in one or more locations on one or more memory modules, and the file system is accessible from one or more devices and from one or more locations. A VAST file system is a file system consisting of files stored in a large number of locations. Using the techniques disclosed herein, the file system can be represented as a Merkle tree, and the Merkle tree may include each file as a leaf of the Merkle tree and may include information such as routing data and database memory locations to facilitate access to the files.

[0083] A leaf of a Merkle tree may also become the root of another Merkle tree representing an editable file according to one or more of the methods disclosed herein.

[0084] One or more signatures are generated by the data administrator and applied to the Merkle root of the VAST file system and the contents of the entire database. This provides a secure and verifiable snapshot of the file system at the time the signatures were generated. If a file and its Merkle root to its leaves are available, it is proven that the file was part of the VAST file system. If the file is in an editable format, both the Merkle path to the file's Merkle root and the Merkle path to the unedited file segment being shared must be provided to the recipient, to demonstrate that 1) the provided file or editable element of the file is correct, and 2) the file has been accepted into the VAST file system.

[0085] Figures 13 and 14 illustrate how a data administrator (e.g., database administrator Alice) creates a VAST file system and adds data to it using the embodiments disclosed herein. As shown in Figure 13, each entry / item has a unique location within the Merkle tree.

[0086] Figure 15 illustrates the process by which Alice generates VAST filesystem records and assigns or attributes ownership of the filesystem to identities such as owners, organizations, or departments. As shown in Figure 15, Alice can expose the Merkle root to a blockchain, which may, but is not limited to, a public blockchain such as the Bitcoin blockchain in some examples. In addition, or alternatively, Alice can expose the Merkle root to the public as a Metanet child of a Metanet node owned by the party managing the database (in accordance with one or more of International Publications 2020 / 109910, 202 / 110025, 2021 / 229334, 2022 / 200193, and 2020 / 109908, these are all incorporated herein). Advantages of exposing the Merkle root to a blockchain include the ability to provide a timestamped, immutable record for snapshot verification.

[0087] All files within the VAST file system can now be traced back to a publicly available Merkle root signed by the VAST file system owner. Furthermore, as shown in Figure 15, the Merkle root can be made public for Bob's verification purposes, while the actual content remains private. Therefore, Bob can verify the continued existence and integrity of the database content for security purposes without leaking sensitive information, personal information, valuable information, or other classified information (such as military-related or commercially valuable data).

[0088] Referring to Figures 16 to 18, examples of embodiments in which a user can request and retrieve files in multiple ways are shown. In Figure 16, when a file is requested, the illustrated service verifies the user's access rights to the information, and if valid, searches for the file in the memory storage unit where the information is stored and provides it to the user's device. The user can send user account information, device-specific identifiers, etc. In all cases, a gating function is applied that responds only to valid requests from parties with the appropriate level of permission.

[0089] In Figure 17, when a file is requested, the service provides the user with a hash of the file. The user and the database owner / administrator (Alice) work together to create a secret key pair using the service's known key (for example, one provided by the Metanet root node), the user's account key, and the file hash.

[0090] Figure 18 shows how files are delivered from Alice to Bob by providing the following two components: 1. Files. To transfer files, the service creates an HMAC (Hash-Based Authentication Code), known in this technology, and uses the generated secret key to encrypt and transfer the files. 2. The Merkle path from the file hash to the Merkle root of the public file system is also transferred. This makes the aforementioned verification possible.

[0091] Figure 19 illustrates the file verification process. The user (e.g., Bob) verifies the file using the following steps: 1. The entire contents of that leaf in the Merkle tree need to be transferred. 2. The recipient hashes the file. 3. The hash is matched against the provided Merkle path. 4. The Merkle path is cross-referenced with the Merkle root publicly available in the public ledger.

[0092] If the matching results are a match, the verification is successful; otherwise, it fails. This process allows Bob to verify that the file is exactly the same as the one added to the file system when the entry was created.

[0093] Figure 20 illustrates how entries in a VAST filesystem are processed (e.g., modified). An entry can be modified once or multiple times. Each modification requires the computation of a new N hash set, 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 redirect can be issued. This pushes all modifications to the active side of the Merkle tree (i.e., the part where actions and modifications take place), limiting the complexity and resource costs associated with performing updates.

[0094] Scalable updates The VAST file system shown in Figures 13 to 24 illustrates how an embodiment of this disclosure can be used to achieve scalable updates of information and data. Referring particularly to Figure 21, to achieve effective scaling, 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., the pre-update document, the previous document, and / or the original document).

[0095] When a file is modified, a new leaf is created with the new file hash and information. The Merkle path is recalculated up to the top of the relevant branch closest to the original location.

[0096] Then, a redirect is issued to the leaf location where the previous version was registered, and the Merkle path is recalculated to the root of the Merkle tree. After that, the root can be published.

[0097] subtree Referring particularly to Figures 22 to 26, subtrees can be added to implement, represent, and / or make functional subdirectory structures. This allows for the implementation of hierarchical data structures in an efficient and verifiable manner. In some embodiments, subtrees as a whole can represent separate databases. 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, which are Merkle trees of documents formed into segments according to the embodiments described above.

[0098] Figures 23 to 26 illustrate examples of subtree usage. Consider a scenario in which an organization creates a tree of contract clauses within a contract document, as shown in the attached diagrams and described above. In this example, these contract clauses are stored in a subtree of an enterprise-wide on-chain ledger. The first N entries are a list of contract clauses that can be used to construct the entire contract. In some embodiments, this can be implemented in EBRL, FPML, or other suitable format.

[0099] The N+1th entry is the transaction identifier (TXID) of the blockchain transaction. This transaction consists of a contract generated from the higher-level tree, and a subtree (or Merkle root of the subtree) containing associated user data and signatures. The hash of the complete document is added to the Merkle tree and made public.

[0100] Advantageously, it is possible to provide logic code to automate the execution and use of contracts. For example, the software may include rules that prevent a contract containing clauses lower down in the Merkle tree from being used in a valid contract. This allows for updating the database and applying permissions to specific versions of the document. In some embodiments, contracts may be implemented on the blockchain as “smart contracts.” In certain embodiments, smart contracts may be associated with tokenized assets, which may be non-fungible tokens (NFTs) known in the art.

[0101] In some embodiments, a contract can be generated from segments that are hashed to leaf elements of a higher-level tree. The entire contract is delivered as a single contiguous part via HMAC, and the user can hash the entire document and verify that it matches the expected hash in the contract ledger. This ensures that the user is always referring to the correct version of the contract. As an example, as shown in Figure 26, a contract using the clause at position 13 is invalid in the subtree at position 10 but valid in the subtree at position 16. Thus, some embodiments may include steps of providing, obtaining, processing and / or using smart contracts to automate the execution of a contract configured substantially as disclosed in any of the embodiments provided herein.

[0102] As described above, the embodiments provide a solution for verifying electronic data resources even when a subset of the data has been edited / deleted. In preferred embodiments, the properties of Merkle trees are utilized to provide such a solution. While Merkle trees are known, the disclosed embodiments differ in important and original ways.

[0103] Merkle tree and software provisioning / validation Herein, with reference to Figures 27 to 32, the advantageous aspects of this disclosure will be described. The technologies and systems described above can be used for provisioning and / or verifying software products to end users. End users refer to individuals or groups operating electronic devices such as laptop computers, mobile devices such as cell phones and tablets, IoT devices such as vehicles and home appliances, and military equipment such as drones and tanks.

[0104] 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. A repository can contain individual code elements that, when executed, perform a predetermined function. Thus, elements within a repository can be described as modules or building blocks, and a repository can be described as a (code) library or a collection of elements. A code library can correspond to the “data resources” described above. Code elements can contain sections or snippets of code that provide a particular predefined function. Preferably, they can be used to perform small, simple tasks. These can be described as “subtasks” because, when used in combination, they can provide a more complex part of computer code (software product) that performs a larger, desired task. A task can be defined as one or more specific functions.

[0105] By using the Merkle tree technique described above, (hashed) code elements can be provided as leaves of the Merkle tree. The preimages of selected code elements (leaves) are provided to specific users based on the following criteria: 1) User needs, such as the features required for installation and execution on the user's device. 2) User access rights. These are determined based on factors such as the user's ability to provide authentication identifiers like license keys, passwords, and PINs, and the user's role within the organization.

[0106] By using the disclosed technology, it is possible to select the functionality of the software provided to the user from multiple software elements in the tree, while simultaneously prohibiting access to elements that do not need to be shared with the user or elements that are not authorized to be shared with the user. In other words, some or more parts of the code library can be edited so that they are not shared with a specific user or group of users, as described above. The edited parts are provided only in hash format for verification.

[0107] It should be noted that user needs and access permissions can change over time. For example, a user might pay for an upgrade to an electric vehicle and need access to software that improves performance, or they might be promoted to a higher position within an organization and be able to perform a wider range of tasks and operations on their computing device, or a manufacturer might need to introduce an operating system upgrade to implement bug fixes or security patches. Therefore, data administrators may need to grant different users access to different code elements at different times. This can be done securely, quickly, and reliably by modifying the code elements shared with users.

[0108] Such embodiments may include those that use blockchain transactions, including the root of the Merkle tree, to allow end users to independently verify the authenticity of a portion of the software published or shared by a provider. In such embodiments, the software provider is the creator or distributor of the software and may be referred to as the “data controller” as described above. The software may be referred to as a “portion of (computer) code” and / or a “software package” or “software product.” A software product may consist of multiple software items or components. For consistency with the above terminology, these may be referred to as “elements.” In addition, or alternatively, elements may also be referred to as “computer code elements” or “code elements,” “software elements,” or “segments,” following the examples above. Code elements may consist of a complete executable program or code snippets to be included in a complete executable program. Code elements are preferably stored as collections or in relation to each other in a repository referred to as a “data resource” or “code library” or simply “library.”

[0109] In some embodiments, software products can be created with code executable via a blockchain. In this example, for illustrative purposes only, a software product can be generated from blockchain executable code (e.g., Bitcoin script) from multiple parts of blockchain executable code contained in multiple blockchain transaction outputs, each containing a different blockchain transaction output. The blockchain (e.g., Bitcoin) transaction outputs are processed in a specific order to obtain the desired result. However, in other embodiments, the software product can be generated with other types of executable machine code. For example, the software can be generated with native machine code for use in embedded system controllers or for systems with specific system architectures.

[0110] Other embodiments relate to the following: • Distribution of processed data items for use as variables in subsequent software product items, and / or • Distribution of software stored in a private database or storage resource. A publicly available Merkle root acts as an anchor from which verification can be performed on any element of the software product.

[0111] An overview of how to build software products using data contained in Merkle routes and blockchain transaction output sets. Here, we refer in particular to Figures 27 and 28. Figure 27 shows a Merkle tree containing elements of a code library, where the Merkle root of the tree is exposed in a blockchain transaction. This transaction may be formed according to the protocol of the Bitcoin blockchain, the Ethereum ledger, or other blockchain ledger implemented using the relevant protocol and node network. Figure 28 shows another embodiment of a Merkle tree containing elements of a code library, where each leaf of the Merkle tree is a transaction ID (TxID) or other identifier that can be used to identify a blockchain transaction that can be used to extract, identify, or access the relevant code element.

[0112] More specifically, Figure 27 shows a software repository ("code library") mapped or represented in a Merkle tree as described above. The (signed) root of the Merkle tree representing the entire library is stored in a blockchain transaction. This can be done using any appropriate transaction identifier. For example, the identifier may be a transaction ID formed according to the blockchain protocol implemented by the full node on the blockchain network, or it may be predetermined metadata or flags provided in the script within the transaction. The root can be stored in the transaction in any appropriate way, such as metadata within the script, or inoperable parts of the output, such as data provided after an OP_RETURN statement.

[0113] Each code element is hashed (optionally along with additional data such as version data, copyright data, encryption keys, and metadata), and the leaves of the tree are provided.

[0114] In Figure 28, individual code elements are shown as multiple blockchain transactions, each associated with a different code element in the library. In some embodiments, each leaf is the hash of the entire blockchain transaction, its identifier only, or a combination of data items that can identify a specific location on the blockchain (e.g., a combination of block ID, transaction ID, and / or output number (VOUT)). Figure 28 shows how one code element is stored, mapped, or associated with a different blockchain transaction, but this disclosure is not limited thereto. In other embodiments, one or more code elements may be stored or mapped to the same transaction. Mapping or other association between a code element and a specific transaction can be performed in a variety of ways. For example, in some embodiments, a code element can be directly inserted into a transaction in a script. In other examples, a reference or pointer to the storage location where the relevant code element is stored can be used, such as a URL of an internet site, an IP address, a DHT table, or a record identifier in a database. Thus, a code element can be accessed from an off-chain location or from the blockchain ledger itself.

[0115] In some embodiments, the library may be accessed via an application program that is installed on an end-user's device and operates to download and copy the software product distributed pursuant to this disclosure. This program is referred to as the “verification program” to distinguish it from the software product, which is downloaded from multiple unedited code elements, built, and installed on one or more devices if it successfully verifies.

[0116] In one example, the verification program can be provided with a signed Merkle root of a code library and at least one public key associated with at least one authorized party. Verification of a code segment can be performed as described above; that is, the entire tree can be verified by providing the verification program with hashed leaves of other (edited) parts of the library. The verification program can calculate a hash of the received code element and combine it with the hashes of the edited leaves to calculate the entire Merkle tree, including the Merkle root. This can be compared to a Merkle root signed by an authorized party. If the calculated root matches the signed root, the received code element must exist in a Merkle tree with a signed root. Thus, the verification program can verify that the received code element belongs to a Merkle tree representing a legitimate code library.

[0117] For enhanced security, the data controller / authorized party may include at least one verification element or "watermark" element as a leaf in the tree. A watermark leaf can consist of a hash of any data item known only to the data controller / authorized party. Examples include random numbers, selected images, or messages. Over time, to ensure security is not compromised, the watermark can be changed, and the data controller can calculate and sign a new Merkle root in the tree. The new Merkle root and watermark leaf can then be distributed to the verification party.

[0118] The new Merkle root allows data controllers / authorizing parties to sign using subkeys generated from the master key. This is done in substantially the same manner as disclosed in International Publication 2017 / 145016 and includes the following: The data administrator possesses an asymmetric encryption key pair called a master key pair, which consists of a master public key and a master private key. The parties agree on a common elliptic curve cryptography (ECC) system and a common generator (G), which can be selected, randomly generated, or assigned. • The user and the data administrator agree to or share the message (M). M may be anything chosen by one or both parties, such as random numbers, strings, pre-selected codes, or the output of mathematical calculations. The message may be shared between the parties using appropriate methods, such as communication over the internet or telecommunications, or downloading or viewing from a remote store. • A deterministic key (DK) is generated using the message (M). The DK is generated as H(M) by using M as input to a cryptographic hash function such as SHA-256. • Data administrators generate subkey pairs based on the master key pair in the following way: i) Generate a secret subkey using scalar addition of the master secret key and the deterministic key. ii) Generate a public subkey using the following method: Master Public Key + H(M) x G Here, + represents addition on the elliptic curve, x represents multiplication of points on the elliptic curve, and MasterPubKey is the master public key.

[0119] This allows you to generate a subkey pair from an existing (master) key pair, and the new subkey pair will be certifiablely linked to the master key.

[0120] The verification program is also provided with input to identify the first transaction on the blockchain in which one or more outputs (e.g., UTXOs) containing the library root are placed. The verification program analyzes the blockchain and determines whether the requested software product meets the following conditions: 1) It must be issued by an authorized party, and / or 2) It must be properly formatted so that it can be interpreted and installed in the way expected by the device.

[0121] In some embodiments, on-chain libraries can be built using application-level protocols. One example is the Metanet protocol, substantially described in International Publication No. 2020 / 109908, which enables the simplification and rapid verification of deep and complex on-chain hierarchies involving multiple code elements. Code elements may be provided by multiple separate developers or suppliers and / or approved by a parent organization that manages the device or parent software system on which they are installed. An example of such an ecosystem is a mobile phone operating system with a built-in app store. The mobile device is provided with an identifier for blockchain transactions (e.g., TXID) including the root node of the app store, which can independently verify the signature of any package on the device to ensure that it is an approved app and can be securely installed on the user's device.

[0122] In an exemplary embodiment, once instructed which software product to install (for example, which app to access and install from the app store), the verification program downloads the following: 1) Merkle Route 2) A list of transaction IDs for the required code elements (only). 3) A list of specific data extracted from each transaction (which may include one or more parts or all of the output script, or at least one stack item remaining in one or more processing stacks available within the blockchain evaluation environment at the end of transaction verification) and / or 4) Instructions regarding the order in which the code elements of a specified transaction are assembled to generate the desired software product.

[0123] In some embodiments, the verifier accesses a website or other software repository and downloads the listed items off-chain. In addition, or alternatively, the verifier can access some or all of the listed data from at least one transaction by using one or more outputs of at least one blockchain transaction. For example, the verifier may need to use pre-authorization or a provided key to use the output containing the required data, which would then reveal the required data, for example, using a Pay-to-Script-hash (P2SH). The use of the output is recorded in the blockchain ledger, providing an immutable, timestamped, and irrefutable record indicating that the end-user's device was authorized to access the specific data.

[0124] When accessed, the software build component assembles the downloaded code elements and uses them to build a complete software product. The build component may be installed on the end-user's device or may constitute part of a verification program. If the downloaded code is not in a native executable format for the device's processor architecture, the build component compiles and / or interprets the instructions accordingly and verifies all elements necessary to build the software product. One, part, or all of the build, assembly, interpretation, and / or execution steps may be performed within the device's secure component, such as a secure enclave, TEE, or HSM.

[0125] An overview of how to create multiple diverse software products using code elements contained in a Merkle tree. For illustrative purposes, consider a scenario where the data administrator is a mobile device (e.g., a phone / tablet manufacturer providing an app store where users can choose which apps to download and install on their mobile devices). In another example, the data administrator might be a device manufacturer providing various devices or systems to end users, such as kitchen appliances, vehicles, or control systems. 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 manufacturer. However, a particular model or version may not be allowed to execute all code elements, or may not need to execute them. If a user wants to upgrade their device to a more functionally advanced version, they may need to access and install additional software elements from the manufacturer's software library.

[0126] By using such techniques, data administrators can design and build software products with different configurations for different users or user groups, depending on which software elements in the tree users specify as downloadable or non-downloadable (i.e., removed from a particular user's repository). As shown in Figure 29, software configuration hashes can be exposed within the Merkle tree, and each hash represents a fully constructed executable code element, either entirely or partially constructed from the code elements contained in the library's Merkle tree. Each configuration may be unique within the Merkle tree by using different elements selected from the entire set of code elements in the library.

[0127] In the example in Figure 29, 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. It is possible to distribute different configurations for each end-user device. For example, different configurations can be distributed based on the device model and version, or whether the user is subscribed to the provider's premium service.

[0128] Accordingly, according to the disclosed embodiments, a Merkle tree can contain multiple code elements, which can be assembled in a predetermined order to build different software products. Each code element provides a building block or functional component that performs its own function (i.e., task). The tasks of the code elements, when combined, function as subtasks of a more complex task. In some examples, instructions are distributed to an end-user computing device that tell it how to build a software product to install and run on the device. The device can take any form, such as a mobile phone, laptop, server, vehicle, IoT device, distributed system, or parallel processing system.

[0129] Therefore, these instructions determine, direct, and control which software products the user's device accesses and builds. One advantage of using a Merkle tree is that the end-user's device does not have access to the entire code structure, but is limited to only the elements necessary to build the software products it has been granted access to.

[0130] In these embodiments, individual leaves of the same Merkle tree may contain references to code elements that are used multiple times in the software assembly process, such as software where a function needs to perform operations repeatedly, or software where multiple similar functions are created, each containing the same sub-elements / tasks. In these embodiments, the Merkle tree makes software exposure more efficient by eliminating the need to expose the same instruction set multiple times.

[0131] This method of assembling multiple different software products from elements contained in a single Merkle tree can be applied when the code is contained in a transaction on the blockchain or when the code is stored in a private database or other storage facility outside the blockchain. The advantage is that the Merkle root can give any party instructions for assembling any software package, and it can be verified that all components are downloaded and assembled correctly, from the correct sources, and not compromised by unauthorized third parties.

[0132] Overview of the method used to control updates to Merkle trees containing software elements within a software repository. In some embodiments, when a software repository (code library) is created, an initialization process is performed, generating a blockchain transaction output that includes a script with the appropriate set of permission controls implemented to add leaves to the Merkle tree and update the library. This script can be formed in multiple ways, and the structure of a particular script may be entirely dependent on the permissions and permission structure of the repository containing the Merkle tree in which the script is formed.

[0133] For example, consider a code library created and managed by two developers, both of whom can add it to a Merkle tree. In a Bitcoin-based embodiment, (although presented purely for illustrative purposes) such output could be used by structuring two multi-signature evaluation script segments as follows: 1 <pubkey1> <pubkey2>2 OP_CHECKMULTISIG

[0134] Thus, either party can expose an updated Merkle root by using the output of a transaction that includes the Merkle root. Furthermore, by solving this puzzle, the publishing party can also modify existing permissions. Because developers may leave the project or new developers may join, the output must be used to create a new version of the transaction unlock script that takes the changed permission structure into account.

[0135] This method allows for the publication of scripts that ensure the published Merkle root is purely additive by applying rules that guarantee that existing hashes verifying previously added data items are still present in the tree and that there is a path to the new Merkle root value. Such scripts take the new Merkle root and a Merkle path connecting previously existing hashes to this updated root as input, allowing the party submitting the updated Merkle tree to prove that the previous hashes have not been altered at the same location throughout the tree. Such scripts are particularly advantageous in large open-source projects where anonymous parties may submit code, as they can guarantee that references to previously existing valid code are not removed from the Merkle tree. This ensures the integrity of the code.

[0136] Figure 32 illustrates a scenario in which an existing software product (selected code elements + configuration) is updated or extended by additional code elements. As shown in Figure 32, the Merkle tree consists of a set of code elements, which are combined to build a software product with an initial configuration v1.0. Subsequently, the configuration needs to be updated or extended to provide a new configuration v2.0. Rather than replacing elements in the Merkle tree, the code elements are replaced additionally, the previous version remains in its existing leaf position, and a new leaf of the updated configuration is added to the tree. The monitoring process (indicated by the number 1 next to the eye symbol in Figure 32) monitors the incorporation of the update transaction into the blockchain, and then (indicated by the number 2 next to the processor symbol in Figure 32) accesses the new version of the software assembly instructions from update transaction 2 and downloads the updated configuration to the processor.

[0137] An overview of how end users can update published software using Merkle tree validation. In some embodiments, the Merkle root of a tree containing a set of code elements is exposed. An end user who has built software for use on a device can access: 1) the blockchain transaction containing the Merkle root, 2) instructions detailing which leaves of the tree should be assembled and in what order, and 3) the code elements represented by the leaves of the Merkle tree and the corresponding Merkle paths.

[0138] After the software is built and running, the software publisher can publish an update that updates existing code elements used in the package or adds new code elements to the software product. In either case, a new Merkle root is published.

[0139] Publishers achieve this by passing the existing output of the transaction, including the Merkle root, to a new blockchain transaction that includes the new Merkle tree and updated lock conditions related to subsequent updates. End-user devices can be configured to monitor the existing output so that they can respond immediately when an update is published. Alternatively, users can decide when to check for updates by configuring the output to be monitored periodically (e.g., weekly / monthly) or not monitored at all. In either case, the process of accessing and building the updated software remains the same.

[0140] The process outline is as follows: 1. The user's device checks the latest known transaction output for the root and determines if it has been used. If it has not been used, this is the latest version. If this is the version already installed, no further action is taken. 2. If an output is used, the device requests and / or retrieves information about the transaction in which the output was used and determines which output in this transaction represents the updated Merkle tree root. 3. The user's device repeats steps 1 and 2 until the latest version of Merkle Root is detected. 4. The user's device accesses instructions for the latest build of the software product being used. This may mean accessing a private database or another transaction on the blockchain that contains such instructions. 5. Using the instructions above, the user's device downloads the code elements necessary to build the updated software product and verifies that they are part of the Merkle tree using the provided proof. 6. The device assembles a new version of a software product, uses it to replace an existing version, and provides the user with an updated version of an app or utility.

[0141] Figure 30 shows an example of creating a blockchain (e.g., Bitcoin) transaction (Tx) that implements a software compilation process to generate firmware for embedded computing resources. The transaction (Tx) generates executable code as a stack item at the end of script processing. The transaction also generates output containing a copy of the script that runs the compilation process. If the firmware needs to be updated, the newly created output (e.g., UTXO) is used, and an update transaction generates a new firmware configuration. The update transaction is a new transaction written to the ledger, consuming the previous transaction. Embedded systems can view and access the updated firmware without logging into the platform or service.

[0142] An overview of how to use blockchain output obtained from a list of possible next steps based on the result output generated by variable input. In some embodiments, a set of script outputs may be created that perform different types of actions depending on the data generated. In such situations, a functional layer can be implemented that dynamically selects the next step from a list of valid next steps, depending on the data output generated from the previous state. This type of processing can be defined as a finite state machine, where a series of dynamic and changing inputs guide the operation of the entire system through a series of states to a final result.

[0143] In this scenario, each possible state is contained within the entire Merkle tree and can be downloaded and validated individually as part of the corresponding package, thus guaranteeing that the finite state machine will only transition to predetermined states within the system. The states and / or trigger events / conditions that cause the machine to transition from its current state to a new state can be defined in stored records, such as the machine's state transition table. A finite state machine is a deterministic finite automaton (DFA) and can be implemented on computing resources running independently of the blockchain, but can also be configured to interact with the blockchain or monitor its state.

[0144] These embodiments are illustrated with reference to Figures 31a to 31f, in which multiple blockchain transaction outputs are generated, each output performing a different function. These outputs are executed sequentially by a high-level program to calculate a desired result, such as the volume of a cylinder in this example. In Figure 31e, these outputs are processed through a series of separate blockchain transactions (Tx), whereas in Figure 31f, they are processed sequentially within a single transaction (Tx).

[0145] term It should be noted that the terms “editing,” “adaptive editing,” and “sanitizing” have been used in a somewhat fluid and inconsistent manner in the prior art. Here, for ease of reference, we will use the term “editing,” which is intended to include “adaptive editing” and “sanitizing,” and to encompass the “concealing,” “masking,” “deleting,” and “replacing” one or more selected portions of a data resource.

[0146] Furthermore, the following terms are used in this book as follows: "Sharing" includes any or more of displaying, transmitting, distributing, presenting, streaming, printing, making available, providing access, or providing from one or more other entities to at least one other entity. Entities mean any human being, machine-based resource, or group thereof. Preferably, "sharing" includes providing the contents of a segment to at least one other entity in a meaningful manner, for example, in a manner that a human or machine can read, process, perform, or understand for a particular purpose. • “Data Resource” includes, but is not limited to, any portion of data (preferably electronic or digital), such as one or more files, documents, videos, or other electronically / digitally delivered content. The term may be used to include a single content item or multiple data items that can be collectively represented as a single entity / resource. Furthermore, a single data resource may be owned and / or controlled by one or more data administrators, and in some cases, a data resource may be a computer program or part thereof, an executable file or part of source code, or a complete software product. • A “Data Controller” refers to any entity or group of entities that manages and / or authorizes a data resource. A Data Controller may be the creator or owner of the data resource or any part thereof, or may be authorized by such party or its agent to access and / or control access to the data resource. A Data Controller may consist of multiple entities or subordinate entities; for example, multiple organizations, individuals, or entities may share management / ownership of a data resource. In some cases, when multiple parties form a Data Controller, a signature threshold may apply. For example, an action may require, for example, n signatures or approvals out of m for it to be considered authorized by the Data Controller. For convenience, the Data Controller may be referred to as “Alice” here. "Acquisition" means any means of possessing any entity, including generating, calculating, selecting, or receiving from one or more sources. • In this book, the terms “validation” and “verification” (and the corresponding “validator / verifier”) may be used interchangeably. "Processing" includes, but is not limited to, one or more of the following: generation, storage, transmission (via electronic network), and transfer. "Blockchain" refers to any form of cryptographically enhanced ledger, regardless of the associated implementation, network, protocol, any type of cryptocurrency that may be associated, whether private or public, proof-of-work, proof-of-stake, or any other type of consensus mechanism. In some cases, ledgers may be implemented in a decentralized and / or peer-to-peer architecture or implementation. In this document, the terms "blockchain" and "ledger" may be used interchangeably. As used herein, “Bitcoin” is intended to include all protocols and implementations that are derived from or deviate from the original protocol defined by Satoshi Nakamoto in the Bitcoin white paper, “Bitcoin: A Peer-to-Peer Electronic Cash System” (2008). For convenience and ease of reference / explanation, the Bitcoin blockchain may be referred to; this is the most widely known one. However, embodiments of this disclosure are not limited to this, and other blockchain protocols and implementations, whether derived from the original Bitcoin protocol or not, are also included in the scope of this disclosure. "On-chain" may include storing, executing, or processing on, within, or via a cryptographically enhanced ledger such as a blockchain ledger. Conversely, "off-chain" may include storing, processing, or executing separately from a cryptographically enhanced ledger such as a blockchain ledger.

[0147] Listed clauses of the illustrated embodiments It will be understood that the embodiments described above are illustrative only. More generally, methods, apparatus, or programs are provided according to one or more of the following descriptions.

[0148] The features provided in this section with respect to a particular set of clauses, embodiments, or aspects may be used or incorporated in respect to any other set of clauses, embodiments, or aspects, and are not limited thereto.

[0149] Embodiments of this disclosure provide computer implementation systems and methods. In addition, or alternatively, they can provide methods and systems for one or more of the following: data security, editing of electronic data, access control (by encryption) to (preferably digital) data resources or at least a portion thereof, editing of (preferably digital) data resources, secure communication / distribution of (preferably digital) data resources, and selective access control to (preferably digital) data resources.

[0150] In addition, or alternatively, embodiments of the present disclosure may provide one or more of the following: • Improved digital signature algorithm • Improvement of smart contract solutions • An improved solution for obtaining or providing forms, templates, or data resources for one or more users to fill out. Input may include providing a signature (digital, encrypted, or otherwise) and / or providing one or more pieces of data. An edited version of the data resource is provided, and users can replace, change, modify, or otherwise process the edited portion by providing answers or input. Thus, the edited portion may function as a placeholder for one or more users to fill out.

[0151] Embodiments are provided substantially with respect to the systems and methods described herein, in particular to the section “Templates and Forms”.

[0152] Technical benefits derived from the embodiments include, but are not limited to, protection or enhancement of privacy and / or anonymity, data security, improved selective sharing of data, and improved verification of the reliability and / or integrity of data resources. In a preferred embodiment, this disclosure can provide solutions for protecting, sharing, verifying, and / or generating data resources such as, but not limited to, documents, files, code libraries, executable code, media files, or multimedia files. In one embodiment, the data resource is represented, expressed, or defined as a plurality of constituent segments, which are then hashed. Using the segment hashes as leaves, a Merkle tree is generated representing the complete original version of the data resource. An authorized signer signs the root of the tree. The edited version of the data resource can then be shared, with one or more segments omitted that the data controller wishes to keep secret or does not wish to share in its original form. These steps may be performed by an authorized party authorized to verify the authenticity of the data resource, such as a data controller, the creator or owner of the resource, or an authorized party acting on their behalf. To verify the authenticity and / or completeness of an edited data resource, the verifier is provided with sufficient data (e.g., the hash of each non-shared segment) to verify the presence of non-shared segments in the tree representing the original complete version, and the authorized signature that signed the root. In some embodiments, the data resource is a code library, and the segments are parts of computer code that perform a particular subtask. The code can be expressed in any form of artificial language and may include one or more, such as source code, object code, binary instructions, OP code, assembly code, native machine code, executable code, virtual machine code, and firmware code. Shared code segments, when executed on a processor, may be selected to combine to perform a larger task.

[0153] In addition, or alternatively, according to one form of expression, the embodiment can be described as including a computer implementation method that includes: Sharing and / or providing at least one segment of a data resource that includes multiple segments, To facilitate or perform validation of data resources using a Merkle tree that includes the hashes of each of multiple segments as leaf nodes.

[0154] Data resource validation may include validation of authenticity, ownership, origin, completeness, and / or provenance-related data regarding the data resource.

[0155] In addition, or alternatively, according to another form of expression, the embodiment may be described as including a computer implementation method that includes representing data resources as a Merkle tree, where: i) Data resources include multiple segments, ii) A Merkle tree consists of a root and multiple leaves, and each leaf contains the hash of each segment within multiple segments.

[0156] This method may include a step in which an authorized party signs the root of the Merkle tree. It may also include a step in which the administrator of the data resource shares or sends one or more of the following to the recipient: i) Signed roots of the Merkle tree, ii) Preimage of the hash of at least one leaf among multiple leaves, and iii) The hashes of the other leaves among multiple leaves, which the recipient (or other party) needs to reconstruct the Merkle tree and compute its root.

[0157] In some embodiments, step iii may include sending hashes of all other leaves among multiple leaves, excluding the leaf whose preimage is shared. In other words, the administrator can share all leaves of the Merkle tree, but some leaves are shared in preimage (unedited) form, and the remaining leaves (i.e., edited segments) are shared only in hash form. This method may include the step of selecting which segments are shared in preimage form (i.e., unedited) and which segments are shared only in hash form (i.e., edited).

[0158] The preimage may be an unhashened version of at least one leaf among several leaves. In one or more embodiments, the data administrator and authorized parties may be the same entity / actor / party, or comprised of the same entity / actor / party. Reconstructing a Merkle tree may involve hashing hash pairs to reach the Merkle root of the tree. The recipient and the other parties may be the same entity / actor / party, or may consist of the same entity / actor / party. Any other leaf hashes sent from the administrator to the recipient may be hashes of one or more edited segments of a data resource that the data administrator does not wish to share with the recipient in its original (or meaningful) form.

[0159] This delicious, Reconstruct the Merkle tree using the preimage and hash received from the data manager, and calculate its root. This involves comparing the signed root of the Merkle tree received from the data administrator with the calculated root of the reconstructed Merkle tree. This may further include steps to verify the authenticity and / or completeness of the data resources.

[0160] If the signed route matches the calculated route, the data resource is considered verified / authentic / uncompromised; otherwise, it is not considered verified / authentic / uncompromised.

[0161] In addition, or alternatively, according to another form of expression, the embodiment is: To obtain (e.g., generate) a Merkle tree of a first version of a digital resource containing multiple segments, where each (leaf) node of the Merkle tree contains the hash of each of the multiple segments. Signing the root of the Merkle tree, Verifying the first and / or second versions of a digital resource using the signed Merkle tree root. It can be described as including a computer implementation method that includes this.

[0162] Those skilled in the art will understand that all tree structures, including Merkle trees, consist of a root. Therefore, the "root" in the above definition does not require any prior relationship.

[0163] The first version may be the unedited and / or original version of the data resource. The second version is an edited version of the data resource in which one or more parts / segments / elements of the first version are omitted, replaced, and / or modified in some way compared to the original state. The second version may be provided or obtained by selecting sub-parts of multiple segments (i.e., parts of multiple segments excluding at least one segment).

[0164] A digitally signed message may contain one or more additional data items. Digital signatures may be generated using keys owned, controlled, or operated by the administrator / owner of the data resource.

[0165] Signing a root may involve signing a message that contains the root or its hash. A root may be signed by one or more administrators / owners / managers of a data resource.

[0166] The verification of the first and / or second versions of a digital resource may include one or more of the “verification / validation” process steps disclosed herein. This may include one or more of the following: • Verify that the key, digital signature, and message match. • Verify that the calculated Merkle route matches the version and / or signed message provided by the data administrator. • Access one or more (minimum editable) segments / elements of a data resource. • Hash at least one minimum editable element (segment). • Calculate the route using the provided Merkle path elements. Provide or retrieve one or more Merkle paths to an unedited resource segment (i.e., the minimum number of additional nodes in the tree required to compute the root hash, starting from a specific leaf).

[0167] In addition, or alternatively, according to another form of expression, the embodiment is: A step of providing or obtaining the root of a Merkle tree representing at least one data resource, wherein each segment of the at least one data resource is provided as the respective leaf of the Merkle tree, Steps to easily verify or perform the verification of an edited version of at least one data resource using a signed message that includes the root of the Merkle tree. It can be described as including a computer implementation method that includes this.

[0168] In addition, or alternatively, according to another form of expression, the embodiment is: A step of providing a computer implementation configuration for verifying an edited subset of a data resource, and / or This includes steps to validate or facilitate validation of an edited subset of a data resource. It can be described as including a computer implementation method.

[0169] This method can be combined with one or more of the features / steps disclosed herein. The term “part” may be replaced with “segment.”

[0170] In addition, or alternatively, according to another form of expression, the embodiment is transmitted from the sender (e.g., data controller) or its agent to the recipient (e.g., data verifier), An edited version of a data resource containing multiple segments (where the data resource has been edited relative to the original (first / initial) state of the data resource, in that at least one of the multiple segments has been edited), The edited segment or the hash of each segment, and / or The computer implementation method is described as including the step of providing the original version of the Merkle tree of the data resources, and the Merkle tree is i) (Leaf) nodes containing the hashes of each of the multiple segments of the original version of the data resource, and / or ii) Including roots signed by or on behalf of the data administrator.

[0171] Editing at least one segment may include omitting, replacing, or modifying that segment from the edited version.

[0172] In addition, or alternatively, according to another form of expression, the embodiment allows the recipient (e.g., a data verifier) ​​to receive from the sender (e.g., a data controller or a data controller's agent), An edited version of a data resource containing multiple segments, where the data resource has been edited relative to its original (initial / initial) state, in which at least one of the multiple segments has been edited. The edited segment or the hash of each segment, and / or Original version of the Merkle tree for data resources The computer implementation method is described as including the step of receiving, and the Merkle tree is i) (Leaf) nodes containing the hashes of each of the multiple segments of the original version of the data resource, and / or ii) Including roots signed by or on behalf of the data administrator.

[0173] This delicious, The steps include: constructing a new instance of the Merkle tree of the original version of the data resource using the edited version of the data resource and the hash of at least one edited segment, either by the recipient or on behalf of the recipient; The steps include comparing the root of the new instance of the Merkle tree in the original version of the data resource with the root of the Merkle tree provided by the sender, Steps to verify the digital signature of the Merkle tree root provided by the sender. The step of verifying the digital signature of the Merkle tree root provided by the sender may include one or more steps of determining 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.

[0174] The step of constructing a new instance of the Merkle tree for the original version of a data resource can be performed by combining the edited version of the data resource with the edited segments or the hashes of each segment. The Merkle tree can be constructed using known techniques to hash pairs and derive the root of the entire data resource. This step involves inserting the hash values ​​of the edited segments, or each hash value, into the edited data resource, and / or replacing the edited segments in the edited data resource with the hash values ​​of the edited segments, or each hash value. In other words, a new instance of the Merkle tree can be constructed by replacing the edited segments with their respective hash values.

[0175] The edited version of the data resource is: - If it is confirmed or verified that the signed Merkle root digital signature was generated using or derived from an encryption key known to be associated with the data controller, and / or - If the root of a new instance of the Merkle tree (built by the recipient) matches the signed root of the Merkle tree (provided by the sender), Verified and / or considered legitimate.

[0176] In addition, or alternatively, according to another form of expression, the embodiment can be described as a method for verifying an edited version of a data resource from a source. A signed root of a Merkle tree representing the original version of a data resource containing multiple segments (each leaf in the tree contains the hash of its respective segment, and the signed root contains, or is associated with, a digital signature associated with the authorized entity of the data resource), The hash of at least one segment of multiple segments and This includes the step of obtaining [something].

[0177] This method further, Steps to obtain the Merkle path and / or edited version of the data resource from the source, Steps to verify the edited version of the data resource, Steps to display or identify one or more segments from multiple edited segments. It may include one or more of these steps.

[0178] In addition, or alternatively, according to another form of expression, the embodiment is: i) A Merkle tree representing at least one data resource, where each of the multiple segments of at least one data resource is provided as a leaf of the Merkle tree, and the signed Merkle root is signed by or on behalf of at least one authoritative entity or managing entity, and ii) An edited version of at least one data resource, wherein the edited version includes a subset of multiple segments, iii) The hash of each segment in a subset of multiple segments and This can be described as a computer implementation method that includes the step of providing or obtaining.

[0179] The steps of providing and / or receiving may be performed by nodes on a computer network. The providing step may be performed by at least one (first) sending node / computing resource, and the receiving step may be performed by at least one (second) receiving node / computing resource.

[0180] Clause Set 1: The functionality provided under Clause Set 1 may be used or incorporated with respect to other sets of clauses included herein, but is not limited to these.

[0181] Clause 1.1. A step of providing or obtaining the root of a 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 the respective leaf of the Merkle tree. The steps include: verifying the edited version of at least one data resource using the Merkle root signed version; and Computer implementation methods including

[0182] Clause 1.2. Merkleroot must be signed by at least one authorized entity or managing entity, or by their proxy, and / or The method described in Clause 1, wherein the edited version of at least one data resource contains a subset of multiple segments.

[0183] Clause 1.3. Steps to select, specify, or define multiple and / or subsets of multiple segments of at least one data resource, Steps to select at least one segment for editing from a data resource and obtain a subset of multiple segments. The method described in Clause 2, which includes one or more of the following.

[0184] Clause 1.4. At least one recipient, i) An edited version of at least one data resource, ii) Digitally signed messages, ii) A digitally signed copy of Merkleroot, iii) Merkle proofs derived from Merkle trees, iv) The hash of at least one segment of the data resource, v) Additional data The method described in Clause 2 or 3, which includes the step of providing one or more of the following.

[0185] Clause 1.5. The method described in any of the preceding Clauses, wherein an edited version of at least one data resource includes or provides a template, form, or other resource for completion or input by one or more users.

[0186] Clause 1.6 i) The data resource includes a contract and / or, ii) A computer program is provided in relation to at least one data resource, and the computer program operates to control or influence the use of the data resource, and / or iii) At least one segment of at least one data resource includes, or functions as, a watermark, version identifier, authentication code, or security mechanism, configured to enable verification of the authenticity, completeness, origin, or legitimacy of the data resource. The method described in any of the preceding clauses.

[0187] Article 1.7. The steps include hashing one, some, or each of the segments within multiple segments, Steps to obtain a Merkle tree using multiple segments, Steps to perform or facilitate validation of an edited version of at least one data resource, and one or more of the following: a) A step of performing a comparison operation on one or more of the acquired encryption keys, digital signatures, and / or messages, or using them, to determine whether there is a match with the corresponding computed encryption key, digital signature, and / or message; b) A step to check whether the obtained Merkle root matches the calculated Merkle root, c) A step of accessing at least one segment of multiple segments, or processing at least one segment of multiple segments, d) The step of hashing at least one segment of multiple segments, e) A method of any of the preceding clauses, comprising the step of calculating a Merkle root using one or more Merkle path components.

[0188] Clause 1.8. The sender further provides at least one recipient with an edited version of at least one data resource, Optionally, the step of providing an edited version includes the method of any of the preceding clauses, which includes the step of generating a shared secret between the sender and at least one recipient.

[0189] Clause 1.9. A method comprising the step of providing a computer-based system that outputs an edited version of at least one data resource, wherein the system optionally... Cloud-based services or executable resources Internet-based services or resources Software applications configured to run on mobile, portable, or desktop-based systems. Digital wallet, browser, Word processing application or PDF / document viewer, Software for providing audio and / or video output, Electronic computer-based storage resources, Software for scanning, copying, or capturing images of resources. Software for generating digital signatures, and / or software for binding digital signatures to a portion of data. Software and / or hardware for executing or facilitating financial transactions and / or asset exchanges, Cryptocurrency platform A method of any of the preceding clauses, including one or more of the following.

[0190] Clause 1.10. From the source, the root of a Merkle tree representing a data resource containing multiple segments, where each leaf of the tree contains the hash of its respective segment, The hash of at least one segment among a plurality of segments, and a Merkle path, and a digital signature associated with an entity authorized for at least one data resource and obtaining the same, a method for verifying an edited document.

[0191] Clause 1.11. a memory including one or more memory units, and a processing device including one or more processing units A computer system comprising: the memory stores or executes code configured to execute on the processing device, and the code is configured to execute any of the methods of Clauses 1 to 10 on the processing device.

[0192] Clause 1.12. A storage or file system, optionally, the file system is a VAST file system, a storage or file system, a database, a component operating to interact with a blockchain network and / or a blockchain ledger The computer system according to Clause 1.11, further comprising one or more of the above.

[0193] Clause 1.13. A computer program implemented on a computer-readable storage and configured to execute any of the methods of Clauses 1.1 to 1.10 when executed on one or more processors.

[0194] Clause Set 2: The functions provided with respect to Clause Set 2 can be used or incorporated with respect to other clause sets included in this specification, without limitation.

[0195] Clause 2.1. According to an exemplary Clause Set 2, a method is provided, the method being A step of obtaining (e.g., generating) a Merkle tree of a first version of a digital resource containing multiple segments, wherein one, some, or all (leaf) nodes in the Merkle tree contain the hashes of each of the multiple segments, Steps to sign the root of the Merkle tree, This includes the step of verifying the first and / or second versions of a digital resource using a signed Merkle tree root. The second version may be called the edited version of the data resource. It may consist of at least one fewer segment than the first version.

[0196] Clause 2.2. i) A step of verifying the authenticity and / or completeness of the first or second version of the digital resource using a digitally signed Merkle tree, ii) The step of providing the recipient with a second version of the digital resource, which includes a subset of multiple segments, from the source. The method described in Clause 2.1, further including one or more of the following. The term "subset" can mean "one or more fewer" than the original set / number.

[0197] Clause 2.3. The method described in Clause 2.1 or 2.2, wherein the step of verifying the authenticity and / or completeness of a first or second version of a digital resource includes the step of verifying a digital signature applied to at least one or more hashes of the root and / or multiple segments of a Merkle tree (in a message containing them).

[0198] Clause 2.4. i) The step of hashing multiple segments to provide each node of the Merkle tree, ii) A method of any of the preceding clauses of Clause Set 2, comprising the step of selecting a subset of multiple segments.

[0199] A method according to either Clause Set 1 or 2, • The first (i.e., unedited / original) version of the data resource has N segments. • Multiple N segments are hashed to provide each (leaf) node in the Merkle tree. • The Merkle tree has a root signed by an authorized party, for example, at least one data controller / owner or their representative. • Signing is performed via any electronic / cryptographic means using a key generated with a common secret, at the discretion of the signatory. The step of providing a Merkle tree involves hashing each of the N segments to provide each (leaf) node in the Merkle tree. • Display or present an edited version of the data, i.e., output multiple segments excluding x selected edited segments (x=>=1). The (nx) segments to be shared each have a preimage of the hash of each (nx) segment. • Steps to share replacement segments for edited segments (from the same entity (e.g., Alice) or to the same entity (e.g., Bob)), Select x segments to exclude from the shared step. Verification involves hashing some or preferably all of the n segments and comparing each hash to the corresponding node in the Merkle tree.

[0200] "Sharing" refers to any method of making something available. This includes, but is not limited to, sending, transmitting, displaying, outputting, or providing access by means of download by a user.

[0201] Clause Set 3: The functionality provided in Clause Set 3 may be used or incorporated in relation to other sets of clauses included herein, but is not limited to these.

[0202] 3.1 A computer implementation method that includes inserting or providing at least one identifier / code / watermark / timestamp / reference in at least one segment within multiple segments of a data resource.

[0203] Multiple segments may be processed according to any of the disclosed embodiments. For example, this method may include one or more of the following: - Steps to define, select, calculate, or retrieve multiple segments of a data resource. - Steps to hash multiple segments, - A step of obtaining a Merkle tree representing a data resource, wherein the hash of a segment provides the leaves of the tree. - Steps to sign the root of the Merkle tree (and / or messages containing the root), - In the step of selecting one or more segments for editing, those segments are designated as “not shareable” and excluded from sharing operations in their original, unobfuscated form. Note that edited segments may be shared in an obfuscated form. For example, edited segments may be provided in a hashed, masked, and / or encoded form. Providing a hashed version of an edited segment allows that segment to be used in the verification process for calculating the Merkle root without exposing the edited data in its original meaningful form. - A step to share one or more unedited segments (i.e., segments designated as "permitted or allowed" for sharing) with at least one recipient. - Sharing with at least one recipient one or more of the public key associated with the secret key used for signing the route, the signed Merkle root, and the Merkle path / hash, to enable verification of the unedited segments by calculation of one or more Merkle proofs by the at least one recipient; and comparing the calculated root with the obtained / shared root, and using the public key to confirm that the signature and Merkle root calculated by the recipient match the Merkle root and signature obtained from the sharer / sender.

[0204] Codes, identifiers, and / or watermarks may be inserted into one or more edited segments and / or unedited segments. The codes, identifiers, and / or watermarks may be data for uniquely proving the authenticity, source, version, ownership of the data resource, or may indicate or contain other data.

[0205] Clause set 4: The functions provided with respect to clause set 4 can be used or incorporated with respect to other clause sets included in this specification, without limitation.

[0206] A computer-implemented method for providing a portion of computer code configured to perform a given task (when executed on one or more processors), the task including a plurality of subtasks, the method comprising: i) Using a Merkle tree to represent a (code) library including (a plurality of) computer code elements each configured to perform a respective subtask of the (plurality of) subtasks; and ii) Selecting a plurality of computer code elements from the library to provide a portion of the computer code.

[0207] In step i), the leaves of the Merkle tree may have hashes of computer code elements. In other words, each computer code element is hashed and provides a corresponding leaf of the Merkle tree representing a code library.

[0208] The computer code elements selected in step ii) are referred to as "multiple selected code elements," and the computer code elements that were not selected are referred to as "unselected computer code elements." Furthermore, the expression "provides a portion of computer code" may include the expression "provides a portion of the functionality of computer code."

[0209] Preferably, the method also transmits from the code provider to the code receiver. The preimage of each computer code element within multiple selected computer code elements, The hash of each of the unselected computer code elements and This includes the step of providing.

[0210] Therefore, the method may include the steps of sharing unhashed versions of code elements within a plurality of selected computer code elements, and sharing hashed versions of unselected computer code elements. In this way, the selected elements provide unedited code elements, while the hashed (leaf) elements can be edited. Thus, in other words, a code library can be edited according to embodiments of the present disclosure.

[0211] Clause 4.2. Each computer code element in the library is: i) Represented as a leaf of a Merkle tree, and / or ii) The method described in Clause 4.1, which includes code that is executable on a processor or can be processed for execution.

[0212] Clause 4.3. The method of Clause 1 or 2, which includes the step of having an authorized party or their agent sign the root of a Merkle tree in order to facilitate the verification of computer code elements in the Merkle tree.

[0213] Clause 4.4. A step including verifying the integrity or authenticity of one or more computer code elements of a portion of computer code, or of a group of computer code elements, using the root of a Merkle tree.

[0214] Clause 4.5. The method described in Clause 4.4, which includes the step of installing or executing a portion of computer code on at least one processor.

[0215] Clause 4.6 A method of any of the preceding Clauses, which includes the step of combining multiple computer code elements to provide a portion of the computer code.

[0216] Clause 4.7. A method of any of the preceding Clauses, which includes the step of providing a user with multiple computer code elements and / or portions of computer code from a provider.

[0217] Clause 4.8. The method of any of the preceding Clauses, wherein multiple computer code elements, when combined with each other or with other additional code elements, or when executed, provide a portion of computer code and are selected from a library to perform a given task.

[0218] Clause 4.9. Includes a step of verifying the authenticity and / or completeness of at least one of the computer code elements, which is part of or part of the code. From the code provider, via the code receiver, i) A signed copy of the Merkle root of the Merkle tree, where the signed copy of the root is signed by or on behalf of an authorized party, ii) The preimage of each computer code element within a plurality of selected computer code elements, and iii) The hash of some or all of the unselected computer code elements The step of receiving, By the code receiver and / or verifying party, i) The hash of each preimage received from the code provider, ii) Merkle tree of the library, and iii) Merkle tree route The steps to calculate, The steps include comparing the signed copy of the Merkle root received from the code provider with the root of the Merkle tree calculated by the code receiver and / or the verifying party, and It is done by [the specified method].

[0219] Clause 4.10. The method of Clause 4.9, which includes the step of determining the authenticity and / or completeness of at least one of the parts of the code or multiple computer code elements being verified, only if a 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 the verifying party.

[0220] Clause 4.11. The method described in Clause 4.9 or 4.10, which includes the step of a code receiver or verifying party obtaining a public key associated with or provided by the code provider.

[0221] Clause 4.12. The method described in Clause 4.11, which includes the step of the code receiver or verifying party signing the root of a Merkle tree calculated by the code receiver and / or verifying party using a public key associated with or provided by the code provider.

[0222] Clause 4.13. The method described in Clauses 4.9 to 4.11, which includes the step of installing and / or running multiple computer code elements on one or more processors, if it is determined that the authenticity and / or completeness of at least one of the computer code elements of the code has been verified.

[0223] Clause 4.14. Memory including one or more memory units, Apparatus including one or more processing units A computer system comprising: memory for storing or executing code configured to run on a processing unit; and the code, when executed on the processing unit, is configured to perform any of the methods described in Clauses 4.1 to 4.13.

[0224] Clause 4.15. A computer program recorded on computer-readable storage and configured to perform any of the methods described in Clauses 4.1 through 4.13 when executed on one or more processors.

[0225] In another aspect disclosed herein, a system is provided which comprises computer equipment claimed or described herein and / or capable of performing any method disclosed herein.

[0226] Example of a system overview A blockchain is a form of decentralized data structure in which duplicate copies of the blockchain are maintained on each of several nodes within a decentralized peer-to-peer (P2P) network (hereinafter referred to as the "blockchain network") and are widely publicized. A blockchain consists of a chain of data blocks, each containing one or more transactions. Each transaction, other than so-called "coinbase transactions," points to a preceding transaction in a sequence, which can span one or more blocks and trace back to one or more coinbase transactions. Coinbase transactions will be discussed further below. Transactions submitted to the blockchain network are included in a new block. New blocks are created through a process often called "mining," which involves each of several nodes competing to perform "proof of work," that is, solving a cryptographic puzzle based on a defined representation of an ordered, validated, and unprocessed set of transactions waiting to be included in a new block of the blockchain. Note that the blockchain may be pruned on some nodes, and block publication may be achieved through the publication of only the block header.

[0227] Transactions in a blockchain can be used for one or more purposes, such as moving digital assets (i.e., a certain number of digital tokens), ordering a set of entries in a virtualized ledger or registry, receiving and processing timestamp entries, and / or ordering index pointers in time. Blockchains can also be leveraged to overlay additional functionality on top of them. For example, blockchain protocols can enable the storage of additional user data or indexing of data within transactions. Since there is no predetermined limit on the maximum amount of data that can be stored within a single transaction, increasingly complex data can be incorporated. For example, this can be used to store electronic documents or audio or video data on a blockchain.

[0228] In the "output-based" model (sometimes called the UTXO-based model), the data structure of a given transaction comprises one or more inputs and one or more outputs. Every consumable output comprises an element specifying the amount of digital asset that can be derived from the preceding sequence of the transaction. Consumable outputs are sometimes called UTXOs ("unconsumed transaction outputs"). Outputs may further comprise a locking script that specifies the conditions for the future redemption of the output. A locking script is a predicate that defines the conditions necessary to validate and transmit digital tokens or assets. Each input of a transaction (other than a coinbase transaction) comprises a pointer (i.e., a reference) to such an output in a preceding transaction and may further comprise an unlocking script to unlock the locking script of the pointed-to output. Thus, we consider pairs of transactions, which we call the first transaction and the second transaction (or "target" transaction). The first transaction comprises at least one output specifying the amount of digital asset and a locking script that defines one or more conditions for unlocking the output. The second target transaction has at least one input, which is a pointer to the output of the first transaction and a lock release script for unlocking the output of the first transaction.

[0229] In such a model, when a second target transaction is sent to the blockchain network to be propagated and recorded on the blockchain, one of the legitimacy criteria applied at each node is that the unlock script satisfies all one or more conditions defined in the lock script of the first transaction. Another criterion is that the output of the first transaction has not yet been redeemed by another earlier, legitimate transaction. Any node that finds the target transaction to be fraudulent according to any of these conditions will not propagate the target transaction (not as a legitimate transaction, but possibly to register a fraudulent transaction), nor will it include the target transaction in a new block to be recorded on the blockchain.

[0230] An alternative type of transaction model is the account-based model. In this case, each transaction is defined not by referring back to the UTXO of a preceding transaction in a sequence of past transactions, but by referring to the absolute balance of the account. The current state of all accounts is stored separately on the blockchain by multiple nodes and is constantly updated.

[0231] Figure 1 shows an exemplary system 100 for implementing blockchain 150. System 100 may comprise a packet-switched network 101, typically a wide-area internet such as the internet. The packet-switched network 101 comprises a plurality of blockchain nodes 104, 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, so that each blockchain node 104 is highly connected to other blockchain nodes 104.

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

[0233] Blockchain 150 comprises a chain of data blocks 151, and each copy of blockchain 150 is maintained in each of the multiple blockchain nodes 104 within the decentralized network or blockchain network 106. As mentioned above, maintaining a copy of blockchain 150 does not necessarily mean storing blockchain 150 completely. Instead, blockchain 150 can be pruned in terms of data, as long as each blockchain node 150 stores the block header (discussed below) of each block 151. Each block 151 in the chain comprises one or more transactions 152, where a transaction refers to some kind of data structure. The nature of the data structure depends on the type of transaction protocol used as part of the transaction model or scheme. A given blockchain uses one particular transaction protocol throughout.

[0234] Each blockchain node 104 is configured to forward transaction 152 to other blockchain nodes 104, thereby allowing transaction 152 to spread throughout the network 106. Each blockchain node 104 is configured to create block 151 and store each copy of the same blockchain 150 in its own memory. Each blockchain node 104 also maintains 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 the “mempool.” In this specification, this term is not limited to any particular blockchain, protocol, or model. It refers to an ordered set of transactions that a node 104 has accepted as legitimate, and for which node 104 is not obligated to accept other transactions that seek to consume the same output.

[0235] In a given current transaction 152j, its (or each) input contains a pointer to the output of a preceding transaction 152i in the sequence of transactions, specifying that this output should be redeemed or "consumed" in the current transaction 152j. Consuming or redeeming is certainly one common use, but it does not necessarily mean the transfer of a financial asset. More generally, consumption can be described as consuming an output or assigning it to one or more outputs in another subsequent transaction. Generally, a preceding transaction can be any transaction in an ordered set 154 or any block 151. The preceding transaction 152i does not necessarily exist when the current transaction 152j is created or even when it is sent to the network 106, but for the current transaction to be valid, the preceding transaction 152i must exist and be validated. Therefore, in this specification, "preceding" refers to something that precedes a logical sequence linked by pointers, and does not necessarily refer to the time of creation or transmission in chronological order, and does not necessarily exclude the possibility that transactions 152i and 152j may be created or transmitted in a different order (see the following discussion on orphan transactions). The preceding transaction 152i may be equivalently called an ancestor transaction or predecessor transaction.

[0236] Due to the resources involved in verifying and publishing the validity of transactions, each of the blockchain nodes 104 typically takes the form of a server with 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 user terminal, or a group of user terminals connected together to the network.

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

[0238] Any given blockchain node can be configured to perform one or more of the following actions: verifying transactions, storing transactions, propagating transactions to other peers, and performing consensus (e.g., proof-of-work) / mining actions. In some examples, each type of action is performed by a different node 104; that is, nodes can specialize in specific actions. For example, node 104 can specialize in transaction verification and propagation, or in block mining. In some examples, blockchain node 104 can perform multiple processes of these actions in parallel. A reference to blockchain node 104 may refer to an entity configured to perform at least one of these actions.

[0239] Each computer device 102 of the multiple parties 103, who act as consuming users, is also connected to the network 101. These users can interact with the blockchain network 106, but do not participate in validating transactions or building blocks. Some of these users or agents 103 may act as senders and receivers in transactions. Other users may interact with the blockchain 150 without necessarily acting as senders or receivers. For example, some parties may act as storage entities that store a copy of the blockchain 150 (for example, by obtaining a copy of the blockchain from a blockchain node 104).

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

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

[0242] The client application 105 is initially provided to the computer equipment 102 of any given party 103 on a suitable computer-readable storage medium, which may be downloaded from a server and provided on a removable storage device such as a removable SSD, flash memory key, removable EEPROM, removable magnetic disk drive, magnetic floppy disk or tape, optical disk such as a CD or DVD ROM, or removable optical drive.

[0243] The client application 105 has at least a “wallet” function. This has two main functions. One is to enable each party 103 to create, authorize (e.g., sign) a transaction 152 and send it to one or more Bitcoin nodes 104 so that the transaction 152 is disseminated throughout the network of blockchain nodes 104 and thereby included in blockchain 150. The other is to report to each party the amount of digital assets that each party currently owns. In an output-based system, the second function is to match the amounts defined in the outputs of various transactions 152 scattered throughout blockchain 150 that belong to the party in question.

[0244] Note: While various client functions may be described as being integrated into a given client application 105, this is not necessarily limited, and any client function described herein may instead be implemented in a suite of two or more separate applications, for example, interfaced via an API, or one being a plug-in to the other. More generally, client functions may be implemented in the application layer, lower layers such as the operating system, or any combination thereof. The following description will be based on client application 105, but it will be understood that this is not limited.

[0245] Each computer device 102, an entity of a client application or software 105, is operably coupled to at least one of the blockchain nodes 104 of the network 106. This enables the wallet function of client 105 to send transaction 152 to the network 106. Client 105 can also contact the blockchain node 104 to inquire about any transaction to which each party 103 is the recipient (or, in an embodiment, to actually investigate the transactions of other parties on blockchain 150, since blockchain 150 is a public institution that brings credibility to transactions by being publicly visible in part). The wallet function of each computer device 102 is configured to organize and send transaction 152 according to the transaction protocol. As stated above, each blockchain node 104 runs software configured to validate transaction 152 according to the blockchain node protocol and to forward transaction 152 to propagate transaction 152 throughout the blockchain network 106. Transaction protocols and node protocols correspond to each other; a given transaction protocol is associated with a given node protocol, and together they implement a given transaction model. The same transaction protocol is used for all transactions 152 in blockchain 150. The same node protocol is used by all nodes 104 in network 106.

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

[0247] Some account-based transaction models share some similarities with the output-based transaction models described here. For example, as mentioned earlier, the data fields in an account-based transaction may reference previous transactions. This is equivalent to the input in an output-based transaction referencing the output point of a previous transaction. Thus, both models enable links between transactions. As another example, an account-based transaction may include a "Recipient" field (specifying the account's receiving address) and a "Value" field (where the amount of the digital asset can be specified). The recipient and value fields, combined, are equivalent to the output in an output-based transaction and can be used to assign the amount of the digital asset to a blockchain address. Similarly, an account-based transaction may have a "Signature" field containing the transaction's signature. This signature is generated using the sender's private key and confirms that the sender has approved this transaction. This is typically equivalent to the input / unlock script in an output-based transaction that includes the transaction's signature. Once both types of transactions are sent to their respective blockchain networks, the signatures are checked to determine whether the transaction is valid and recordable on the blockchain. In account-based blockchains, a “smart contact” refers to a transaction containing a script configured to perform one or more actions (for example, sending or “releasing” a digital asset to a recipient’s address) in response to one or more inputs (provided by the transaction) that satisfy one or more conditions defined in the smart contact’s script. Smart contracts exist as transactions on the blockchain and are invoked (or triggered) by subsequent transactions.Therefore, in some examples, a smart contract can be considered equivalent to a locking script for an output-based transaction, which is triggered by a subsequent transaction and checks whether the input of the subsequent transaction satisfies one or more conditions defined in the locking script.

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

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

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

[0251] In the context of transaction sequences, the terms “preceding” and “successor” as used herein refer to the order of transactions in a sequence as defined by the transaction pointers specified in the transaction (e.g., which transaction points to which other transaction). They can be equally replaced with “predecessor” and “successor,” or “ancestor” and “descendant,” “parent” and “child,” etc. It does not necessarily imply the order in which they are created, the order in which they are sent to network 106, or the order in which they reach any given blockchain node 104. Nevertheless, a successor transaction (descendant transaction or “child”) pointing to a preceding transaction (ancestor transaction or “parent”) will not be validated until the parent transaction has been validated, and unless it has been validated. A child that reaches blockchain node 104 before its parent is considered an orphan. Depending on the node protocol and / or node behavior, it may be discarded or buffered for a period of time to wait for its parent.

[0252] One of the one or more outputs 203 of the preceding transaction Tx0 comprises a specific UTXO, here labeled UTXO0. Each UTXO comprises a value specifying the amount of the digital asset represented by the UTXO, and a lock script defining conditions that must be met by the unlock script in the subsequent transaction's input 202 for the subsequent transaction to be validated and thus for the redemption of the UTXO to be successful.

[0253] A lock script (also known as scriptPubKey) is code written in a domain-specific language recognized by the node protocol. A specific example of such a language is called "Script" (uppercase S), used by blockchain networks. The lock script specifies what information is needed to consume transaction output 203, for example, the requirements for Alice's signature. The unlock script appears in the transaction output. The unlock script (also known as scriptSig) is code written in a domain-specific language that provides the information needed to satisfy the lock script criteria. For example, it might include Bob's signature. The unlock script appears in transaction input 202.

[0254] Therefore, in the example shown, UTXO0 in output 203 of Tx0 is the lock script [Checksig P A This includes Alice's signature Sig P, which is necessary for the UTXO0 to be redeemed (more precisely, for subsequent transactions attempting to redeem the UTXO0 to be legitimate). A [Checksig P A ] is the public key P from Alice's public key-private key pair. A The input 202 of Tx1 includes a representation (i.e., a hash). The input 202 of Tx1 includes a pointer that points to Tx1 (for example, by transaction ID TxID0, where in an embodiment TxID0 is the hash of the entire transaction Tx0). The input 202 of Tx1 includes an index that identifies the UTXO0 in Tx0 in order to identify the UTXO0 from all other possible outputs of Tx0. The input 202 of Tx1 further includes a lock release script <Sig P A > comprises Alice's cryptographic signature, which is created by Alice applying her private key from a key pair to a predetermined portion of the data (sometimes called a "message" in cryptography). The data (or "message") that needs to be signed by Alice to provide a valid signature may be defined by a lock script, by a node protocol, or a combination thereof.

[0255] When a new transaction Tx1 reaches blockchain node 104, that node applies the node protocol. This involves executing both the lock script and the unlock script to check whether the unlock script satisfies the conditions defined in the lock script (which may consist of one or more criteria).

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

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

[0258] A lock script is sometimes called a "scriptPubKey," which relates to the fact that the lock script typically contains the public key of the party to which each transaction is locked. An unlock script is sometimes called a "scriptSig," which relates to the fact that the unlock script typically supplies the corresponding signature. However, more generally, it is not required in all application examples of blockchain150 that the condition for a UTXO to be redeemed includes authenticating a signature. More generally, a scripting language can be used to define any one or more conditions. Thus, the more general terms "lock script" and "unlock script" may be preferred.

[0259] Appendix Other variations or use cases of the techniques disclosed may become apparent to those skilled in the art if the disclosures herein are given. The scope of this disclosure is limited only by the appended claims and not by the embodiments described herein.

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

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

[0262] In other embodiments of the present invention, the blockchain network 106 may not be a Bitcoin network. In these embodiments, it is not excluded that a node may perform at least one or more functions, rather than all, of creating, publishing, distributing, and storing blocks 151 of blockchain 150. For example, on those other blockchain networks, “node” may be used to refer to a network entity configured to create and publish blocks 151 but not to store and / or distribute those blocks 151 to other nodes.

[0263] More generally, any reference to the term “Bitcoin node” 104 above may be replaced with the term “network entity” or “network element,” such entities / elements configured to perform some or all of the roles of creating, publishing, distributing, and storing blocks. The functionality of such network entities / elements may be implemented in hardware in the same way as described above with reference to blockchain nodes 104.

[0264] Several embodiments describe blockchain networks that implement a proof-of-work consensus mechanism to secure the underlying blockchain. However, proof-of-work is only one type of consensus mechanism, and in general embodiments, any type of appropriate consensus mechanism can be used, such as proof-of-stake, delegated proof-of-stake, proof-of-capacity, or proof-of-elapsed time. As a special case, proof-of-stake uses a randomized process to determine which blockchain node 104 will be given the opportunity to generate the next block 151. The selected node is often called a validator. Blockchain nodes can lock tokens for a certain period of time to have a chance of becoming a validator. Generally, the node that locks the largest stake for the longest period of time is most likely to become the next validator. References to “Bitcoin,” “cryptocurrency,” or specific cryptocurrency protocols in this specification and accompanying diagrams may be replaced with the terms “blockchain,” “blockchain network,” or “blockchain protocol,” depending on the specific context in which these terms are used.

[0265] Disclaimer Incorporation by reference of the above documents is limited so as not to include subject matter contrary to the express disclosure of this Spec. Incorporation by reference of the above documents is further limited so as not to include claims contained in such documents. Incorporation by reference of the above documents is further limited so as not to include definitions contained in such documents unless expressly stated herein. [Explanation of Symbols]

[0266] 101 Internet, packet-switched network 102 Computer terminals and equipment 103 users 104 Blockchain Nodes 105 Client Applications 106 P2P Network 107 Side Channel 150 Blockchains 151 blocks 152 transactions 153 Genesis Block 154 Pool 155 Block pointers 201 Header 202 inputs 203 Output < / pubkey1>

Claims

1. A computer implementation method that provides a portion of computer code configured to perform a given task which includes multiple subtasks, i) A step of using a Merkle tree to represent a library containing computer code elements, each of which is configured to perform its own subtask, ii) The step of selecting a plurality of computer code elements from the library in order to provide the portion of the computer code, iii) From the code provider to the code receiver, The preimage of each computer code element in multiple selected computer code elements, and The hash of each of the unselected computer code elements Steps to provide and A method that includes [a certain feature].

2. Each computer code element in the aforementioned library is: i) represented as leaves of the Merkle tree, and / or ii) Including code that is executable or processable for execution on the processor, The method according to claim 1.

3. The method according to claim 1 or 2, further comprising the step of signing the root of the Merkle tree by or on behalf of an authorized party in order to facilitate the verification of the computer code elements in the Merkle tree.

4. Using the root of the Merkle tree, Part of computer code, or One or more computer code elements from the aforementioned plurality of computer code elements The method according to any one of claims 1 to 3, comprising the step of verifying the completeness or authenticity of the.

5. The method according to claim 4, further comprising the steps of installing a portion of computer code on at least one processor or executing a portion of computer code on at least one processor.

6. The method according to any one of claims 1 to 5, further comprising the step of combining the plurality of computer code elements to provide the portion of the computer code.

7. The method according to any one of claims 1 to 6, further comprising the step of providing the user with the plurality of computer code elements and / or the portion of the computer code from the provider.

8. The method according to any one of claims 1 to 7, wherein the plurality of selected computer code elements are selected from the library such that when combined or when the combination is performed, the plurality of selected computer code elements provide the portion of the computer code and perform the given task.

9. iv) A signed copy of the Merkle root of the Merkle tree, wherein the signed copy of the root is signed by or on behalf of an authorized party. v) The preimage of each computer code element in the multiple selected computer code elements, and vi) The hash of each of any or all unselected computer code elements The code is received by the code receiver from the code provider, iv) The hash of each preimage received from the code provider, v) The Merkle tree of the library, and vi) The root of the Merkle tree The calculation of the above code receiver and / or the verifying party, Comparing the signed copy of the Merkle root received from the code provider with the root of the Merkle tree calculated by the code receiver and / or the verifying party: The method according to any one of claims 1 to 8, comprising the step of verifying the authenticity and / or completeness of at least one of the portion of the code or the plurality of computer code elements.

10. The method of claim 9, further comprising the step of determining 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 the verifying party, and only if it matches, that the authenticity and / or completeness of the portion of the code or at least one of the multiple computer code elements has been verified.

11. The method according to claim 9 or 10, further comprising the step of obtaining a public key associated with the code provider or a public key provided by the code provider by the code receiver or the verifying party.

12. The method according to claim 11, further comprising the step of using a public key associated with the code provider or a public key provided by the code provider by the code receiver or the verifying party to sign the root of the Merkle tree calculated by the code receiver and / or the verifying party.

13. The method according to any one of claims 9 to 11, further comprising the step of installing and / or executing the computer code elements on one or more processors if it is determined that the authenticity and / or completeness of at least one of the portion of the code or the plurality of computer code elements has been verified.

14. Memory including one or more memory units, A computer system comprising a processing unit including one or more processing units, A computer system wherein the memory stores or executes code configured to be executed on the processing unit, and the code, when executed on the processing unit, is configured to perform the method according to any one of claims 1 to 13.

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

Images