Proving that data belong to set

Abstract

A computer-implemented method for proving that data items are contained in a set of data items, where the method is performed by a prover and comprises: for each data item, generating a respective first private key based on the respective data item; generating a public key; for one or more of the data items: generating a respective inclusion proof based on the respective data item and the second private key; and providing the data item and / or its commitment, the public key, and the corresponding inclusion proof to a verifier to verify whether the data item belongs to the set of data items.

Description

TECHNICAL FIELD

[0001] The present disclosure relates to a method of proving that a data item (e.g. a blockchain transaction) belongs to a set of data items (e.g. a block of blockchain transactions). BACKGROUND

[0002] The Elliptic Curve Digital Signature Algorithm (ECDSA) is a digital signature scheme whose public parameters are: • an elliptic curve E defined over a field K of characteristic p (the field of size ). .

[0003] • a generator g of a subgroup of prime order of E . .

[0004] The private key of the ECDSA algorithm is an integer d , and the associated public key is the elliptic curve point Q = d .

[0005] The method for signing a message m using the private key d is as follows. 1. Compute the hash of the message m.

[0006] 2. Generate a random temporary key k .

[0007] 3. Compute h = H(m) and set r = h .

[0008] 4. Compute s = (k - d ) / r. If s , then go to step 2.

[0009] 5. Compute s = (k - d ) / r. If s , then go to step 2; otherwise, the signature is (r, s).

[0010] The method for verifying a signature (r, s) on a message m is as follows.

[0011] 1. Compute the hash of the message m. 2. Compute e = H(m) and s

[0012] , where s -1 is computed modulo n. 3. Check that r .

[0013]

[0014] ​​​Threshold signatures are digital signatures in which a signer can establish a group such that only certain subsets of the group can produce signatures on behalf of the group. Different schemes require different types of interaction between signers. Threshold signatures can require multiple rounds of interaction between signers. Non-interactive schemes are referred to as threshold signature schemes in which a single round of generation of a signature is required. This single round can or can not require preprocessing (FROST) (BLS).

[0015] BLS is a deterministic, non-malleable, and efficient digital signature scheme with aggregation properties that relies on elliptic curve bilinear pairings. It is also possible to aggregate secret keys and public keys. The simplicity and cryptographic properties of this scheme make it useful in a variety of use cases, especially when minimal storage space or bandwidth is required.

[0016] FROST is a threshold signature scheme based on EdDSA (a variant of the Schnorr signature scheme). FROST can be used either as a two-round protocol, in which signers send and receive a total of two messages, or optimized as a single-round signature protocol with a preprocessing phase. SUMMARY

[0017] According to one aspect disclosed herein, there is provided a computer- implemented method for proving that a data item is included in a set of data items, wherein the method is performed by a proving party and comprises: for each data item, generating a respective first private key based on the respective data item; generating a public key based on each of the first private keys; for one or more of the data items: generating a respective inclusion proof based on the respective data item and the respective first private key; and providing the data item and / or a commitment thereof, the public key, and the respective inclusion proof to a verifying party for verifying whether the data item belongs to the set of data items.

[0018] According to another aspect disclosed herein, there is provided a computer- implemented method for verifying that a data item is included in a set of data items, wherein the method is performed by a verifying party and comprises: obtaining a data item and / or a commitment thereof, a public key, and an inclusion proof for the data item, wherein the public key is based on a plurality of respective first private keys, each respective first private key being based on a respective data item in the set, wherein the inclusion proof is based on the data item and the respective first private keys; and verifying whether the data item is included in the set using the public key and the inclusion proof.

[0019] According to another aspect disclosed herein, a computer-implemented method is provided for proving that a data item is contained in a set of data items, wherein the method is performed by a proving party and includes: for each data item, generating a corresponding first private key based on the corresponding data item; aggregating the corresponding first private keys to generate a second private key; generating a public key corresponding to the second private key; for one or more data items among the data items: generating a corresponding fourth private key, wherein the corresponding first private key and the corresponding fourth private key together can be used to generate a threshold signature for the second private key; using the corresponding first private key to generate a corresponding first signature, wherein the corresponding signature signs the hash of the corresponding data item; and providing the following to a verifying party to verify whether the corresponding data item belongs to the dataset: the corresponding first signature and the public key.

[0020] Embodiments of this disclosure enable the proving party to generate (and provide to the verifying party) an inclusion proof for a given data structure, utilizing a private key obtained by aggregating fingerprints (e.g., hashes) of the data contained within the data structure. The inclusion proof is particularly suitable for overlay networks and blockchains maintained by trusted servers or nodes, but can also be applied more broadly to all scenarios of data aggregation where each piece of data requires a unique, independent, and unforgeable inclusion proof to demonstrate its inclusion in the data structure. Attached Figure Description

[0021] To aid in understanding embodiments of this disclosure and to illustrate how such embodiments can be implemented, descriptions will now be provided by way of example only, with reference to the accompanying drawings, in which: Figure 1 This is a schematic block diagram of a system for implementing blockchain. Figure 2 The illustration shows some examples of transactions that can be recorded in a blockchain; Figure 3 The generation of the aggregation key is illustrated schematically; Figure 4 An elliptic tree with three leaves is schematically shown; Figure 5 The illustration schematically shows a tulip tree that aggregates four data blocks; Figure 6 An alternative implementation of the tulip tree is illustrated schematically. Detailed Implementation

[0022] 1. Inclusion proof Some embodiments of this disclosure provide for the generation of a proof of inclusion (or inclusion proof)—a proof that a data item belongs to a set of data items (or a dataset) (i.e., constitutes part of it). While some examples can be described based on data items that act as transactions belonging to block 151 of blockchain 150, this is merely for illustrative purposes. More importantly, the described embodiments can be implemented entirely independently of blockchain 150. For example, a data item could be an email in an inbox, a record / entry in a database, an entry in an account (e.g., a bank account), and so on.

[0023] Similarly, while the proving party may be referred to as Alice 103a and the verifying party as Bob 103b, this is merely for convenience, and the proving and verifying parties do not need to be configured to perform the actions described below by Alice 103a and Bob 103b, although this is an option. More generally, each of the proving and verifying parties can be an individual user, a group of users, a company, an organization, a government, a blockchain node, etc. In some examples, the proving and verifying parties can be the same party. Although described as being performed by Alice 103a and Bob 103b, it should be understood that the actions they perform are implemented through computing devices (e.g., user terminals, servers, etc.) operated separately by Alice 103a and Bob 103b.

[0024] Alice 103a acquires a set of data items. One or more of these data items may have been generated by Alice 103a. One or more of these data items may have been sent to Alice 103a. For example, Alice 103a could be a blockchain node 104 receiving transactions from user 103 and other nodes 104. One or more of these data items can be extracted from a database (or other types of records) such as block 151. In some examples, one of these data items may be a secret value (or other types of data items) known only to Alice 103a.

[0025] Alice 103a generates a first value for each data item by applying a function to it. That is, it generates a first value for each data item. This function can be a one-way function. The first value can be generated by hashing the data item and an optional salt (e.g., a combination of data item and salt, such as a concatenation). The hash function can be a SHA-based hash function, such as SHA256. Functions other than hash functions can be used. The salt for each data item can be the same or different. Each first value can be considered a private key.

[0026] Alice 103a aggregates (i.e., combines) each of the first values ​​in the first value set to generate the second value. The first values ​​can be combined by summing them to generate the second value. Other types of aggregation can be used (e.g., a combination of concatenation and hashing of the first values). The second value can be considered as a private key.

[0027] Alice 103a generates a third value based on a second value by applying a function to the second value. This function can be a one-way function. The third value can be a public key corresponding to the second value. For example, the function applied to the second value could be a dot product with an elliptic curve generator point. In some examples, a salt value is also input into the function to generate the third value. For verification purposes, the third value is published or otherwise provided (e.g., sent directly to) Bob 103b.

[0028] A third value is used to generate a fourth value for each data item (or at least the data items that Alice 103a wants to prove belong to the set). For a given data item, the fourth value is generated based on the third value and the data item (i.e., as a function of the third value and the data item). This function can be a one-way function, such as a hash function. The fourth value can be considered as a private key.

[0029] Then, a proof of inclusion (or a fifth value) is generated for each data item (or at least the data item that Alice 103a wants to prove belongs to the set). For a given data item, the proof of inclusion is generated based on the fourth value generated for that data item (i.e., a function of the fourth value). This function can be a one-way function. In some examples, this function is a signature generating function. The signature can be an ECDSA signature. For verification purposes, the proof of inclusion is published or otherwise provided to (e.g., sent directly to) Bob 103b. Alice 103a may also send the data item or a commitment (e.g., a hash) to Bob 103b. In some examples, if Bob 103b already has access to the data item, it is not necessary to send the data item or the commitment.

[0030] Bob 103b obtains a data item or commitment (e.g., a hashed data item), a third value (e.g., a public key corresponding to an aggregated private key), and a proof of inclusion for the data item. Bob 103b uses the third value and the proof of inclusion to verify whether the dataset contains the data item. The third value and the proof of inclusion can be obtained directly from Alice 103a. The data item (or commitment) can be obtained from Alice 103a, or Bob 103b may already have access to the data item (or commitment).

[0031] In these examples, each fourth value for each data item can be generated by subtracting the corresponding third first value (e.g., the hash of the data item) from the second value (i.e., the aggregation of the corresponding first values). The inclusion proof can then be generated by converting the fourth value (which can be considered a private key) into a public key. Bob 103b can generate a public key corresponding to the hash of the data item (i.e., the private key) and verify whether the combination of that public key and the inclusion proof (i.e., the public key corresponding to the fourth value) corresponds to the third value (i.e., the public key corresponding to the aggregated private key).

[0032] Alice 103a can generate a signature (e.g., an ECDSA signature) using the corresponding fourth value of the data item. This signature can be used to sign the first value (e.g., the hash of the data item). Alice 103a publishes the signature and / or sends it to Bob 103b. The signature can be included as part of a proof of inclusion. Bob 103b can verify that the signature is valid for the proof of inclusion (i.e., the public key corresponding to the fourth value).

[0033] In some examples, the RSA scheme (or at least some of its properties) can be used to generate proofs containing [a certain value]. Alice 103a determines a value n that is the product of two prime numbers p and q. Alice 103a also determines two integers e and d such that [a certain value is missing in the original text]. .

[0034] In these examples, a first value can be generated by hashing the data item and then taking the modulo of n (i.e., returning the remainder when the hashed data item is divided by n). In some examples, the first value can be generated by taking the modulo of the data item itself. A third value is generated by aggregating the second value (e.g., summing) and then taking the modulo of n. Alice 103a can publish the values ​​e and n, for example, as part of the third value. For each data item, a fourth value is generated by subtracting the corresponding first value from the second value and then taking the modulo of n. Finally, a proof of inclusion is generated by raising the fourth value to the power of d and taking the modulo of n. Bob 103b can combine the hash of the data item and the proof of inclusion raised to the power of e (e.g., summing). Bob 103b can take the second value modulo n and verify that the result is equal to the previously mentioned combination.

[0035] Alternatively, a first value can be generated by hashing the data item twice (i.e., applying the same hash function twice) and taking the modulo of n. A third value is generated by aggregating the second value and the salt value (e.g., summing) and then taking the modulo of n. Alice 103a can publish the values ​​e and n, for example, as part of the third value. For each data item, a fourth value is generated by aggregating the corresponding hashes of the other data items (e.g., summing) and subtracting the hash of the data item, and then taking the modulo of n. Bob 103b can combine the double hash of the data item (i.e., hashing the data item twice) with a hash containing proof, raised to the power of e (e.g., summing). Bob 103b can take the second value modulo n and verify that the result is equal to the previously mentioned combination.

[0036] Now, an alternative mechanism for proving that a data item belongs to the dataset is described. Similar to the embodiments described above, for example, a first value is generated for each data item by hashing it. The first value is a private key. For example, the first value is aggregated to form a second value (also a private key) by summing the first values. A third value (public key) is generated based on the second value. A fourth value is generated for each data item that Alice 103a wants to prove belongs to the set. The fourth value is a private key such that the combination of the first and fourth values ​​corresponds to the second value. In other words, the first and fourth values ​​can be used to generate a threshold signature that is valid for the second value.

[0037] Alice 103a uses a fourth value to generate a first signature, which signs a message including a data item and / or a hash of the data item. This signature is provided to Bob 103b. Alice 103a can also use the first value to generate and provide a second signature, which signs a message including a data item and / or a hash of the data item. Alice 130a can send Bob 103b one or more of the following public keys: a third value (i.e., the public key corresponding to the aggregated private key), the public key corresponding to the first value, and the public key corresponding to the fourth value.

[0038] Bob 103b uses the first and second signatures to verify that they are valid signatures for a third value. If Bob 103b has access to the required data, he can generate the second signature himself. Bob 103b can also verify that the first signature is valid for the public key corresponding to the fourth value. Similarly, Bob 103b can verify that the second signature is valid for the public key corresponding to the first value.

[0039] 1.1 Inclusion proof for aggregated keys This section describes how to use the above embodiments to process multiple data chunks. Aggregated into a single block of data. And subsequently for each Provide its in The inclusion proof. Knowing And each party to the proof generated by the aggregator can use the information provided by the aggregator regarding... Some publicly available information can be used to verify Is it already included? It should be understood that this is a specific implementation of the described embodiments, and not all examples described in this section are necessary for implementing the described embodiments.

[0040] The process described assumes At least one fingerprint of the data contained therein is unknown to any other party besides the aggregator (e.g., a private blockchain and an overlay network on a public blockchain). If this is not the case (e.g., a public blockchain), the aggregator generates a secret value. The secret value was added This is to prevent users from forging inclusion proofs. In the latter case, because the aggregator is using a secret... To salt the data, so he can use (or a security value generated from it) is used for signing.

[0041] As a stimulating example, data blocks It can be a transaction or a data block. This could be a block in a blockchain, or an overlay network run and maintained by trusted servers. For example, this would be the case with a blockchain or overlay network operated by a private company or government entity.

[0042] Each data block is associated with some information used to label the leaves of the tree. The root is labeled by the aggregation of these leaves; while Merkle trees enforce a fixed order for all leaves, the scheme disclosed here provides flexibility in whether or not the order is maintained. The root, or some derived information, is publicly available, and it is intended that the parties involved in the verification, including the proof, can check the consistency of all this data.

[0043] 1.1.1 General key aggregation For the purposes of this section, key aggregation refers to creating a single value that depends on multiple data points. This section provides a brief discussion of key aggregation. This discussion does not involve specific choices of encryption schemes.

[0044] 1. Each Both with value Related; that is ,in It is a function.

[0045] 2. Value Aggregated into private block values .

[0046] 3. Aggregator Release Value ,in It is a function. From Unable to recover .value Salting can be added to enhance safety. Figure 3 It shows , , and The relationship between them.

[0047] 4. For each data block Aggregator calculated value ,in It is a function.

[0048] 5. Aggregator computation includes proof. ,in It's a function. The aggregator will... Send to the relevant parties. From Unable to rebuild .

[0049] 6. Know , and (or Any party can prove (a particular fingerprint) Included in data blocks middle.

[0050] This protocol can be specifically applied to a variety of situations, some of which will be explored in the following sections. The following are some additional notes regarding the proposed protocol.

[0051] ● In all the examples discussed in this section, the function in step 1 They will all be hash functions, but this is not mandatory.

[0052] ● In all examples, the aggregation in step 2 will be summation. While summation is a convenient aggregation function (easy to invert and compute), it is not required to use it, and any other aggregation function can be used.

[0053] ● Aggregate functions that satisfy the commutative law and aggregate functions that satisfy the associative law have several advantages, the most important being that they are not affected by the data. The influence of the order.

[0054] ● Based on the selected function The values ​​may differ before being published; therefore, the values ​​to be published may need to be... Perform salting or masking.

[0055] ● The specific details of the included proof and the method used to verify the included proof depend on the specific choices made when implementing the protocol.

[0056] ● If additional data can be added to the initial data, the algorithm can be modified to track historical data when calculating private block values. For example, suppose the data is a blockchain transaction. It is contained in the block In the middle. Calculation At the same time, it may also depend on all the transactions already contained in the blockchain.

[0057] 1.1.2 ECDSA aggregation This section describes a key aggregator protocol for ECDSA signatures. This approach uses the concept of an elliptic curve tree to compute the various private and public values ​​described in the protocol.

[0058] Elliptic curve trees are labeled trees, where the leaves are labeled by points on the elliptic curve, and the internal nodes are labeled by the sum of the labels of their children. Because elliptic curve addition satisfies the commutative and associative laws, the root's label is independent of the tree's structure and the order of the leaves. The root of an elliptic curve tree is the sum of the labels of all its leaves. Figure 4 An exemplary elliptic curve tree is shown in the figure.

[0059] set up It is an elliptic curve, and let... It is the generator of the subgroup. Let... It is a hash function. The protocol is as follows: 1. Each Both with value Related, the corresponding leaf's tag is .

[0060] 2. The private block value is ,in It is a secret value known only to the aggregator.

[0061] 3. The root's label is a publicly known value. .

[0062] 4. For each Values ​​calculated by the aggregator .

[0063] 5. Aggregator Generation And distribute these values.

[0064] Know and Any party can verify this through the following methods. Is it included? First, check if the conditions are met. Then verify the signature. Is it a valid signature? The signature must be included in the proof to prevent malicious actors from forging it. Due to the private root value It is not publicly known and undetectable, therefore the signature It cannot be forged.

[0065] If the data originates from blockchain transactions on the overlay network, ECDSA aggregation can easily support proof mechanisms, applicable not only to transactions but also to blocks, with a single setup required. Each transaction in From point Indicates, point It is a block The sum of all points. It is up to a certain point in time. All The sum, and representing The entire blockchain.

[0066] ● Transactions The inclusion proof is relative to the public key. The signature.

[0067] ● Block The inclusion proof is relative to the public key. The signature.

[0068] 1.1.3 RSA aggregation This section describes a variant of key aggregation that adopts the same principles as the RSA scheme. Let... It is the product of two prime numbers, and let... It is a pair of integers such that .set up It is a hash function, if If it is a homomorphism, then the scheme can be enhanced.

[0069] if If it is a standard hash function, then the protocol becomes as follows.

[0070] 1. Each Both with value Related.

[0071] 2. The block value is .

[0072] 3. Aggregator Publishing .

[0073] 4. Aggregator Calculation .

[0074] 5. Aggregator Distribution Value .

[0075] Know and Any party can verify whether Due to Finding the inverse is quite difficult, therefore the value is... It cannot be forged.

[0076] If function It is a cryptographic homomorphic hash function (i.e., If so, the proposed solution can be modified as follows.

[0077] 1. Each Both with value Related.

[0078] 2. The block value is ,in It is a secret value known only to the aggregator.

[0079] 3. Aggregator Publishing .

[0080] 4. Aggregator Calculation .

[0081] 5. Aggregator Distribution Value .

[0082] Know and Any party can verify whether The advantage of this version over the previous one is its improved security, as it is more resistant to forgery. It is also necessary to Perform the inverse operation.

[0083] 1.1.4 2-2 threshold signature aggregation Both scenarios discussed above require the disclosure of raw data, but this is not ideal in all use cases.

[0084] Using 2-2 non-interactive threshold signature schemes such as BLS or FROST, inclusion proofs can be generated without disclosing the original data. The specific details of the aggregation and verification protocols depend on the chosen threshold scheme. This section provides a brief description of the general case.

[0085] The value in step 3 It is the private key known only to the aggregator. The associated public key. Value and There are two private keys, and these two private keys can be used as private keys. Generate a 2-2 threshold signature. (Information) It depends on the specific 2-2 threshold signature scheme. This requires the use of a private key. For messages (e.g., H 2 ( D i You need to sign it, and you may also need some additional information. The owner receives the signature and uses the value. Generate a signature for the same message and check if the two signatures are the same. Generate a valid signature.

[0086] If the aggregator is honest, some interactive threshold signature schemes can be simplified and applied to this protocol. The described scheme is not limited to cryptographic schemes that rely on elliptic curve cryptography; for example, it can also be used for variants of Schnorr signatures different from EdDSA.

[0087] If the aggregator is willing to communicate with the verifier (directly or through a trusted verification service), a wider range of encryption schemes can be employed. Allowing verifiers to communicate freely with the aggregator can be risky, as it is vulnerable to denial-of-service attacks. Offering verification as a payment service can mitigate this risk.

[0088] 1.2 Chain data The inclusion proof discussed in Section 1.1 applies to overlay networks or blockchains operated and maintained by trusted nodes. The reason for needing trusted nodes is that if the aggregator is dishonest, it can arbitrarily manipulate information propagating within the network. While the need for trusted nodes may be a limitation for standard public blockchains, this assumption may be in the best interest of private blockchains and overlay networks operated by companies or public entities.

[0089] Blockchain divides data into linked blocks, and aggregation protocols can be applied to track these links. In the case of overlay networks, data blocks can be isolated from each other; in this case, the aggregation protocol only needs to consider each data block individually and execute as described in Section 1.1. The remainder of this section focuses on how to modify the protocol to connect data blocks to previous data blocks. It refers to a blockchain or overlay network, but in principle it can be any structure that adds and aggregates data in batches.

[0090] 1.2.1 Tulip tree The tulip tree is the name of the data structure described in this article used to link data blocks. Each block in these blocks is associated with a labeled tree. Relatedly, the root label of this tree is obtained by aggregating the leaf labels (this could be a Merkle tree, elliptic curve tree, etc.). These trees Combined recursively in tulip trees In, it includes not only information about blocks The information also includes information about all previous data blocks. More precisely, , It is a tree, and the left subtree of its root (the subtree generated from the left child) is also a tree. The right subtree is The root label is obtained by aggregating the labels of the roots of the two subtrees. Figure 5 An example tree is shown in the figure.

[0091] When to Add new data block At that time, the aggregator will perform the following operations.

[0092] 1. Search for the roots of the tulip tree.

[0093] 2. Calculation and Related trees.

[0094] 3. Update the roots of the tulip tree.

[0095] 4. Sign the root (more details are discussed below).

[0096] 5. Publish and The roots of the associated tree and the new roots of the tulip tree (for verification purposes).

[0097] The main advantage of the tulip tree data structure lies in its verification efficiency. The signatures generated by the aggregator can quickly verify the entire chain structure. In fact, it is not necessary to verify every data block; only the last block needs to be verified. This will also verify previous blocks.

[0098] One possible alternative implementation of the tulip tree involves using the root of a previous block as a leaf (e.g., the first leaf) in a new block. This implementation can generate the same (e.g., for an elliptic curve tree) or different (e.g., for a Merkle tree) root values. The following diagram shows an example of a tulip tree created in this way: Add a data block containing two data blocks and The new block. and The value is the label of an internal node that is not related to the content of this disclosure. Figure 6 An example tree is shown in the figure.

[0099] 1.2.2 Comparison with PoW blockchains In a blockchain, a Merkle tree contains only information about the current block, and a block is linked to the previous block via the hash of the previous block's header. A tulip tree's root connects the blockchain without relying on other structures because it combines information about both the current and past blocks. If the aggregation function has some additional properties (e.g., commutativity and associativity), verifying the inclusion proof of old data may become easier for verifiers because they don't need to store all the historical records of the data.

[0100] This can be done on existing blockchains (e.g., Bitcoin SV) without changing their protocols. Overlay networks can create blocks that mirror blockchain blocks, but only those transactions related to the overlay network. They can use the embodiments described herein to prove that a specific transaction is included in the overlay network without relying on Merkel proofs.

[0101] 1.2.3 Aggregated signature of chain blocks This section focuses on how to generate the necessary data for verification and addition. New data blocks in The signature. With The associated private value is And blocks Includes and Related data blocks .

[0102] if Maintained by a single aggregator, since this aggregator can access information about... It contains all the information in the data, therefore it can calculate private values. (The secret value can be omitted), and this private value is used to sign the root of the tulip tree. This prevents users from being deceived by trusting fake blocks. In fact, to forge a block... The malicious party needs to restore the relevant information. Information.

[0103] If there is more than one aggregator, blocks are not always published by the same aggregator. Two scenarios can be distinguished.

[0104] ● If no secret value is added, or if aggregators communicate values ​​to each other. They can calculate the value This value can also be used to sign the roots of tulip trees.

[0105] ● Otherwise, the aggregator will operate as follows: By using a signature scheme that supports signature and key aggregation (e.g., 2-2 non-interactive threshold signature), it will... To sign a specific message. Aggregator calculation. and use it to calculate with Compatible signatures for selected messages.

[0106] 1.2.4 Inclusion proof When to When adding a new block, proof may be required. Included In, rather than asking Is it included? In the middle. Usually, this is more important than proof. Included More work is required because the latest information must be calculated every time a new block is added. Nevertheless, it is still possible to achieve this.

[0107] Alice possesses data and includes proof And hope to prove to Bob Included In (or in a certain block) (Previously). Alice could achieve this goal in several ways: ● Alice Shared , and points The point is from arrive End (to block) The sum of the public block values ​​of ).

[0108] ● Alice used , And from To the end (to the block) The signature used in the block is used to generate a valid signature.

[0109] 1.3 Exemplary use cases 1.3.1 GOvNet Key aggregation protocols using ECDSA can be used by overlay networks operated by governments or companies. These overlay networks use blockchain to generate and store fingerprints (e.g., hashes) of data packets propagating within the network and rely on ECDSA aggregation protocols to provide users with proof of their inclusion within the network.

[0110] Fingerprints of data packets are extracted from blockchain blocks, and the corresponding data packets are aggregated into overlay data blocks. Each data packet is linked to an elliptic curve point, and the aggregation point is published by the organization maintaining the overlay network. These data blocks in the overlay network can rely on the inclusion proof protocol described in Section 1.2 to provide inclusion proofs to users.

[0111] The government-covered network provides a natural framework for implementing CBDC. A CBDC transaction is essentially a data packet, and the way CBDC transactions are implemented ensures they share the same properties as cash transactions. GOvNet is independent of the design choices of the CBDC system. The lifecycle of CBDC-type data packets is similar to that of document-type data packets, with the main difference being in correctness checks. In fact, the correctness of CBDC data packets also includes checking whether the spender has sufficient assets to support the transaction.

[0112] The fingerprint transaction associated with the expenditure and the CBDC type data packet can be used as a way for the payee to confirm receipt of funds.

[0113] Embodiments of this disclosure can be used to demonstrate the storage or awareness of tax-related data. For example, companies and / or individuals can use GOvNet to file tax returns, submit invoices, provide proof of tax payment, etc. For individuals, GOvNet can perform checks to ensure that tax-related data meets certain criteria. For example, users filing tax returns may need to provide entries for different types of taxable income: wages, bonuses, dividends, investment returns, rent, etc.

[0114] Similarly, GOvNet can be used to record licenses. For example, nodes on the network can be dedicated to recording television licenses or business licenses (e.g., licenses to trade certain goods). Businesses can use proof of their license storage to demonstrate to regulators that they have indeed obtained the licenses. Other types of licenses can be stored on the network, such as intellectual property licenses. Overlay servers can verify whether a license for the same IP address has not yet been granted (at least in the case of exclusive licenses).

[0115] GOvNet can be used to store data related to land and / or vehicle ownership and any changes in said ownership. For example, each data packet may contain a separate land or vehicle registration, or a transfer of ownership of a piece of land or vehicle. GOvNet can perform verification steps, for example, to ensure that a piece of land is not sold twice (unintentionally or fraudulently). To do this, GOvNet may verify whether the same land is already on a covered network indicated to be owned by someone else. Users can use evidence (stored proof) to verify whether the seller of the land or vehicle is the legal owner of that land / vehicle.

[0116] GOvNet can also be used to prove certain things about a document (e.g., the document exists, or the document contains certain data or meets certain requirements) without revealing the document itself.

[0117] In an example of age checks upon entering a venue (e.g., a bar, nightclub, etc.), people might want to prove they are 18 or older without revealing their actual age or any other information contained on their ID. In this case, a cover certificate can be provided at the venue entrance. Security personnel can use this certificate to verify with GOvNet whether GOvNet has accepted the document, and GOvNet can confirm the user is 18 or older without revealing any details. Because security personnel trust GOvNet, no additional checks are required. Other similar use cases include visas allowing owners entry into a country.

[0118] 1.3.2 Training set The use case described in this section pertains to training AI. This is a way to record and certify modifications to the training set. Using the notation from Section 1.1, each training instance is... And the training set is Alice is training the AI ​​and sending the training set to Bob, a trusted, certified entity. Bob uses any aggregation scheme to aggregate the data and publishes the public block value on the blockchain. Bob sends a single training data set to Alice. The inclusion proof. Now, Alice can use the inclusion proof to show that a certain Included This use case requires Alice to publicly disclose (e.g., publish on a blockchain) the fingerprint of the training set when training its AI.

[0119] If Alice needs to add training data, she can repeat the process, asking Bob to add the new dataset to the previous dataset. The new data can be linked to the old data or independent of it. Similarly (if the aggregation function satisfies the commutative and associative laws), Alice can also obtain proofs of exclusion for datasets not included in the training set. The proof of exclusion is The inclusion proof, where the use As the opposite value.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0144] For example, Alice 103a wants to create transaction 152j to transfer a certain amount of related digital assets to Bob 103b. Figure 2 In the middle, Alice's New Affairs 152j is marked as " Tx 1 The new transaction acquires the amount of digital assets locked to Alice in the output 203 of the previous transaction 152i in the sequence, and transfers at least a portion of such an amount to Bob. Figure 2 In the middle, the previous transaction 152i is marked as " Tx 0 ". Tx 0 and Tx 1 It is just an arbitrary marker, which does not necessarily mean Tx 0 The first transaction in Blockchain 151 and Tx 1 Subsequent transactions in pool 154. Tx 1 It can point to any previous (i.e. preceding) transaction that still has an unspent output 203 locked to Alice.

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

[0146] Previous matters Tx 0 One or more outputs 203 include a specific UTXO, tagged as Tx 0 Each UTXO includes a value representing the amount of digital assets and a locking script that defines the conditions that the unlocking script in input 202 of a subsequent transaction must meet to make the subsequent transaction valid and thus successfully redeem the UTXO.

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

[0148] Therefore, in the example shown, UTXO 0 Output 203 Tx 0 Including the locking script [Checksig] P A This locking script requires Alice's signature (Sig). P A to redeem UTXO 0 (Strictly speaking, it is for those who attempt to redeem) UTXO 0 Subsequent transactions are valid). [Checksig] P A Contains the public key from Alice's public-private key pair. PA The representation of (i.e., hash). UTXO 1 Input 202 includes pointers to Tx 1 pointers (e.g., via their transaction IDs) Tx 0 In the implementation example, this refers to the entire transaction. TxID 0 (hash value). Tx 1 Input 202 includes Tx 0 Chinese logo Tx 0 The index, in order to UTXO 0 It is identified in any other possible output. Tx 1 Input 202 further includes an unlock script. <Sig P A The unlocking script includes Alice's cryptographic signature, which she creates by applying the private key from her key pair to a predetermined portion of data (sometimes referred to in cryptography as a "message"). The data (or "message") that Alice needs to sign to provide a valid signature can be defined via a locking script, a node protocol, or a combination thereof.

[0149] When new transactions Tx 1 Upon reaching blockchain node 104, the node applies the node protocol. This includes running the locking and unlocking scripts together to check if the unlocking script meets the conditions defined in the locking script (wherein the conditions may include one or more criteria).

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

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

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

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

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

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

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

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

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

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

[0160] Statement 1. A computer-implemented method for proving that a data item is contained in a set of data items, wherein the method is performed by a proving party and includes: For each data item, generate a corresponding first private key based on the data item; A public key is generated based on each of the corresponding first private keys in the corresponding first private keys; For one or more of the data items: Generate a corresponding inclusion proof based on the corresponding data item and the corresponding first private key; and The data item and / or its commitment, the public key, and the corresponding proof are provided to the verifier to verify whether the data item belongs to the set of data items.

[0161] In some embodiments, the respective first private keys are aggregated, and the public key is generated based on the aggregated private keys. In other embodiments, a public key is generated for each respective first private key, and these public keys are aggregated to form the public key.

[0162] Statement 2. The method according to Statement 1, wherein the set of data items includes data items known only to the proving party.

[0163] Statement 3. The method according to any of the preceding statements, wherein the public key is generated based on a salt value.

[0164] Statement 4. The method according to any of the preceding statements, wherein the public key is generated based on a second private key, the second private key being based on each of the respective first private keys.

[0165] Statement 5. The method described in statement 4, wherein the second private key is generated by aggregating the corresponding first private key.

[0166] Statement 6. The method according to any one of statements 1 to 3, wherein the public key is generated in the following manner: Generate a corresponding first public key based on the corresponding first private key; and The public key is generated based on the corresponding first public key.

[0167] Statement 7. The method according to any of the preceding statements, wherein the public key is the root of the tree structure, and wherein the corresponding first private key or the corresponding first private key is a leaf node of the tree structure.

[0168] Statement 8. The method according to any of the preceding statements, wherein the corresponding includes proof based on the corresponding data item.

[0169] Statement 9. The method described according to statement 4 or any of its dependent statements, the method comprising: A corresponding fourth value is generated based on the corresponding data item and the second private key, wherein the corresponding value includes proof based on the corresponding fourth value.

[0170] Statement 10. The method described according to any of the preceding statements, wherein at least one of the following conditions exists: The corresponding first private key is generated by applying a one-way function to the corresponding data item; The public key is generated by applying a one-way function to the second private key.

[0171] Statement 11. The method described according to statement 9 or any of its dependent statements, wherein the corresponding inclusion proof is generated by applying a one-way function to the fourth value.

[0172] Statement 12. The method described according to statement 10 or 11, wherein at least one of the following conditions exists: The one-way function used to generate the corresponding first private key includes a hash function; The one-way function used to generate the public key includes a hash function.

[0173] Statement 13. The method according to Statement 10 or any of its dependent statements, wherein the corresponding fourth value is generated based on subtracting the corresponding first private key from the second private key, and wherein the one-way function used to generate the corresponding proof is multiplying the corresponding fourth value by an elliptic curve generator.

[0174] Statement 14. The method according to statement 13, the method comprising: providing a corresponding signature to the verifier, wherein the corresponding signature signs a message including the corresponding first private key and generates it using the corresponding fourth value.

[0175] Statement 15. The method according to any one of statements 1 to 12 belonging to statement 9, wherein the one-way function for generating the corresponding first private key comprises a hash function modulo n, where n is the product of two prime numbers, wherein the second value is generated by aggregating the corresponding first private key modulo n, wherein the common value comprises the second value, n, and e, where e is an integer, wherein the corresponding fourth value is generated by subtracting the corresponding first private key from the private key value modulo n, and wherein the corresponding proof is generated based on exponentiation of the corresponding fourth value modulo n to the power of d, where d is an integer.

[0176] Statement 16. The method according to any one of statements 1 to 12 belonging to statement 9, wherein the one-way function for generating the corresponding first private key comprises a double hash function modulo n, where n is the product of two prime numbers, wherein the second private key is generated by aggregating the corresponding first private key and the secret value modulo n, wherein the common value comprises the second value, n, and e, where e is an integer, wherein the corresponding fourth value is generated by aggregating the corresponding hash in the corresponding data item modulo n, and wherein the corresponding proof is generated based on exponentiation of the corresponding fourth value modulo n to the power of d, where d is an integer.

[0177] Statement 17. The method according to any of the preceding statements, wherein one or more of the data items are blockchain transactions, and the blockchain transactions belong to blocks of the blockchain.

[0178] Statement 18. The method described in statement 17, wherein each blockchain transaction includes corresponding data associated with the overlay network and / or application.

[0179] Statement 19. The method according to any one of statements 1 to 17, wherein one or more of the data items are entries in a database.

[0180] Statement 20. The method according to any one of statements 1 to 17, wherein one or more of the data items are elements in a dataset used to train a neural network.

[0181] Statement 21. A computer-implemented method for verifying that data items are contained in a set of data items, wherein the method is performed by a verifying party and includes: Obtain a data item and / or its commitment, public key, and inclusion proof of the data item, wherein the public key is based on a plurality of corresponding first private keys, each corresponding first private key being based on a corresponding data item in the set, wherein the inclusion proof is based on the data item and the corresponding first private key; and, The public key and the inclusion proof are used to verify whether the data item is included in the set.

[0182] Statement 22. The method according to Statement 21, wherein the corresponding first private key is generated by applying a hash function to the corresponding data item, wherein a corresponding fourth value is generated based on subtracting the corresponding first private key from a second private key generated based on each corresponding first private key, the corresponding containing proof being based on the corresponding fourth value, and wherein the one-way function used to generate the corresponding containing proof is multiplying the corresponding fourth value by an elliptic curve generator, and wherein the use includes: A first public key is generated based on the hash of the data item and the elliptic curve generator; and, Verify whether the combination of the first public key and the proof corresponds to the public value.

[0183] Statement 23. The method described according to statement 21, the method comprising: Obtain a signature, wherein the signature is used to sign a corresponding message including the corresponding first private key; and, Verify whether the signature is a valid signature containing the proof.

[0184] Statement 24. The method according to Statement 21, wherein the corresponding first private key is generated by applying a one-way function to the corresponding data item, wherein the one-way function for generating the corresponding first private key includes a hash function modulo n, where n is the product of two prime numbers, wherein a second private key is generated by aggregating the corresponding first private key modulo n, wherein the public key includes the second value, n, and e, where e is an integer, wherein a corresponding fourth value is generated by subtracting the corresponding first value from the second private key modulo n, the corresponding containing proof being based on the corresponding fourth value, and wherein the corresponding containing proof is generated based on raising the corresponding fourth value to the power of d modulo n, where d is an integer, and wherein the method includes: Verify whether the combination of "i) the hash of the data item" and "ii) the inclusion proof after being raised to the power of e" corresponds to the second private key modulo n.

[0185] Statement 25. The method according to Statement 21, wherein the corresponding first private key is generated by applying a one-way function to the corresponding data item, wherein the one-way function for generating the corresponding first private key includes a double hash function modulo n, where n is the product of two prime numbers, wherein a second private key is generated by aggregating the corresponding first private key and a secret value modulo n, wherein the public key includes the second private key, n, and e, where e is an integer, wherein a corresponding fourth value is generated by aggregating the corresponding hash of the corresponding data item modulo n, wherein a corresponding fourth value is generated by subtracting the corresponding first private key from the second value modulo n, the corresponding containing proof is based on the corresponding fourth value, and wherein the corresponding containing proof is generated based on raising the corresponding fourth value to the power of d modulo n, where d is an integer, and wherein the method includes: Verify whether the combination of "i) the double hash of the data item" and "ii) the hash containing the proof after being raised to the power of e" corresponds to the second private key modulo n.

[0186] Statement 26. A computer-implemented method for proving that a data item is contained in a set of data items, wherein the method is performed by the proving party and includes: For each data item, a corresponding first private key is generated based on the corresponding data item; The corresponding first private keys are aggregated to generate a second private key; Generate a public key corresponding to the second private key; For one or more of the data items: Generate a corresponding fourth private key, wherein the corresponding first private key and the corresponding fourth private key together can be used to generate a threshold signature for the second private key; The corresponding first private key is used to generate a corresponding first signature, wherein the corresponding signature signs the hash of the corresponding data item; and, The following items are provided to the verifier to verify whether the corresponding data item belongs to the set of data items: the corresponding first signature and the public key.

[0187] Statement 27. The method according to statement 26, the method comprising: generating a corresponding first signature using the corresponding first private key, wherein the corresponding signature signs the hash of the corresponding data item.

[0188] Statement 28. The method according to statement 26 or 27, the method comprising providing the verifier with: a public key corresponding to the corresponding first private key, and / or a public key corresponding to the corresponding fourth private key.

[0189] Statement 29. A computer device, said computer device comprising: The memory, comprising one or more memory cells; and, A processing apparatus comprising one or more processing units, wherein the memory stores code configured to run on the processing apparatus, the code being configured to execute a method according to any one of statements 1 to 28 when run on the processing apparatus.

[0190] Statement 30. A computer program contained on a computer-readable storage medium and configured to perform the method according to any one of statements 1 to 28 when run on one or more processors.

[0191] According to another aspect disclosed herein, a method can be provided, the method comprising actions of the proving party and the verifying party. According to another aspect disclosed herein, a system can be provided comprising computer devices of the proving party and the verifying party.

Claims

1. A computer-implemented method for proving that a data item is contained in a set of data items, wherein the method is performed by the proving party and includes: For each data item, generate a corresponding first private key based on the data item; A public key is generated based on each of the corresponding first private keys in the corresponding first private keys; For one or more of the data items: Generate a corresponding inclusion proof based on the corresponding data item and the corresponding first private key; and The data item and / or its commitment, the public key, and the corresponding proof are provided to the verifier to verify whether the data item belongs to the set of data items.

2. The method of claim 1, wherein the set of data items includes data items known only to the proving party.

3. The method according to any one of the preceding claims, wherein the public key is generated based on a salt value.

4. The method according to any one of the preceding claims, wherein the public key is generated based on a second private key, the second private key being based on each of the respective first private keys.

5. The method of claim 4, wherein the second private key is generated by aggregating the corresponding first private key.

6. The method according to any one of claims 1 to 3, wherein the public key is generated in the following manner: Generate a corresponding first public key based on the corresponding first private key; and The public key is generated based on the corresponding first public key.

7. The method according to any of the preceding claims, wherein the public key is the root of the tree structure, and wherein the corresponding first private key or the corresponding first private key is a leaf node of the tree structure.

8. The method according to claim 4 or any dependent claim thereof, wherein the method comprises: A corresponding fourth value is generated based on the corresponding data item and the second private key, wherein the corresponding value includes proof based on the corresponding fourth value.

9. The method according to any one of the preceding claims, wherein at least one of the following conditions is met: The corresponding first private key is generated by applying a one-way function to the corresponding data item; The public key is generated by applying a one-way function to the second private key.

10. The method of claim 8 or any of its dependent claims, wherein the corresponding inclusion proof is generated by applying a one-way function to the fourth value.

11. The method according to claim 9 or 10, wherein at least one of the following conditions is met: The one-way function used to generate the corresponding first private key includes a hash function; The one-way function used to generate the public key includes a hash function.

12. The method of claim 9 or any of its dependent claims, wherein the corresponding fourth value is generated based on subtracting the corresponding first private key from the second private key, and wherein the one-way function used to generate the corresponding proof is to multiply the corresponding fourth value by an elliptic curve generator.

13. The method according to claim 12, wherein the method comprises: The corresponding signature is provided to the verifier, wherein the corresponding signature is used to sign the message including the corresponding first private key and generated using the corresponding fourth value.

14. The method according to any one of claims 1 to 11, dependent on claim 8, wherein the one-way function for generating the corresponding first private key comprises a hash function modulo n, where n is the product of two prime numbers, wherein the second value is generated by aggregating the corresponding first private key modulo n, wherein the common value comprises the second value, n, and e, where e is an integer, wherein the corresponding fourth value is generated by subtracting the corresponding first private key from the private key value modulo n, and wherein the corresponding inclusion proof is generated based on raising the corresponding fourth value to the power of d modulo n, where d is an integer.

15. The method according to any one of claims 1 to 11, which are dependent on claim 8, wherein the one-way function for generating the corresponding first private key comprises a double hash function modulo n, where n is the product of two prime numbers, wherein the second private key is generated by aggregating the corresponding first private key and the secret value modulo n, wherein the common value comprises the second value, n, and e, where e is an integer, wherein the corresponding fourth value is generated by aggregating the corresponding hash in the corresponding data item modulo n, and wherein the corresponding proof of inclusion is generated based on exponentiation of the corresponding fourth value modulo n to the power of d, where d is an integer.

16. The method according to any of the preceding claims, wherein one or more of the data items are blockchain transactions belonging to blocks of the blockchain.

17. The method of claim 16, wherein each blockchain transaction includes corresponding data associated with the overlay network and / or application.

18. The method according to any one of claims 1 to 16, wherein one or more of the data items are entries in a database.

19. The method according to any one of claims 1 to 16, wherein one or more of the data items are elements in a dataset used to train a neural network.

20. A computer-implemented method for verifying that data items are contained in a set of data items, wherein the method is performed by a verifier and includes: Obtain a data item and / or its commitment, public key, and inclusion proof of the data item, wherein the public key is based on a plurality of corresponding first private keys, each corresponding first private key being based on a corresponding data item in the set, wherein the inclusion proof is based on the data item and the corresponding first private key; and The public key and the inclusion proof are used to verify whether the data item is included in the set.

21. The method of claim 20, wherein the corresponding first private key is generated by applying a hash function to the corresponding data item, wherein a corresponding fourth value is generated based on subtracting the corresponding first private key from a second private key generated based on each corresponding first private key, the corresponding containing proof being based on the corresponding fourth value, and wherein the one-way function used to generate the corresponding containing proof is multiplying the corresponding fourth value by an elliptic curve generator, and wherein the use includes: The first public key is generated based on the hash of the data item and the elliptic curve generator. as well as Verify whether the combination of the first public key and the proof corresponds to the public value.

22. The method of claim 20, wherein the method comprises: Obtain a signature, wherein the signature is used to sign the corresponding message including the corresponding first private key; as well as Verify whether the signature is a valid signature containing the proof.

23. The method of claim 20, wherein the corresponding first private key is generated by applying a one-way function to the corresponding data item, wherein the one-way function for generating the corresponding first private key comprises a hash function modulo n, where n is the product of two prime numbers, wherein a second private key is generated by aggregating the corresponding first private key modulo n, wherein the public key comprises the second value, n, and e, where e is an integer, wherein a corresponding fourth value is generated by subtracting the corresponding first value from the second private key modulo n, the corresponding containing proof being based on the corresponding fourth value, and wherein the corresponding containing proof is generated based on raising the corresponding fourth value to the power of d modulo n, where d is an integer, and wherein the method comprises: Verify whether the combination of i) the hash of the data item and ii) the proof-containing data item, after being raised to the power of e, corresponds to the second private key modulo n.

24. The method of claim 20, wherein the corresponding first private key is generated by applying a one-way function to the corresponding data item, wherein the one-way function for generating the corresponding first private key comprises a double hash function modulo n, where n is the product of two prime numbers, wherein a second private key is generated by aggregating the corresponding first private key and a secret value modulo n, wherein the public key comprises the second private key, n, and e, where e is an integer, wherein a corresponding fourth value is generated by aggregating the corresponding hash of the corresponding data item modulo n, wherein a corresponding fourth value is generated by subtracting the corresponding first private key from the second value modulo n, the corresponding inclusion proof being based on the corresponding fourth value, and wherein the corresponding inclusion proof is generated based on raising the corresponding fourth value to the power of d modulo n, where d is an integer, and wherein the method comprises: Verify whether the combination of i) the double hash of the data item and ii) the hash containing the proof, which has been raised to the power of e, corresponds to the second private key modulo n.

25. A computer-implemented method for proving that a data item is contained in a set of data items, wherein the method is performed by the proving party and includes: For each data item, a corresponding first private key is generated based on the corresponding data item; The corresponding first private keys are aggregated to generate a second private key; Generate a public key corresponding to the second private key; For one or more of the data items: Generate a corresponding fourth private key, wherein the corresponding first private key and the corresponding fourth private key together can be used to generate a threshold signature for the second private key; The corresponding first private key is used to generate a corresponding first signature, wherein the corresponding signature signs the hash of the corresponding data item; and The following items are provided to the verifier to verify whether the corresponding data item belongs to the set of data items: the corresponding first signature and the public key.

26. The method of claim 25, wherein the method comprises: The corresponding first private key is used to generate a corresponding first signature, wherein the corresponding signature signs the hash of the corresponding data item.

27. The method of claim 25 or 26, wherein the method comprises providing the verifier with a public key corresponding to the corresponding first private key and / or a public key corresponding to the corresponding fourth private key.

28. A computer device, the computer device comprising: The memory includes one or more memory units; as well as A processing apparatus comprising one or more processing units, wherein the memory stores code set to run on the processing apparatus, the code being configured to execute the method according to any one of claims 1 to 27 when run on the processing apparatus.

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

Images