EP4128655A1 - Preuve d'engagements cryptographique basée sur un arbre épars déterministe - Google Patents

Preuve d'engagements cryptographique basée sur un arbre épars déterministe

Info

Publication number
EP4128655A1
EP4128655A1 EP21719490.1A EP21719490A EP4128655A1 EP 4128655 A1 EP4128655 A1 EP 4128655A1 EP 21719490 A EP21719490 A EP 21719490A EP 4128655 A1 EP4128655 A1 EP 4128655A1
Authority
EP
European Patent Office
Prior art keywords
user
node
tree
liability
liabilities
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
EP21719490.1A
Other languages
German (de)
English (en)
Inventor
Konstantinos Chalkias
Kevin Lewi
Payman Mohassel
Valeria Olegovna Nikolaenko
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Meta Platforms Inc
Original Assignee
Meta Platforms Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Meta Platforms Inc filed Critical Meta Platforms Inc
Publication of EP4128655A1 publication Critical patent/EP4128655A1/fr
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3218—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using proof of knowledge, e.g. Fiat-Shamir, GQ, Schnorr, ornon-interactive zero-knowledge proofs
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/10—Office automation; Time management
    • G06Q10/105—Human resources
    • G06Q10/1053—Employment or hiring
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/08—Insurance
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/04—Masking or blinding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/16—Obfuscation or hiding, e.g. involving white box
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash

Definitions

  • Proof of liability is an important scheme that allows companies to prove their total amount of liabilities or obligations.
  • proofs of liabilities can be important for proving various types of liabilities in various industries.
  • proofs of liabilities can be useful in blockchain systems, such as cryptocurrency exchanges.
  • Solvency is the ability of a company to meet its long-term financial commitments.
  • proof of solvency consists of two components: 1.
  • Proof of liabilities proving the total quantity of coins the exchange owes to all of its customers; and 2.
  • Proof of reserves also known as proof of assets
  • proof of assets also known as proof of assets
  • an exchange should be able to prove on demand that the total balance of owned coins is greater than or equal to their liabilities, which correspond to the sum of coins their users own internally to their platform.
  • some conventional cryptographic proof of liability schemes and systems can expose access patterns to the provided proofs. For example, a vulnerable period in the distributed auditing process is when the audited entity uses information of former audits to predict the probability of a user checking their proofs. This information can be utilized by the audited entity to omit particular balances in the upcoming audits, as the risk of being caught is very low. [0005] By leaking and exposing data in these ways, conventional cryptographic proof of liability schemes give rise to system inaccuracies. For example, by exploiting leaking and exposing data, malicious entities can create inaccuracies within a blockchain system in order to syphon-off digital assets.
  • One or more embodiments described herein provide benefits and/or solve one or more of the foregoing or other problems in the art with systems, methods, and non-transitory computer readable storage media for decentralized, privacy -preserving cryptographic proofs of liabilities.
  • a cryptographic proof of liabilities system that allows an entity to securely, transparently, and accurately report its total amount of liabilities, obligations or other metrics related to fungible negative reports without exposing any user data or sensitive system data (e.g., the liabilities structure).
  • a cryptographic proof of liabilities system that allows individual users to independently verify that their committed liability is included in a reported total liability.
  • a method comprising: generating a user leaf node for a user by applying a deterministic function to a committed liability and user identifier associated with the user; positioning the generated user leaf node in a deterministic sparse-tree by deterministically shuffling the user leaf node with padding nodes and other user leaf nodes; receiving a request to verify that the committed liability associated with the user is included in a total liability for the deterministic sparse-tree; and generating an authentication path for the user leaf node comprising a list of nodes in the sparse-tree between the user leaf node associated with the user and a root node indicating the total liability, wherein the authentication path establishes that the committed liability associated with the user is reflected in the total liability.
  • applying the deterministic function to the committed liability and the user identifier comprises applying a verifiable random function to the committed liability and the user identifier associated with the user.
  • applying the deterministic function to the committed liability and the user identifier further comprises applying one or more key derivation functions to an output of the verifiable random function to generate an audit identifier and a blinding factor, wherein the audit identifier is optionally a unique and deterministically generated value, and optionally the blinding factor is a deterministically generated commitment that obfuscates the committed liability.
  • deterministically shuffling the user leaf node with padding nodes and other leaf nodes comprises: generating user hashes of user identifiers associated with the user leaf node and the other user leaf nodes, ordering the user leaf node and the other user leaf nodes based on the generated user hashes, randomly placing the ordered user leaf node and other user leaf nodes on the deterministic sparse-tree, and deterministically computing the padding nodes based on empty positions in the deterministic sparse-tree.
  • the method may further comprise positioning the padding nodes in the deterministic sparse-tree as the roots of empty sub-trees of the deterministic sparse-tree.
  • a padding node comprises a committed liability of zero.
  • the method may further comprise generating a zero-knowledge range proof associated with the committed liability that proves the committed liability is a small positive number within a predetermined range of numbers.
  • the authentication path further comprises a zero-knowledge range proof associated with every node in the list of nodes in the sparse-tree between the user leaf node and the root node.
  • the method may further comprise generating an internal node of the deterministic sparse-tree by: identifying a left-child-node of the internal node and a right-child- node of the internal node, generating an encrypted liability for the internal node by adding committed liabilities of the left-child node and the right-child-node, and generating a hash for the internal node by concatenating all committed liabilities and hashes of the left-child-node and the right-child-node.
  • generating the authentication path for the user leaf node further comprises identifying, at every level of the sparse-tree starting at the user leaf node and moving up by parent nodes, sibling nodes, and adding, for every level of the sparse-tree, the identified sibling nodes to the authentication path to establish that a committed liability at every level reflects a product of committed liabilities of two children nodes.
  • the method may further comprise publishing the root node of the deterministic sparse-tree to an immutable database, receiving additional requests to verify that committed liabilities associated with other users are included in the total liability for the deterministic sparse-tree, generating additional authentication paths associated with the other users, and comparing the authentication paths to the published root node to ensure every user has the same view of the total liability for the deterministic sparse-tree.
  • the method may further comprise receiving an audit request associated with the deterministic sparse-tree, and optionally, in response to receiving the audit request, reshuffling the leaf nodes based on hashed of user identifiers in each of the lead nodes, and redetermining internal nodes for the deterministic sparse-tree such that an encrypted liability for each internal node is a sum of committed liabilities of a left-child-node and a right-child-node of the internal node.
  • a system comprising at least one processor, and at least one non-transitory computer-readable storage medium storing instructions thereon that, when executed by the at least one processor, cause the system to: generate a user leaf node for a user by applying a deterministic function to a committed liability and user identifier associated with the user; position the generated user leaf node in a deterministic sparse-tree by deterministically shuffling the user leaf node with padding nodes and other user leaf nodes; receive a request to verify that the committed liability associated with the user is included in a total liability for the deterministic sparse-tree, and generate an authentication path for the user leaf node comprising a list of nodes in the sparse-tree between the user leaf node associated with the user and a root node indicating the total liability, where the authentication path establishes that the committed liability associated with the user is reflected in the total liability.
  • the non-transitory computer-readable storage medium further stores instructions thereon that, when executed by the at least one processor, cause the system to generate an internal node of the deterministic sparse-tree by identifying a left-child-node of the internal node and a right-child-node of the internal node, generating an encrypted liability for the internal node by adding committed liabilities of the left-child-node and the right-child- node, and generating a hash for the internal node by concatenating all committed liabilities and hashes of the left-child-node and the right-child-node.
  • the medium further stores instructions thereon that, when executed by the at least one processor, cause the system to generate the authentication path for the user leaf node by identifying, at every level of the sparse-tree starting at the user leaf node and moving up by parent nodes, sibling nodes, and adding, for every level of the sparse tree, the identified sibling nodes to the authentication path to establish that a committed liability at every level reflects a product of committed liabilities of two children nodes.
  • a non-transitory computer-readable medium storing instructions thereon that, when executed by at least one processor, cause a computing device to: generate a user leaf node for a user by applying a deterministic function to a committed liability and user identifier associated with the user; position the generated user leaf node in a deterministic sparse-tree by deterministically shuffling the user leaf node with padding nodes and other user leaf nodes; receive a request to verify that the committed liability associated with the user is included in a total liability for the deterministic sparse-tree, and generate an authentication path for the user leaf node comprising a list of nodes in the sparse-tree between the user leaf node associated with the user and a root node indicating the total liability, where the authentication path establishes that the committed liability associated with the user is reflected in the total liability.
  • FIG. 1 illustrates an example distributed network in which a cryptographic proof of liabilities system can operate in accordance with one or more embodiments
  • FIG. 2 illustrates a schematic diagram providing an overview of liability splitting and leaf shuffling in in accordance with one or more embodiments
  • FIG. 3 illustrates a schematic diagram providing an overview of deterministically determining an audit identifier in accordance with one or more embodiments
  • FIG. 4 illustrates a schematic diagram providing an overview of adding fake users with a zero balance liability in accordance with one or more embodiments
  • FIG. 5 illustrates a schematic diagram of a sparse tree in accordance with one or more embodiments
  • FIG. 6 illustrates a schematic diagram of a sparse tree with a height of two that includes two users and one padding node in accordance with one or more embodiments
  • FIG. 7 illustrates a schematic diagram of a signed proof of liabilities in accordance with one or more embodiments
  • FIG. 8 illustrates a schematic diagram of a sparse tree showing an authentication path to prove a closest user in accordance with one or more embodiments
  • FIG. 9 illustrates a schematic diagram of a cryptographic proof of liabilities system in accordance with one or more embodiments
  • FIG. 10 illustrates a flowchart of a series of acts for generating an authentication path establishing that a user’s committed liability is reflected in a total liability for a deterministic sparse-tree in accordance with one or more embodiments; and [0036] FIG. 11 illustrates a block diagram of an exemplary computing device in accordance with one or more embodiments.
  • One or more embodiments include a cryptographic proof of liabilities system that utilizes deterministic sparse-tree based cryptographic proof of liabilities.
  • cryptographic proof of liabilities system can utilize a tree construction (e.g., Merkle tree) that is extended using one or more of balance splitting, efficient padding, verifiable random functions, deterministic key derivation functions, or range proof techniques.
  • the cryptographic proof of liabilities system extends a Merkle tree with each of balance splitting, efficient padding, verifiable random functions, deterministic key derivation functions, and range proof techniques.
  • the cryptographic proof of liabilities system deterministically generates a sparse-tree such that every leaf node in the sparse-tree is associated with an authentication path. In one or more embodiments, the cryptographic proof of liabilities system utilizes this list of nodes in the sparse-tree between the leaf node and the root of the sparse-tree to establish that the committed liability associated with the leaf node is reflected in the total liability for the entire sparse-tree. [0038] To illustrate, in one or more embodiments the cryptographic proof of liabilities system generates a deterministic sparse-tree (e.g., a sparse Merkle tree) associated with an immutable database (e.g., a blockchain).
  • a deterministic sparse-tree e.g., a sparse Merkle tree
  • the cryptographic proof of liabilities system generates the deterministic sparse-tree by generating and positioning at least one leaf node in the sparse-tree for every user or member in the immutable database.
  • the cryptographic proof of liabilities system can further generate internal nodes for every other level in the sparse- tree that includes sums and concatenations of information from children nodes.
  • the cryptographic proof of liabilities system can ensure that the root node of the sparse-tree reflects a total liability for the entire immutable database, and that an accurate authentication path exists within the sparse- tree between every user leaf node and the root node.
  • the cryptographic proof of liabilities system utilizes deterministic functions to improve security and protect user liabilities.
  • the cryptographic proof of liabilities system can apply deterministic function to a user liability within a sparse-tree leaf node such that the user’s liabilities are obfuscated but cryptographically provable.
  • the cryptographic proof of liabilities system can utilize a deterministic function such as a homomorphic commitment (e.g., a Pedersen commitment) to ensure that any particular liability stay hidden within the sparse-tree and is only usable in comparison with another homomorphic commitment.
  • a homomorphic commitment e.g., a Pedersen commitment
  • the cryptographic proof of liabilities system can utilize verifiable random functions (VRFs) and key derivation functions (KDFs) to provide deterministic pre-commitments that can be revealed later using proofs.
  • VRFs verifiable random functions
  • KDFs key derivation functions
  • the cryptographic proof of liabilities system can utilize a key derivation function together with a verifiable random function to generate a unique audit id and blinding factor per user. Based on these unique and deterministically generated values, the cryptographic proof of liabilities system can further ensure that information about users and the sparse-tree remain private, even in between continuous and subsequent audits.
  • the cryptographic proof of liabilities system further generates the deterministic sparse-tree to obfuscate a total number of users or members within the sparse-tree.
  • the cryptographic proof of liabilities system can generate the sparse-tree including padding nodes with zero balances (e.g., zero liabilities). These padding nodes do not affect the total liability represented in the sparse-tree, but rather serve to hide the number of real user leaf nodes in the tree that carry actual liability balances.
  • the cryptographic proof of liabilities system can position a padding node at the root of every empty sub-tree within the deterministic sparse-tree.
  • the cryptographic proof of liabilities system can further ensure that the total liability reflected in the root node of the sparse-tree is accurate by generating one or more zero-knowledge range proofs.
  • the cryptographic proof of liabilities system can generate a zero-knowledge range proof for every internal node of the sparse-tree leading up the root node that demonstrates that the committed liability of each node is a small positive number within a predetermined range of numbers.
  • the cryptographic proof of liabilities system can show at every level of the sparse-tree that the liabilities represented therein are expected.
  • the cryptographic proof of liabilities system can generate and provide an individual proof of membership or inclusion for any user represented in the deterministic sparse-tree.
  • the cryptographic proof of liabilities system can receive a request from a user client device to verify that a committed liability of the user (e.g., number of coins, positive infection report, vote) is included in the total liability listed at the root node of the sparse-tree.
  • the cryptographic proof of liabilities system can generate a proof including an authentication path including a list of nodes in the sparse-tree between the user’s leaf node and the root node of the sparse-tree.
  • the cryptographic proof of liabilities system can use the authentication path prove to the user that liabilities of the user are correctly reflected in the total liability for the sparse-tree.
  • the cryptographic proof of liabilities system can deterministically shuffle user leaf nodes of the deterministic sparse-tree every time the sparse- tree is audited.
  • a malicious actor can potentially learn information about the sparse-tree when leaf nodes are relationally ordered in every audit.
  • the cryptographic proof of liabilities system can deterministically shuffle the sparse-tree leaf nodes periodically (e.g., prior to each audit of the sparse-tree) so that no information can be extracted by subsequent ordering.
  • the cryptographic proof of liabilities system provides many technical advantages and benefits over conventional proof of liabilities systems.
  • the cryptographic proof of liabilities system improves the accuracy and security with which conventional proof of liabilities systems determine various liabilities.
  • the cryptographic proof of liabilities system avoids many of the data leaks and exposures common to other schemes by utilizing a deterministic sparse-tree approach that effectively hides information about the users and accounts represented in the sparse-tree, in addition to hiding information about the sparse-tree itself (e.g., the tree size). In this way, the cryptographic proof of liabilities system avoids the data inaccuracies of conventional systems that are often exploited by malicious entities.
  • the cryptographic proof of liabilities system improves the accuracy of conventional systems by utilizing the structure of the deterministic sparse-tree to determine accurate liability proofs.
  • the cryptographic proof of liabilities system utilizes key derivations and verifiable random functions in connection with nodes at every level of the sparse-tree to ensure that a parent node accurately reflect liability information of both children nodes.
  • the cryptographic proof of liabilities system can ensure that a total liability reflected in the root node of the sparse-tree accurately reflects each contributing leaf node liability.
  • the cryptographic proof of liabilities system also improves the efficiency of conventional systems.
  • the cryptographic proof of liabilities system presents, to an auditor or user, an elegant and robust proof of liability based on a single generated deterministic sparse-tree.
  • the cryptographic proof of liabilities system minimizes the computational verification costs typically associated with proving the liabilities of an immutable database, such as a blockchain.
  • the cryptographic proof of liabilities system also provides various privacy and security advances over conventional systems.
  • the cryptographic proof of liabilities system improves the following privacy and security shortcomings common to conventional systems.
  • Account Information Leaks Conventional systems generally leak account information. For example, in a proof structured as a Merkle Tree, a verifying user can leam the balance belonging to a sibling leaf node in the Merkle Tree. Even when the leaf nodes are shuffled, a verifier can leam something about the distribution of balances. As will be described in greater detail, in one or more implementations the cryptographic proof of liabilities system ensures that no data about individual users (id or balance) is ever revealed, even between independent audits.
  • Exchange Information Leaks In publishing total liability amounts associated with exchanges, conventional systems generally expose information about the exchanges that can be exploited. For example, a malicious entity can extract business information on the success of an exchange’s business. As will be described in greater detail, in one or more implementations the cryptographic proof of liabilities system proves the option to reveal or not reveal total liabilities.
  • the cryptographic proof of liabilities system ensures each account holder receives an individual inclusion proof from the exchange containing only the nodes between their own leaf node and the root, while protecting against leaking information about the user inclusion proof requests. For example, utilizing conventional systems, a malicious prover can use the identities of inclusion proof requesting users to omit users who rarely or never check their inclusion proofs. As will be discussed further below, the cryptographic proof of liabilities system can guard against this type of leak using padding nodes.
  • Independent Verification Tool Conventional systems generally fail to provide users with an automated independent verification tool.
  • the cryptographic proof of liabilities system provides each account holder with an individual proof containing only the nodes between their own leaf node and the root.
  • Number of users As mentioned above, conventional systems often leak information about an exchange or other body that includes the number of users. This information can be exploited by malicious entities in various ways. As will be discussed in greater detail below, the cryptographic proof of liabilities system can generate proofs of liability that hide the total number of users such that that number is not leaked or discoverable. [0055] Implementation issues — As mentioned above, conventional system often leak user information to an auditor. As with the number of users above, this leaked information can be exploited by malicious entitles in various ways. The cryptographic proof of liabilities system, in contrast, can generate proofs of liability that do not expose user information to the auditor (including individual balances), unless it is required for dispute resolution and routine sampling.
  • a traditional proof of liability mainly consists of a commitment to each user’s balance and a proof that said balance is within a range. For all new users and users whose balance has changed, the commitment the proof is regenerated in a subsequent audit. For the other users, the proof of liability need not be regenerated. However, not changing the proofs for users whose balance remained unchanged will leak how many users were actively using their account between the two proofs. Thus, in one or more implementations, the cryptographic proof of liabilities system regenerates a complete proof of liability for all users in each audit such that this user information remains private.
  • deterministic sparse-tree refers to a binary tree data structure.
  • a deterministic sparse-tree includes a sparse Merkle tree that includes one or more leaf nodes, padding nodes, and a single root node.
  • a “leaf node” refers to a node at a lowest level of a sparse-tree. As will be described in greater detail below, a deterministic sparse-tree includes user information only in its leaf nodes. As used herein a “root node” refers to the top-most node of a sparse- tree. As will be described in greater detail below, a deterministic sparse-tree includes only one root node, and the root node of the deterministic sparse-tree includes a committed liability that reflects a total liability for all nodes in the deterministic sparse-tree.
  • internal nodes refer to nodes in the sparse-tree that are between the leaf nodes and the root node.
  • padded node refers to a node that does not reflect a user or account.
  • a padded node can include a node representing a simulated user with a committed balance of zero.
  • the cryptographic proof of liabilities system can utilize padded nodes in the sparse-tree to obscure a total number of authentic users included in the sparse-tree.
  • committed liability refers to an amount associated with a user (e.g., a number of coins, a monetary balance, a negative vote).
  • a committed liability can include an amount that is deterministically obscured by a homomorphic commitment such as a Pedersen commitment.
  • a homomorphic commitment is binding while revealing nothing about the committed value (e.g., the user’s liability).
  • total liability refers to a sum of liabilities (e.g., total liabilities represented by a deterministic sparse-tree such as a total number of coins in a blockchain exchange, total number of negative votes, etc.).
  • a deterministic sparse-tree such as a total number of coins in a blockchain exchange, total number of negative votes, etc.
  • the cryptographic proof of liabilities system recursively generates the sparse-tree such that the balance of the root node reflects the total liability for all nodes in the sparse-tree.
  • an “authentication path” refers to a list of nodes in a deterministic sparse-tree from a particular leaf node to the root node.
  • an authentication path from a user’s leaf node to the root node of a deterministic sparse-tree assists in proving that the user’s individual liability is reflected in the total liability for the entire sparse-tree.
  • a “deterministic function” refers to a function that returns the same result when applied to the same inputs. In other words, a deterministic function is not random or stochastic.
  • a “verifiable random function” refers to a pseudo-random function that provides publicly verifiable proofs of its outputs’ correctness.
  • a “key derivation function” refers to a cryptographic hash function that derives one or more secret keys from a secret value such as a master key or password using a pseudo-random function.
  • a “zero-knowledge range proof’ refers to a cryptographic method that allows a prover to prove to a verifier that a given value lies within a certain range.
  • a zero-knowledge range proof proves that a balance of a node is a small positive number within a given range.
  • an “immutable database” refers to a data collection including entries that cannot be modified once they are added.
  • a blockchain is a popular example of an immutable database.
  • FIG. 1 illustrates a schematic diagram of a distributed digital ledger transaction network 100 in which a ledger liabilities system 106 can be implemented.
  • the distributed digital ledger transaction network 100 includes a communication network 101, computer nodes 114 (which include validator node devices 108a-108b and full node devices 108c-108d), and client devices 112a-112n (having corresponding users 116a- 116n).
  • the distributed digital ledger transaction network 100 of FIG. 1 is depicted as having a particular number of components, the distributed digital ledger transaction network 100 can have any number of additional or alternative components (e.g., any number of computer nodes, client devices, or other components in communication with the ledger liabilities system 106 via the communication network 101).
  • FIG. 1 illustrates a particular arrangement of the communication network 101, the computer nodes 114, the client devices 112a-112n, and the users 116a-116n, various additional arrangements are possible.
  • the communication network 101, the computer nodes 114, and the client devices 112a-l 12n may be communicatively coupled with each other either directly or indirectly (e.g., through the communication network 101 discussed in greater detail below in relation to FIG. 11).
  • the computer nodes 114, and the client devices 112a-112n may include a computing device (including one or more computing devices as discussed in greater detail below with relation to FIG. 11).
  • the distributed digital ledger transaction network 100 includes the computer nodes 114.
  • the computer nodes 114 can generate, store, receive, and/or transmit data, including data corresponding to a digital ledger.
  • the computer nodes 114 can receive transaction requests and transmit transaction execution results.
  • at least one of the computer nodes 114 comprises a data server.
  • at least one of the computer nodes 114 comprises a communication server or a web-hosting server.
  • one or more of the computer nodes 114 include personal computing devices operated by a user.
  • the computer nodes can transmit data to one another.
  • a given computer node can transmit data to a particular computer node (i.e., one computer node) using point-to-point communication.
  • a given computer node can also transmit data to all other computer nodes using broadcasting techniques.
  • a computer node broadcasts data by transmitting the data to a random or semi-random subset of computer nodes with voting power (e.g., validator node devices).
  • the recipient validator node devices can then reshare (i.e., retransmit) to other computer nodes in the same way until the data known to (i.e., stored at) every computer node stabilizes.
  • a computer node transmits data to other computer nodes in several steps. For example, at a first step, the transmitting computer node can make the data available (i.e., passively publish the data). The transmitting computer node can then send a notification to each potential recipient computer node, indicating that the data is now available. Subsequently, the transmitting computer node can let the potential recipient computer nodes connect to the transmitting computer node and retrieve the available data. [0071] As shown FIG. 1 , the computer nodes include the validator node devices 108a- 108b and the full node devices 108c-108d.
  • the validator node devices 108a- 108b and the full node devices 108c-108d can perform different functions; though, in some embodiments, the validator node devices 108a-108b and the full node devices 108c-108d perform, at least some, overlapping functions. For example, in one or more embodiments, both the validator node devices 108a- 108b and the full node devices 108c-108d can service queries for information regarding transactions, events, or states of user accounts. [0072] Additionally, as shown in FIG. 1 the computer nodes 114 include the ledger liabilities system 106.
  • the ledger liabilities system 106 utilizes the computer nodes 114 to execute transactions and service queries for information.
  • the ledger liabilities system 106 can use the validator node devices 108a-108b to execute transactions and implement a consensus protocol.
  • the ledger liabilities system 106 can utilize the full node devices 108c-108d to receive and service queries for information.
  • the ledger liabilities system 106 implements a Byzantine-fault-tolerant consensus approach.
  • the validator node devices 108a-108b implement a modified HotStuff consensus protocol.
  • the computer nodes 114 select a lead validator node device to drive consensus for a transaction block.
  • the lead validator node device is selected deterministically (e.g., via a round-robin selection from a pre-defmed list).
  • the lead validator node device is selected non- deterministically (e.g., candidate validator node devices attempt to solve a cryptographic puzzle or participate in a cryptographic lottery, and the winner becomes the lead validator node device).
  • a lead validator node device can assemble a transaction block containing transactions received from one or more of the client devices 112a-l 12n and propose the transaction block to the other validator node devices.
  • the other validator node devices execute the transactions within the transaction block and then vote on the execution results.
  • a fixed, unknown subset of malicious validator node devices also known as “Byzantine validator node devices” within the current set of validator node devices.
  • all other validator node devices (known as “honest validator node devices”) follow the consensus protocol scrupulously.
  • the ledger liabilities system 106 can operate so that N > 3f In other words, the ledger liabilities system 106 can operate so that the combined voting power of the malicious node devices does not exceed the security threshold f.
  • a subset of nodes whose combined voting power M verifies a transaction block can be referred to as a quorum.
  • the ledger liabilities system 106 can further operate under a “BFT assumption” that indicates, for every two quorums of nodes in the same epoch, there exists an honest node that belongs to both quorums.
  • the lead validator node device Upon determining that a threshold number of votes confirming the execution results have been received, the lead validator node device can determine to finalize the block of transactions and transmit confirmation to the other validator node devices.
  • the ledger liabilities system 106 can accommodate validators that arbitrarily deviate from the protocol without constraint. Moreover, the ledger liabilities system 106 can utilize a byzantine fault tolerance consensus approach to mitigate failures caused by malicious or hacked validators. Specifically, in one or more embodiments, the ledger liabilities system 106 utilizes 2f + 1 votes as the threshold number of votes, where f refers to anumber of Byzantine voters (e.g., malicious, fraudulent, or untrustworthy validators) that can be accommodated by the consensus protocol.
  • f refers to anumber of Byzantine voters (e.g., malicious, fraudulent, or untrustworthy validators) that can be accommodated by the consensus protocol.
  • f reflects the number of Byzantine voters that can be accommodated while preventing attacks or other unsafe behaviors (e.g., double-spends or forks).
  • 2 f+ 1 votes corresponds to just over two-thirds of the validator node devices participating in consensus.
  • each validator node device can commit the transaction results to storage. Indeed, in one or more embodiments, each validator node device generates data structures for storing data relevant to the digital ledger (e.g., a transaction data structure, a state data structure, and an event data structure). The validator node devices can update these data structures based on the execution results when the execution results achieve consensus. In particular, each validator node device can generate and maintain an independent copy of the data structures and then update the data structures stored at that validator node device based on the execution results.
  • data relevant to the digital ledger e.g., a transaction data structure, a state data structure, and an event data structure.
  • the validator node devices can update these data structures based on the execution results when the execution results achieve consensus.
  • each validator node device can generate and maintain an independent copy of the data structures and then update the data structures stored at that validator node device based on the execution results.
  • a full node device can receive a query for information.
  • the full node device can locate the relevant data within the data structures stored at the full node device and transmit the data to the requesting client device.
  • each full node device can generate and maintain an independent copy of the data structures.
  • the full node device can communicate with the validator node devices 108a-108b to identify the results of executing transactions and update the data structures stored at the full node device accordingly.
  • the full node device can further submit a proof (e.g., a Merkle proof) to demonstrate the accuracy of the provided data in response to receiving the query for information.
  • the full node device can implement the cryptographic proof of liabilities system 102 described below to provide deterministic sparse-tree based cryptographic proof of liabilities.
  • the client devices 112a-112n include computer devices that allow users of the devices (e.g., the users 116a-l 16n) to submit transaction requests and queries for information.
  • the client devices 112a-112n can include smartphones, tablets, desktop computers, laptop computers, or other electronic devices (examples of which are described below in relation to FIG. 11).
  • the client devices 112a-112n can include one or more applications (e.g., the client application 110) that allow the users 116a- 116n to submit transaction requests and queries for information.
  • the client application 110 can include a software application installed on the client devices 112a-112n.
  • the client application 110 can include a software application hosted on one or more servers, which may be accessed by the client devices 112a- 112n through another application, such as a web browser.
  • a subset of the client devices 112a-112n can have cryptographic keys to modify or manage features of the distributed digital ledger transaction network (referred to as “authorized devices”).
  • authorized devices or authorized accounts corresponding to authorized devices
  • consensus protocols and collective agreement among the authorized devices.
  • authorized devices can manage changes to the set of validator node devices participating in consensus (i.e., voting rights), changes to the processes utilized in validating rejections or distributing transaction fees (i.e., gas) amongst the computer nodes 114, and/or changes to tangible monetary reserves (e.g., diverse real-world assets) utilized to back digital assets (e.g., a cryptographic currency) on the distributed digital ledger transaction network.
  • consensus i.e., voting rights
  • tangible monetary reserves e.g., diverse real-world assets
  • back digital assets e.g., a cryptographic currency
  • the distributed digital ledger transaction network 100 further includes one or more reporting managers (not shown).
  • the reporting manager can track and report actions taken by the components of the distributed digital ledger transaction network 100 (e.g., one of the validator node devices 108a- 108b) for which rewards should be provided or fees extracted.
  • Some actions that the reporting manager can track and report include, but are not limited to, a client device submitting a transaction request, a lead validator node device proposing or failing to propose a transaction block, a lead validator node device proposing an incorrect or malformed transaction block, validator node devices participating in consensus, validator node devices committing a block of transactions to storage, and general information dissemination (whether among the computer nodes 114 or to the client devices 112a-112n).
  • the reporting manager reports such actions to the computer nodes 114 to determine and carryout the corresponding reward or fee.
  • the reporting manager can be implemented by any of the devices of the distributed digital ledger transaction network 100 shown in FIG. 1 (e.g., implemented by a computer nodes 114) or another computing device.
  • the ledger liabilities system 106 can be implemented in whole, or in part, by the individual elements of the distributed digital ledger transaction network 100. Indeed, although FIG. 1 illustrates the ledger liabilities system 106 implemented with regards to the computer nodes 114, different components of the ledger liabilities system 106 can be implemented in any of the components of the distributed digital ledger transaction network 100. In particular, part of, or all of, the ledger liabilities system 106 can be implemented by a client device (e.g., one of the client devices 112a-112n).
  • the ledger liabilities system 106 can utilize the client devices 112a-l 12n to perform various functions.
  • the ledger liabilities system 106 can utilize a client device to poll one or more of the computer nodes 114 for transaction event updates and request data corresponding to a sequence of events.
  • the ledger liabilities system 106 can utilize a client device to generate a transaction request.
  • the ledger liabilities system 106 can utilize a client device to identify a main public address identifier and sub-address identifier corresponding to a user account and then encrypt the sub- address identifier using an encryption key.
  • the ledger liabilities system 106 can then utilize the client device to generate and submit a transaction request associated with the user account using the main public address identifier and the encrypted sub-address corresponding to that user account.
  • the ledger liabilities system 106 comprises the ledger transaction system 106 as described in U.S. Patent Application No. 16/442,476 filed on June 15, 2019 and hereby incorporated by reference in its entirety.
  • the cryptographic proof of liabilities system 102 can utilize one or more cryptographic primitives, algorithms, or techniques to provide the above-identified advantages. An overview of such cryptographic primitives, algorithms, or techniques is now provided.
  • the cryptographic proof of liabilities system 102 can utilize Merkle trees in one or more embodiments.
  • Merkle trees are hierarchical data structures that enable secure verification of collections of data.
  • each node has been given an index pair (i; j) and is represented as N(i;j).
  • the indexes i,j are numerical labels that are related to a specific position in the tree.
  • the i ⁇ j case corresponds to an internal or parent node, which is generated by recursively hashing and concatenating child nodes, until one parent (the Merkle root node) is found.
  • the tree depth M is defined as the lowest level of nodes in the tree, and the depth m of a node is the level at which the node exists.
  • the cryptographic proof of liabilities system 102 can utilize a Merkle tree to verify that some data packet Di is a member of a list or set (known as set-membership) of N data packets ⁇ D1, . .. , DN.
  • the mechanism for verification is known as a Merkle proof, and includes obtaining a set of hashes known as the authentication path for a given data packet Di and Merkle root R.
  • the authentication path for a data packet is the minimum list of hashes required to reconstruct the root R by way of repeated hashing and concatenation.
  • the cryptographic proof of liabilities system 102 can utilize a summation Merkle tree, which is a modified Merkle tree.
  • a summation Merkle tree is characterized as having every leaf consist of (v, h) where v is a numeric value (i.e., balance) and h is a blob (e.g., usually the result of a hash result under a collision-resistant hash function H).
  • v a numeric value
  • H a collision-resistant hash function
  • a summation Merkle tree can comprise a secure proof of sum correctness scheme, if the total sum at the root node equals the sum of the amounts of all leaves in the tree and the cumulative relation between the internal node and its children holds. Every intersection node of two successfully verified paths remains the same as the one on the established summation Merkle tree, assuming the collision resistance of the hash functions.
  • the scheme is secure if the claimed liabilities are no less than the sum of the amount in the dataset when no verification fails.
  • h 2 )) in order for the corresponding parent internal node to achieve summation correctness. This approach is secure, while h H(v 1 + v 2
  • the cryptographic proof of liabilities system 102 can utilize a commitment scheme.
  • the cryptographic proof of liabilities system 102 can utilize Pedersen commitments.
  • the commitments are also computationally binding: if an adversary can open a commitment c in two different ways (for the same r, two different values v and v l ), then the same adversary can be used to compute log h (g) and thus break the discrete logarithm problem in G.
  • the cryptographic proof of liabilities system 102 can utilize commitments that are additively homomorphic.
  • the cryptographic proof of liabilities system 102 can utilize a commitment scheme to protect some user balances, while also exposing other user balances. For example, in the case of an exchange, the cryptographic proof of liabilities system 102 expose balances less than a threshold amount, e.g., one dollar or two dollars. The cryptographic proof of liabilities system 102 can do so to reduce processing times and computing resources to encrypt these balances.
  • a threshold amount e.g., one dollar or two dollars.
  • the cryptographic proof of liabilities system 102 can utilize a set membership proof to allow a prover to prove, in a zero-knowledge way, that their secret lies in a given public set.
  • the cryptographic proof of liabilities system 102 can utilize such a proof, for instance, in the context of electronic voting, where the voter needs to prove that his secret vote belongs to the set of all possible candidates.
  • the cryptographic proof of liabilities system 102 can utilize such a proof to prove inclusion of a user’s balance to the reported total value.
  • Another popular special case of the set membership problem occurs when the set S consists of a range [a, a + 1, a + 2, ...
  • the cryptographic proof of liabilities system 102 can be defined with respect to any commitment scheme. Thus, in particular, if Com is a perfectly-hiding scheme, then the language ⁇ S includes of all commitments (assuming that S is non-empty).
  • the protocol can be a proof of knowledge.
  • the cryptographic proof of liabilities system 102 can also utilize Zero-Knowledge Range Proofs (ZKRP) to allow for proofing that a number lies within a certain range.
  • ZKRP Zero-Knowledge Range Proofs
  • S is a numerical range such as [0, 2 64 ⁇ 1].
  • the cryptographic proof of liabilities system 102 can also utilize a Verifiable Random Function (VRF), which is pseudorandom function that gives a public verifiable proof of its output based on public input and private key.
  • VRF Verifiable Random Function
  • the cryptographic proof of liabilities system 102 can utilize a VRF to map inputs to verifiable pseudorandom outputs.
  • the cryptographic proof of liabilities system 102 can utilize a VRF to provide deterministic pre-commitments that can be revealed later using proofs. More particularly, the cryptographic proof of liabilities system 102 can utilize VRFs for deterministic and unique generation of audit ids and inherently Merkle trees.
  • the cryptographic proof of liabilities system 102 can utilize a VRF that is a triple of the following algorithms: [0100] KeyGen(r) ⁇ (VK, SK).
  • the cryptographic proof of liabilities system 102 can utilize a Key generation algorithm to generate a verification key VK and a secret key SK on random input r.
  • the cryptographic proof of liabilities system 102 can utilize an Evaluation algorithm to take the secret key SK and message M as input and produce pseudorandom output string O and proof ⁇ .
  • the cryptographic proof of liabilities system 102 can utilize a verification algorithm that takes input as verification key VK , message M, output string O, and proof ⁇ .
  • the verification algorithm can output 1 if and only if it verifies that O is the output produced by the evaluation algorithm on input secret key SK and message M , otherwise the verification algorithm outputs 0.
  • the cryptographic proof of liabilities system 102 can utilize a VRF to support uniqueness according to which, for any fixed public VRF key and for any input alpha, there is a unique VRF output beta that can be proved to be valid.
  • the cryptographic proof of liabilities system 102 can utilize a VRF where Uniqueness holds even for an adversarial Prover that knows the VRF secret key SK.
  • the cryptographic proof of liabilities system 102 can utilize a VRF that is collision resistant. In other words, the cryptographic proof of liabilities system 102 can utilize a VRF where Collison resistance holds even for an adversarial Prover that knows the VRF secret key SK. [0105] The cryptographic proof of liabilities system 102 can utilize a VRF that is a pseudorandom function. Pseudorandom-ness ensures that the VRF hash output beta (without its corresponding VRF proof pi) on any adversarially-chosen “target” VRF input alpha looks indistinguishable from random for any computationally bounded adversary who does not know the private VRF key SK.
  • Publicly accessible databases are an indispensable resource for retrieving up— to-date information. But publicly accessible databases also pose a significant risk to the privacy of the user, since a curious database operator can follow the user’s queries and infer what the user is after. Indeed, in cases where the user’s intentions are to be kept secret, users are often cautious about accessing the database. [0107] In recurring audits, an important property that a complete distributed liabilities proof solution should satisfy, is to serve the inclusion proofs to clients without learning which proof has been requested. This is desirable, because the audited entity can extract information about users who never or rarely check their proofs and thus the risk from omitting their balances from upcoming audit proofs is statistically lower.
  • Private Information Retrieval is a protocol that allows a client to retrieve an element of a database without the owner of that database being able to determine which element was selected. While this problem admits a trivial solution - sending the entire database to the client allows the client to query with perfect privacy - there are techniques to reduce the communication complexity of this problem, which can be critical for large databases.
  • SPIR Strong Private Information Retrieval
  • SPIR is private information retrieval with the additional requirement that the client only learn about the elements for which he or she is querying, and nothing else. This requirement captures the typical privacy needs of a database owner.
  • cryptographic proof of liabilities system 102 can utilize deterministic sparse-tree based cryptographic proof of liabilities.
  • the cryptographic proof of liabilities system 102 utilizes a Merkle tree.
  • each leaf node contains a user’s liability, as well as the hash of the balance concatenated with the customer id and a fresh nonce (i.e., a hash-based commitment).
  • the cryptographic proof of liabilities system 102 can add to the hash balances separately instead of aggregating them first.
  • An internal node stores the aggregate balance of its left child and right child, as well as the hash of its left and right children data.
  • the root node stores the aggregate of all customers’ liabilities.
  • the cryptographic proof of liabilities system 102 can send to the user their nonce and the sibling node of each node on the unique path from the user’s leaf node to the root node, this is called the authentication path.
  • the cryptographic proof of liabilities system 102 splits liabilities into multiple leaves (e.g., a user’s liabilities can be split into multiple leaves than be associated with a single leaf).
  • the cryptographic proof of liabilities system 102 can shuffle all the leaves before adding them to the tree.
  • FIG. 2 illustrates one embodiment of how the cryptographic proof of liabilities system 102 can split balances/liabilities and shuffle the leaves.
  • the cryptographic proof of liabilities system 102 can randomly split the balance associated with the leaf node 202a six ways.
  • the cryptographic proof of liabilities system 102 ways respectively.
  • the cryptographic proof of liabilities system 102 can generate a leaf node for each split balance such that each generated leaf node includes the information from the original leaf node 202a-202c (e.g., user_id, audit_id) in addition to the split balance amount.
  • the cryptographic proof of liabilities system 102 replaces the original three leaf nodes 202a-202b with sixteen split- balance leaf nodes.
  • the cryptographic proof of liabilities system 102 can shuffle the split-balance leaf nodes (204). For example, as shown in FIG. 2, the cryptographic proof of liabilities system 102 can shuffle the split-balance leaf nodes such that a malicious entity would be unable to determine 1) the total liability represented across all nodes (e.g., 50), 2) a total number of users (e.g., 3), and 3) each user’s individual balance.
  • each user will receive multiple authentication paths and although the tree height might grow, less information is exposed by sibling leaves, while the size of user-base is obfuscated.
  • the cryptographic proof of liabilities system 102 can limit exposure of user liabilities to both an auditor and other users, fully protect identifies as there is no link between splits of the same liabilities, conceal the total number of users, prevent subsequent proofs of solvency from learning any of the foregoing by utilizing independent audits and different split/shuffling, and prevent correlation of balances between different audits and prevent extraction of statistical data around specific user’s profit/loss by utilizing randomized splitting and shuffling.
  • the cryptographic proof of liabilities system 102 can replace visible balances with homomorphic commitments.
  • the cryptographic proof of liabilities system 102 can utilize a zero-knowledge proof (ZKP) to prevent an entity from inserting fake accounts with negative balances.
  • the cryptographic proof of liabilities system 102 can utilize a zero-knowledge range proof (ZKRP) with an aggregation technique, such as that in Bulletproofs, so that any proof is dominated by one commitment per user, thereby ensure that the proof is compact.
  • ZKP zero-knowledge proof
  • ZKRP zero-knowledge range proof
  • the cryptographic proof of liabilities system 102 can keep the total value of the liabilities secret (from the auditor, public or users), and prevent exposure of individual balances (i.e., from sibling nodes).
  • the cryptographic proof of liabilities system 102 can utilize a zero-knowledge range proof combined with a deterministic sparse Merkle tree construction.
  • the cryptographic proof of liabilities system 102 can utilize Key Derivation Functions (KDF) on top of VRFs to compute each audit id and blinding factor deterministically.
  • KDF Key Derivation Functions
  • a malicious entity can put all of the users that based on some analysis have higher probability of checking their proofs next to each other, and thus statistically, only a small part of the tree might be verified for correctness.
  • the cryptographic proof of liabilities system 102 allows for better dispersion of users’ leaves by allowing deterministic shuffles on each audit.
  • the cryptographic proof of liabilities system 102 can sort the hash values of the leaves before putting them on the tree. Because the cryptographic proof of liabilities system 102 computes hashes deterministically, due to the properties of VRF, a malicious entity cannot arbitrarily fix the relational ordering of user nodes in the tree.
  • the cryptographic proof of liabilities system 102 can also ensure that this deterministic ordering is always different between different audit rounds, thus no information can be extracted by subsequent ordering.
  • the complete proof can be a full binary summation tree of height H, where the leaf data is generated from user’s account data by applying a deterministic function for the creation of a unique audit id and blinding factor per user. A user’s audit id is sometimes called a nonce.
  • FIG. 3 shows the full process for the generation of b_factor (blinding factor ) and h (user’s leaf hash).
  • the cryptographic proof of liabilities system 102 can generate the audit_id 304a (or alternatively the audit_id 304b) based on information from the user’s leaf node 302. For instance, the cryptographic proof of liabilities system 102 can generate the audit_id 304a based on first applying a verifiable random function to the user_id and amount, both taken from the user leaf nod 302, in association with an audit_seq_id (e.g., a sequence identifier for the current audit) and an “audit_seed_salt” (e.g., a seed amount for the randomizer).
  • an audit_seq_id e.g., a sequence identifier for the current audit
  • an “audit_seed_salt” e.g., a seed amount for the randomizer
  • the cryptographic proof of liabilities system 102 can next apply a key derivation function to the output of that verifiable random function to determine the audit_id 304a.
  • the cryptographic proof of liabilities system 102 can determine the audit_id 304b by applying a key derivation function to the amount (e.g., taken from the user leaf node 302) in connection with the audit_seq_id and an audit_key (e.g., a secret value specific to the current audit).
  • the cryptographic proof of liabilities system 102 can also determine other values based on the audit_id 304a. For example, as shown in FIG.
  • the cryptographic proof of derivation function to the audit_id 304a in connection with “b_salt” e.g., another randomizer value
  • the cryptographic proof of liabilities system 102 can determine h_seed 308 (e.g., a seed value for the user hash function) by applying a key derivation function to the audit_id 304a in connection with “h_salt” (e.g., another randomizer value).
  • the cryptographic proof of liabilities system 102 can determine u_hash 310 (e.g., the user hash) by applying a key derivation function to the user_id (e.g., from the user leaf node 302) in connection with h_seed 308.
  • the cryptographic proof of liabilities system 102 can utilize a sparse Merkle tree.
  • the cryptographic proof of liabilities system 102 can add padding nodes 404a and 404b to 404n (e.g., fake accounts with zero balances) to the sparse-tree including real user leaf nodes 402a, 402b, 402c.
  • the cryptographic proof of liabilities system 102 can obfuscate the population size of the user-base.
  • the cryptographic proof of liabilities system 102 can minimize the number of fake users (with zero balances) for padding purposes.
  • the cryptographic proof of liabilities system 102 can utilize padding, in one or more embodiments, only to the roots of empty sub-trees and thus, support tree heights that were not previously possible without extensive and prohibitive computational resources.
  • the cryptographic proof of liabilities system 102 generates the deterministic sparse-tree 500 with user leaf nodes 502a, 502b, and 502c.
  • the cryptographic proof of liabilities system 102 obfuscates the number of users by further adding padding nodes 504a, 504b, 504c, 504d, 504e, and 504f.
  • the cryptographic proof of liabilities system 102 adds the padding nodes 504a-504f only to the roots of empty sub-trees 506a, 506b, 506c, 506d, 506e, and 506f (e.g., a node with no children is considered to be the root of an empty sub-tree, as with the padding nodes 504a, 504b, and 504d).
  • the cryptographic proof of liabilities system 102 can pick a big enough tree that will work for next x years even in the most promising forecasting scenarios.
  • the tree size will likely not need to be updated, which is desirable because updating the tree size would otherwise reveal that something changed (i.e., more users (that surpass previous padding size) entered the system).
  • the cryptographic proof of liabilities system 102 can provide, to each requesting user, an authentication path of 40 nodes. Accordingly, the cryptographic proof of liabilities system 102 selects and utilizes a ZKRP system that is as succinct as possible, thus minimizing verification costs.
  • the cryptographic proof of liabilities system 102 can estimate the bounds on the number of zero-nodes to add to the tree as follows: (1) in one embodiment all user nodes occupy the left-most leaves of the tree, therefore filling-in the left-most lowest sub-tree of height m, the zero-nodes then need to be added along the path from the root of this sub-tree to the root, there will be at most (H ⁇ m) of them added; (2) in another embodiment, all users are evenly dispersed in the leaves of the tree, therefore the lowest sub-trees of height (H ⁇ m) will have only one node each and will need (H m) of zero-nodes to be added to produce the roots of the sub-trees, the number of zero-n
  • the deterministic sparse-tree should be kept private by the audited entity in order to protect the privacy of its users.
  • the cryptographic proof of liabilities system 102 can publish only the root node, preferably in an immutable public bulletin board (i.e., one or more blockchains) and each individual user should securely and privately receive their own partial proof tree (authentication path).
  • the cryptographic proof of liabilities system 102 can help ensure every user has exactly the same view of the reported proof of liabilities commitment.
  • the cryptographic proof of liabilities system 102 creates a binary tree that is not a full tree and can in theory have any shape.
  • the cryptographic proof of liabilities system 102 can implement a fixed-height sparse tree solution (e.g., as shown in FIG. 5) to: a) have a consistent and fair authentication path length for every user and b) provide better estimates on population size exposure up to a certain limit, even when users collude between themselves.
  • the cryptographic proof of liabilities system 102 can utilize a random scattering algorithm to place user leaves in the tree, which is both unique and deterministic.
  • the cryptographic proof of liabilities system 102 can utilize a random scattering algorithm in order to prove that indexes were not manipulated by the prover (i.e., putting those who regularly check their inclusion proofs next to each other with the aim to corrupt parts of the tree that with high probability will not be checked).
  • the cryptographic proof of liabilities system 102 uses VRFs for computing audit_ids, then order users based on their unique and deterministic u_hash value.
  • the cryptographic proof of liabilities system 102 can randomly place/scatter them in the tree and then deterministically compute the padding nodes based on the output distribution (again by using VRFs that take as an input the “fake” node index).
  • VRFs that take as an input the “fake” node index.
  • the cryptographic proof of liabilities system 102 can utilize a heuristic method to circumvent this problem, which works well when S ⁇ L, by picking the index randomly inside a range close to the expected index.
  • the cryptographic proof of liabilities system 102 can use a ZKP- based set membership proof to hide any ordering or position evidence.
  • Leaf nodes can represent either user data or padding (fake users with a liability balance of zero) that has been deterministically generated via VRF.
  • the deterministic sparse-tree 600 can fit up to four users, but as shown in this example, only one padding node 604 is required due to the sparse tree properties.
  • the cryptographic proof of liabilities system 102 can deterministically generate the sparse-tree 600 so that it can be regenerated in case of a full audit.
  • the VRF takes as input the index of the padding node to ensure uniqueness. Additionally, the value of any padding node in the sparse- tree 600 is a commitment to zero. [0133]
  • the cryptographic proof of liabilities system 102 configures the leaf nodes 602a, 602b to possess the following values: • user_id: A unique identifier for the user. The user must ensure the uniqueness of this value so using their e-mail or phone number is recommended. Note that the cryptographic proof of liabilities system 102 need not ever reveal this information.
  • • node_index The node index that is used as the deterministic seed (input) to the KDF/VRF of padding nodes.
  • the cryptographic proof of liabilities system 102 can ensure that when user’s data is revealed, the committed balance is not exposed and vice versa.
  • the cryptographic proof of liabilities system 102 does not include the range proofs 610a, 610b, 610c, 610d, 610e ( ⁇ ’s) as part of the construction of the deterministic sparse-tree 600, but has them accompany the authentication path which is sent to users.
  • the cryptographic proof of liabilities system 102 can generate the internal node 606 using the function described below.
  • the cryptographic proof of liabilities system 102 can configure an encrypted balance of the internal node 606 to be the result of adding of its children’s homomorphic commitments (e.g., the balances of the leaf nodes 602a and 602b).
  • the cryptographic proof of liabilities system 102 can configure a hash of the internal node 606 to be the concatenation of all children commitments and hashes (e.g., the commitments and hashes of the leaf nodes 602a, 602b), fed to some hash function, for instance sha256.
  • he cryptographic proof of liabilities system 102 can configure the root node 608 of the deterministic sparse-tree 600 in the same manner as all internal nodes (e.g., the internal node 606) to possess a balance commitment 702 and a hash 704.
  • the cryptographic proof of liabilities system 102 publishes the data associated with the root node 608 publicly in one or more immutable databases (i.e., blockchains), so that all users can ensure that they are verifying against the same proof tree.
  • immutable databases i.e., blockchains
  • this data can be accompanied by a range proof 610e of the balance commitment 702, while the full payload, including a timestamp 706 and metadata information 708 related to the audit (i.e., the audit round this proof refers to), can be signed by a prover (indicated by any type of certification).
  • the cryptographic proof of liabilities system 102 configures an authentication path to contain only the nodes from the complete tree which a given user needs in order to verify he/she was included in the tree. Unlike the original Maxwell scheme where users observe sibling values, each node is accompanied by a range proof on the commitment value to ensure it is a small positive number.
  • the cryptographic proof of liabilities system 102 can generate an authentication path by starting with the user’s leaf node and including every parent node up to the root. To illustrate, in FIG. 6, the cryptographic proof of liabilities system 102 can generate an internal node 606, and the root node 608.
  • the cryptographic proof of liabilities system 102 can then add the sibling at each level, and thus in practice an authentication path is a list of sibling nodes per height layer.
  • the cryptographic proof of liabilities system 102 can add the leaf node 602b, and the padding node 604 to the authentication path for the leaf node 602a. This can enable the user associated with the leaf node 602a to verify independently that their balance is included in the reported liabilities by following their path to the root node 608, checking at each node in the authentication path that the committed balance is the product of its two children node committed balances.
  • the cryptographic proof of liabilities system 102 can avoid including nodes that can be directly computed, in one or more embodiments, to save space and encourage users to compute them by themselves.
  • the cryptographic proof of liabilities system 102 can also send the range proofs of the computed nodes as well.
  • the cryptographic proof of liabilities system 102 generates an authentication path such that a verifier receives the range proofs of sibling nodes only.
  • the cryptographic proof of liabilities system 102 can additionally include the range proofs of the computed nodes in the authentication path.
  • an exploitable scenario would be to use a range of [0, N ] where N is close to the curve order l of the commitment scheme.
  • the cryptographic proof of liabilities system 102 can configure the allowed range of each commitment to be is very close to l/H, when the cryptographic proof of liabilities system 102 adds them all together in the authentication path, no intermediate or final value can surpass the group order l.
  • a scenario includes Alice, who wants to make a transaction in a cryptocurrency exchange. Alice connects to the exchange via TLS and authenticates herself using her password. Both Alice and the exchange know for sure with whom they are communicating. This, however, does not necessarily mean that both Alice and the exchange can fully trust each other. Alice needs a confirmation that the transaction actually happened, and that the exchange cannot act without her permission. On the other hand, the exchange wants evidence that it indeed received a transaction order from Alice.
  • the cryptographic proof of liabilities system 102 provides one potential solution; namely, utilizing signatures or mutual contract signing per transaction. In some applications of the cryptographic proof of liabilities system 102 though (i.e., disapproval voting), receiving a signed ticket/email from the prover only would be sufficient.
  • the cryptographic proof of liabilities system 102 can ensure that the prover is not be able to track who requested or downloaded his/her inclusion proofs. For example, such information could expose data around who is regularly checking the proofs and who rarely or never does. A malicious prover can omit adding balances from users with low probability to check. However, if the prover does not have a clue on who requested and executed the inclusion authentication path, he/she can only speculate and the risk of being caught is a lot higher. [0152] It has already been suggested that ideally, users should use verified and audited third party or locally installed tools to verify the proofs.
  • the cryptographic proof of liabilities system 102 enables users to privately download the leaf index and the audit id (or a related VRF output) associated with their individual leaf node. For instance, as shown by the audit_id 304b shown in FIG. 3, the cryptographic proof of liabilities system 102 can also provide unique audit ids at the time of registration. [0153] In particular, the cryptographic proof of liabilities system 102 can use this audit id via a KDF to be able to derive the commitment’s blinding factor. The cryptographic proof of liabilities system 102 can then broadcast or serve the proofs via third party services using PIR (private information retrieval), ORAM (oblivious RAM) and network mixing services.
  • PIR private information retrieval
  • ORAM oblivious RAM
  • the second approach can allow for lighter clients and the encryption protects the PIR protocol against users who request to download other proof indexes (even if they manage to receive them, they cannot decrypt the commitments). All in all, using deterministic KDF derived audit ids, the cryptographic proof of liabilities system 102 can use regular PIR to simulate an authenticated PIR protocol. [0154] In one or more embodiments, an audit may require full access or random sampling of nodes, especially when investigation takes place due to a dispute. As shown in FIG.
  • the fact that the padding nodes 806a-806c are constructed with a different input than real user nodes can be used to distinguish between real and artificial users/nodes (e.g., see FIG.
  • the cryptographic proof of liabilities system 102 lets each account in ACCS be a tuple (uid, bal) where uid is a unique user identifier associated with the account and bal is the current balance for the account used in the proof of liabilities.
  • ( ⁇ aud ) ⁇ AuditorProve(aud).
  • the AuditorProve algorithm takes as input the audit material aud output by the AuditSetup and a proof of liability ⁇ aud to be verified by the auditor. The proof intends to show that the claimed total is consistent with the public component of the setup audpk.
  • the AuditorVerify algorithm takes as input the declared total liabilities TL, the public audit material aud pk and the proof ⁇ aud .
  • the AuditorVerify algorithm outputs 1 if the verification passes and 0 otherwise.
  • ⁇ uid ⁇ UserProve(uid, aud).
  • the UserProve algorithm takes as input the unique user identifier uid for a particular user and the audit material and outputs a user specific proof ⁇ uid. ⁇ 0, 1 ⁇ ⁇ UserVerify(uid, audpk, ⁇ uid, bal).
  • the UserVerify algorithm takes as input, the user identifier uid and its balance bal, the public audit material aud pk and a proof ⁇ uid , and outputs 1 if the proof verifies and 0 otherwise.
  • the cryptographic proof of liabilities system 102 can bound the probability that a malicious prover can eliminate more than t user balances from the total liabilities using a function ⁇ (c, t), given that the AuditorVerify outputs 1 and UserVerify outputs 1 for a uniformly chosen fraction c of total balances in ACCS. More formally:
  • the cryptographic proof of liabilities system 102 can also consider privacy guarantees against dishonest users and a dishonest auditor separately.
  • An auditor who does not collude with any users only sees the public portion of the audit material audpk, the total liabilities, as well as the proof provided by the prover i.e. ⁇ aud.
  • the cryptographic proof of liabilities system 102 refers to this as the auditor’s view in a real execution of the PoL scheme and denote it by ViewAuditor(ACCS).
  • the cryptographic proof of liabilities system 102 can then require that this view can be simulated by a PPT simulator (e.g., a probabilistic polynomial time simulator) that does not see the information in ACCS and only has access to leakage function L(ACCS) which depends on the particular scheme. Examples of such leakage functions are
  • and liab(ACCS). More formally: [0162] A subset of users U ⁇ u 1 , . .. , u n ⁇ , who can collude among each other, get to see the public audit material audpk, those users’ balances i.e.
  • BalU ⁇ (ui, a s well as the set of proofs generated by the prover i.e. ⁇ u1 , . . . , ⁇ un ⁇ .
  • This can be referred to as the adversary’s view in the real execution of the PoL scheme and denote it by ViewAU (ACCS) where AU denotes an adversary who controls the users in U.
  • the cryptographic proof of liabilities system 102 then require that this view can be simulated by a PPT simulation that only sees the balances of users in U as well as a leakage function L(ACCS) which depends on the particular scheme. More formally: [0163] Centralized Maxwell + Setup: [0164] Centralized Maxwell + Prove and Verify algorithms:
  • the cryptographic proof of liabilities system is described herein primarily with reference to proving solvency of cryptocurrency exchanges, other embodiments are possible.
  • the cryptographic proof of liabilities system can prove solvency in connection with other applications, several of which are described below.
  • the cryptographic proof of liabilities system provides a proof of total liabilities or obligations or “negative” votes in a way that every user whose value/balance should be included in the aggregated liabilities can transparently verify his/her inclusion in the proof, without learning any information about other users’ balances.
  • Proof of Solvency The cryptographic proof of liabilities system can generate a proof of solvency.
  • a proof of solvency is a public proof to verify that a custodial service does not run as a fractional reserve, e.g., some of the customer assets could not be withdrawn at any given moment.
  • a proof of solvency consists of two components: 1) proof of liabilities, and 2) proof of reserves.
  • the cryptographic proof of liabilities system can provide proofs of solvency in connection with any blockchain exchange and/or custodial wallet to transparently prove solvency to a auditors and users alike.
  • Disapproval Voting The term negative voting is sometimes used for allowing a voter to reject the entire field of candidates; it can also mean that the only option offered voters is to vote against one or more candidates, but it is sometimes used for systems that allow a voter to choose whether to vote for or against a candidate.
  • a negative (or disapproval) vote is a vote against a candidate, proposal, or service (e.g., negative feedback for hotels or restaurants) and is either counted as minus one or as a weight.
  • disapproval voting requires that only negative measures or choices be presented. For instance, disapproval voting schemes generally includes that there is no incentive for the prover to increase the amount of these votes.
  • the cryptographic proof of liabilities system described herein can prove liability in connection with a disapproval voting scheme, where every candidate receives negative votes and stores them in a local ledger.
  • a disapproval voting scheme includes no central authority or web-service to receive votes, and audit and oversee the voting process.
  • the cryptographic proof of liabilities system can generate a proof of liability such that a voter can check his/her inclusion in the reported v o t i n g result – thus preventing a malicious entity from attempting to cheat by not including [0173]
  • the cryptographic proof of liabilities system utilize a homomorphic commitment to ensure that the total reported amount stays hidden, and is only used in comparison with another homomorphic commitment (i.e., to sort candidates without learning their actual voting percentage difference). For example, an election system where competing parties compare homomorphic commitments obscuring voting totals without revealing actual numbers of negative votes (i.e., by using a multi-party computation to produce a range proof of the difference in number of votes).
  • Dislikes and Offensive Content – A dislike in social platforms can be considered an instance of disapproval voting.
  • each social platform user in a disapproval voting scheme may receive negative votes on a particular post, and be obliged to publish a report on the total number of received dislikes.
  • the cryptographic proof of liabilities system can provide a proof of liability associated with the total number of dislikes such that the user cannot omit some or all of the negative votes from the published report.
  • the social platform need not run a dislike tracking service because the cryptographic proof of liabilities system described herein is completely decentralized.
  • the cryptographic proof of liabilities system can apply such a disapproval voting scheme to transparent reports of any type of offensive content, including fake news and hate speech.
  • the cryptographic proof of liabilities system can enable any voter to check that their vote has been included in the reported total.
  • the social platform may automatically discard as offensive any post with a total number of disapproval votes that meets a threshold.
  • Fundraising and ICO – For tax audit purposes, businesses have to report revenue at regular intervals.
  • the cryptographic proof of liabilities system described herein can enable every citizen/buyer associated with a commercial company to automatically contribute to verifying a tax liabilities proof for that commercial company. Utilizing the cryptographic proof of liabilities system, a government or Internal Revenue System need not track individual receipts to crosscheck correctness of the accounting reports.
  • Syndicated Loans A syndicated loan is offered by a group of lenders who work together to provide credit to a large borrower.
  • the borrower can be a corporation, an individual project, or a government.
  • Each lender in the syndicate contributes part of the loan amount, and all lenders share in the lending risk.
  • One of the lenders acts as the manager (arranging bank), which administers the loan on behalf of the other lenders in the syndicate.
  • lenders should not necessarily know the contribution of other lenders due to extra privacy requirements. At the same time, the arranging bank might be liable if it reports fake total contribution.
  • the cryptographic proof of liabilities system described herein provides an efficient and accurate cryptographic tool in the cryptographic proof of liabilities system generates a proof of liabilities where user privacy is protected.
  • Lottery Prizes - Lotteries are tightly controlled, being restricted or at least regulated in most places. Despite this, there have been reports for rigged jackpots and large-scale fraud scandals – making it difficult to demonstrate fairness for genuine lotteries.
  • Some lottery systems utilize blockchain technology and smart contracts, so that players can actually know and trust the probability and revenue distribution.
  • the cryptographic proof of liabilities system described herein can add additional safeties to traditional lottery systems because the prize pool is actually a liability and the organizer does not have any incentive to increase it.
  • a credit score is a number that represents an assessment of the creditworthiness of a person, or the likelihood that the person will repay his or her debts. Credit scores are traditionally generated based on the statistical analysis of a person’s credit report. In addition to its original purpose, credit scores are also used to determine insurance rates and for pre-employment screening. [0181] Usually these services are centralized and credit bureaus maintain a record of a person’s borrowing and repaying activities.
  • a referral website is an Internet address or hostname used to refer a visitor to another site. For example, a visitor may click a hyperlink on the referral website, which then leads the user to a referred website.
  • the referral industry is usually monetizing by introducing fees; the referred website should pay back the referrer. However in many cases, (i.e., in gambling websites) the fee is linked with the referred user’s activity, for instance registration or depositing funds. Traditionally, the referral the fair payback fee.
  • a similar scenario is referral fees in the real estate business, where fees are charged by one agent or broker to another for a client referral.
  • the cryptographic proof of liabilities system described herein can provide an extra layer of transparency in the referrals business.
  • the cryptographic proof of liabilities system provides an automatic way for referral generating users to check their personal inclusion proofs, and catch reporting entities that are reporting fake or skewed numbers.
  • Transparent Reports on Virus Outbreaks – During epidemics and pandemics, affected countries and health organizations report official numbers of infections and fatalities caused by a virus or bacteria. The same is applied at a micro-scale (i.e., cities, hospitals) for various diseases or even occupational accidents per business sector.
  • the cryptographic proof of liabilities system described herein offers an extra level of decentralized transparency while simultaneously protecting patient data privacy. For example, each person proven to be infected with the virus can receive a signed response from local authorities or hospital. Then, every day, the cryptographic proof of liabilities system can publish a deterministic sparse-tree such as described herein, where each leaf node corresponds to one person (or a group if multiple members in a family caught the virus). Then, every infected person with a signed response can then check their inclusion in the sparse-tree.
  • the cryptographic proof of liabilities system 102 can enable governments to cross-compare their numbers without disclosing the actual amounts.
  • the cryptographic proof of liabilities system 102 generates deterministic sparse-trees and provides authentication paths verifying that an individual liability in a total liability for the sparse-tree.
  • FIG.9 illustrates a detailed schematic diagram of an embodiment of the cryptographic proof of liabilities system 102 described above.
  • the cryptographic proof of liabilities system 102 includes a sparse-tree generator 902, a client communicator 904, a zero-knowledge proof generator 906, and an authentication path generator 908.
  • the augmented reality system 102 can be hosted by a server or can reside on any of the computer nodes 114 or the client devices 112a-112n.
  • the functionality of cryptographic proof of liabilities system 102 may be wholly contained by any of the computer nodes 114 and/or the client devices 112a-112n. Additionally or alternatively, parts of the functionality of the cryptographic proof of liabilities system 102 may be hosted by a server, while other parts of the functionality of the cryptographic proof of liabilities system 102 may be performed by any of the computer nodes 114 and/or the client devices 112a-112n.
  • the cryptographic proof of liabilities system 102 can include the sparse-tree generator 902.
  • the sparse- tree generator 902 accesses an immutable database and deterministically generates a sparse- tree including the information in the immutable database.
  • the sparse-tree generator 902 can generate a sparse Merkle tree including a leaf node for each user entry in the immutable database.
  • the sparse-tree generator 902 can generate a deterministic sparse-tree in response to an audit request or an verification proof request.
  • the sparse-tree generator 902 can deterministically position padding nodes in a sparse-tree. For example, to obscure the number of real users in the sparse-tree and depending on the height of the sparse-tree, the sparse-tree generator 902 can position a plurality of padding nodes in the sparse-tree such that each padding node is positioned at the root of an empty sub-tree. [0190] Additionally, the sparse-tree generator 902 can also generate user leaf nodes for every user represented by the sparse-tree. For example, as discussed above, the sparse-tree generator 902 can determine a committed liability and user identifier associated with a particular user.
  • the sparse-tree generator 902 can further apply a verifiable random function to the committed liability and the user identifier associated with the user to determine a verifiable random function output.
  • the sparse-tree generator 902 can then apply a key blinding factor (e.g., b_factor).
  • b_factor a key blinding factor
  • the sparse-tree generator 902 can derive other deterministically generated values included in each leaf node that are based on the audit identifier and the blinding factor to ensure that the privacy and security of the sparse-tree are maintained.
  • the sparse-tree generator 902 can deterministically split and shuffle leaf nodes.
  • the sparse- tree generator 902 can split the balance associated with a single user across multiple leaf nodes. Furthermore, the sparse-tree generator 902 can shuffle and re-shuffle the leaf nodes in subsequent audits in order to hide users who fail to request verification proofs on a regular basis.
  • the cryptographic proof of liabilities system 102 includes the client communicator 904.
  • the client communicator 904 handles communications between the cryptographic proof of liabilities system 102 and auditors and/or individual users. For example, the client communicator 904 can receive audit requests and/or verification requests.
  • the client communicator 904 can further provide to auditors and/or individual users proofs and/or authentication paths in response to the received requests.
  • the cryptographic proof of liabilities system 102 includes the zero-knowledge proof generator 906.
  • the zero-knowledge proof generator 906 calculates a proof for every node in the deterministic sparse-tree proving that the balance associated with each node falls within a discrete range, without any knowledge of the actual balance.
  • the zero-knowledge proof generator 906 can provide zero-knowledge proofs for every node in an authentication path to show that the balance of every node is a small, positive number.
  • the cryptographic proof of liabilities system 102 includes the authentication path generator 908.
  • the authentication path generator 908 in response to receiving a request to verify that a user’s committed liability (e.g., number of coins) is included in a total liability for a sparse-tree, the authentication path generator 908 can recursively identify every node from the user’s leaf node back to the root node of the sparse- tree. The authentication path generator 908 can provide this list of nodes as the user’s authentication path.
  • the authentication path generator 908 can further provide zero-knowledge proofs (e.g., calculated by the zero-knowledge proof generator 906) for every node in the user’s authentication path showing the balance reflected by each [0195]
  • Each of the components 902-908 of the cryptographic proof of liabilities system 102 can include software, hardware, or both.
  • the components 902-908 can include one or more instructions stored on a computer-readable storage medium and executable by processors of one or more computing devices, such as a client device or server device. When executed by the one or more processors, the computer-executable instructions of the cryptographic proof of liabilities system 102 can cause the computing device(s) to perform the methods described herein.
  • the components 902-908 can include hardware, such as a special-purpose processing device to perform a certain function or group of functions.
  • the components 902-908 of the cryptographic proof of liabilities system 102 can include a combination of computer-executable instructions and hardware.
  • the components 902-908 of the cryptographic proof of liabilities system 102 may, for example, be implemented as one or more operating systems, as one or more stand-alone applications, as one or more modules of an application, as one or more plug- ins, as one or more library functions or functions that may be called by other applications, and/or as a cloud-computing model.
  • the components 902-908 may be implemented as a stand-alone application, such as a desktop or mobile application.
  • FIGS.1-9, the corresponding text, and the examples provide a number of different methods, systems, devices, and non-transitory computer-readable media of the cryptographic proof of liabilities system 102.
  • FIG.10 may be performed with more or fewer acts. Further, the acts may be performed in differing orders.
  • FIG.10 illustrates a flowchart of a series of acts 1000 for generating an authentication path establishing that a user’s committed liability is reflected in a total liability for a deterministic sparse-tree in accordance with one or more embodiments. While FIG.10 illustrates acts according to one embodiment, alternative embodiments may omit, add to, reorder, and/or modify any of the acts shown in FIG. 10. The acts of FIG. 10 can be performed as part of a method. Alternatively, a non-transitory computer-readable medium can to perform the acts of FIG. 10.
  • a system can perform the acts of FIG. 10.
  • the series of acts 1000 includes an act 1010 of generating a user leaf node for a user.
  • the act 1010 can involve generating a user leaf node for a user by applying a deterministic function to a committed liability and user identifier associated with the user.
  • applying the deterministic function to the committed liability and the user identifier includes applying a verifiable random function to the committed liability and the user identifier associated with the user.
  • applying the deterministic function to the committed liability and the user identifier further includes applying one or more key derivation functions to an output of the verifiable random function to generate an audit identifier and a blinding factor, wherein: the audit identifier is a unique and deterministically generated value; and the blinding factor is a deterministically generated commitment that obfuscates the committed liability.
  • the series of acts 1000 can include generating a zero-knowledge range proof associated with the committed liability that proves the committed liability is a small positive number within a predetermined range of numbers. [0200]
  • the series of acts also includes an act 1020 of positioning the generated user leaf node in a deterministic sparse-tree.
  • the act 1020 can involve positioning the generated user leaf node in a deterministic sparse-tree by deterministically shuffling the user leaf node with padding nodes and other user leaf nodes.
  • deterministically shuffling the user leaf node with padding nodes and other user leaf nodes includes: generating user hashes of user identifiers associated with the user leaf node and the other user leaf nodes; ordering the user leaf node and the other user leaf nodes based on the generated user hashes; randomly placing the ordered user leaf node and other user leaf nodes on the deterministic sparse-tree; and deterministically computing the padding nodes based on empty positions in the deterministic sparse-tree.
  • the series of acts 1000 includes an act of positioning the padding nodes in the deterministic sparse-tree as the roots of empty sub-trees of the deterministic sparse-tree.
  • the padding node can include a committed liability of zero.
  • the series of acts includes an act 1030 of receiving a request to verify that a user’s committed liability is reflected in a total associated with the deterministic sparse- tree.
  • the act 1030 can involve receiving a request to verify that the committed liability associated with the user is included in a total liability for the deterministic sparse-tree.
  • the series of acts includes an act 1040 of generating an authentication path for the user leaf node proving the user’s committed liability is reflected in the total.
  • the act 1040 can involve generating an authentication path for the user leaf node comprising a list of nodes in the sparse-tree between the user leaf node associated with the user and a root node indicating the total liability, wherein the authentication path establishes that the committed liability associated with the user is reflected in the total liability.
  • the authentication path can further include a zero-knowledge range proof associated with every node in the list of nodes in the sparse-tree between the user leaf node and the root node.
  • the series of acts 1000 further includes generating an internal node of the deterministic sparse-tree by: identifying a left-child-node of the internal node and a right-child-node of the internal node; generating an encrypted liability for the internal node by adding committed liabilities of the left-child-node and the right-child-node; and generating a hash for the internal node by concatenating all committed liabilities and hashes of the left-child-node and the right-child node.
  • generating the authentication path for the user leaf node can include: identifying, at every level of the sparse- tree starting at the user leaf node and moving up by parent nodes, sibling nodes; and adding, for every level of the sparse-tree, the identified sibling nodes to the authentication path to establish that a committed liability at every level reflects a product of committed liabilities of two children nodes.
  • the series of acts 1000 includes acts of: publishing the root node of the deterministic sparse-tree to an immutable database; receiving additional requests to verify that committed liabilities associated with other users are included in the total liability for the deterministic sparse-tree; generating additional authentication paths associated with the other users; and comparing the authentication paths to the published root node to ensure every user has the same view of the total liability for the deterministic sparse-tree.
  • the series of acts 1000 includes acts of: receiving an audit request associated with the deterministic sparse-tree; in response to receiving the audit request, re-shuffling the leaf nodes based on hashes of user identifiers in each of the leaf nodes; and re-determining internal nodes for the deterministic sparse-tree such that an encrypted liability for each internal node is a sum of committed liabilities of a left-child-node and a right-child-node of the internal node.
  • Embodiments of the present disclosure may comprise or utilize a special purpose or processors and system memory, as discussed in greater detail below.
  • Embodiments within the scope of the present disclosure also include physical and other computer-readable media for carrying or storing computer-executable instructions and/or data structures.
  • one or more of the processes described herein may be implemented at least in part as instructions embodied in a non-transitory computer-readable medium and executable by one or more computing devices (e.g., any of the media content access devices described herein).
  • a processor e.g., a microprocessor
  • Computer-readable media can be any available media that can be accessed by a general purpose or special purpose computer system.
  • Computer-readable media that store computer-executable instructions are non-transitory computer-readable storage media (devices).
  • Computer-readable media that carry computer-executable instructions are transmission media.
  • embodiments of the disclosure can comprise at least two distinctly different kinds of computer-readable media: non-transitory computer-readable storage media (devices) and transmission media.
  • Non-transitory computer-readable storage media includes RAM, ROM, EEPROM, CD-ROM, solid state drives (“SSDs”) (e.g., based on RAM), Flash memory, phase- change memory (“PCM”), other types of memory, other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store desired program code means in the form of computer-executable instructions or data structures and which can be accessed by a general purpose or special purpose computer.
  • SSDs solid state drives
  • PCM phase- change memory
  • a “network” is defined as one or more data links that enable the transport of electronic data between computer systems and/or modules and/or other electronic devices.
  • Transmissions media can include a network and/or data links which can be used to carry desired program code means in the form of computer-executable instructions or data structures and which can be accessed by a general purpose or special purpose computer. Combinations of the above should also be included within the scope of computer-readable media.
  • Computer-executable instructions or data structures received over a network or data link can be buffered in RAM within a network interface module (e.g., a “NIC”), and then eventually transferred to computer system RAM and/or to less volatile computer storage media (devices) at a computer system.
  • a network interface module e.g., a “NIC”
  • Non-transitory computer-readable storage media can be included in computer system components that also (or even primarily) utilize transmission media.
  • Computer-executable instructions comprise, for example, instructions and data which, when executed by a processor, cause a general-purpose computer, special purpose computer, or special purpose processing device to perform a certain function or group of functions.
  • computer-executable instructions are executed on a general- purpose computer to turn the general-purpose computer into a special purpose computer implementing elements of the disclosure.
  • the computer executable instructions may be, for example, binaries, intermediate format instructions such as assembly language, or even source code.
  • the disclosure may be practiced in network computing environments with many types of computer system configurations, including, personal computers, desktop computers, laptop computers, message processors, hand-held devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, mobile telephones, PDAs, tablets, pagers, routers, switches, and the like.
  • the disclosure may also be practiced in distributed system environments where local and remote computer systems, which are linked (either by hardwired data links, wireless data links, or by a combination of hardwired and wireless data links) through a network, both perform tasks.
  • program modules may be located in both local and remote memory storage devices.
  • Embodiments of the present disclosure can also be implemented in cloud computing environments.
  • “cloud computing” is defined as a model for enabling on- demand network access to a shared pool of configurable computing resources.
  • cloud computing can be employed in the marketplace to offer ubiquitous and convenient on- configurable computing resources can be rapidly provisioned via virtualization and released with low management effort or service provider interaction, and then scaled accordingly.
  • a cloud-computing model can be composed of various characteristics such as, for example, on-demand self-service, broad network access, resource pooling, rapid elasticity, measured service, and so forth.
  • a cloud-computing model can also expose various service models, such as, for example, Software as a Service (“SaaS”), Platform as a Service (“PaaS”), and Infrastructure as a Service (“IaaS”).
  • SaaS Software as a Service
  • PaaS Platform as a Service
  • IaaS Infrastructure as a Service
  • a cloud-computing model can also be deployed using different deployment models such as private cloud, community cloud, public cloud, hybrid cloud, and so forth.
  • a “cloud-computing environment” is an environment in which cloud computing is employed.
  • FIG.11 illustrates a block diagram of an example computing device 1100 that may be configured to perform one or more of the processes described above.
  • the computing device 1100 may represent the computing devices described above (e.g., the client devices 112a-112n, and the computer nodes 114).
  • the computing device 1100 may be a mobile device (e.g., a mobile telephone, a smartphone, a PDA, a tablet, a laptop, a camera, a tracker, a watch, a wearable device, etc.).
  • the computing device 1100 may be a non-mobile device (e.g., a desktop computer or another type of client device).
  • the computing device 1100 may be a server device that includes cloud-based processing and storage capabilities. [0216] As shown in FIG.
  • the computing device 1100 can include one or more processor(s) 1102, memory 1104, a storage device 1106, input/output interfaces 1108 (or “I/O interfaces 1108”), and a communication interface 1110, which may be communicatively coupled by way of a communication infrastructure (e.g., bus 1112). While the computing device 1100 is shown in FIG.11, the components illustrated in FIG.11 are not intended to be limiting. Additional or alternative components may be used in other embodiments. Furthermore, in certain embodiments, the computing device 1100 includes fewer components than those shown in FIG.11. Components of the computing device 1100 shown in FIG.11 will now be described in additional detail.
  • the processor(s) 1102 includes hardware for executing instructions, such as those making up a computer program.
  • the processor(s) 1102 may retrieve (or fetch) the instructions from an internal register, an internal cache, memory 1104, or a storage device 1106 and decode [0218]
  • the computing device 1100 includes memory 1104, which is coupled to the processor(s) 1102.
  • the memory 1104 may be used for storing data, metadata, and programs for execution by the processor(s).
  • the memory 1104 may include one or more of volatile and non-volatile memories, such as Random-Access Memory (“RAM”), Read-Only Memory (“ROM”), a solid-state disk (“SSD”), Flash, Phase Change Memory (“PCM”), or other types of data storage.
  • RAM Random-Access Memory
  • ROM Read-Only Memory
  • SSD solid-state disk
  • PCM Phase Change Memory
  • the memory 1104 may be internal or distributed memory.
  • the computing device 1100 includes a storage device 1106 including storage for storing data or instructions.
  • the storage device 1106 can include a non-transitory storage medium described above.
  • the storage device 1106 may include a hard disk drive (HDD), flash memory, a Universal Serial Bus (USB) drive or a combination these or other storage devices.
  • HDD hard disk drive
  • USB Universal Serial Bus
  • the computing device 1100 includes one or more I/O interfaces 1108, which are provided to allow a user to provide input to (such as user strokes), receive output from, and otherwise transfer data to and from the computing device 1100.
  • I/O interfaces 1108 may include a mouse, keypad or a keyboard, a touch screen, camera, optical scanner, network interface, modem, other known I/O devices or a combination of such I/O interfaces 1108.
  • the touch screen may be activated with a stylus or a finger.
  • the I/O interfaces 1108 may include one or more devices for presenting output to a user, including, but not limited to, a graphics engine, a display (e.g., a display screen), one or more output drivers (e.g., display drivers), one or more audio speakers, and one or more audio drivers.
  • I/O interfaces 1108 are configured to provide graphical data to a display for presentation to a user.
  • the graphical data may be representative of one or more graphical user interfaces and/or any other graphical content as may serve a particular implementation.
  • the computing device 1100 can further include a communication interface 1110.
  • the communication interface 1110 can include hardware, software, or both.
  • the communication interface 1110 provides one or more interfaces for communication (such as, for example, packet-based communication) between the computing device and one or more other computing devices or one or more networks.
  • communication interface 1110 may include a network interface controller (NIC) or network adapter for communicating with an Ethernet or other wire-based network or a wireless NIC (WNIC) or wireless adapter for communicating with a wireless network, such as a WI-FI.
  • NIC network interface controller
  • WNIC wireless NIC
  • the computing device 1100 can further include a bus 1112.
  • the bus 1112 can include hardware, [0223]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Business, Economics & Management (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Human Resources & Organizations (AREA)
  • Strategic Management (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Marketing (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Economics (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Technology Law (AREA)
  • Data Mining & Analysis (AREA)
  • Development Economics (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • Tourism & Hospitality (AREA)
  • Storage Device Security (AREA)

Abstract

La présente divulgation concerne des systèmes, des supports non transitoires lisibles par ordinateur et des procédés permettant de générer des preuves d'engagements cryptographiques décentralisées et préservant la confidentialité, associées à des bases de données immuables. En particulier, dans un ou plusieurs modes de réalisation, les systèmes divulgués permettent à une entité de rapporter de manière transparente et précise sa quantité totale d'engagements, d'obligations ou d'autres données associées à des rapports négatifs fongibles sans exposer de données d'utilisateur ou de données de système confidentielles (par exemple, la structure d'engagements). En outre, les systèmes divulgués peuvent générer une preuve d'engagement cryptographique qui permet à des utilisateurs individuels de vérifier indépendamment que leur engagement déterminé est compris dans un engagement total rapporté.
EP21719490.1A 2020-03-30 2021-03-26 Preuve d'engagements cryptographique basée sur un arbre épars déterministe Pending EP4128655A1 (fr)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US202063002298P 2020-03-30 2020-03-30
US17/206,423 US20210336789A1 (en) 2020-03-30 2021-03-19 Deterministic sparse-tree based cryptographic proof of liabilities
PCT/US2021/024415 WO2021202289A1 (fr) 2020-03-30 2021-03-26 Preuve d'engagements cryptographique basée sur un arbre épars déterministe

Publications (1)

Publication Number Publication Date
EP4128655A1 true EP4128655A1 (fr) 2023-02-08

Family

ID=75540070

Family Applications (1)

Application Number Title Priority Date Filing Date
EP21719490.1A Pending EP4128655A1 (fr) 2020-03-30 2021-03-26 Preuve d'engagements cryptographique basée sur un arbre épars déterministe

Country Status (5)

Country Link
US (1) US20210336789A1 (fr)
EP (1) EP4128655A1 (fr)
CN (1) CN115152178A (fr)
TW (1) TW202137732A (fr)
WO (1) WO2021202289A1 (fr)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP4142211A1 (fr) * 2021-08-26 2023-03-01 BitFlow GmbH Protection d'intégrité de documents
WO2024197102A1 (fr) * 2023-03-21 2024-09-26 Unity Chain, Inc. Chaînes de transfert vrfs distribuées privées de sortie et chaînes de transfert d'application
CN116629175B (zh) * 2023-07-26 2023-12-15 深圳中安辰鸿技术有限公司 对npu中的译码单元进行验证的方法及相关装置、设备
US12015713B1 (en) 2023-08-23 2024-06-18 Yuga Labs, Inc. Artificial intelligence protocols for enhancing token holder autonomy

Family Cites Families (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4309569A (en) * 1979-09-05 1982-01-05 The Board Of Trustees Of The Leland Stanford Junior University Method of providing digital signatures
AU2001250976A1 (en) * 2000-03-24 2001-10-08 Votehere, Inc. Verifiable, secret shuffles of encrypted data, such as elgamal encrypted data for secure multi-authority elections
US20080000969A1 (en) * 2004-03-25 2008-01-03 Cryptomathic A/S Electronic Voting Systems
US7586892B2 (en) * 2004-04-26 2009-09-08 Hewlett-Packard Development Company, L.P. Computer method and apparatus for periodic scheduling with jitter-approximation tradeoff
US8245038B2 (en) * 2008-03-26 2012-08-14 Palo Alto Research Center Incorporated Method and apparatus for verifying integrity of redacted documents
EP2338127B1 (fr) * 2008-08-29 2015-07-29 Brown University Accumulateurs cryptographiques pour tables de hachage authentifiées
US8078642B1 (en) * 2009-07-24 2011-12-13 Yahoo! Inc. Concurrent traversal of multiple binary trees
US8396896B2 (en) * 2010-11-10 2013-03-12 International Business Machines Corporation Assigning resources to a binary tree structure
US20140245020A1 (en) * 2013-02-22 2014-08-28 Guardtime Ip Holdings Limited Verification System and Method with Extra Security for Lower-Entropy Input Records
US9356965B2 (en) * 2013-12-30 2016-05-31 Alexander Kjeldaas Method and system for providing transparent trusted computing
US9792431B1 (en) * 2014-02-11 2017-10-17 Veritas Technologies Llc Systems and methods for selectively masking data on virtual storage devices
US10237074B2 (en) * 2014-04-08 2019-03-19 Hewlett Packard Enterprise Development Lp Redactable document signatures
US10812274B2 (en) * 2015-05-07 2020-10-20 Blockstream Corporation Transferring ledger assets between blockchains via pegged sidechains
US10740474B1 (en) * 2015-12-28 2020-08-11 Ionic Security Inc. Systems and methods for generation of secure indexes for cryptographically-secure queries
US10291408B2 (en) * 2016-12-23 2019-05-14 Amazon Technologies, Inc. Generation of Merkle trees as proof-of-work
EP3646563B1 (fr) * 2017-06-30 2023-12-13 Visa International Service Association Procédé, système et produit-programme d'ordinateur permettant de déterminer la solvabilité d'un échange d'actifs numériques
EP3442160A1 (fr) * 2017-08-07 2019-02-13 Siemens Aktiengesellschaft Élagage des arbres d'authentification
US11151259B2 (en) * 2017-12-06 2021-10-19 Zamna Technologies Limited Method and system for data security, validation, verification and provenance within independent computer systems and digital networks
EP3522064B1 (fr) * 2018-02-02 2021-12-22 Università Degli Studi Di Trento Procédé et appareil pour un échange, un inventaire et un carnet de commandes distribués, préservant la confidentialité et l'intégrité
US11438139B2 (en) * 2018-02-07 2022-09-06 Raouf Boutaba Blockchain based secure naming and update verification
CN113989047A (zh) * 2018-07-27 2022-01-28 创新先进技术有限公司 基于区块链的资产发布方法及装置、电子设备
TW202034656A (zh) * 2019-01-31 2020-09-16 柯賓漢數位金融科技有限公司 產生區塊鏈上之安全隨機數的方法
US11018856B2 (en) * 2019-09-11 2021-05-25 Guardtime Sa Auditable system and methods for secret sharing

Also Published As

Publication number Publication date
WO2021202289A1 (fr) 2021-10-07
US20210336789A1 (en) 2021-10-28
TW202137732A (zh) 2021-10-01
CN115152178A (zh) 2022-10-04

Similar Documents

Publication Publication Date Title
JP7569602B2 (ja) 分散協調を用いるスマートコントラクトの実行
Khan et al. Investigating performance constraints for blockchain based secure e-voting system
Abuidris et al. Secure large‐scale E‐voting system based on blockchain contract using a hybrid consensus model combined with sharding
US20210336789A1 (en) Deterministic sparse-tree based cryptographic proof of liabilities
EP4117228B1 (fr) Systèmes et procédés de communication, de stockage et de traitement de données fournies par une entité sur un réseau de chaîne de blocs
WO2019010392A1 (fr) Systèmes, procédés et dispositifs pour réduire et/ou éliminer une fuite de données dans des technologies de registre électronique pour une mise en correspondance d'ordres sans fiducie
CN115152177B (zh) 提供机密知识的专门证明的系统和方法
KR102187294B1 (ko) 블록체인 네트워크를 기반으로 한 비밀 전자 투표 시스템 및 방법
Qu et al. A electronic voting protocol based on blockchain and homomorphic signcryption
Chalkias et al. Distributed auditing proofs of liabilities
Ruoti et al. SoK: Blockchain technology and its potential use cases
CN112613601A (zh) 神经网络模型更新方法、设备及计算机存储介质
Chaudhary et al. Decentralized voting platform based on ethereum blockchain
Chaieb et al. Dabsters: A privacy preserving e-voting protocol for permissioned blockchain
Antoni et al. The Role of Blockchain Technology in E-Govemment Capability: Literature Review
Saket et al. Smart contract protocol for authenticity and compliance with anonymity on hyperledger fabric
Smahi et al. VFL-Chain: Bulletproofing Federated Learning in the V2X environments
KR102717970B1 (ko) 분산 조정을 사용한 스마트 계약 실행
Gurushankar et al. Decentralized universally verifiable stake voting system with perfect privacy
Jafari Fundamental Attacks on Ethereum Oracles and How to Prevent Them
Cachin Distributing trust with blockchains
Dewangan et al. Blockchain with Fault Tolerance Mechanism
Matile Cast-as-Intended Verifiability in Blockchain-based Electronic Voting for Swiss National Elections
Dewan et al. Secure Electronic Voting System based on Mobile-app and Blockchain
Lu Crowdsourcing Atop Blockchains

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20220930

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)