Blockchain-Based Privacy-Enhanced Outsourced Data Storage

Abstract

The present application provides a method and system for verifying safe, consistent, and secure storage of data, particularly, but not by way of limitation, in situations where the storage of data is delegated to a third party. Alice, the data controller, takes at least one sample of her data D and performs operations on it to generate a variation. Alice then calculates the root value of a Merkle tree that represents the data including the modified data sample. Alice sends her data to Bob, the storage provider, keeping her sample and the resulting Merkle root value. Alice does not inform Bob of which sample she is selecting, the operations she used in the variation, or the inputs to the operations. Alice can delete her original copy of her data. At a later date, Alice can verify that Bob still has her complete data in its original state by requesting Bob to perform the same operations on the same data sample, calculate the root value of the resulting Merkle tree, and send it to her. If Bob's root value matches Alice's root value, Bob has the original complete copy of Alice's data, otherwise he would not be able to calculate the correct Merkle root value. The embodiments can be configured to fully automate the process, including implementation on a blockchain.

Description

[Technical field]

[0001] The present disclosure relates to improved techniques and systems for secure, efficient and verifiable storage, backup, archiving and / or recovery of electronic data. Particularly, but not exclusively, suitable for use in scenarios where data is stored by a second party (e.g., a storage provider) on behalf of a first party (e.g., a data owner, creator, controller and / or authorized custodian), even if the second party is not a trusted entity. Exemplary embodiments of the present disclosure provide improved solutions for verifying the integrity, presence and / or availability of data stored at or by the second party upon request. Advantages include, but are not limited to, being able to outsource storage of what may be a large portion of the data to secondary locations or devices, avoiding or reducing the need for storage and processing resources at the primary location. [Background technology]

[0002] In the digital age, data storage is a necessity for organizations and individuals. The safe and secure storage of such data poses challenges for a variety of reasons. For example, the data may have sentimental and / or commercial value, or may be sensitive from a legal, security, military, or political perspective, and / or the storage of the data may require resources that the data owner / controller cannot provide. Thus, for a variety of reasons, it may be desirable to delegate at least a portion of the data to another entity. For example, there may be scenarios in which an individual wishes to store a family video record for future posterity, or a company wishes to store large amounts of historical archive data to comply with legal requirements, or an inventor wishes to store experimental data in a time-stamped and verifiable manner, but does not themselves have the necessary resources to do so.

[0003] In such a situation, the first entity may be the owner, creator, controller, handler, and / or administrator of the data. For ease of reference, the first entity will hereafter be referred to as the "data controller." The second entity may be any entity that provides storage of data at the request of the first entity, and for ease of reference, this entity will be referred to as the "storage provider." The data controller and / or storage provider may be a human, organizational, or machine-based entity.

[0004] There are technical challenges in such scenarios because after storage of the data by the storage provider, the data controller needs to prove that a) it still has the data, and b) the data is unaltered or defective with respect to the data's original state. The storage provider must be able to provide proof of the continued integrity and availability of the data to the data controller. To be trustworthy, verification needs to be provided quickly and efficiently; computationally complex proofs that are costly in terms of time or processing resources are often unacceptable to the entities involved. Also, it is often desirable to provide proof in a way that does not require a trust relationship between the two parties.

[0005] Embodiments of the present disclosure provide solutions to at least these technical problems. Summary of the Invention [Means for solving the problem]

[0006] The present disclosure provides (at least) improved methods and systems for secure and / or efficient storage of data or enabling verification of the continuous availability and unchanged state of data. Preferred embodiments may include using Merkle trees to check and / or ensure the integrity of blocks / portions of data stored at a data storage provider.

[0007] In a preferred embodiment, a data controller (Alice) wishes to outsource or delegate storage of a portion of the data to another entity (Bob) because the data controller is unable or unwilling to retain storage of the entire portion of the data itself. This disclosure is not limited with respect to the format, structure, or purpose of the data. However, Alice requires certification from Bob that Bob has retained a full copy of the data and that his copy has not been altered from the original version Alice provided him.

[0008] In a preferred embodiment, Alice splits the original data (D) into multiple segments {m 1 , m 2 , m 3 , ... m N 7. Organize or arrange the data D into segments}, each segment being a sub-portion of the data D. This organizing / arranging may include splitting the data into logical or physically separate segments, for example by storing one or more of the segments separately from the others. In a preferred embodiment, Alice then records or applies the segments to data storage blocks (B) and hashes them pairwise, as known in the art, to form a Merkle tree. This provides a binary tree (T) that represents the entire original version of the data D, with the Merkle tree (R) as shown in FIG. 7.

[0009] Alice selects, or otherwise identifies, a set (M) of one or more segments and retains it / them. Each segment of the set M is small and therefore requires little storage space. The term "sample" may also be used hereinafter to refer to the segments that Alice retains. While in some embodiments only one segment may be retained, in typical embodiments M has two or more segments of the original data D such that different samples are used in separate verification sessions, further enhancing security.

[0010] Before or after Alice identifies and stores M, she sends Bob an entire block of segment B (i.e., a complete copy of D). After Bob receives the entire portion of the data, Alice deletes her entire copy of D while retaining access to segment M. Upon receiving block B from Alice, Bob stores the block in a storage resource that he has control over, or at least has access to, and from which he can retrieve D in the future. In an exemplary variation, Alice may request an acknowledgement of secure receipt of the data before deleting her copy. In another variation, Alice may send the data to Bob, who then organizes it himself into blocks of segments. In such a variation, the structure of the segments and how individual segments are identified and referenced would need to be agreed upon between Alice and Bob, or determined in some way in advance.

[0011] When Alice then requests verification that Bob still has D in its original state, she performs one or more operations on at least one segment of M. The operations provide an output (Y) that is the result of processing at least one segment of M. Alice then computes a new Merkle root (R') for a new version of T (T') in which the original segment used in the operation is replaced with the processed output Y. Hereinafter, the terms "modify," "alter," and "replace" are used interchangeably, but are all intended to include the interpretation that the original version of at least one given segment is in some way overwritten, modified, or replaced by a different subsequent version. "Verify" may mean "authentication, certification, and / or confirmation" herein.

[0012] Alice then asks Bob to perform the same operations using the same segments of his copy of D. Bob does not know in advance which segments and / or operations Alice will ask him to use in the verification proof. Bob then performs the operations using the specified segments from his original copy of the data to produce the output Y. Bob then computes a new Merkle Tree (T') and Merkle root (R') for the updated block that contains Y instead of the original segments. He sends Alice the new value for the root R'. Alice can then compare Bob's recomputed Merkle root R' value with the value of R' that she computed. If they match, Bob should have a complete copy of Alice's data in the original state that she provided it. If Bob did not have the entire data, or if any parts had been changed, he would not have been able to compute the correct value for the proof.

[0013] Embodiments and variations that are easy to understand are also described in the following sections, showing that the disclosure provides (at least) the following non-exhaustive list of advantages: the ability to outsource the storage of data to potentially unreliable storage providers; Allowing verifiable proof of the existence of data at the storage provider's location, as well as proof that the data has not been altered relative to its original state; Relieving the data storage burden from data controllers who are unable or unwilling to store the data themselves (e.g., physical storage constraints, legal constraints, business or organizational needs to place data in shared locations, etc.); · The ease of proving data integrity, origin and authenticity; · Secure, efficient and rapid verification of data availability and integrity; · facilitating the design and implementation of a wider range of systems and applications where data authenticity and availability need to be verified; · the ability to use simple operations that require fewer resources in terms of storage or processing and can provide results very quickly; The segments held by Alice are small and therefore do not require a large amount of storage space, which is an advantage for devices with limited capacity. Alice does not even need to store the segments; she only needs to have parts of the Merkle path that allow her to recompute them when necessary; this allows for Simplified Payment Verification (SPV) style verification of the contents of block B. · Alice does not need to keep a large set of sample segments; instead, she can vary the operations performed on her samples and / or the parameters she asks Bob to use for the operations. For example, in a first verification, she can ask him to concatenate the letter "G" to a given segment, in a subsequent verification, she can ask him to concatenate the result of an XOR operation on the same or a different segment using a string of randomly generated bits as a mask; in a third verification, she can ask him to concatenate the letter "U" to the same or a different segment, and so on. Thus, Alice only needs to keep a small number of segments to safely allow many iterations or modifications of the verification process without facilitating Bob's ability to predict the proofs he will be asked to provide. · Traditionally, Merkle proofs are used to verify that a particular blockchain transaction is part of the root (i.e., in a particular block). In contrast, the present disclosure uses one or more sample segments of a block to verify the existence / control / storage of the entire tree of data, not just a portion of it. So even if Alice's block B contained 100 million segments, she only needs one of those segments to quickly and easily verify that all of the segments are present in Bob's copy of the tree / block. · Alice can delegate or authorize the verification to another party (Carol), e.g. a third-party auditor or any entity that requires verification of the existence and authenticity of the stored data. Alice can send or share a secret to Carol using any suitable technique, such as those disclosed in WO 2017 / 145016. Carol can use the secret to request a verification proof from Bob. This allows delegation / authorization of third party validation for specific data items, which is privacy enhancing or at least privacy preserving (i.e. Alice doesn't need to give Carol access to her entire data store if she simply needs to validate an item). The invention facilitates scalability of technical systems and networks, since storage of data can be safely and verifiably outsourced. Embodiments also provide a solution to solve the technical challenge of data persistence; it is well known that commonly used techniques for system imaging suffer from the challenge of needing enough RAM to hold an entire copy of the data. See https: / / en.wikipedia.org / wiki / Persistence_(computer_science). Embodiments may address this challenge by outsourcing the storage to a provider. Embodiments may also provide improved solutions for data backup and recovery, archiving, file system dumps, versioning, and consistency assurance. See https: / / en.wikipedia.org / wiki / Backup.

[0014] To facilitate an understanding of embodiments of the present disclosure and to show how such embodiments may be carried into effect, reference will now be made, by way of example only, to the accompanying drawings in which: [Brief description of the drawings]

[0015] [Figure 1]FIG. 1 is a schematic block diagram of a system for implementing a blockchain. [Diagram 2] FIG. 1 illustrates generally some examples of transactions that may be recorded on a blockchain. [Figure 3A] FIG. 2 is a schematic block diagram of a client application. [Figure 3B] 3B is a schematic mock-up diagram of an exemplary user interface that may be presented by the client application of FIG. 3A. [Figure 4] FIG. 2 is a schematic block diagram of some node software for processing transactions. [Diagram 5] A flowchart illustrating an embodiment of the disclosure at a high level is provided, including at least some of the example steps that may be taken during the storage and subsequent validation phases of the disclosure. [Figure 6] 6 is an illustration of a preferred embodiment in which Alice sends a block of a data segment to Bob for storage and sends a copy of the block header to the blockchain for storage in an on-chain transaction. FIG. 6 illustrates several steps that may be taken during the storage phase of the disclosure. Some steps shown in FIG. 6 may be omitted in certain embodiments, and other steps that may be performed are not illustrated in FIG. 6. [Figure 7] FIG. 1 shows a very simple Merkle tree T with a Merkle root R and nodes below the root. [Figure 8] FIG. 2 illustrates a Merkle tree that may be used in accordance with the disclosed embodiments, including a sample segment {m1, m2, m3, m4}. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0016] With particular reference to Figures 5-8, examples of embodiments of the disclosure are provided for purposes of illustration only.

[0017] Consider a scenario where a first party (Alice 1), who is a data controller, needs to store a data item (D). The term "data controller" is used to include any party that has data that needs to be stored, including, but not limited to, the owner, creator, administrator, handler, processor, and / or authorized custodian of the data. The term "data item" is used to mean a piece of data, regardless of how the data is structured, generated, formed, used, or organized. For example, it may be a collection of related data items such as one or more discrete data files, database records, company accounts, related media content, legal documents, the contents of a physical storage medium such as a disk, etc.

[0018] Suppose Alice1 is unable or unwilling to store the entire data item herself. For example, her device may not have enough memory, or the data may be so sensitive that she does not want to store it locally for security or liability reasons. Thus, she needs to outsource the storage to another entity (Bob2) that acts as a storage provider. Bob has, or at least has access to, storage resource 3.

[0019] However, Alice 1 needs assurance that Bob 2 satisfies the following conditions: not losing any data item D, and / or Not to intentionally or inadvertently modify data D, for example if his device is compromised by an exploit that corrupts the data, or if his storage device fails without the ability to recover Alice's data.

[0020] Thus, Alice1 needs a verifiable proof that the data Bob2 is storing on Alice1's behalf is still present and in its original, unaltered state. She may need to obtain such proof periodically - for example, she may want to prove secure storage to Bob2 monthly, or at random / unscheduled times. Subsequent actions may depend on the success or failure of Bob's provision of the proof. For example, if the existence and state of the data is successfully verified, a signal or confirmatory electronic communication may be sent to the recipient, a file or record may be updated, an event may be triggered, resources may be unlocked, a transfer may take place between the transacting parties, such as Alice sending a payment to Bob. Similarly, if the verification fails, an event may be triggered, a communication may be sent to the recipient, and a record / file may be updated. For example, an alert signal may be generated and sent, or some resources may be locked to prevent access.

[0021] In some embodiments, Bob may be an entity entirely separate from Alice, and there may be no commercial or organization-based association and / or trust-based relationship between the two. For example, Bob may be a third-party provider that offers data storage as a service to paying customers. However, in other embodiments, Bob may be known to, associated with, and / or trusted by Alice. For example, Bob may have data storage capabilities or facilities that form part of an organization to which Alice belongs. Even if Bob is trusted by Alice, Alice may require verification from him that the data Bob is storing is intact and unaltered. This may be, for example, because Alice needs to comply with regulatory, commercial, or legal requirements related to the storage of (sensitive) data.

[0022] Exemplary embodiments are described with reference to Figures 5-8. Note that the steps illustrated in Figure 5 and illustrated in the description may in fact be performed in various orders. For example, the step of sending block B to Bob may be performed after or before Alice computes output Y. Alice identifies and records her set of segments M before she deletes her entire copy of D. Other steps may also be performed in different orders, and the disclosure is not limited in this respect.

[0023] In step 110 of Figure 5, Alice contributes her data (D) to a block (B). Note that the term "block" here is used to refer to a block of data in the traditional computing sense (see https: / / en.wikipedia.org / wiki / Block_(data_storage)) rather than a "blockchain block", which is a structured set of blockchain transactions. As is known in the general computing art, data may be stored in a block, which has a body (or "payload") and a header. The header contains information related to the data stored in the body of the block.

[0024] To do this, data is organized in segments. These segments of a data item are sometimes referred to as "sub-portions". Combined, the sub-portions / segments form a whole copy of data item D (Figure 5, step 110) and are thus combined to provide block B. The segments within the block are hashed pairwise from the leaf nodes upwards to compute a Merkle tree T that represents all segments of block B and has a Merkle root (R) (Figure 5, step 112). The Merkle root R is derived from a hash of all segments in the block and may be used to verify D as described below. Those skilled in the art will readily understand the concepts and techniques associated with the generation and use of Merkle trees - see https: / / en.wikipedia.org / wiki / Merkle_tree.

[0025] In step 114 of Figure 5, Alice identifies a set (M) of one or more sample segments. As a simple example, let us assume that she has three segments m 0 , m 1 , m 3 Suppose Alice selects segments 11001110, ...

[0026] Whether stored in raw or processed form, Alice's segments are small, e.g., 1 kByte each, and storing them requires little resources on Alice's device. Alice can select her segment samples according to any criteria, such as every 10th segment, or randomly selected from a set of M segments. Selecting randomly may improve security since it is harder for a third party to predict which segments she will store. Although the disclosed embodiments may be implemented using only one selected segment, the use of multiple segments provides an enhanced level of security since it makes it harder for Bob to predict the proofs he will need to generate.

[0027] In step 113 of Figure 5, as also shown in Figure 6, Alice sends block B containing the entire segmented data D to Bob along with a request for Bob to store it on her behalf. (As shown in Figure 6, the entire block she sends includes the sample segment m 0 , m 1 , m 3 ) He stores block B, which contains the data, in storage device 3 that he controls or to which he has at least the ability to send the data for storage. Storage device 3 may include one or more databases, disks, servers, or a combination of data storage media. However, Bob does not know which segments Alice has chosen to keep or how many segments she has chosen to keep.

[0028] The storage phase of this embodiment of the disclosure, shown in Figure 6, is now complete. However, at some point in the future, Alice needs to verify that Bob still has D and that it has not been modified in any way. Perhaps Alice wants to do this at regular intervals, or at random times, or when a triggering event occurs, e.g., the beginning of each month, or when she notices that a new malware exploit has recently become active, or when a third party asks her to provide proof of the existence of D in its original form. Because Alice needs proof of the existence and unmodified state of D in Bob's possession, the verification phase begins.

[0029] In FIG. 5, in step 115, she selects sample segment m 0 , m 1 , m 3 one or more sample segments m by performing some operation on them or using them as input / parameters to operations 0 , m 1 , m 3She can select a segment randomly from the stored set M, or according to some pre-determined criteria, such as taking the next unused segment in the set. The modifications she makes to the selected segment can result in any type of change; for example, they could include bit operations, Boolean operations, mathematical functions, etc. In this example, she transforms the letter "A" into a sample m 2 Suppose we add to . She now knows the result of this operation.

[0030] Therefore, m 2 is 0111001001001110, If "A" (in ASCII) is 01000001, she can calculate the following: m 2 |“A”=011100100100111001000001

[0031] In step 115 of Figure 4, Alice recomputes the Merkle tree, this time using the modified version of m instead of the original version. 2 As a result, Alice knows the value of the new Merkle root (R') of the recomputed tree (T').

[0032] In step 116 of Figure 5, Alice sends Bob a message to 2 We make the same change, i.e., operation f, to segment m 2 Alice then asks Bob to send her a Merkle root (the value of the Merkle root of a new tree containing the modified version of D). Thus, in step 117, Bob must perform a computation based on the whole of D and the operations specified by Alice. Alice may have also provided or specified certain parameters to use for modifying the segments. If Bob does not have the whole copy of D that Alice provided, he will not be able to compute the Merkle root needed for Alice to verify his copy.

[0033] If Bob has a full copy of D, then Alice can send a sample m 0 , m1 , m 3 and / or their hashes, so that she can discard her own complete copy. Alice does not need to store the entire Merkle tree for block B, but she does need to keep the Merkle root value for block B so that she can compare it with the value computed by Bob during the verification phase described below.

[0034] Communicate the requested changes to Bob Alice may use an identifier to specify the blocks and / or segments that are relevant. The identifier of block B may be provided in the header of block B that Alice sends to Bob. The header may include the Merkle root R of the block, which may be, or form part of, the identifier used in the validation request sent to Bob. At least one segment that Alice requests him to perform an operation on may be identifiable within the block by a unique identifier.

[0035] In another embodiment, Alice can communicate the requested changes to Bob using an encrypted or authenticated message technique, such as an authentication code (MAC). This provides Bob with an assurance that the message was indeed sent by Alice and not by an unauthorized party, thus enhancing security. For example, Alice can send information to Bob using HMAC, where Alice provides the segment or its identifier and associated information, such as the operation and operands in the message. HMAC techniques are known in the art, and Wikipedia (https: / / en.wikipedia.org / wiki / HMAC) provides a definition taken from RFC2104.

number

number

[0036] In such embodiments, the private key may be generated using any known technique, such as, but not limited to, those disclosed in WO 2017 / 145016 or the shared secret concepts and techniques described in https: / / en.wikipedia.org / wiki / Secret_sharing and https: / / en.wikipedia.org / wiki / Shared_secret. The use of such techniques may allow for automated processing, as described in more detail below.

[0037] Success or failure of the validation Upon receiving the Merkle root computed by Bob, in step 118 of Figure 5, Alice checks whether the value Bob provided matches her expectation of what R' should be. Note that if a piece of data is changed in any way, the resulting hash of that data will not be the same as the original hash. Thus, if a piece of data in block B is changed, the entire path and tree that piece is a part of will change, including the value of the Merkle root.

[0038] If, in step 120 of Figure 5, Bob's recomputed Merkle root value matches Alice's recomputed value, then the verification is considered successful and Bob is guaranteed that a) he still has a complete copy of D and b) he has not modified any part of D, since to perform a correct recomputation he needs a complete and unmodified copy of D. If, in step 119 of Figure 5, they do not match, then Alice and / or Bob can take some form of corrective or warning action.

[0039] The operations Alice chooses may be more complicated than the simple concatenation example used above, but they need not be. Because Bob does not know in advance which segments will be selected and which operations will be performed for the purposes of verification, it is not realistic for him to predict what Alice will ask of Bob in order to provide the necessary proofs.

[0040] Various options for storage of data D In another embodiment, the data is not stored in data blocks, but may be stored in any suitable alternative format, in any suitable medium, and in any suitable structure. What is important is that there must be a way for Alice to identify and uniquely reference a particular segment of data, so that she can communicate to Bob which segment the verification operation should be performed on. Similarly, Bob must be able to interpret Alice's reference and be able to access the specified segment from his storage resources. For example, Bob may store the data on a contiguous storage such as a tape, and Alice may reference the segment by byte number starting with byte number 0, which is the first byte written to the tape. In another variation, the data may be stored in a linked list, a DHT, a distributed database. The storage of the data may be distributed across multiple physical and / or logical storage devices. For convenience, reference is made herein to the storage of data in blocks, but this should be taken to mean any suitable method of storing data such that portions of the data may be identified and / or specified. Preferably, the selected storage method and structure is configured to be capable of including a header segment or sub-portion to facilitate the embodiments disclosed herein that require the use of a header H.

[0041] In some embodiments, Bob stores Alice's original block B of the segmented data item D off-chain in storage device 3, as shown in Figure 6. Data can be stored on the blockchain in a variety of ways, but such approaches may not always be the desirable or most efficient solution, depending on the requirements and constraints of a particular implementation. Therefore, for efficiency in processing time, resources, and fees, it may be desirable to store block B in an off-chain storage resource, such as storage 3 in Figure 6.

[0042] However, scenarios may arise where the original state of block B needs to be verified. For example, Alice and Bob may disagree about what Alice sent to Bob, or a third party may want to verify that the copy Bob stores actually matches Alice's original data item. In other words, the authenticity of the original data item D needs to be verified. To solve this problem, the preferred embodiment includes a step in which the header H of block B is written into a transaction (Tx) and the Merkle root of the tree T of the original block B is written into the ledger of the blockchain 4 (see FIG. 6).

[0043] Simplified Payment Verification (SPV) The disclosed embodiments allow the header H of a block to function as an SPV-style marker or reference for a data block. As is known in the field of blockchain transactions, SPV can use the Merkle tree structure built into the blockchain block to simplify the transaction verification process and reduce the amount of storage and processing resources required. Instead of storing a full copy of the blockchain, a verifier can prove that a target transaction (Tx) is within a particular block as long as the verifier knows the block's Merkle root and enough information to calculate a path to the target transaction. This is advantageous for devices with limited resources, such as digital wallets running on small devices. Further background information can be found in the field, for example, https: / / medium.com / coinmonks / spv-proofs-explained-f38f8bb8f580.

[0044] Similarly, FIG. 8 shows the sample segment {m 1 , m 2 , m 3 , m 41 illustrates a Merkle tree that may be used in accordance with an embodiment of the present disclosure, including:} Just as traditional SPV-style verification allows a verifier to minimize storage and processing, the present disclosure allows Alice to compute the Merkle root of a Merkle tree using only the minimum number of required data items, as long as she selects her sample segments appropriately.

[0045] As an example, assume that Alice’s data is represented by the Merkle tree T shown in Figure 8. Alice has access to the sample segments {m 1 , m 2 , m 3 , m 4}. Alice does not need to store the segments shown by the solid or dotted black lines, only the selected samples, because she m 1 and m 2 hash it to c 1 Can you calculate Next, c 1 and m 3 hash it to c 2 We can calculate Next, c 2 and m 4 This is because we can hash T to compute the Merkle root R of T.

[0046] It is therefore clear that this technique provides significant technical advantages, including, but not limited to, increased speed and efficiency in performing validation and security processing. However, it should be noted that while providing the same technical advantages as traditional style SPV, the embodiments of the present disclosure operate in a completely different manner to achieve those results. In traditional SPV approaches, the Merkle root is known, and the verifier makes a path downward from the root, proving whether the target transaction exists at a lower level. In contrast, the embodiments of the present disclosure allow the verifier to start at a lower level and work upwards toward the computed Merkle root, which is then used to determine the success or failure of the validation.

[0047] As described above, in use, Alice and Bob can exchange messages via any suitable communication method to transmit the information required for a particular validation request. The verifier (Bob) can perform off-chain validation checks. The process can be partially or fully automated and / or configured to operate at least partially over the blockchain. Embodiments of the blockchain implementation can be configured to include locking mechanisms, such as nLocktime-based conditions, so that blockchain transactions can be exchanged between Alice and Bob and later settled using SPV.

[0048] Enabling third-party data verification requests Advantageously, embodiments of the present disclosure allow verification to be requested by Alice herself or by another entity. We refer to this third party as Carol. For example, Alice can delegate or authorize the verification to Carol, who may be, for example, a third-party auditor or any entity (human, organizational, or machine-based) that requires verification of the existence and authenticity of Alice's stored data. Alice can transmit or share the secret to Carol using any suitable technique, such as those disclosed in WO 2017 / 145016. Carol can use the secret to request a verification proof from Bob by incorporating the use of the shared secret in the operations used to modify selected segments or replace them with different versions. Although the present disclosure is not limited to use for secret sharing, the techniques disclosed in WO 2017 / 145016 may be advantageously used since two parties can generate a shared secret independently of each other. Thus, the transmission of the secret and its potential interception in transit can be avoided. This provides added security because if an unauthorized party were to learn the secret, they could potentially identify information that would help them predict or determine what computations Bob needs to perform.

[0049] Advantageously, Alice does not need to give Carol access to the entire data storage (such as the entire server or disk) if Carol only needs to verify certain items in that storage space. Instead, she can send various data items to Bob (and possibly other service providers) in separate blocks and ask him to store each of the blocks according to the embodiments described herein. When Carol requests verification, Bob can provide the necessary proof only for the specific data items in the relevant blocks. Thus, embodiments allow delegation / authorization of third-party verification for specific data items, improving or at least protecting data privacy, and ring-fencing the storage of data, enhancing the security of other data items and / or storage resources.

[0050] Update data item D - record incremental changes Over time, a data item D may change, evolve, or be updated. For example, an original document such as a "will" may change depending on the age of the testator, a musical arrangement may change to suit popular styles, or software may be modified to fix bugs. There are many reasons why a data item may need to be changed or updated from its original form, so a technical solution is needed on how to capture and verifiably record such changes to a data item. In such cases, the following must be captured and verified: Changes made to the original, and / or The time when the adaptation took place.

[0051] Consider a scenario in which Alice modifies at least one segment of data stored in block B. Call the updated version B'. According to one embodiment, the incremental change or modification is recorded by Alice or a third party by specifying to Bob that one or more specific sub-parts should be modified. Bob should record details such as the nature, time, and format of the change, and the differences between the existing and new versions. In one embodiment, this is done by recording an initial transaction (Tx 0 ) (including the header of block B) to the subsequent transaction (Tx 1 This can be achieved by writing a transaction to the blockchain, recording an on-chain “update” link or reference to the Tx 1 contains a modified version of at least one segment of block B, or a reference / pointer / link to where the updated and modified segment or a full copy of B' is located. Alice can communicate to Bob that the state of block B has changed using any appropriate method. Bob can access the modified segment from a location specified by Alice, or Alice can communicate the relevant segments to Bob in any appropriate method of her choosing. The advantage of using a blockchain is that it provides an immutable, auditable, and time-stamped record of changes.

[0052] Alternatively, or in addition, Bob can detect that block B has been modified. This can be achieved in a variety of ways. For example, an automated process can be used to monitor and detect the state of the data. One way to do this is to use an automated DFA, such as the technique disclosed in WO 2018 / 078584. Bob can then access the modified (i.e., changed) segments from a location specified by Alice, or Alice can communicate the relevant segments to Bob in any suitable manner of her choosing.

[0053] Various combinations of such embodiments can be devised depending on the needs of a particular scenario. For example, when only minor changes are made to the data, Alice can include the modified segment in the blockchain transaction, and Bob can access it from the transaction (copy, download, etc.). Alice can embed the data in the transaction (Tx) in various ways, such as including the modified data segment as metadata in the script associated with the unspent output (UTXO). The new data can be included in the script in a location designated as the location of the cryptographic key by the protocol associated with the blockchain. This is the approach disclosed in WO 2018 / 078584. Alternatively, or in addition, the data can be included in the script after the OP_RETURN statement, and can be included using a tokenized digital asset, including a hash of a reference to the data, or using a compressed, encoded, abbreviated, summarized, and / or condensed version. For example, the changes may be provided in such a way that Bob can estimate or calculate the changes by unzipping a file, performing a function or applying a process on the original data, or other known techniques for deriving the desired output, such as the modified data.

[0054] According to another variation of the embodiment, when Alice updates the data D, the original transaction Tx 0 A blockchain transaction that uses Tx is generated. "Using a transaction" means "using at least one UTXO of the transaction," which is easily understood by those skilled in the art. 0 transfers one or more digital assets to a second transaction, Tx 1 In some embodiments, an encryption key controlled by Alice, Bob, and / or a third party may be used to forward the encrypted data to the input of Tx 1 This may be required to unlock assets transferred to.

[0055] Thus, embodiments provide the ability to record changes to stored data and ensure that related but different versions of data are linked in a verifiable way, potentially using cryptographic timestamps. This ensures the integrity of the data in its latest form, and new versions of the data can be trusted, verified and certified. Thus, embodiments of the present invention provide an improved approach to ensure the integrity of data, which allows it to be used by other applications further "downstream" in technical processes that need to utilize that data in some way. For example, critical systems involving safety and security may need to be able to rely on the integrity of the data they use as input to their processes.

[0056] Automated Implementation In some circumstances, it may be advantageous to automate the processes described herein. This not only relieves Alice or Bob of the burden of performing parts of the processes, but also allows the processes to be delegated to third-party resources to easily utilize different hardware / software architectures. It also allows for the separation or partitioning of technical processes, enhancing security. For example, automated resources (sometimes called "oracles," "bots," or "smart contracts") can operate to perform the steps of the disclosed techniques without the need for manual human intervention. Such automated resources, which we will refer to as "agents" for ease of reference, may be software-implemented entities running on one or more hardware devices, each of which includes at least one processor.

[0057] Consider a scenario in which Alice enters into a 12-month contract with Bob, and Bob stores Alice's data on her behalf. Alice can automate the execution of the contract by determining the validation proofs for each month. Alice can determine multiple Merkle roots in advance and use them in scheduled validation sessions, requiring Bob to provide the correct proofs.

[0058] In such a scenario, Alice pre-computes several different variations of R'. Alice selects or identifies different modifications to the data and computes a respective Merkle path and root for each. For example, Alice selects or pre-determines at least one operation (f), at least one operand of the operation, and / or at least one segment on which the operation is performed or used. Alice then computes and records a Merkle root for each of the various modifications. With reference to FIG. 5, this embodiment involves selecting multiple operations and / or segments in step 114, and then repeating the computations of step 115 for each new Merkle tree T' having the output Y of operation f. Assume the tree shown in FIG. 7 is a Merkle tree T representing Alice's data block B. Each node of the tree is a segment of data D. Alice selects segment m as a sample segment. 1 and m 4 Suppose you select and .

[0059] Then, perform the operation on each segment. 1 Perform a bitwise XOR operation on m 1 Then use a second mask to change m 4 Suppose you want to perform the same operation on . For example:

number

[0060] She is m 1 The Merkle root of the new tree obtained by the operation on m 4 We can then compute the Merkle root of the new tree resulting from the operation on . She stores these two computed Merkle roots.

[0061] A blockchain transaction can then be set up that specifies the various segments selected and their respective masks, allowing Bob to know what he is being asked to calculate. The transaction can be constructed with a time-lock mechanism that reveals the next required calculation at a desired time. For example, Alice can use different sample segments and / or masks to calculate 12 different Merkle roots, each available to Bob at the end of each month. Bob can respond to Alice each month by providing verification with an HMAC such as: HMAC 1 (MerkleRoot 1 , Secret 1 ) HMAC 2 (MerkleRoot 2 , Secret 2 ) etc.

[0062] Thus, Alice predetermines multiple validation challenges that are provided to Bob via the blockchain using an automated system. Bob receives payment for storage services from Alice upon successful validation at the end of each period. Smart contracts can be used to monitor or enforce the performance of these steps.

[0063] The contents of International Applications PCT / IB2017 / 050856, PCT / IB2017 / 056696, and PCT / IB2017 / 050819 are incorporated herein in their entireties.

[0064] Exemplary System Overview Above, certain (but not all) embodiments involving the use of or interaction with a blockchain are described. Here, we describe an example system that can be used to implement such embodiments. In accordance with standard terminology, the following refers to "Alice" and "Bob," but note that the use of these terms in the following overview is not tied to the use of the same names in the previous section. The following is related to Figures 1 through 4. The following refers to the Bitcoin network, but a) the term "Bitcoin" is intended to include all variations or deviations of the original Bitcoin protocol; b) any reference herein to the Bitcoin blockchain / protocol / network is for illustrative purposes only, and the disclosure is not intended to be limited in this respect. Non-Bitcoin blockchains / protocols / networks may be used to implement, and are included within the scope of, one or more embodiments of the disclosure.

[0065] The term "blockchain" refers to a form of distributed data structure in which a duplicate copy of the blockchain is maintained at each of multiple nodes in a distributed peer-to-peer (P2P) network (hereafter referred to as the "blockchain network") and made publicly available. The blockchain consists of a chain of blocks of data, with each block consisting of one or more transactions. Each transaction, other than the so-called "coinbase transaction", points to the previous transaction in a sequence spanning one or more blocks that traces back to one or more coinbase transactions. Coinbase transactions are described in more detail below. Transactions submitted to the blockchain network are included in new blocks. New blocks are created by a process often called "mining", in which each of multiple nodes compete to perform a "proof of work" - that is, to solve a cryptographic puzzle based on a representation of a predefined set of ordered and validated pending transactions that are waiting to be included in a new block of the blockchain. Note that the blockchain may be pruned at some nodes, and publication of a block can be achieved by publishing only the block header.

[0066] Transactions in a blockchain can be used for one or more of the following purposes, such as to convey digital assets (i.e., a number of digital tokens), to order a set of entries in a virtualized ledger or registry, to receive and process timestamp entries, and / or to chronologically order index pointers. A blockchain can also be used to layer additional functionality on top of the blockchain. For example, blockchain protocols allow additional user data or indexes to be stored on data within a transaction. Since there is no pre-specified 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 and video data on the blockchain.

[0067] Nodes in a blockchain network (often called "miners") perform a distributed transaction registration and validation process, which is described in more detail below. In summary, during this process, nodes validate transactions and insert them into a block template in an attempt to identify a valid proof-of-work solution. Once a valid solution is found, a new block is propagated to other nodes in the network, allowing each node to record the new block in the blockchain. To record a transaction in the blockchain, a user (e.g., a blockchain client application) submits the transaction to one of the nodes in the network, which propagates it. Nodes that receive the transaction may compete to find a proof-of-work solution that will incorporate the validated transaction into a new block. Each node is configured to apply the same node protocol, which includes one or more conditions for a transaction to be valid. Invalid transactions are not propagated or incorporated into blocks. Once a transaction is validated and accepted into the blockchain, the transaction (including the user data) remains registered and indexed with each node in the blockchain network as an immutable public record.

[0068] The node that solves the proof-of-work puzzle and creates the latest block is rewarded with a new transaction, called a "coinbase transaction," which typically distributes a fixed amount of digital assets, or number of tokens. The detection and rejection of invalid transactions is performed by the actions of competing nodes, who act as agents of the network and are incentivized to report and block misconduct. Widely published information allows users to continuously audit node performance. By publishing only block headers, participants can ensure the ongoing integrity of the blockchain.

[0069] In the “output-based” model (sometimes called the UTXO-based model), the data structure of a particular transaction consists of one or more inputs and one or more outputs. A usable output consists of an element that specifies the amount of digital assets obtained from a series of transactions. A usable output is sometimes called a UTXO (or “unspent transaction output”). An output may also include a locking script that specifies the future redemption conditions of the output. A locking script is a predicate that defines the conditions required to validate and transfer a digital token or asset. Each input of a transaction (other than a coinbase transaction) includes a pointer (i.e., a reference) to such an output of a preceding transaction and may further include an unlocking script to unlock the locking script of the pointed output. Now consider a pair of transactions, which we call the first transaction and the second transaction (or “target” transaction). The first transaction includes at least one output that includes a locking script that specifies the amount of digital assets and defines one or more conditions to unlock the output. The second target transaction consists of at least one input that includes a pointer to an output of the first transaction and an unlocking script to unlock the output of the first transaction.

[0070] In such a model, when a second target transaction is submitted to the blockchain network to be propagated and recorded in the blockchain, one validity criterion applied by each node is that the unlocking script meets all of one or more conditions defined in the locking script of the first transaction; another is that the output of the first transaction has not yet been redeemed by another previous valid transaction. A node that determines that the target transaction is invalid based on any of these conditions will not propagate it (potentially registering it as an invalid transaction rather than as a valid transaction) and will not include it in any new block recorded in the blockchain.

[0071] Another type of transaction model is the account-based model, where each transaction defines the amount to transfer by referring to the absolute balance of the account, rather than by referring to the UTXO of the previous transaction in the sequence of past transactions. The current state of every account is stored in a node separate from the blockchain and is constantly updated.

[0072] Returning now to Figures 1-4, Figure 1 illustrates an exemplary system 100 for implementing a blockchain 150. The system 100 may comprise a packet-switched network 101, typically a wide area internetwork such as the Internet. The packet-switched network 101 includes a number of blockchain nodes 104 that may be configured to form a peer-to-peer (P2P) network 106 within the packet-switched network 101. Although not illustrated, the blockchain nodes 104 may be configured as a near-complete graph. Thus, each blockchain node 104 is highly connected to the other blockchain nodes 104.

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

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

[0075] Each block 151 also contains a block pointer 155 that points to a previously created block 151 in the chain, defining an order for the blocks 151. Each transaction 152 (other than a coinbase transaction) contains a pointer to a previous transaction, defining an order for the sequence of transactions (Note: the sequence of transactions 152 is allowed to branch). The chain of blocks 151 dates back to a genesis block (Gb) 153, which was the first block in the chain. One or more original transactions 152 earlier in the chain 150 pointed to the genesis block 153 rather than to a preceding transaction.

[0076] Each of the blockchain nodes 104 is configured to forward transactions 152 to other blockchain nodes 104, thereby propagating the transactions 152 throughout the network 106. Each blockchain node 104 is configured to create blocks 151 and store a respective copy of the same blockchain 150 in its respective memory. Each blockchain node 104 also maintains an ordered set (or "pool") 154 of transactions 152 waiting to be incorporated into a block 151. The ordered pool 154 is often referred to as a "mempool." This term herein is not intended to be limited to any particular blockchain, protocol, or model. It refers to the ordered set of transactions that the node 104 has accepted as valid, for which the node 104 is obligated not to accept any other transactions that attempt to consume the same output.

[0077] For a given current transaction 152j, its (or each) input contains a pointer that references 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. In general, the preceding transaction can be any transaction in the ordered set 154 or any block 151. The preceding transaction 152i does not necessarily have to exist at the time the current transaction 152j is created or even sent to the network 106, but the preceding transaction 152i must exist and be validated for the current transaction to be valid. Thus, "preceding" in this specification refers to a preceding element in a logical sequence linked by a pointer, not necessarily at the time of creation or transmission in the temporal sequence, and therefore does not necessarily exclude transactions 152i, 152j from being created or transmitted out of sequence (see the discussion below regarding orphan transactions). The preceding transaction 152i can equally be referred to as a previous transaction or a preceding transaction.

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

[0079] According to an output-based transaction protocol such as Bitcoin, when a party 103, such as an individual user or an organization, wants to enact a new transaction 152j (either manually or by an automated process adopted by the party), the enacting party sends the new transaction from its computer terminal 102 to a recipient. The enacting party or recipient will eventually send this transaction to one or more of the blockchain nodes 104 of the network 106 (currently typically a server or a data center, but in principle it could be other user terminals). It is also not excluded that the party 103 enacting the new transaction 152j sends this transaction directly to one or more of the blockchain nodes 104 and in some examples does not send it to a recipient. The blockchain nodes 104 that receive the transaction check whether the transaction is valid according to the blockchain node protocol applied at each of them. The blockchain node protocol typically requires that the blockchain nodes 104 check that the cryptographic signature in the new transaction 152j matches an expected signature, which depends on the previous transaction 152i in the ordered sequence of transactions 152. In such output-based transaction protocols, this may involve checking that a cryptographic signature or other authorization of party 103 included in the input of the new transaction 152j matches a condition defined in the output of the previous transaction 152i that the new transaction assigns, which typically involves at least checking that the cryptographic signature or other authorization in the input of the new transaction 152j unlocks the output of the previous transaction 152i to which the input of the new transaction is linked. This condition may be defined at least in part by a script included in the output of the previous transaction 152i. Alternatively, it may simply be fixed by the blockchain node protocol alone, or result from a combination of these.In any case, if the new transaction 152j is valid, the blockchain node 104 forwards it to one or more other blockchain nodes 104 in the blockchain network 106. These other blockchain nodes 104, following the same blockchain node protocol and applying the same tests, forward the new transaction 152j to one or more further nodes 104, and so on. In this manner, the new transaction is propagated throughout the network of blockchain nodes 104.

[0080] In the output-based model, the definition of whether a given output (e.g., UTXO) has been allocated (e.g., spent) is whether it has still been validly redeemed by the input of another, forward transaction 152j according to the blockchain node protocol. Another condition for a transaction to be valid is that the output of the preceding transaction 152i that it attempts to redeem has not yet been redeemed by another transaction. Again, if it is not valid, the transaction 152j is not propagated (unless it is flagged as invalid and propagated due to a warning) or recorded in the blockchain 150. This protects against double spending, where a transaction executor tries to allocate the output of the same transaction multiple times. On the other hand, the account-based model prevents double spending by maintaining an account balance. Again, since there is a defined order of transactions, the account balance has a single defined state at any point in time.

[0081] In addition to validating transactions, blockchain nodes 104 compete to be the first to create a block of transactions in a process commonly referred to as mining, supported by "proof of work." At the blockchain nodes 104, new transactions are added to an ordered pool 154 of valid transactions that have not yet appeared in a block 151 recorded on the blockchain 150. The blockchain nodes then compete to assemble a new valid block 151 of transactions 152 from an ordered set of transactions 154 by attempting to solve a cryptographic puzzle. Typically, this involves searching for a "nonce" value such that when the nonce is concatenated with a representation of the ordered pool of pending transactions 154 and hashed, the output of the hash satisfies a predefined condition. For example, the predefined condition could be that the output of the hash has a certain predefined number of leading zeros. This is just one particular type of proof of work puzzle, others are not excluded. A property of a hash function is that it has an unpredictable output for an input. Therefore, this search can only be performed by brute force, thus consuming a significant amount of processing resources at each blockchain node 104 attempting to solve the puzzle.

[0082] The first blockchain node 104 that solves the puzzle publishes this to the network 106, providing the solution as a proof that other blockchain nodes 104 in the network can easily check (given the hash solution, it is easy to check that it matches the hash output). The first blockchain node 104 propagates the block to a threshold consensus of other nodes that accept the block, thus enforcing the protocol rules. The ordered set of transactions 154 then becomes recorded as a new block 151 in the blockchain 150 by each of the blockchain nodes 104. A block pointer 155 is also assigned to the new block 151n that points to a previously created block 151n-1 in the chain. The significant amount of effort, e.g., in the form of a hash, required to create the proof-of-work solution signals the first node 104's willingness to follow the rules of the blockchain protocol. Such rules include not accepting a transaction as valid if it assigns the same output as a previously validated transaction, otherwise known as double spending. Once created, blocks 151 cannot be modified because they are known and maintained by each of the blockchain nodes 104 in the blockchain network 106. Block pointers 155 also impose an order on blocks 151. This therefore provides an immutable public ledger of transactions, as transactions 152 are recorded in ordered blocks at each blockchain node 104 in the network 106.

[0083] Note that different blockchain nodes 104 competing to solve the puzzle at any given time may do so based on different snapshots of the pool of transactions 154 that are not yet published at any given time, depending on when they started looking for a solution or the order in which the transactions were received. The first to solve each puzzle defines which transactions 152 will be included in the next new block 151n and in what order, and the current pool of unpublished transactions 154 is updated. The blockchain nodes 104 then compete to create blocks from the newly defined ordered pool of unpublished transactions 154, and so on. There is also a protocol to resolve any "forks" that may occur, which is when two blockchain nodes 104 solve the puzzle within such a short time of each other that opposing views of the blockchain are propagated between the nodes 104. In essence, whichever branch of the fork grows the longest becomes the definitive blockchain 150. Note that this should not affect users or agents of the network when the same transaction appears in both forks.

[0084] According to the Bitcoin blockchain (and most other blockchains), a node that successfully constructs a new block 104 is granted the ability to allocate a new additional accepted amount of digital assets in a new special type of transaction that distributes an additional defined amount of digital assets (as opposed to an agent-to-agent or user-to-user transaction that transfers digital assets from one agent or user to another). This special type of transaction is usually referred to as a "coinbase transaction," but may also be called an "initiation transaction" or "generation transaction." It typically forms the first transaction of a new block 151n. The proof of work signals the intention of the node constructing the new block to follow protocol rules that allow this special transaction to be redeemed later. Blockchain protocol rules may require a redemption period, e.g., 100 blocks, before this special transaction can be redeemed. Often, a regular (non-generating) transaction 152 also specifies an additional transaction fee in one of its outputs to further reward the blockchain node 104 that created the block 151n in which the transaction was published. This fee is commonly referred to as a "transaction fee" and is explained below.

[0085] Due to the resources involved in validating and publishing transactions, typically at least each of the blockchain nodes 104 takes the form of a server including one or more physical server units, or even an entire data center. However, in principle, any given blockchain node 104 can also take the form of a user terminal or a group of networked user terminals.

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

[0087] Also connected to the network 101 are computer devices 102 of each of a number of parties 103 who assume the role of consuming users. These users may interact with the blockchain network 106 but do not participate in validating transactions or constructing 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 copies of the blockchain 150 (e.g., having obtained a copy of the blockchain from a blockchain node 104).

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

[0089] The computer equipment 102 of each party 103 comprises a respective processing device including one or more processors, e.g., one or more CPUs, GPUs, other accelerator processors, application specific processors, and / or FPGAs. The computer equipment 102 of each party 103 further includes a memory, i.e., a computer readable storage device in the form of a non-transitory computer readable medium. This memory may include one or more memory units employing one or more memory media, e.g., a magnetic medium such as a hard disk, an electronic medium such as a SSD, a flash memory, or an EEPROM, and / or an optical medium such as an optical disk drive. The memory on the computer equipment 102 of each party 103 stores software including a respective instance of at least one client application 105 configured to execute on the processing device. It will be understood that any activity attributed to a given party 103 herein may be performed using software executed on the processing device of the respective computer equipment 102. The computer equipment 102 of each party 103 includes at least one user terminal, e.g., a desktop or laptop computer, a tablet, a smartphone, or a wearable device such as a smart watch. The computing 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.

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

[0091] The client application 105 has at least a "wallet" function. It has two main functionalities. One of these is to allow each party 103 to create, authorize (e.g., sign), and send transactions 152 to one or more Bitcoin nodes 104 for subsequent propagation throughout the network of blockchain nodes 104 and thereby inclusion in the blockchain 150. The other is to report to each party the amount of digital assets it currently owns. In an output-based system, this second function involves reconciling amounts belonging to the party of interest as determined in the outputs of various transactions 152 scattered throughout the blockchain 150.

[0092] NOTE: Although various client functions may be described as being integrated into a given client application 105, this is not necessarily limiting, and instead any client functionality described herein may instead be implemented as a set of two or more different applications, for example, interfaced via an API or plugged into one another. More generally, client functionality may also be implemented at the application layer, or at a lower layer such as an operating system, or any combination of these. While the following will describe client application 105, it will be understood that this is not limiting.

[0093] An instance of a client application or software 105 on each computing device 102 is operatively coupled to at least one of the blockchain nodes 104 of the network 106. This allows the wallet function of the client 105 to send transactions 152 to the network 106. The client 105 can also contact the blockchain nodes 104 to query the blockchain 150 for any transactions in which the respective party 103 is a recipient (or indeed to inspect the transactions of other parties in the blockchain 150, since in an embodiment the blockchain 150 is a public facility that provides trust to transactions in part through its public visibility). The wallet function on each computing device 102 is configured to formulate and send transactions 152 according to a transaction protocol. As noted above, each blockchain node 104 executes software configured to validate transactions 152 according to a blockchain node protocol and forward transactions 152 for propagation throughout the blockchain network 106. The transaction protocol and the node protocol correspond to each other, and a given transaction protocol goes with a given node protocol and together implement a given transaction model. The same transaction protocol is used for all transactions 152 in the blockchain 150. The same node protocol is used by all nodes 104 in the network 106.

[0094] When a given party 103, say Alice, wants to send a new transaction 152j to be included in the blockchain 150, Alice formulates the new transaction (using the wallet functionality of Alice's client application 105) according to the relevant transaction protocol. Alice then sends the transaction 152 from her client application 105 to one or more blockchain nodes 104 to which she is connected. For example, this could be the blockchain node 104 that is most connected to Alice's computer 102. When any given blockchain node 104 receives a new transaction 152j, it processes it according to the blockchain node protocol and its respective role. This involves first checking whether the newly received transaction 152j satisfies certain conditions to be "valid", examples of which will be explained in more detail shortly. In some transaction protocols, the conditions for validity checking may be configurable per transaction by a script included in the transaction 152. Alternatively, this condition could simply be a built-in feature of the node protocol or be defined by a combination of the script and the node protocol.

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

[0096] After being admitted into the ordered pool of pending transactions 154 maintained by a given blockchain node 104, that blockchain node 104 starts a race to solve a proof-of-work puzzle with the latest version of each pool 154 that contains the new transaction 152. (Recall that other blockchain nodes 104 may be trying to solve the puzzle based on different pools of transactions l54, but whoever gets there first defines the set of transactions included in the latest block 151. Eventually, the blockchain node 104 will have solved the puzzle for the part of the ordered pool 154 that contains Alice's transaction 152j.) After the proof-of-work is done for the pool 154 that contains the new transaction 152j, it immutably becomes part of one of the blocks 151 in the blockchain 150. Each transaction 152 contains a pointer to the previous transaction, so the order of the transactions is also immutably recorded.

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

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

[0099] UTXO-based model FIG. 2 illustrates an example of a transaction protocol. This is an example of a UTXO-based protocol. A transaction 152 (abbreviated as "Tx") is a fundamental data structure of a blockchain 150 (each block 151 contains one or more transactions 152). The following is described with reference to an output-based or "UTXO"-based protocol. However, this is not limited to all possible embodiments. It should be noted that the exemplary UTXO-based protocol is described with reference to Bitcoin, but could equally be implemented on other exemplary blockchain networks.

[0100] In the UTXO-based model, each transaction ("Tx") 152 comprises a data structure that includes one or more inputs 202 and one or more outputs 203. Each output 203 may include an unspent transaction output (UTXO) that may be used as a source of input 202 for another new transaction (if the UTXO has not yet been redeemed). The UTXO includes a value that specifies an amount of a digital asset. This represents a set number of tokens on the distributed ledger. The UTXO may also include, among other information, the transaction ID of the transaction from which it originated. The transaction data structure may also include a header 201 that may include indicators of the sizes of the input fields 202 and the output fields 203. The header 201 may also include 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 the node 104.

[0101] For example, Alice 103a wishes to create a transaction 152j that transfers an amount of a digital asset of interest to Bob 103b. In FIG. 2, Alice’s new transaction 152j begins with “Tx 1" which takes the amount of digital assets locked in Alice in the output 203 of the previous transaction 152i in the sequence and transfers at least a portion of it to Bob. The previous transaction 152i is labeled "Tx 0 " Tx 0 and Tx 1 are just arbitrary labels. They do not necessarily correspond to Tx 0 is also the first transaction on blockchain 151. 1 It does not mean that Tx is the next transaction in the pool 154. 1 may also refer to any preceding (i.e., previous) transaction that still has unspent outputs 203 locked to Alice.

[0102] Preceding transaction Tx 0 Alice creates a new transaction Tx 1 By the time Tx is created, or at least by the time it is sent to the network 106, it may already have been validated and included in a block 151 of the blockchain 150. It may already be included in one of the blocks 151 at that point, or may still be waiting in the ordered set 154, in which case it will be included in the new block 151 shortly. Alternatively, Tx 0 and Tx 1 may be created together and sent together to the network 106, or Tx 0 Tx if the node protocol allows for buffering of "orphan" transactions 1It is even possible that a transaction may be sent after a previous transaction. The phrases "preceding" and "successor" as used herein in the context of a sequence of transactions refer to the order of the transactions in the sequence as defined by the transaction pointers specified in the transaction (which transaction points to which other transaction, etc.). They may equally be replaced with "predecessor" and "successor", or "predecessor" and "descendant", "parent" and "child", or the like. This does not necessarily imply the order in which they are created, sent to the network 106, or arrive at any given blockchain node 104. Nevertheless, a subsequent transaction (descendant transaction or "child") that points to a previous transaction (previous transaction or "parent") is not validated until and unless the parent transaction is validated. A child that arrives at a blockchain node 104 before its parent is considered an orphan. It may be discarded or buffered for a period of time to await the parent, depending on the node protocol and / or node behavior.

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

[0104] A lock script (also called scriptPubKey) is a piece of code written in a domain-specific language recognized by the node protocol. A particular example of such a language is called "Script" (capital S) used in blockchain networks. A lock script specifies the information required to consume a transaction output 203, for example the requirements for Alice's signature. An unlock script appears within the output of a transaction. An unlock script (also called scriptSig) is a piece of code written in a domain-specific language that provides the information required to satisfy the criteria of the lock script. For example, this may include Bob's signature. An unlock script appears within the input 202 of a transaction.

[0105] Therefore, in the illustrated example, Tx 0 The output 203 of UTXO0 must have Alice’s signature Sig P in order for UTXO0 to be redeemed (or, more precisely, for a subsequent transaction that attempts to redeem UTXO0 to be valid). A Requires lock script [Checksig P A ] is equipped. A ] is the public key P from Alice’s public-private key pair. A Contains a representation (i.e., a hash) of Tx 1 The input 202 of the Tx 1 A pointer to a transaction Tx 0 The transaction ID, TxID0, is a hash of the entire Tx 1 The input 202 of the Tx 0 To distinguish it from any other possible output of Tx 0 Contains an index that identifies UTXO0 within the Tx 1 The input 202 is an unlock script containing Alice's cryptographic signature, created by Alice applying the private key from her key pair to a predefined portion of data (sometimes called a "message" in cryptography). <Sig P AThe data (or "message") that needs to be signed by Alice to provide a valid signature may be defined by the lock script, or by the node protocol, or by a combination of these.

[0106] New transaction Tx 1 When the arrives at a blockchain node 104, the node applies the node protocol, which involves running the lock script and the unlock script together to check whether the unlock script satisfies the conditions defined in the lock script (where the conditions may include one or more criteria). In an embodiment, this involves concatenating the two scripts as follows: <Sig P A > <P A > || [Checksig P A ] Here, "||" represents concatenation, "<...>" means to put data on the stack, and "[...]" is a function that is constructed by lock script (a stack-based language in this example). Equivalently, scripts could be executed one after the other with a common stack, rather than concatenating the scripts. Either way, when executed together, the scripts will be executed in the order of Tx 0 Alice's public key P, as contained in the lock script in the output of A Using Tx 1 , the input of Tx contains Alice's signature, which signs the expected portion of the data. To perform this authentication, the expected portion of the data itself (the "message") must also be included. In an embodiment, the signed data is 1 (Thus, there is no need to include a separate element specifying the signed portion of the data in plaintext, since that is already inherently present).

[0107] The details of authentication with public-private cryptography will be familiar to those skilled in the art. Essentially, if Alice signs a message using her private key, then given Alice's public key and the plaintext message, another entity, such as node 104, can authenticate that the message must have been signed by Alice. Signing typically involves hashing the message, signing the hash, and tagging this as the signature to the message, so that anyone holding the public key can authenticate the signature. Thus, it should be noted that references herein to signing a particular data portion or part of a transaction, etc., may, in embodiments, mean signing a hash of that data portion or part of a transaction.

[0108] Tx 1 The unlock script is Tx 0 If it satisfies one or more conditions specified in the lock script of (so, in the illustrated example, Alice's signature is Tx 1 If provided and authenticated by Tx 1 This means that the blockchain node 104 considers Tx 1 The blockchain node 104 also adds the transaction Tx 1 to one or more other blockchain nodes 104 in the network 106, whereby it is propagated throughout the network 106. 1 After being validated and entered into the blockchain, this is called Tx 0 Define UTXO0 as spent from Tx 1 Note that Tx can only be valid if it consumes an unconsumed transaction output 203. If it attempts to consume an output that has already been consumed by another transaction 152, Tx 1is invalid even if all other conditions are met. Therefore, the blockchain node 104 0 It is also necessary to check whether the UTXO referenced in has already been spent (i.e., whether it already forms a valid input to another valid transaction). This is one of the reasons why it is important for the blockchain 150 to impose a defined order on transactions 152. Indeed, a given blockchain node 104 may maintain a separate database that marks which UTXOs 203 have been spent in which transactions 152, but what ultimately defines whether a UTXO is spent is whether it already forms a valid input to another valid transaction in the blockchain 150.

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

[0110] Note that in the UTXO-based transaction model, a given UTXO must be spent in its entirety. It is not possible to "leave" part of the amount defined in the UTXO as spent while another part is being spent. However, the amount from a UTXO can be split among multiple outputs of subsequent transactions. For example, Tx 0 The amount defined in UTXO0 is Tx 1 Therefore, if Alice does not want to give Bob the entire amount defined in UTXO0, she can send the remainder as Tx 1 The second output of the can be used to give yourself change or to pay another party.

[0111] In practice, Alice would normally also need to include a fee for any Bitcoin node 104 that successfully puts her transaction 104 into a block 151. If Alice does not include such a fee, Tx 0 will be rejected by the blockchain node 104 and therefore, although technically valid, will not be propagated and included in the blockchain 150 (the node protocol does not force blockchain nodes 104 to accept a transaction 152 if they do not want to do so). In some protocols, the transaction fee does not require its own separate output 203 (i.e., it does not require a separate UTXO). Instead, any difference between the total amount pointed to by the input 202 and the total amount specified in the output 203 of a given transaction 152 is automatically given to the blockchain node 104 that publishes the transaction. For example, a pointer to UTXO0 is 1 Only input to Tx 1 has only one output UTXO1. If the amount of the digital asset specified in UTXO0 is greater than the amount specified in UTXO1, the difference may be allocated by the node 104 that won the proof-of-work race to create the block containing UTXO1. However, it is not necessarily excluded that a transaction fee could alternatively, or in addition, be explicitly specified in one of the UTXOs 203 of transaction 152 itself.

[0112] Alice and Bob's digital assets consist of the UTXOs locked to them in any transaction 152 anywhere in the blockchain 150. Thus, typically, a given party's 103 assets are scattered throughout the UTXOs of various transactions 152 throughout the blockchain 150. There is no one number stored anywhere in the blockchain 150 that defines a given party's 103 total balance. It is the role of the wallet function in the client application 105 to collate together the values ​​of all the various UTXOs locked to each party that have not yet been spent in another onward transaction. This can be done by querying a copy of the blockchain 150 as stored in any of the Bitcoin nodes 104.

[0113] Note that script code is often expressed generally (i.e., without using a precise language). For example, an operation code (opcode) may be used to express a particular function. "OP_..." refers to a particular opcode in the Script language. As an example, OP_RETURN is an opcode in the Script language that, when preceded by OP_FALSE at the beginning of the lock script, creates a non-consumable output of the transaction that can store data within the transaction, thereby immutably recording the data in the blockchain 150. For example, the data may include a document that is desired to be stored in the blockchain.

[0114] Typically, the input for a transaction is a public key P AIn an embodiment, this is based on ECDSA using the elliptic curve secp256k1. The digital signature signs certain 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 parts of the outputs it signs depend on the SIGHASH flag, which is typically a four-byte code included at the end of the signature that selects which outputs are signed (and thus fixed at the time of signing).

[0115] The lock script may be referred to as a "scriptPubKey", referring to the fact that it typically includes the public key of the party for whom the respective transaction is locked. The unlock script may be referred to as a "scriptSig", referring to the fact that it typically provides a corresponding signature. However, more generally, in all applications of the blockchain 150, it is not essential that the condition for a UTXO to be redeemed includes authenticating the signature. More generally, the scripting language may be used to define any condition or conditions. Thus, the more general terms "lock script" and "unlock script" may be preferred.

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

[0117] The side channel 107 may be established over the same packet-switched network 101 as the blockchain network 106. Alternatively, or in addition, the side channel 301 may be established over a different network, such as a mobile cellular network, or a local area network, such as a local wireless network, or even over a direct wired or wireless link between Alice's device 102a and Bob's device 102b. In general, the side channel 107 referenced anywhere herein may include any one or more links over one or more network technologies or communication media for exchanging data "off-chain," i.e., separate from the blockchain network 106. When multiple links are used, the bundle or collection of off-chain links may be referred to as the side channel 107 as a whole. Thus, it should be noted that when Alice and Bob are said to exchange some information or data or the like over the side channel 107, this does not necessarily imply that all pieces of these data must be transmitted over the exact same link or the same type of network.

[0118] Client Software 3A illustrates an example implementation of a client application 105 for implementing an embodiment of the presently disclosed scheme. The client application 105 includes a transaction engine 401 and a user interface (UI) layer 402. The transaction engine 401 is configured to implement basic transaction-related functionality of the client 105, such as creating transactions 152, receiving and / or sending transactions and other data via side channels 301, and / or sending transactions to one or more nodes 104 (propagating through the blockchain network 106). These functions are performed according to the schemes described above and in more detail below.

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

[0120] NOTE: Although various functions herein are described as being integrated into the same client application 105, this is not necessarily limiting and instead may be implemented in a suite of two or more different applications, e.g. one may be a plug-in to the other and interface via an API (Application Programming Interface). For example, the functionality of the transaction engine 401 may be implemented in a separate application from the UI layer 402, and the functionality of a particular module such as the transaction engine 401 may be split between multiple applications. It is also not excluded that some or all of the described functionality may be implemented, for example, in the operating system layer. Where reference is made anywhere in this specification to a single application 105 or a particular application 105, etc., it will be understood that this is merely an example and that, more generally, the described functionality may be implemented in any form of software.

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

[0122] For purposes of illustration, Figure 3B shows the UI 500 from Alice's perspective. The UI 500 is composed of one or more UI elements 501, 502, 502 that are rendered as separate UI elements by a user output means.

[0123] For example, the UI elements may include one or more user-selectable elements 501, such as different on-screen buttons, or different options in a menu. User input means are arranged to allow a user 103 (in this case Alice 103a) to select or manipulate one of the options by clicking or touching the UI elements on the screen or by speaking the name of the desired option (Note: the term "manual" as used here is used only in contrast to automatic and is not necessarily limited to use of the hand).

[0124] Alternatively, or in addition, the UI elements may include one or more data entry fields 502 through which the user can interact, which are rendered via a user output means (e.g., on a screen) and data can be entered into the fields via a user input means (e.g., a keyboard or touch screen). Alternatively, data may be received verbally, for example based on speech recognition.

[0125] Alternatively, or in addition, the UI elements may include one or more information elements 503 that are output to output information to the user, which may be rendered on a screen or audio, for example.

[0126] It will be understood that the particular means of rendering the various UI elements, selecting options, and inputting data is not important. The functionality of these UI elements will be described in more detail below. Also, the UI 500 shown in FIG. 3 is only a stylized mockup and may in fact include one or more additional UI elements, which are not shown for the sake of simplicity.

[0127] Node Software FIG. 4 illustrates an example of node software 450 executed by each blockchain node 104 of the network 106 in an example UTXO-based or output-based model. Note that another entity may execute the node software 450 without being classified as a node 104 on the network 106, i.e., without performing the actions required for a node 104. The node software 450 includes, but is not limited to, a protocol engine 451, a script engine 452, a stack 453, an application-level decision engine 454, and a set of one or more blockchain-related function modules 455. Each node 104 may execute node software including, but not limited to, all three of the following: a consensus module 455C (e.g., proof of work), a propagation module 455P, and a storage module 455S (e.g., database). The protocol engine 401 is typically configured to recognize various fields of the transaction 152 and process them according to the node protocol. Another prior transaction 152i (Tx m-1 ) output (e.g. UTXO). j ) is received, the protocol engine 451 j The protocol engine 451 identifies the unlock script in the Tx j Based on the pointer in the input of Tx i Identify and obtain Tx i may have been published to the blockchain 150, in which case the protocol engine may derive Tx from a copy of the block 151 of the blockchain 150 stored in the node 104. i Alternatively, you can get Tx i It is possible that Tx has not yet been published to the blockchain 150. In that case, the protocol engine 451 may select Tx from the ordered set of unpublished transactions 154 maintained by the node 104. i In either case, the script engine 451 can obtain Tx iand passes it to the script engine 452.

[0128] Therefore, the script engine 452 has Tx i The lock script and the corresponding input Tx j For example, Figure 2 shows the unlock script from Tx 0 Transactions labeled X and Tx are shown, but the same applies to any transaction pair. Script engine 452 executes the two scripts together as described above. This includes putting data onto and retrieving data from stack 453 according to the stack-based scripting language being used (e.g., Script).

[0129] By executing the scripts together, script engine 452 determines whether the unlock script meets one or more criteria defined in the lock script (i.e., whether the lock script "unlocks" the output it is contained in). Script engine 452 returns the result of this determination to protocol engine 451. If script engine 452 determines that the unlock script meets one or more criteria specified in the corresponding lock script, it returns the result "true". Otherwise, it returns the result "false".

[0130] In the output-based model, a "true" result from the script engine 452 is one of the conditions for the validity of a transaction. Typically, one or more protocol-level conditions evaluated by the protocol engine 451 must also be satisfied. For example, Tx jThe protocol engine 451 evaluates the results from the script engine 452 and one or more protocol-level conditions, and only if all are true, does it accept the transaction Txt. j The protocol engine 451 outputs an indication of whether the transaction is valid to the application-level decision engine 454. j Only on condition that Tx is actually validated, the decision engine 454 controls both the consensus module 455C and the propagation module 455P to j , for incorporation into a block 151. This includes having the consensus module 455C select the nodes' respective ordered transaction sets 154 to be tagged with Tx j and a propagation module 455P transmits the Tx j Optionally, in embodiments, the application-level decision engine 454 can apply one or more additional conditions before triggering either or both of these functions. For example, the decision engine can choose to publish a transaction only on the condition that the transaction is valid and that sufficient transaction fees remain.

[0131] Also, the terms "true" and "false" here are not necessarily limited to returning a result represented in the form of a single binary digit (bit), although that is certainly one possible implementation. More generally, "true" refers to any state that indicates success or a positive outcome, and "false" refers to any state that indicates failure or a non-positive outcome. For example, in an account-based model, a "true" outcome might be indicated by a combination of an implicit protocol-level validation of a signature and an additional positive output of a smart contract (if both individual outcomes are true, then the overall outcome is considered to indicate true).

[0132] conclusion Other variations or uses of the disclosed technology will be apparent to those skilled in the art upon reading the disclosure herein. The scope of the disclosure is not limited by the described embodiments, but only by the appended claims. For example, some embodiments above are described with respect to the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin nodes 104. However, it will be understood that the Bitcoin blockchain is one particular example of the blockchain 150, and the above description is generally applicable to any blockchain. That is, the present invention is not limited to the Bitcoin blockchain. More generally, references to the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin nodes 104 above may be replaced with references to the blockchain network 106, the blockchain 150, and the blockchain nodes 104, respectively. The blockchains, blockchain networks, and / or blockchain nodes may share some or all of the described properties of the Bitcoin blockchain 150, the Bitcoin network 106, and the Bitcoin nodes 104, as described above.

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

[0134] In other embodiments of the present disclosure, the blockchain network 106 may not be the Bitcoin network. These embodiments do not preclude a node from performing at least one or some (but not all) of the functions of creating, publishing, propagating, and storing blocks 151 of the blockchain 150. For example, in other blockchain networks, a "node" may be used to refer to a network entity that is configured to create and publish blocks 151, but is configured not to store and / or propagate those blocks 151 to other nodes.

[0135] More generally, references above to the term "Bitcoin node" 104 may be replaced with the term "network entity" or "network element," where such entity / element is configured to perform some or all of the roles of creating, publishing, propagating, and storing blocks. The functionality of such network entities / elements may be implemented in hardware in the same manner as described above with reference to blockchain nodes 104.

[0136] Enumerated Statements It will be understood that the above embodiments have been described by way of example only. More generally, a method, an apparatus, or a program may be provided according to any of the following statements:

[0137] In statement 1 (alternatively 1.a through 1.h), the first entity may be Alice and / or the second entity may be Bob, or an entity authorized or directed by Alice / Bob acting on its behalf. The third entity may be Carol. Alice may keep the requested variation from Bob confidential before sending the request to Bob. The functionality described below with respect to any of statements 2 onwards may be incorporated into the alternative wording of any of statements 1.a through 1.h. In the subsequent statements, the term "request / requesting" may be replaced with "directing / directing / instructing".

[0138] Statement 1 (comprising Statement1.a to Statement1.h): 1.a A computer-implemented method is provided, the method comprising: requesting, by the first entity from the second entity, a root value (R') of a Merkle tree (T') computed based on at least one variation of a plurality of sub-portions of the portion of the data (D); and / or The method includes providing, from the second entity to the first entity, a root value (R') of a Merkle tree (T') calculated based on at least one variation of a plurality of sub-portions of a portion of the data (D).

[0139] 1.b Alternatively or additionally, there is provided a (computer-implemented) method, the method comprising: The method comprises the step of requesting, by the first entity from the second entity, a root value (R') of a Merkle tree (T') computed based on at least one variation of a plurality of sub-portions of a portion of the data (D).

[0140] 1.c Alternatively or additionally, there is provided a (computer-implemented) method, the method comprising: The method includes providing, from the second entity to the first entity, a root value (R') of a Merkle tree (T') calculated based on at least one variation of a plurality of sub-portions of a portion of the data (D).

[0141] 1.d Alternatively or additionally, there is provided a (computer-implemented) method, the method comprising: providing, from the second entity to the first entity, a root value (R') of a Merkle tree (T') calculated based on at least one variation of a plurality of sub-portions of the portion of the data (D); and receiving from the second entity and / or an authorized party on behalf of the second entity a root value (R') of the Merkle tree (T'') calculated based on the at least one variation of the sub-portion.

[0142] 1.e Alternatively or additionally, there is provided a (computer-implemented) method, the method comprising: - transmitting a portion of data D from the first entity to the second entity; sending a request from the first entity or a third entity to the second entity to calculate an output of the challenge based on a modified version of the portion of the data; and the first or third entity checking whether the output calculated by the second entity matches an output calculated by the first or third entity for the same challenge; Preferably, the method comprises one or more of the following i) to v): i) storing, by the first or third entity, at least one, some or all of the one or more sub-portions; ii) selecting or otherwise identifying, by a first entity, at least a sub-portion of the portion of the data (D); iii) maintaining, by the first entity and / or by a third entity, at least one subpart and / or at least one operation that is secret from the second entity; iv) computing an output of the challenge, the output comprising: computing a modified version of the portion of data by performing at least one operation on at least one sub-portion of the portion of data, the at least one sub-portion being specified in the request; and a root value of a Merkle tree representing the modified version of the portion of data; v) the checking step includes the step of checking whether the route value calculated by the second entity matches the route value calculated by the first or third entity.

[0143] 1.f Alternatively or additionally, there is provided a (computer-implemented) method for verifying, backing up, recovering and / or managing a portion of data D, the method comprising: storing, by a second entity, a portion of the data; and performing a verification check by the first or third entity by comparing a challenge output calculated by the second entity with a challenge output calculated by the first and / or third entity; The calculation of the challenge output is a modified version of the portion of data by performing at least one operation on at least one sub-portion of the portion of data, where at least one sub-portion is specified in the request; and a root value of a Merkle tree representing a modified version of a portion of the data; Preferably, the method comprises: - transmitting a portion of data D from the first entity to the second entity; sending a request from the first entity or a third entity to the second entity to calculate an output of the challenge based on a modified version of the portion of the data; and the first or third entity checking whether the output calculated by the second entity matches an output calculated by the first or third entity for the same challenge; At least one subportion is an element of a set (M) of subportions identified and / or selected from a plurality of subportions, the set (M) of subportions being identified such that a root value (R') can be calculated using a minimum number of calculations.

[0144] 1.g Alternatively or additionally, there is provided a (computer-implemented) method, the method comprising: The method includes receiving, from or on behalf of a data provider, a request for a Merkle tree root value for a modified (i.e., divergent) version of a portion of data stored by, at, or on behalf of the data provider.

[0145] Preferably, the modified version of the data is specified by or on behalf of a data provider, who may specify one or more modifications made by the data store to one or more segments (sub-portions) of the data prior to computing the root value of the Merkle tree. The data store may be referred to as a second entity. The data provider may be referred to as a first entity. The one or more modifications may be referred to as one or more variations. The request may include a request or instructions to a) modify one or more sub-portions of the data and / or b) compute a root value.

[0146] 1.h Alternatively or additionally, there is provided a (computer-implemented) method, the method comprising: The method includes a step of a data provider receiving a request for a Merkle tree root value for a modified (i.e., divergent) version of a portion of data stored at, by, or on behalf of the data provider from a data store.

[0147] Preferably, the modified version of the data is specified by or on behalf of a data provider, who may specify one or more modifications made by the data store to one or more segments (sub-portions) of the data prior to computing the root value of the Merkle tree. The data store may be referred to as a second entity. The data provider may be referred to as a first entity. The one or more modifications may be referred to as one or more variations. The step of requesting a root may include a) modifying one or more sub-portions and / or b) a request to compute a root.

[0148] One or more of the following statements may be applicable to any of Statements 1.a through 1.h. The phrase "Statement 1" as used below means "any one or more of Statements 1.a through 1.h."

[0149] Statement 2: A method according to statement 1, wherein the variation of at least one subpart comprises: i) by or on behalf of a second entity; and / or ii) by using at least one operation (f) specified by the first entity; and / or iii) by using at least one operation (f) on at least one subdivision to generate an output (Y); and / or iv) by using at least one sub-portion as an operand or input to at least one operation (f); and / or v) Performed or provided by using bitwise, logical, mathematical, or cryptographic operations.

[0150] The term "operation" is intended to mean any function, process, procedure, subroutine, or method that produces a transformed, modified, or processed version of a value, a subpart of which may be used as an operand or some input by the operation.

[0151] Statement 3: A method according to statement 1 or 2, i) a portion of the data (D) is stored and / or provided by a second entity as a data block (B), the data block having at least one sub-portion; and / or ii) the first entity is the owner, creator, controller, processor, processor and / or admin of some of the data; and / or iii) the second entity is a storage provider.

[0152] Statement 4: A method according to any one of statements 1 to 3, wherein at least one subpart comprises: i) identified by a first entity; and / or ii) one or more elements of a set (M) of subparts identified by the first entity from the plurality of subparts; and / or iii) a sample of part of the data (D); and / or iv) is identifiable by an identifier that is unique within the sub-portions and / or within a set of one or more sub-portions (M).

[0153] Statement 5: A method according to any one of statements 1 to 4, i) storing a portion of the data (D) by a second entity in a storage resource; ii) receiving, by the first entity, a route value (R') from the second entity; and / or iii) Comparing the route value (R') received from the second entity with a pre-computed route value calculated by the first entity.

[0154] Statement 6: A method according to any one of statements 1 to 5, i) storing a portion of the data (D) by or on behalf of a second entity, where the portion of the data (D) is stored in an off-chain storage resource; ii) storing a handler (H) of a data block (B) having a portion of the data (D) in a transaction (Tx) on the blockchain.

[0155] Statement 7: A method according to any one of statements 1 to 6, i) triggering an action depending on a comparison of route values ​​provided by the second entity to the first entity, preferably the action being the sending of a signal or an electronic communication or the unlocking of a resource; and / or ii) comprising one or more steps of comparing a route value (R') received from the second entity with a pre-computed route value calculated by the first entity and, if the received route value (R') matches the pre-computed route value, considering the verification of (a part of the data (D)) to be successful and, if the received route value (R') does not match the pre-computed route value, considering the verification to be unsuccessful.

[0156] Statement 8: A method according to any one of statements 1 to 7, the first entity requesting from the second entity a further Merkle tree root value calculated based on a further variation of at least one sub-portion; and / or The method further comprises providing, from the second entity to the first entity, a further Merkle tree root value calculated based on a further variation of the at least one sub-portion.

[0157] Statement 9: A method according to any one of statements 1 to 8, at least one subportion is an element of a set (M) of subportions identified from a plurality of subportions; A set of sub-portions (M) is identified that allows for the calculation of a root value (R') using a minimum number of calculations.

[0158] Statement 10: A method according to any one of statements 1 to 9, At least one subportion is an element of a set (M) of subportions identified from a plurality of subportions; and / or The method further comprises determining, by the first entity, a plurality of pre-defined challenges based on a plurality of variations to the set of sub-portions (M).

[0159] The challenge is / includes a computation of an output for a selected / predetermined operation, and the selected operation is arranged to operate on or otherwise use one or more sub-portions to produce a result that is based on or depends on the sub-portions.

[0160] Statement 11: The method is a method for verifying the existence, state, integrity, consistency, persistence, storage and / or security of a portion of data (D); Alternatively, or in addition, the method of any of statements 1-10, wherein the method is for performing one or more of data backup and / or recovery, data archiving, file system dump and / or data version management activities.

[0161] Statement 12: A memory having one or more memory units; a processing device having one or more processing units; A computing device, the memory storing code configured to be executed on a processor, the code configured to execute on the processor a method according to any one of statements 1 to 11.

[0162] Statement 13: A computer program embodied on a computer-readable storage configured to perform the method of any of statements 1-11 when executed on one or more processors. [Explanation of symbols]

[0163] 100 Systems 101 Packet Switching Network 102 Computer terminals 103 User, Parties 104 Blockchain nodes 105 Client Applications 107 Side Channel 150 Blockchain 151 Blocks of Data 151n Block 151n-1 Block 152 Transactions 152i Transactions 152j Transaction 153 Genesis Block (Gb) 155 Block Pointer 201 Header 202 Input 203 Output

Claims

1. 1. A computer-implemented method, comprising: i) requesting by the first entity from the second entity a root value (R') of a Merkle tree (T') computed based on at least one variation of a plurality of sub-portions of a portion of the data (D); or providing, from the second entity to the first entity, a root value (R') of a Merkle tree (T') calculated based on at least one variation of a plurality of sub-portions of the portion of the data (D); ii) comparing by the first entity a route value (R') received from the second entity with a pre-computed route value calculated by the first entity and considering the verification of said portion of data (D) successful if the received route value (R') matches the pre-computed route value and unsuccessful if the received route value (R') does not match the pre-computed route value. A computer-implemented method comprising:

2. At least one variation of the subpart is i) by or on behalf of said second entity; and / or ii) by using at least one operation (f) specified by said first entity; and / or iii) by using at least one operation (f) on said at least one sub-portion to generate an output (Y); and / or iv) by using said at least one sub-portion as an operand or input to at least one operation (f); and / or v) By using bitwise, logical, mathematical, or cryptographic operations; The method of claim 1 performed or provided.

3. i) said portion of data (D) is stored and / or provided by said second entity as a data block (B), said data block having at least one sub-portion; and / or ii) the first entity is the owner, creator, controller, processor, processor and / or admin of said part of data; and / or iii) the second entity is a storage provider; The method according to claim 1 or 2.

4. At least one sub-portion is i) identified by said first entity; and / or ii) one or more elements of a set (M) of sub-portions identified by the first entity from the plurality of sub-portions; and / or iii) a sample of said portion of data (D); and / or iv) identifiable by an identifier that is unique within the plurality of sub-portions and / or within a set of one or more sub-portions (M); The method according to any one of claims 1 to 3.

5. i) storing said portion of data (D) by said second entity in a storage resource; ii) receiving, by the first entity, the route value (R') from the second entity; and iii) comparing the route value (R') received from the second entity with a pre-computed route value calculated by the first entity; The method of any one of claims 1 to 4, comprising one or more of:

6. i) storing said portion of data (D) by or on behalf of said second entity, wherein said portion of data (D) is stored in an off-chain storage resource; ii) storing in a transaction (Tx) on the blockchain a handler (H) of the data block (B) having said part of the data (D); The method according to any one of claims 1 to 5, further comprising one or both of:

7. 7. A method according to any one of claims 1 to 6, comprising triggering an action in response to a comparison of the route values ​​provided by the second entity to the first entity, the action being the sending of a signal or electronic communication, or the unlocking of a resource.

8. the first entity requesting from the second entity a further Merkle tree root value calculated based on a further variation of at least one sub-portion; and / or providing from the second entity to the first entity a further Merkle tree root value calculated based on a further variation of the at least one subportion. The method of any one of claims 1 to 7, further comprising:

9. at least one subportion is an element of a set (M) of subportions identified from said plurality of subportions; The set of sub-portions (M) is identified so as to enable the calculation of the root value (R') using a minimum number of calculations. The method according to any one of claims 1 to 8.

10. i) at least one subportion is a member of a set (M) of subportions identified from said plurality of subportions; and / or ii) the method further comprises the step of determining, by the first entity, a plurality of predefined challenges based on a plurality of variations to the set of sub-portions (M); The method according to any one of claims 1 to 9.

11. The method further comprising: i) verifying the existence, state, integrity, consistency, persistence, storage and / or security of said portion of data (D); ii) performing data backup and / or recovery, data archiving, file system dumps, and / or data version management activities; The method according to any one of claims 1 to 10,

12. a memory having one or more memory units; a processing device having one or more processing units; A computing device, wherein the memory stores code configured to be executed on the processing unit, the code being configured to execute on the processing unit a method according to any one of claims 1 to 11.

13. A computer program embodied on a computer readable storage configured to perform the method of any one of claims 1 to 11 when executed on one or more processors.

Images