A distributed database structure for anonymous information exchange

Abstract

This disclosure provides a system and method for managing and verifying information via a blockchain. The method includes: generating a cryptographic state commitment associated with the state of a user node by a user node; storing the state of a user node by a user node, wherein the state of the user node comprises data associated with one or more claims that trigger a state update, the data being not publicly shared; constructing a zero-knowledge proof (zk-SNARK) by a user node that validates the validity of a state update without revealing the data; and broadcasting the zero-knowledge proof and the cryptographic state commitment to the blockchain, wherein the zero-knowledge proof ensures the validity of the state of the user node on the blockchain.

Description

Technical Field

[0001] (Cross-Reference to Related Applications) This application claims the priority benefit of U.S. Provisional Application No. 63 / 538,411, filed on September 14, 2023, which is hereby incorporated by reference in its entirety into this specification.

Background Art

[0002] Existing systems for generating verifiable sustainability-related claims typically either rely on full transparency, or resort to an authorized authority to provide evidence regarding the validity of the claims. Alternatively, they attempt a weaker, more conventional concept of verifiability, where instead of auditing the basis of the claim, the user is provided with a non-repudiable signed version of the claim that only guarantees its authenticity, without ensuring its integrity.

Summary of the Invention

Means for Solving the Problems

[0003] Existing systems and methods lack the ability to provide consumers with a high level of assurance regarding the truthfulness of sustainability-related claims made about products. Current methods may not adequately equip consumers with the ability to effectively investigate claims relating to products and have confidence in the accuracy of these claims. Challenges also exist in providing satisfactory responses to further consumer inquiries about products, which are supported by substantial documentation. In essence, there is an unaddressed need for complete customer-facing audits to support each sustainability-related claim. To foster competition, there may be an inherent level of information asymmetry between consumers and entities in the supply chain.

[0004] Given the existing challenges, a solution might involve assuming a scenario where a single, highly reliable, and trustworthy authority exists. Each participant in the supply chain could submit their documents, records, and certificates to this authority. This authority could potentially create a global understanding of the interconnections within these documents and comprehensively oversee the operations of participating members. The authority could also trace audit trails, assess the feasibility of operations, verify compliance with established standards, and ensure consistency with certificates and physical assessments. Furthermore, the authority could be alerted to any new documents that contradict previous data. This would allow the authority to substantiate claims about any product at any level of granularity. As a result, consumers could be confident in purchasing products that align with their ethical beliefs, and manufacturers could be rewarded for sustainable practices. However, in reality, such a perfectly fraud-free authority is unlikely to exist.

[0005] This disclosure addresses the above need by providing a system and method for generating economically and computationally feasible, cryptographically verifiable claims about knowledge graphs. This can be achieved by creating a system that enhances transparency through full consumer audits. Such a system could address the need for a full consumer audit for each sustainability claim while maintaining the necessary level of information asymmetry and promoting competition within the supply chain.

[0006] This disclosure provides a system and method for generating cryptographically verifiable claims relating to a knowledge graph. The system and method can promote collaboration, confidentiality, and consistency. It can enable multiple parties within a supply chain to conduct and coordinate their verification, promoting collaboration by reducing reliance on end actors or global authority bodies, and without necessarily revealing participant identities, compared to conventional systems and methods. Confidentiality can be maintained because the system can enable verification without the need to reveal underlying records. Furthermore, the system can support consistency by making verification tamper-detectable and allowing for the possibility of verifying the consistency of these verifications against underlying records, again without revealing them.

[0007] This system can facilitate the creation of pseudonymized knowledge graphs centered on specific objects. Knowledge graphs can be used to develop claims derived about their object or other objects within the knowledge graph, based on their relationships to the root object. Knowledge graphs can contain claims cumulatively supported by subgraphs, and the disclosure of information can be limited to only what is necessary.

[0008] In some respects, what is disclosed herein is a computer implementation method for creating and sharing verifiable information while maintaining anonymity and privacy. The method includes: a user creating one or more claims about an object at a user node, the one or more claims being constrained by a constraint system associated with the object; updating a state at the user node or user account based on one or more claims, the state being associated with the user node or user account, comprising private data stored on the user node and not publicly shared; updating or creating a cryptographic state commitment to validate proof of the updated state, the cryptographic state commitment being pseudonymous or anonymous, associated with a user, and recorded on a blockchain, and validating proof of the updated state including proving that updating the state is a valid state transition from a previous state, or proving the validity of one or more claims about the state underlying the cryptographic state commitment; and constructing a zero-knowledge proof to validate the validity of the updated state without revealing the state.

[0009] Related but distinct in nature, what is disclosed herein is a system for creating and sharing verifiable information while maintaining anonymity and privacy. The system comprises a processor and memory, which includes executable instructions that, as a result of being executed by the processor, cause the system to perform operations including: creating one or more claims about an object at a user node, the one or more claims being constrained by a constraint system associated with the object; updating a state related to a user node or user account at a user node based on one or more claims, the state related to a user node or user account comprising private data stored on the user node and not publicly shared; updating or creating a cryptographic state commitment to validate a proof of the updated state, the cryptographic state commitment being pseudonymous or anonymous, associated with a user, and recorded on a blockchain, and validating a proof of the updated state including proving that updating the state is a valid state transition from a previous state, or proving the validity of one or more claims about the state underlying the cryptographic state commitment; and constructing a zero-knowledge proof that validates the updated state without revealing the state.

[0010] In some embodiments, the constraint system is a framework comprising one or more predefined rules that constrain the formal expression of one or more claims. In some embodiments, one or more claims comprise a cooperative inductive claim. In some cases, the cooperative inductive claim references one or more other claims. In some instances, one or more other claims are created by another user. In some instances, one or more other claims are validated by a user node against a cryptographic state commitment associated with another user, which is recorded on the blockchain. In some instances, one or more referenced claims are predicates relating to the process and / or metadata by which one or more claims were created.

[0011] In some embodiments, the zero-knowledge proof is a zero-knowledge concise non-interactive knowledge argument (zk-SNARK). In some embodiments, the blockchain is a public blockchain.

[0012] In some embodiments, cryptographic state commitments associated with users on the blockchain are stored using authenticated data structures. In some cases, cryptographic state commitments associated with users are identified by an index on a leaf node of a Merkle tree. In some instances, updating a cryptographic state commitment associated with a user involves maintaining a root commitment mapping using a Merkle tree or a cryptographic accumulator. In some embodiments, the root commitment is used as input to a proof to publicly verify one or more claims made by a user and the updated state. In some cases, the user is identified by a key in an indexed Merkle tree or by a key in an authenticated data structure that implements the map structure.

[0013] In some embodiments, one or more claims about a subject can be verified by verifying authenticity or conformance to a constraint system. In some embodiments, a zero-knowledge proof ensures that the claims conform to predetermined rules and prior states.

[0014] In some embodiments, one or more claims about an object are in the form of entries in a record. In some cases, the entry stores information about one or more attributes of the object. In some instances, one or more attributes are defined by one or more predefined rules of a constraint system. For example, one or more attributes are constrained by forward propagation of predicates through an attribute-definition directed acyclic graph (DAG). In another embodiment, one or more attributes are constrained by the propagation of constraints through a dependency DAG.

[0015] In yet another aspect, disclosed herein is a computer implementation method for managing and verifying information via a blockchain. The method includes: generating a cryptographic state commitment associated with the state of the user node by a user node; storing the state of the user node by the user node, wherein the state of the user node comprises data associated with one or more claims that cause an update of the state, the data being not publicly shared; constructing a zero-knowledge proof (zk-SNARK) by the user node that validates the validity of the state update without revealing the data; and broadcasting the zero-knowledge proof and the cryptographic state commitment to the blockchain, wherein the zero-knowledge proof ensures the validity of the state of the user node on the blockchain.

[0016] In some embodiments, the method further includes the user node creating another cryptographic state commitment regarding the updated state. In some cases, the method further includes publishing the other cryptographic state commitment on the blockchain to serve as a verifiable and irreversible record accessible via the blockchain.

[0017] In some embodiments, the state of a user node further includes data about collaborative inductive claims. In some cases, a collaborative inductive claim refers to one or more other claims. In some instances, one or more other claims are created by another user.

[0018] In some embodiments, the state of a user node further includes metadata about one or more claims, one or more previous claims, and the validity or invalidity of the state update. In some embodiments, the state of a user node further includes auxiliary data for constructing zero-knowledge proofs. In some cases, the auxiliary data includes intermediate nodes of authenticated data structures.

[0019] In some embodiments, cryptographic state commitments are stored on the blockchain using authenticated data structures. In some embodiments, the method further includes updating at least a portion of the global state commitment agreed upon by the blockchain's consensus protocol in response to publishing the cryptographic state commitment to the blockchain. In some cases, a state commitment associated with a given user or a given user node is associated with all records relating to all frameworks associated with a given user. In some instances, the global state, comprising all state commitments associated with all users or all user nodes in the network, is published on the blockchain. In some embodiments, validating the update of the state includes determining whether one or more claims are valid. In some embodiments, determining one or more claims is valid if one or more claims are consistent with the global state commitment, without relying on user identification or a source of records, thereby avoiding the exposure of relationships between users.

[0020] In some embodiments, the method further includes verifying a zero-knowledge proof that the state update is the result of a valid transaction in accordance with global rules and previous state commitments. In some embodiments, the cryptographic state commitment encodes metadata about predefined framework rules that constrain the formal expression of one or more claims.

[0021] In some embodiments, one or more claims are stored within one or more entries of a record. In some cases, the record is associated with a subject, and the one or more entries are associated with one or more attributes of the subject. In some instances, the method further includes implementing a UTXO-like model or balance log through cross-referencing between records to enforce consistency between records or to restrict the multiplicity of relationships. For example, cross-referencing is enforced according to a constraint system. In some embodiments, constraints in the constraint system enforce cross-referencing with respect to relationships between attributes of records referenced by multiple records.

[0022] In some embodiments, the method further includes, at least in part, verifying the obsolescence or validity status of one or more claims based on a time threshold. In some embodiments, at least one claim is a relative claim about a second object based on a claim about a first object. In some cases, the relative claim is verified based on the relationship between the first and second objects, without relying on the identification of the first and second objects. In some cases, updating the state includes modifying or updating the state of an entry in the record, and the updated state of the entry is used to determine the invalidity of a dependency entry based on a potential inconsistency with the updated entry.

[0023] In some embodiments, updating the state includes modifying or updating one or more claims and determining the invalidity of dependent claims based on potential inconsistencies between the dependent claims and the updated one or more claims. In some embodiments, the state of a user node further comprises data associated with claims or states of other user nodes that are in transactional state with the user node. In some cases, the claims or states of other user nodes are used to derive inductive claims that match the claims or states via a recursive zk-SNARK. In some cases, the inductive claims are stored on the user node and are not exposed on the blockchain.

[0024] In some embodiments, the blockchain is a concise blockchain, and the global state of the blockchain is validated via a single proof. In some cases, all state updates within a given block or blockchain are recursively aggregated into a single proof.

[0025] Additional aspects and advantages of the present disclosure will be readily apparent to those skilled in the art from the following detailed description, in which only illustrative embodiments of the present disclosure are shown and described. As will be appreciated, the present disclosure is capable of other different embodiments, and several of its details are capable of modifications in various obvious respects, all without departing from the present disclosure. Accordingly, the drawings and descriptions are to be regarded as illustrative in nature, and not as restrictive. (Incorporation by Reference)

[0026] All publications, patents, and patent applications mentioned in this specification are herein incorporated by reference to the same extent as if each individual publication, patent, or patent application was specifically and individually indicated to be incorporated by reference. To the extent that publications and patents or patent applications incorporated by reference contradict the disclosure contained in the present specification, the present specification is intended to supersede and / or take precedence over any such contradictory material. [Brief Description of the Drawings]

[0027] The novel features of the present disclosure are set forth in detail in the appended claims. A better understanding of the features and advantages of the present disclosure will be obtained by reference to the following detailed description that sets forth illustrative embodiments, in which the principles of the present disclosure are utilized, and the accompanying drawings.

[0028] [Figure 1] Figure 1 illustrates an example of a global execution environment that implements the methods and systems of the present specification, according to some embodiments.

[0029] [Figure 2]Figure 2 shows an example of a dependency graph for cooperative inductive claims.

[0030] [Figure 3] Figure 3 shows examples of entries in the records within the system, representing the overall claims about the target record, according to several embodiments.

[0031] [Figure 4] Figure 4 shows examples of how selectively disclosed entries, in several embodiments, function within the system.

[0032] [Figure 5] Figure 5 shows examples of how entries are created as transactions according to rules that depend on the record state and global state, as defined by the framework's transaction method, in several embodiments.

[0033] [Figure 6] Figure 6 shows an example in which, according to several embodiments, entries as claims about the attributes of the target record and disclosures as predicates about the attributes constrained by those individual entries are structured within the record in this system.

[0034] [Figure 7] Figure 7 shows examples of how, in several embodiments, entries relating to statements about the attributes of the record in question, and disclosures as predicates relating to the attributes constrained by the entries, are structured within the record and its associated entries.

[0035] [Figure 8A] Figure 8A shows an example of a record as a collection of version-controlled entries.

[0036] [Figure 8B] Figure 8B shows an example of a record as a version-controlled collection of entries.

[0037] [Figure 8C] Figure 8C shows an example of recording as a version set of references to an entry.

[0038] [Figure 9] Figure 9 shows an example of an implementation of unused transaction output (UTXO)-like expenditure using a cross-reference pattern in this system.

[0039] [Figure 10] Figure 10 shows an example of implementing spending rules in this system that use cross-referencing patterns and update the remaining amount of assets.

[0040] [Figure 11] Figure 11 schematically illustrates an example of a log of records using cross-referencing patterns and indexing in this system.

[0041] [Figure 12] Figure 12 shows an example of the state update process in the user state route mapping approach in this system.

[0042] [Figure 13] Figure 13 shows an example of the user state commitment structure in the ZCash-like model in this system.

[0043] [Figure 14] Figure 14 shows an example of an extended version of the model depicted in Figure 12.

[0044] [Figure 15] Figure 15 shows a simplified embodiment of a bank transaction system illustrating the concept of state changes resulting from transactions in the system, according to several embodiments.

[0045] [Figure 16] Figure 16 shows an example of the proof illustrating the state transition from state 1 to state 2 as a result of executing a specific transaction in several embodiments.

[0046] [Figure 17] Figure 17 shows an example of a user state route in a system, providing a graphical representation of how user states are structured according to several embodiments.

[0047] [Figure 18] Figure 18 shows a non-limiting embodiment of a computing device that implements the methods and systems described herein. [Modes for carrying out the invention]

[0048] Detailed explanation This disclosure provides an improved system and method for creating and sharing verifiable information while maintaining anonymity and privacy, including a user creating one or more claims about a subject at a user node. In some embodiments, one or more claims are constrained by a constraint system associated with the subject. In some embodiments, the method includes updating state related to a user node or user account based on one or more claims at a user node. In some embodiments, the state related to a user node or user account comprises private data stored on the user node and not publicly shared. In some embodiments, the method includes updating or creating a cryptographic state commitment to validate proof of the updated state. In some embodiments, the cryptographic state commitment is pseudonymous or anonymous, associated with a user, and recorded on a blockchain. In some embodiments, the method includes constructing a zero-knowledge proof that validates the updated state without revealing the state.

[0049] This disclosure provides methods and systems for creating verifiable sustainability claims when supporting evidence is confidential and scattered across numerous parties who may not communicate directly with each other. This disclosure provides systems and methods that utilize public blockchains and zero-knowledge proofs to facilitate collaboration in validating sustainability claims while ensuring confidentiality. The systems and methods provided herein may be operated by transforming public commitments into a consistent narrative and sharing claims related to that narrative, which are adjusted to a level of detail deemed appropriate for the recipients.

[0050] The systems and methods provided herein may include mechanisms to support flexibility in data entry while ensuring transparency to the parties receiving the claims regarding any alterations made to the narrative. Unlike existing systems and methods, the disclosed systems and methods provide transparency and accountability in the representation of sustainability practices. For example, within a supply chain, the system may be able to create a knowledge graph illustrating the flow and transformation of assets resulting from various actions such as manufacturing processes and shipments (see Figure 2 for further details). The system may establish a final product, such as recycled shoes, as a reference point. From there, it may begin generating claims such as the materials used to make the shoes, the source of individual input materials, or the proportion of initial supply materials that are subject to sustainability claims. Furthermore, the system may be able to connect this traceability data with existing traceability schemes such as FSC, Fairtrade, and ISCC. This allows those claims to be linked to specific sustainability declarations, such as shipment manifests, which are issued specifically for materials with sustainable characteristics and are supported using predefined audit standards. These declarations may essentially be included within the audit process. This approach is not limited to material procurement and may be applicable to a broader range of sustainability factors, including carbon emissions, avoidance of slave labor, sourcing from conflict-free regions, and others.

[0051] Figure 2 shows examples of dependency graphs for a collaborative inductive claim, specifically highlighting that the supply chain of a given end product is certified as child labor-free, in several embodiments. For the sake of brevity, this example simplifies the framework and omits similar entries, constraint definitions, and history. Arrows, as defined in the legend, indicate references and dependencies in the disclosed system and method. Each line pattern in the legend represents a specific type of arrow, clearly distinguishing between references and dependencies. This allows for a clear interpretation and understanding of the relationships and constraints in this system, as depicted in the diagram.

[0052] The diagram begins with a Trusted Issuing Authority (201), defined in the framework, representing an entity that is trusted to issue certificates. User 123 (202) is identified as one of such issuing authorities that grants a Child Labor-Free Certificate (203). The certificate is linked to an Institution (205) via Accreditation (206) to verify that the Institution is child labor-free (207).

[0053] This process is repeated with another trusted issuing authority, user 234(211), which similarly issues child labor-free certificates. The certificate is again linked to a different facility (213) via accreditation(214), confirming that this facility is also child labor-free. Processes (208 and 215) are linked to each facility. This process incorporates inputs (216 and 221), which are points into which goods produced from child labor-free facilities are brought. These inputs are confirmed to be child labor-free based on the certificates issued to each facility (217 and 222).

[0054] Figure 2 demonstrates how this system can create a knowledge graph that tracks and verifies the ethical certification of materials throughout the supply chain, from their origin within certified facilities to their incorporation as inputs into the manufacturing process. This not only provides assurance regarding sustainability claims but also enables traceability throughout the entire supply chain.

[0055] Unlike conventional systems and methods that simply lay out information within a knowledge graph without comprehensive cryptographic techniques, the systems and methods provided herein enforce a transparent and consistent narrative while supporting derived claims without revealing any sensitive data used to corroborate those claims.

[0056] In contrast to traditional systems where users must fully hand over data to a trusted authority, which then substantiates the user's claims, the systems and methods provided herein maintain both confidentiality and integrity simultaneously. Rather than relying solely on the reputation of a single authority, they instead rely on a number of independent, crypto-economically incentivized parties for a consensus on a single, updatable global narrative. This is achieved by concealing cryptographic commitments from the public blockchain, leveraging zk-SNARKs, and maintaining the internal consistency of its concealed narrative. This enables both comprehensive transparency and confidentiality, bridging the gap between total public disclosure and complete confidentiality.

[0057] While the systems and methods provided herein may enable users to validate their supply chain operations, these systems and methods may also function as a transparency platform that proactively invites external entities to conduct independent audits of supply chain operations, leveraging the robust verification capabilities of the systems and methods provided herein. (1.Definition) (Consensus protocol)

[0058] A fault-tolerant consensus protocol refers to a method that enables computers, which may be controlled by different operators with various interests, to reach an agreement, under conditions that do not require assumptions of perfectly honest, fault-free, and obedient behavior from all machines. For example, Bitcoin uses a consensus protocol to reach an agreement on the ledger of transactions. Bitcoin operates on the premise that no single party controls more than a predetermined percentage of the available computing resources. Similarly, Ethereum uses a consensus protocol to agree on transactions to be executed and smart contracts to be deployed, utilizing the amount of staked financial resources. The systems and methods provided herein apply to these consensus protocols and achieve agreement on a consistent narrative of user actions and the resulting states in the system. (Commitment scheme)

[0059] A commitment scheme is a method for a party to commit to a hidden value and create a corresponding value known as a commitment, in such a way that it is impossible (under certain assumptions) for a party witnessing only the commitment to know the hidden value (a property called secrecy), and it is impossible (under certain assumptions) to convince a party that the hidden value corresponding to the commitment is any value other than the hidden value from which the commitment is derived (a property known as constraint). Some commitment schemes have an even stronger property known as perfect secrecy, which ensures that given only the commitment, it is impossible to know anything about the corresponding hidden value without certain assumptions about the available computational resources. A similar stronger property exists for constraint, but it is less relevant to this system, and the two stronger properties cannot be held simultaneously. (Authenticated data structure)

[0060] Authenticated data structures are a concept derived from delegated computation. Authenticated data structures allow non-credentials to perform operations on the data structure while providing a short witness to the accuracy of those operations, requiring the verifier to remember only a small commitment to that data structure for state tracking. These types of data structures are used in blockchain applications and zero-knowledge proofs and form the core of the systems described herein.

[0061] An example of an authenticated data structure is a hash chain, or in the context of Bitcoin, a blockchain. A hash chain data structure is similar to a linked list, but pointers are replaced by a collision-resistant hash function. A data structure may be referenced by its root hash. An append operation may be verified simply by hashing the previous root with the appended data, or rather, by hashing the appended data. A lookup of deeper values ​​in a list may be done by providing a hash preimage, which, under the assumption of a collision-resistant hash function, acts as an untrusted pointer.

[0062] A more complex embodiment of authenticated data structures is the Merkle tree, which is similar to a binary tree but where pointers are replaced by hashes. The Merkle tree allows for logarithmic-sized lookups or updates of a binary tree by providing a preimage to a hash, as well as by dereferencing pointers along the path. Some more specific variations of the Merkle tree, which will be featured in this paper, are the Sparse Merkle Tree, the Merkle Mountain Range, and the Indexed Merkle Tree, which are useful for representing maps or sets with unlimited capacity, pruning-enabled append-only logs with efficient lookups and low storage requirements, and maps or sets with limited capacity, respectively. Further details about authenticated data structures will be described later in this specification. (Proof of computational consistency)

[0063] Proof of computational integrity, particularly zk-SNARK (zero-knowledge concise non-interactive knowledge argument), is a cryptographic technique that has been proven to be practically feasible to verify that a computation was performed correctly with respect to potentially confidential data and produced concrete results. These proofs reveal only the accuracy of the computation performed and its results, without disclosing the actual state or actions involved. Their compact size and rapid verifiability are significant advantages.

[0064] In the context of the systems and methods disclosed herein, these proofs enable the execution of actions on a given state over a period of time, while maintaining agreement on preceding and succeeding states. This ensures that transitions from one state to the next occur through actions consistent with predefined rules, without revealing the actual state or action. The system enables multiple users to perform these actions bidirectionally and independently, fostering a global consensus on their individual states and sequences of actions. This behavior is consistent with the desired operation of the system as outlined in the introduction. (State and commitment)

[0065] As used herein, the term "state" may refer to data that an application's business logic relies on and manipulates through transactions. The validity and outcome of those transactions may be conditioned on the state value, and the outcome of those transactions becomes a new state. For example, in a banking transaction application, the state could be a user's balance, and the transactions could be transfers between users.

[0066] Figure 15 shows a simplified embodiment of a bank transaction system illustrating the concept of state changes resulting from transactions in the system, in several embodiments. The initial state, state 1 (1501), shows Alice with $100, Bob with $500, and Zander with $0 (1504). The depicted transaction (1502) includes Alice transferring $25 to Bob, and Bob transferring $15 to Zander. These transactions illustrate how state changes occur in this system based on user actions.

[0067] Transaction (1502) describes Alice transferring $25 to Bob, and Bob transferring $15 to Zander (1505). These transactions result in a new state, state 2 (1503), where Alice currently has $75, Bob has $60, and Zander has $15 (1506). This embodiment illustrates how the "state" changes as transactions are executed in this system. (State commitment)

[0068] As used herein, the terms “state commitment” or “cryptographic state commitment” may refer to a cryptographic commitment to a specific state. This commitment is a fragment of data that securely binds the state without being revealed, much like sealing the state in an envelope. Combined with zero-knowledge proofs, the system can make public commitments to a state while keeping the state completely confidential, transition state commitments to new ones according to predefined rules without disclosing the state or updated state, and validate statements about state commitments to other parties.

[0069] Figure 16 shows an example of proof (1601) illustrating the state transition from state 1 (1603) to state 2 (1605) as a result of executing a specific transaction (1604) in several embodiments. This figure demonstrates how the system can provide a verifiable proof of state changes caused by specific transactions in the system.

[0070] States and transactions are identified not by the underlying data, but by their individual commitments (State 1 commitment-1606, Transaction commitment-1607, State 2 commitment-1608), ensuring data confidentiality. Commitments 1606-1608 are made public, while state transitions (1603-1605) remain private. Figure 16 also illustrates proof 1602, confirming the inclusion of the specific transaction (1611) “Alice sends $25 to Bob” within a set of transactions (1610). These transactions are identified by their transaction commitment (1609). Commitment (1609) is made public and verifies the transactions, while the details of transactions (1610-1611) remain private and preserve confidentiality.

[0071] The term "state root" generally refers to the top-level node in a Merkle tree structure used to efficiently prove updates to a state. A commitment to this root can be used as a commitment to the entire tree, and business logic can verifiably update one of the lowest-level nodes, which carries the actual data and is addressed by its position in the tree, and is called a leaf. This can be done using only information about adjacent nodes and the root along the path to the relevant leaf, and this is logarithmic with respect to the total number of leaves.

[0072] Figure 17 shows examples of user state routes (1701) in a system that provide a graphical representation of how user states are structured and managed, according to several embodiments. This figure illustrates user state routes that contribute to maintaining and organizing user-related data in this system.

[0073] The root node (1702) is depicted at the top of the structure, with various paths (1703) extending downward toward individual user state commitments (1705, 1706, 1707, 1708). Adjacent nodes (1704) are shown along these paths. The diagram also identifies specific leaves (1709) for updating and demonstrates how individual leaves (1710) or the lowest-level nodes carrying the actual data can be addressed for updating within this Merkle-tree structure.

[0074] The term "state" in this system has two distinctly different meanings. Firstly, "state proper" specifically refers to data that is read, modified, and regulates subsequent claims by transactions. This includes data such as remaining asset balances, which can prevent false statements about resource consumption. This type of state is not exchanged between users but serves as a regulatory mechanism to avoid inconsistencies. The term "general state" refers to all data within this system, including the existence and status of entries, disclosures, and records. This encompasses recorded claims, which can form part of a "user state commitment." Despite being state, this data can be disclosed to other users. Due to potential ambiguity, these definitions distinguish between technical data constraints and data that records user activity within this system.

[0075] The term "state proper" refers to the specific structure of data in this system. This data consists of claims and attributes and separate variable key / value pairs, which can serve to impose constraints on subsequent transactions that generate claims. In some instances, these constraints are updated by the transaction itself. This state data is not disclosed to other users, thereby maintaining confidentiality. The structure of the state proper may vary depending on the specific aspects of the system, such as when entries constitute an entire claim within the "State and Objects" framework, or when applying a UTXO-like state or ephemeral state model under the "Scarcity and Spending" scenario.

[0076] The term "user state" generally refers to the cumulative state of all records across all frameworks, along with any framework-specific states that are not linked to specific records. This includes all data that may be involved in transactional logic or disclosure. In some cases, user state may refer to all states associated with a user node or user account.

[0077] The term "global state" can refer to a framework-specific state that is not linked to a particular record. This does not refer to the state of all users. The term is used to emphasize the fact that this state is not "local" to any individual record, but applies across various records within a specific framework.

[0078] In addition to user state and framework-specific state, the term "global state" is used in two other distinctly different ways. Firstly, it refers to the overall state of the system, including the state of all users and any shared state between users, such as shared logs or message boards. This global state is recorded on the blockchain and is subject to consensus among participants in the network. Secondly, the term "global state" is used to describe the state of a specific framework under a given user. This framework-specific state forms part of the system's overarching global state and plays a role in regulating transactions and claims within that particular framework.

[0079] In its first use, “global state” means the collective state of the System, including all user states and any shared states. This definition is particularly relevant in the context of proof generation in the System. The Systems and Methods disclosed herein may utilize public inputs during proof generation to define what the proof verifies. However, using user state commitments as public inputs could reveal too much information. To maintain confidentiality, the global state, including all user states, is instead used as the public input, effectively concealing individual users within the updated collective state. For example, when a user wishes to associate an asset with a shipment recorded by another user, using another user's state commitment as a target could inadvertently reveal excessive dependencies on that user within the supply chain. By referencing the global state instead of individual user states, the System maintains confidentiality while verifying proofs.

[0080] In the systems and methods disclosed herein, several key terms are used to describe various aspects of the systems and their functionality. These terms and their simplified illustrative examples are outlined in Table 1 below. [Table 1]

[0081] In a general system description, the term "framework" can refer to the aspects of rule enforcement within this system, as well as the ability to constrain data and formalize claims.

[0082] The "record" is designed to dynamically reflect changes over time. "Entries" are fundamental claims that discuss their evolution according to framework rules. An entry encompasses the entirety of the claim.

[0083] A “disclosure” is a type of claim that is managed as a disclosure. In the context of system descriptions, a “disclosure” is a choice that is shared with other users, subject to invalidation and consistency enforcement mechanisms through state mechanisms. The interaction between disclosures and entries involves logical dependencies on the attributes of local and non-local objects / records, and dependency constraints on non-local objects / records. An entry is defined as the most restrictive claim, which is the underlying fact or the most restrictive description. A disclosure is emphasized as a predicate concerning the specific attributes of a record and encompassing multiple entries.

[0084] A "transaction" can be an operation within this system. Transactions within this system may need to conform to rules defined in the framework. Validation mechanisms are involved in the transaction process. Transactions are constrained by entry and disclosure. Transactions cannot be constrained, and rule compliance is verified indirectly.

[0085] Entries and disclosures can be constrained by a framework business logic representation. For example, a business logic representation defines the forward propagation of predicates through an attribute definition directed acyclic graph (DAG) and the propagation of attribute constraints through a dependency DAG.

[0086] This system features various "approaches to ensuring data up-to-dateness," which are mechanisms to ensure currentness and relevance in data handling. For example, "obsolescence" is employed in data management, and forced propagation and expiration methods are used to ensure data validity.

[0087] The term "incremental claim" can refer to the ability of a user to add or update a claim over time, facilitated by the dynamic nature of the record, thus enabling flexible claim updates.

[0088] The term "claim derivation" can refer to recording, which captures and manages evolving knowledge, facilitates claim derivation, ensures logical dependencies, and ensures that derived claims remain in sync with underlying data and previous claims.

[0089] To construct “relative claims,” disclosures are used to describe the relationships between claims, thereby maintaining context and reference, as detailed in HL-DD. DD-DIS2.1 and DD-DIS2.2 further discuss that disclosures include predicates that address related claims and ensure consistency across interconnected claims.

[0090] From the perspective of "public verifiability of system integrity," the system and methods utilize zk-SNARK to ensure that each state transition conforms to predefined rules. By using interaction with the public blockchain, viewers can verify system integrity with transparency, and the Merkle tree provides an authenticated data structure for efficient system state verification.

[0091] The systems and methods described herein, through the zk-SNARK process, are designed to function without publicly exposing the underlying data, and by utilizing transactions, they can enable "confidentiality of transaction details from public viewing." Furthermore, disclosure is used to enable the sharing of selected information without exposing the entire dataset.

[0092] The systems and methods described herein may enable "confidentiality of transaction details from system operators" by having operators process zk-SNARK certificates without accessing the underlying data, and disclosure further enables selective data sharing without requiring the provision of details to system operators.

[0093] The systems and methods described herein may enable “witness data concealment” and secure, confidential data sharing by using disclosure to handle claims, by exposing predicates about witness data rather than the witness data itself.

[0094] (Issues with existing methods and systems for creating verifiable sustainability claims)

[0095] Existing systems for generating verifiable sustainability claims typically either rely on complete transparency or appeal to an authorized authority to provide evidence of the claim's validity. Alternatively, they explore a more fragile and traditional concept of verifiability, where instead of auditing the basis of the claim, the user is given an unrepealable, signed version of the claim guaranteeing its authenticity. As an example, verifiable certificates (VCs) are a specification developed by the World Wide Web Consortium (W3C) that could digitize existing trust infrastructure. This allows entities to receive or issue unrepealable and revoked certificates from trusted issuing authorities identified by their non-uniform identifiers (DIDs). These certificates can be presented in the form of verifiable presentations, a process by which an entity can, without authorization, prove that it is the holder of the certificate and selectively disclose certificate fields. The recipient of the presentation can then verify that the certificate was indeed issued by the claimed issuing authority. Various initiatives to adopt this technology for authentic data exchange within the supply chain are underway through certificates issued by either the entity itself or a trusted third party.

[0096] Verifiable Certificates (VCs) can only provide a mechanism to ensure the authenticity of claims. VC issuers can stake their reputation on the truthfulness of those claims by substantiating them. However, the extent of this stake can depend on the risk exposed if the claims are found to be false. To mitigate liability and enhance the credibility of claims, users may choose to include underlying VCs along with their original issuers. This alternative may allow users to substantiate claims themselves based on the presented VCs. However, doing so may inadvertently disclose extensive details about the structure of their supply chains and the actors involved, assuming they have access to those source VCs. While this approach may provide assurance of authenticity, it may not inherently guarantee the integrity of the claims.

[0097] Authenticity alone is not sufficient to guarantee a consistent narrative. Entities may provide different information to different parties, and without a central, trusted intermediary, variations in the narrative may not be apparent. Potential collusion between parties can lead to the creation of manipulated information, further complicating the narrative. This is particularly evident in contexts involving respect for scarcity, such as avoiding double spending or overspending of assets, or adhering to the theoretical manufacturing capacity of a facility. Therefore, while the authenticity of a certificate may be one factor, mechanisms to help ensure narrative consistency are also part of these systems.

[0098] Another existing method verifies compliance through transparency on a public blockchain. When the supply chain actions and storage chains are publicly available on a public blockchain, an authentic and publicly binding audit trail can be established. This allows for self-verification of the consistency of claims by algorithmically examining them. Alternatively, a light client may be used, which checks whether an independent validator is guaranteeing compliance with the rules, often at significant financial risk to itself. This approach provides robust credit assurance and accountability. However, it is not always possible to maintain data confidentiality. There may be supply chain actors who are unable or unwilling to provide all relevant data publicly and transparently.

[0099] Furthermore, existing approaches involve anonymizing transaction fields that are not related to business logic, while simultaneously identifying subjects and actors using pseudonyms, through the use of cryptographic commitments. Descriptions of the supply chain can be supported by leveraging committed confidential information. This information does not need to be provided to a public or centrally trusted authority. Instead, it can be verified using off-chain zero-knowledge proofs exchanged peer-to-peer. This approach balances transparency and data privacy. However, it should be noted that data from transparent transaction fields and pseudonymized supply chain graphs may carry sensitive information. Public data can provide insights, among other details, into pseudonymized recipe ratios, centralization risks in the supply chain, and potential opportunities to bypass intermediaries. In addition, correlation with supplemental real-world information can be performed. Similar situations may arise in other contexts, such as the use of pseudonymized transaction data in cryptocurrencies, sometimes used to de-anonymize users through analytical methods.

[0100] Finally, existing methods may involve trusted authority bodies and a private blockchain. These entities could potentially validate the overall narrative consistency and act as witnesses to the underlying data. This approach could be employed for a global narrative comparable to the open transparency described earlier, but the underlying data would only be exposed to these authorized parties. This implies the need for a group of entities entrusted with securing highly sensitive data, handling it in good faith, and agreeing on a consistent ledger of actions within the system. The possibility of utilizing techniques such as threshold homomorphic encryption also exists. Using this approach, the parties operating the system could work with data encrypted under a global public key, making it potentially impossible to decrypt the data without collusion. While this could potentially mitigate the risk of data compromise, current performance levels may make this approach impractical due to overhead and the need for a committee of trusted parties to store the encrypted data. Because these schemes rely on the assumption of computational difficulty, invalidating this assumption could mean that violating only a single committee member could lead to the exposure of all stored confidential data. Further issues remain regarding who can constitute the committee, which is politically sensitive and faces the problem that individuals who can be trusted to operate the system may not necessarily possess the appropriate technical expertise, and vice versa.

[0101] (Improved systems and methods)

[0102] The systems and methods described herein can improve upon existing methods and systems to address the aforementioned needs. The systems and methods described herein present an approach in which users process, validate, and maintain control over their own data. Users commit to the data and their actions on a consensus layer that is reliably neutral, providing a robust guarantee of persistence. The effectiveness of the processing is demonstrated privately using zk-SNARK. By utilizing zk-SNARK and a commitment scheme with perfect confidentiality, the hardness assumption shifts from unconditional data confidentiality to the ability to commit fraud by creating either proof of fraud or a fraudulent claim about the data underlying the commitment. This positions the systems and methods disclosed herein as an innovative solution for secure data management in scenarios such as supply chain transparency.

[0103] The systems and methods disclosed herein are designed to make it computationally impossible to construct a compelling false claim of compliance, based on assumptions about available resources and the resources required to solve a particular computation problem. In addition, extracting further information about committed data beyond what is disclosed is extremely difficult. One consideration in these systems and methods is determining the appropriate level of disclosure regarding the recipient. Multiple disclosures can lead to speculation, and these claims may influence how they are formalized and substantiated. Therefore, these systems and methods aim to balance the need for data confidentiality with transparency and verifiability.

[0104] The systems and methods disclosed herein centralize multiple capabilities for robust data management. The systems and methods disclosed herein utilize third-party issued certificates to support the validity of claims and demonstrate the ability to take specific actions. Simultaneously, these systems and methods provide strong confidentiality and anonymity guarantees, ensuring a consistent narrative across all transactions and interactions within the system.

[0105] The systems and methods disclosed herein provide a flexible approach to data registration and communication. They allow for variations in the order of data registration, the level of detail within the registered data, and the completeness of the communicated data. They also adapt to the correction of errors and omissions. All of this is achieved without compromising the integrity and clarity of claims or revealing the sources on which those claims are based. They prevent corrections from being used to create contradictory claims that are transparent and unquestionable to the recipient. These systems and methods also include scarcity preservation without compromising confidentiality, thereby preventing users from implicitly depleting the same resource multiple times through the use of confidentiality.

[0106] Related systems such as ZCash, Aztec, and Aleo exist that combine blockchain and zero-knowledge proofs for special-purpose private cryptocurrency transactions or general-purpose privacy-preserving smart contracts, but these systems often rely on cryptography rather than commitment schemes. Given the public nature of these systems, this approach may potentially face the risk of post-memory decryption scenarios in which the cryptographic scheme could be compromised. However, the systems and methods disclosed herein utilize commitment schemes to secure data and address these potential vulnerabilities.

[0107] For data requiring a high degree of care in handling, the guarantees provided by encryption-based systems may not be adequate. Furthermore, the existence of such tools and platforms does not necessarily inform how they can be utilized to implement privacy-preserving traceability systems. These systems may need to be sufficiently flexible to adapt to real-world use cases that require features such as updates, expirations, and incremental data entries. The systems and methods disclosed herein aim to address these considerations and provide a framework that such systems may constitute.

[0108] In the context of the systems and methods disclosed herein, “verifiable” means the provision of cryptographic evidence in which the claim is made in a manner consistent with formally defined rules and whose existence may be difficult to construct unless agreed upon by a consensus mechanism.

[0109] In the context of the systems and methods disclosed herein, "confidentiality" refers to the optimal minimization of information disclosed beyond the core claims. This includes not only the subject matter of the claims but also relevant aspects of the derivation of the claims. These aspects may help to foster a trustworthy environment for the claims. However, this does not expressly state that these elements are essential or useful for the overall functioning of the systems. The disclosed systems and methods provide a flexible framework that allows for varying levels of confidentiality based on specific requirements and context.

[0110] In the context of the disclosed systems and methods, "consistency" refers to adherence to predefined rules or conditions, ensuring that all entries and claims within this system maintain uniformity and are not contradictory.

[0111] "Cooperativeness" indicates that in these systems and methods, entries can be verifiablely derived from other records created by different stakeholders. These records themselves can also be derived from other records, thereby enhancing the cooperative nature of the system.

[0112] A “claim” is defined as a limited description of a subject. This can be expressed directly or inferred from other existing claims within this system.

[0113] In the context of these systems and methods, "record" refers to an organized collection of claims related to a specific subject.

[0114] An "entry" is a specific claim associated with a record within this system. (Record keeping and entry version control)

[0115] "Record and Entry Version Control" relates to the time-series management and updating of entries or distinctly different representations about subject matter in the systems and methods disclosed herein. This includes several methods for tracking the progress and revision of entries.

[0116] "RV1" refers to an incremental and sparse method for setting up entries, featuring an append-only log that documents the progress of each entry. Entries are version-controlled, with each version containing the most restrictive or strict assertion.

[0117] "RV2" describes a method in which entries are instantly set within a single instance, known as a version. This allows for state modifications resulting from the creation of entries in other records without requiring the creation of a new version. The integrity of the target record is therefore preserved, and the version log maintains historical tracking.

[0118] "RV3" describes a hybrid approach where records are immediately version-controlled and designated. However, versions potentially consist of references to entries created in previous versions, preserving identical identification and linked metadata of entries across versions.

[0119] Collectively, these options demonstrate the suitability of the disclosed systems and methods for managing and tracking the progress of entries in the records, and ensure accuracy and consistency, even in the case of updates or modifications.

[0120] Figure 8 illustrates different approaches to version control of entries and records within a system in several embodiments. Specifically, Figure 8A shows an embodiment of a record as a collection of versioned entries, Figure 8B presents a record as a versioned collection of entries, and Figure 8C depicts a record as a versioned collection of entry references. Each figure represents a unique approach to managing and tracking the progress of entries within a record, demonstrating the versatility of the disclosed system in handling version control.

[0121] Figure 8A shows an example of a record (801) in this system. The record consists of various attributes (802), specifically attribute 803, attribute 804, and attribute 805. Each attribute in this system has multiple versions (806), represented by distinctly different entries (807, 808, 809). This schematic diagram illustrates one method of organizing and managing entries in a record within the system, according to several embodiments.

[0122] Figure 8B shows an example of a versioned record (810) in this system, showing its initial state (811) and its previous version (812). The record contains several attributes (813), including attributes 814 and 815. Each attribute corresponds to individual entries (817, 818) under entry (816). Subsequently, another version of the record (819) is shown, along with its previous version (820), several attributes (821, 822, 823, 824), and corresponding entries (825, 826, 827, 828). This figure demonstrates different methods of managing entries within a record in the system, according to several embodiments. Figure 8C shows an example of a hybrid approach to record and entry version control in this system. This starts from the initial state (829) and proceeds to record (830), along with its previous version (831) and attributes (832, 833). This is followed by another version of the record (834), along with its previous version (835), multiple attributes (836, 837, 838), and corresponding entries (839, 840). Additional entries (841, 842) are also depicted, which maintain the same identification across different versions. The figure illustrates various approaches to managing and tracking the progression of entries within a record, as demonstrated by several embodiments, and shows the versatility of the disclosed system in handling version control.

[0123] While the overarching purpose of this system is discussed in a broader sense in the previous section, this section lists its specific characteristics and functionalities. These represent only some of the notable features of the system and method described herein.

[0124] In some embodiments, the systems and methods described herein can establish a public consensus regarding the system state. In some embodiments, the systems and methods described herein can facilitate an unambiguous and consistent understanding among all participants of the transactions that have occurred and, if applicable, their order. Such configurations make it extremely difficult to dispute a particular sequence of transactions in the ledger after a specific point in time.

[0125] In some embodiments, the systems and methods described herein may be configured to support public verifiability of system integrity. Such features may enable efficient verification that the progress of the system up to a certain point has reached a specific state or state commitment in accordance with specified rules.

[0126] In some embodiments, the systems and methods described herein may enable users to perform transactions and update the status of their accounts without publicly disclosing the details underlying those transactions or states, thereby providing a feature that preserves the confidentiality of user transactions in the system.

[0127] In some embodiments, the systems and methods described herein may include features that enable users to conduct transactions and update their account states without disclosing the underlying details of those transactions or states to a system operator. This means that the system operator handling the user's transactions and state updates does not require authorized access to the underlying data, thus improving user privacy.

[0128] In some embodiments, the systems and methods described herein may have features that enable a user to disclose to another party a claim made in the system without revealing the underlying data details that support the claim. This means that the existence and truthfulness of the claim can be verified against the system logic while preserving the confidentiality of the witness data.

[0129] In some embodiments, the systems and methods described herein may be configured to allow incremental claims. This means that the user does not need to make all claims about a given subject simultaneously. For example, if information was not available previously, additional information can be provided at a later time. This feature adds flexibility and allows for the integration of new information as it becomes available.

[0130] In some embodiments, the systems and methods described herein may be designed to enable the derivation of claims. This feature enables the use of claims, either by other users or by the user themselves, as evidence to support other claims. According to agreed rules, these derived claims are either concluded from or depend on the evidence, and the system provides a robust mechanism for evidence-based claim support.

[0131] In some embodiments, the systems and methods described herein may be configured to enable updatable claims. This feature allows users to update or override claims about a subject, provide additional details that were not present in the original claim, or even directly deny it in light of new information. This flexibility allows the system to adapt and adjust to information that evolves over time.

[0132] In some embodiments, the systems and methods described herein may include features that facilitate transparency of inconsistencies or invalidations. This means that if a user makes a contradictory claim, such as overriding a specific attribute of a subject or denying the premise of a previously made derivation or conditional claim, it is highly unlikely that the user can reliably represent that the denied claim remains valid from that point onward, unless it can be otherwise demonstrated. As a result, the denied claim may be considered doubtful and effectively given an expiration date. This feature enhances the transparency and reliability of information in the system.

[0133] In some embodiments, the systems and methods described herein may be configured to enable efficient communication of discrepancies. This feature allows users to update the status of claims, the complexity of which depends on the number of updates, not the total number of claims disclosed to the user. This approach enables effective communication of changes or discrepancies without overwhelming the user with unnecessary information.

[0134] In some embodiments, the systems and methods described herein may be designed to support the creation of relative claims. This means that if an object maintains a directed relationship with another object such that a claim exists about the other object, where the other object is a value of an attribute of the original object, then it may be possible to derive a claim about the other object in the context of that relationship with the original object. This feature allows for a more nuanced understanding of the relationships and dependencies between different objects in the system.

[0135] In some embodiments, the systems and methods described herein may be designed to support the authenticity of claims. This feature enables the system to provide evidence that sources or supports claims, to a certain level of detail or from a relative perspective, for identification purposes. The system is configured such that it is extremely unlikely that such claims could be fabricated fraudulently, and the evidence provided is irrefutable. This feature enhances the reliability and credibility of claims in the system.

[0136] In some embodiments, the systems and methods described herein may be designed to allow the propagation of inconsistencies or invalidations. This feature means that if a claim relies on another claim that has been invalidated, it may no longer be possible to assert the validity of the dependent claim from that point onward. As a result, the dependent claim becomes expired. This feature improves the system's ability to maintain the integrity and consistency of claims.

[0137] In some embodiments, the systems and methods described herein may be designed to enforce scarcity respect claims. This feature enables enforcement of certain claims to the concept of scarcity, whether for recoverable resources such as warehouse capacity and unit utilization rates, irreversible resources such as materials converted by irreversible processes, or single allocations such as the receipt of shipments. This feature facilitates the accurate representation and management of scarce resources in the system.

[0138] In some embodiments, the systems and methods described herein may allow for varying levels of granularity when making claims. This feature allows users to make claims with varying degrees of precision or ambiguity that represent their own state of knowledge, which does not always have to be precise. This flexibility enables a more accurate representation of the user's knowledge and uncertainties in the system.

[0139] In some embodiments, the systems and methods described herein may support varying levels of disclosure. This feature allows users to derive less specific claims, from more precise ones, for the purpose of selectively disclosing them at a level of detail appropriate to the disclosing subject. This includes predicates relating to the metadata of the claims. This flexibility improves the suitability of the system for different disclosing subjects and use cases.

[0140] In some embodiments, the systems and methods described herein may enable derivation from disclosures. This feature allows users to support and derive their own claims from less specific claims that have been derived by other users and are subsequently disclosed, according to predefined rules. This functionality enhances the system's ability to integrate and build in accordance with shared information.

[0141] In some embodiments, the systems and methods described herein may support interoperability of claims between rule systems. This feature allows a user to leverage a claim made within a system of rules representing a certain regulatory system or proof scheme to derive a claim within another system of rules, provided that the specific system of rules permits such use. This functionality improves the suitability and compatibility of systems with different regulatory systems and proof schemes. (System description)

[0142] This disclosure provides a system and methodology that leverages blockchain and zero-knowledge proofs to create claims that are resistant to covert ex-post manipulation and inconsistencies associated with the validation of data entries and / or subsequently derived claims, and which are applicable to supply chain transparency. Depending on this foundation, a full-scale traceability and compliance solution can be implemented that carries out the entire process, from defining data requirements to data collection, verification, and auditing, without relying on human trust or the exposure of non-public data, and without relying on a single trusted authority for consistent reporting of recorded content, in accordance with defined rules to ensure the integrity of those processes.

[0143] The following includes components of the methods and systems described herein.

[0144] Public Commitment: Stakeholders interacting with the system publicly contribute to a commitment (or collection thereof) to records and entries. These records refer to either a single claim (entry) or a collection of consistent claims (entries) about an object, entity, process step, event, or characteristic, which may also be a collection of other linked claims.

[0145] Consensus: The entirety of committed records and entries is agreed upon by a fault-tolerant consensus mechanism, such as a public blockchain.

[0146] Dependency links: Committed with an entry are references to any other entries whose truthfulness directly depends on that entry, and references to any other entries whose truthfulness directly depends on that entry.

[0147] Update Link: Entries referenced by the record may also be updated, but the process by which this update occurred and the previous entry being overwritten are specified.

[0148] Public Verifiability: The integrity of committed records and the processes that created those entries, as well as the existence of their dependencies, can be verified by all stakeholders in this system through zero-knowledge proofs, without revealing details of process or dependency identification.

[0149] Logical Transparency: Entries may be made to (verifiably) reference details of the process by which other entries were created (e.g., self-issued claims, claims verifiably inferred from established rules, claims audited / authorized by third parties).

[0150] The systems and methods disclosed herein include verifiable disclosure methods for sharing entries from records among stakeholders. These methods leverage the inherent characteristics of the systems to: a) disclose entries with verifiable audit trails at an appropriate level of detail that maintain their truthfulness while keeping them confidential; b) maintain a consistent narrative about a given record (any deviations are revealed, prohibited, or questioned by the omission of evidence); c) ensure the verifiability of claims that respect scarcity or prevent double spending, such as the transfer of limited assets or limitations on asset volume; d) maintain the identification and protection of stakeholders and subjects through relative claim nature that broadens the scope of disclosure while ensuring authenticity; and e) ensure the truthfulness of disclosed entries based on the truthfulness of disclosed entries, premised on their verifiable correspondence with committed entries.

[0151] Decentralized systems can enable stakeholders to create verifiable digital product passports, which provide publicly verifiable evidence and ensure consistency, authenticity, and coherence regarding claims about the subject, identified by their relationships with the subject, while ensuring privacy beyond the truthfulness of the claims.

[0152] Of particular note is that narrative consistency, balance checks, indication of changes, and credibility in the fulfillment of predicate conditions are achieved without relying on a single central authority or auditor, while simultaneously avoiding unnecessary disclosure of non-public information for the same purpose. This frees auditors from certifying stakeholders' capabilities (e.g., certificates, warehouse capacity) and bridges the gap between records and reality.

[0153] In this system, each user has a private state recorded on their user node. This state includes the complete set of records and claims (entries, disclosures) made, any additional metadata about them, auxiliary data required to create proofs, additional elements required to enforce the framework's rules, and other unspecified data. This state is then committed by a single cryptographic commitment to an authenticated data structure, or alternatively, by multiple cryptographic commitments and nullifiers. These commitments are then made public on the public blockchain. The publication of these state commitments results in an update to the globally agreed state, which consists of these state commitments and potentially additional data. The publication of state updates is subject to verification of a zero-knowledge concise non-interactive knowledge argument (zk-SNARK) that the state update was the result of a valid state transition. State commitments contain encoded metadata about the specific methods used or claims made, as enabled by the framework, which verifiably informs the user about what is being claimed. All of this is enforced by global business logic. (Framework)

[0154] The system and method may include a framework. The framework may represent various regulatory and certification schemes to which the user may wish to provide evidence of compliance, or at least compliance. The framework guides data entries toward a consistent scheme, formalizes claims within the system, and ensures uniformity and compliance with the desired standard or regulation.

[0155] In many instances, the same data about the same subject may be represented in multiple ways, and rules in a regulatory system may be interpreted and formally represented differently. The systems and methods disclosed herein address these issues by defining frameworks, which consist of a set of rules that determine how data is entered and how claims are supported. This limits the number of ways a user may attempt to satisfy a claim, and means that only these rules need to be evaluated by an accredited party to determine whether a claim in this system conforms to the standards of the relevant regulation or certification scheme. This approach reduces the expectation that users should understand the precise formalization of the descriptions to be satisfied, thereby improving the overall availability and efficiency of this system.

[0156] In some instances, defining how these claims can be checked using existing zero-knowledge proof systems is particularly useful. These systems may require specific adjustments to adapt to the inherent characteristics of the underlying proof system for optimal performance. This is another aspect that the systems and methods disclosed herein consider for improved efficiency and accuracy.

[0157] The systems and methods disclosed herein can constrain the formal expression of claims through a framework. This approach potentially reduces the total workload involved in auditing claim counterparts against their real-world meaning, while also enabling the collaborative construction of inductive claims across the supply chain. This is facilitated by semantic consistency of claims among various parties, including those claims that may not be directly audited by the final verifier.

[0158] The systems and methods disclosed herein shift the conventional audit process. Instead of auditors, track and trace providers, accounting services, and other providers being certified based on their ability to comply with specific rulebooks by appropriate competent authorities, the framework itself is intended to be certified. This implies that specific operators or service providers are less relevant as long as the framework can be proven to meet and comply with appropriate standards as long as the evidence used and provided under the definition of the framework can be proven to meet and comply with appropriate standards. Given the highly specific nature of the prescribed constraint system concerning zk-SNARK, the framework may need to be audited by experts trusted by appropriate competent authorities, or a domain-specific language that can be audited by less specific competent authorities may need to be used, with its conversion to provable constraints that can be audited by experts. As a result, trust is not eliminated, but made readable, subject to public scrutiny, and shifted from providers to the implementation of the framework itself.

[0159] The framework is a flexible and transparent formalization of evidence standards, and may define how they interoperate with other systems and the forms of evidence they provide. For example, whether a verifiable certificate issued by a certain authority constitutes a sufficient standard of evidence, or whether a suitable set of entities for notarizing externally sourced information, or a bridge to the state of other verifiable data registries, or a notary public, is considered trustworthy. Records and entries

[0160] In the context of the systems and methods disclosed herein, a record is an object, as described by the framework. As a whole, a record represents the user's knowledge or evidence over time regarding the framework-defined attributes of a given object. These records are dynamic, reflecting the user's evolving understanding of the object being recorded over time, adapting to potential corrections of errors in entries or measurements, the revocation of certificates, or prior assertions that certain details were conditional, among other status attributes such as whether or where an asset was spent. However, this evolving knowledge or evidence about the object is distinctly different from, and is depicted as different from, the changes in the object's state or its current state. The aim of these systems and methods is not to represent the object's current state in that way, but rather to represent the narrative of how they arrived at their current state and the development of the user's knowledge and assertions about this progress.

[0161] In some embodiments, in the systems and methods described herein, each subject may have at most one record per user per framework, but no other constraints exist. Over time, evolving claims about aspects of a subject or the results of transformations of a subject may be represented by multiple records. However, each subject is identified by a specific root record, and the system may provide a distinctly different identifier for each subject.

[0162] In the systems and methods described herein, entries represent the basic claims made by the user about the attributes of the subject described by the record. These entries reflect the current state of the user's knowledge and judgment. They serve as a primary source for the user to present the most precise and limited understanding of the subject's attributes available in the system and for deriving further claims. This feature enables the system to accurately represent and utilize the user's knowledge and understanding of the subject.

[0163] In the systems and methods described herein, each attribute of a record has an associated entry, specified by the user. This entry contains the user's most recent and most constrained claim about that attribute. These entries constitute the state of the record, which evolves as the entries are updated or revised based on new information, corrections, or derivations shared by the other party. This feature serves as a mechanism for maintaining consistency of claims about the same subject within the system.

[0164] In some embodiments, the systems and methods described herein store a history of each entry with respect to attributes. This includes documenting how and when a claim was made and the information on which it is based. This history storage provides a comprehensive and chronological record of claims, improving the traceability and traversability of the system. (Disclosure)

[0165] In the systems and methods described herein, a disclosure is a type of claim that serves as a predicate relating to the entry history, the record history, and its associated metadata. Disclosures are shared with other users and form the basis for their own claims. Disclosures as predicates relating to claims do not alter the state of the record, but they may serve as versions of input claims at a level of detail sufficient for the understanding and derivation of their own entries and recipients of the disclosures.

[0166] In the systems and methods described herein, entries not only describe attributes but also specify (or imply, based on framework constraints) how they were created. Consequently, disclosures act as predicates concerning both attributes and the processes by which the entries were created. This specificity can, for example, help distinguish between claims expressed by a user about an upstream event or subject in a supply chain and claims derived from first-party data about an event immediately after its occurrence. It also distinguishes claims supported by valid certificates from trusted authoritative authorities without revealing the certificates themselves. This feature enhances the specificity and comprehensiveness of disclosures in the system. Global execution environment

[0167] The global execution environment leverages a public blockchain to ensure a single-state commitment agreed upon by all participants, maintaining an immutable and consensus-driven state. In some embodiments, the methods and systems herein employ zk-SNARKs and other zero-knowledge proofs, along with Merkle trees and cryptographic accumulators, to provide a mechanism for globally verifiable state updates, ensuring transactions and consistent system state updates that do not expose the underlying data.

[0168] The global execution environment, as described in the Systems and Methods of this Specified, enables efficient proof that a claim, which is both internal (created by the user issuing the transaction) and external (created by another user and communicated to the user issuing the transaction), exists and is considered valid at a specific timestamp. The system is structured to enable global validation without specifying the particular user who created the claim referenced by the transaction. In some cases, the state is organized into a global root commitment. This commitment encompasses all claims made by the user up to a given timestamp, but in some instances, it does not expose them. This forms a large set of anonymity regarding both the claims and the users issuing them, while still enabling public verification in the system that the claims used actually exist and satisfy their requirements. The root commitment can be used as public input to a proof that verifies the user's state transitions and the claims made, which can be publicly verified. Private witnesses of proofs, on the other hand, are used to verify the claims used, their existence, and their characteristics without exposing them to verifiers.

[0169] Figure 1 shows an example of a global execution environment. The global execution environment implements the methods and systems described herein to manage private data, state commitments, and blockchain transactions within a blockchain network. It depicts the interaction between user node 1805, public blockchain 101, and another user node 109, forming proof of committed data. This figure is an extension of the process previously described in Figure 16, but with additional complexity in the relationship between transactions and state.

[0170] Each user has a state, which is fully recorded on the user node 105. User state may also be referred to as user account or user node state. Data, which is private to individual user nodes, may include: i) the entirety of records and claims (entries, disclosures) made; ii) any additional metadata about the claims or their creation; iii) auxiliary data required to create proofs; iv) optional additional frameworks, records, and user states required to enforce the rules of the framework; v) any other data as needed. In the illustrated embodiment, user node 105 processes its private data, such as shipping records or material property claims. The state resulting from this processing is then committed to the public blockchain 101, forming a user state commitment 102. User node 105 updates the commitment by creating a state commitment update proof 107, which serves to verify that the new state conforms to system rules and is derived from a previously verified state. As described elsewhere in this specification, a state is committed by a single cryptographic commitment to an authenticated data structure / Merkle tree that represents the complete state, or by multiple cryptographic commitments and nullifiers.

[0171] In some embodiments, the data or information published on the public blockchain 101 may include: i) the publication of state commitments consisting of these state commitments (which may result in an update to the global state agreed upon by blockchain consensus); ii) the publication of the state update, subject to zk-SNARK verification that the state update was the result of a valid state transition following global (i.e., non-framework specific) business logic; and iii) metadata encoded within the state commitment about a specific method / formally defined claim being made, which is enforced by the global business logic and which makes the content being claimed verifiable to the user.

[0172] As illustrated in Figure 1, the public blockchain 101 stores user state commitments 102 and global state data 103. This data is updated with any state modification, keeping the blockchain information up-to-date and accurate.

[0173] To ensure privacy, this system uses disclosures. These are additional proofs used to selectively reveal information about state snapshots to other users. For example, if user A records information related to user B, user A can verify this information about user B using disclosures. This allows user B to refer to this new data, integrate it into their systems, and update it.

[0174] Data from the public blockchain 101 may be transferred to the user node 109. The user node 109 holds its own private data and state 110, along with information related to the blockchain state 111.

[0175] User node 105 sends disclosure 112 to user node 109, which generates proof of committed data. This disclosure is then checked within user node 109 against the public blockchain commitment. This verification ensures that the received data is valid and that the blockchain state is consistent.

[0176] In some cases, data in this system may be managed on a per-user account basis. This is due to the importance of consistent and unique identification when assigning value to claims, and the need for this system to maintain readability, particularly for interoperability with other systems centered on non-uniform identifiers (DIDs) and verifiable certificates (VCs) that rely on such persistent pseudonym identification.

[0177] In the systems and methods described herein, accounts confidentially record their state in the form of cryptographic commitments and provide state updates using zk-SNARK. This configuration results in a model consisting of parallel, confidential, and verifiable state machines with shared global state. The model is analogous to a network of fault-tolerant machines that run trusted software in a trusted environment while maintaining the storage of non-public data. This feature enhances the security and confidentiality of the system.

[0178] (Recursive proof)

[0179] In some embodiments, all user states transition within a given block, or further, a given blockchain can be recursively aggregated into a single proof so that the blockchain's global state can be validated through a single proof. When this involves blockchain consensus, it is referred to as a concise blockchain. This allows end users to quickly verify claims.

[0180] In some embodiments, disclosures may interact with and be derived through a recursive zk-SNARK. In these embodiments, a user may seek a proof (disclosure) about their own or another user's state, or multiple proofs about the states of multiple users, and then use those proofs to derive another claim (disclosure) that matches those proofs without updating their own user state. Record states or entries are still committed / recorded on-chain, but the derivation of weak claims or the creation of cooperative inductive claims from disclosures may occur off-chain. The recursive zk-SNARK is used for permissionless derivation of further claims / disclosures, including cooperative inductive claims, based on multiple disclosures, according to framework rules, without performing state transitions (i.e., updating a state from a previous state). (transaction)

[0181] In the systems and methods described herein, a transaction may be involved in creating a claim, which may be either an entry or a disclosure. Upon execution, the transaction validates that the exact claim being made is acceptable, given the context and framework rules. This also results in any secondary effects, such as invalidation, entry setting, and claim creation, all in accordance with the framework rules. This feature ensures that all transactions comply with established rules and maintain the integrity of the system. (An approach to ensure data up-to-dateness)

[0182] In the systems and methods described herein, ensuring that disclosed claims and their inductive dependencies remain current and valid may be advantageous, particularly for claims that rely on certificates, are expirable, or are revoked, or are linked to the consumption or transfer of scarce assets. While the task of ensuring data currentness may be relatively straightforward in public systems, maintaining confidentiality and avoiding correlation between users in such systems may add an element of complexity.

[0183] The systems and methods described herein utilize the concept of disclosure obsolescence. The status of a disclosure may change over time, and its status must be periodically checked against the current committed state of the disclosing party within the global execution environment. If a certain threshold time is exceeded, the disclosure is considered obsolete and therefore becomes questionable, as its underlying claims may have been replaced or become invalid from within, and subsequent claims made by the user may contradict them. This obsolescence applies not only to the disclosure itself but also to any disclosures used to support the underlying claims. Therefore, in order for a disclosure to be credible and to avoid contradictory claims, it may be useful to periodically check the recursive definition of obsolescence, and a disclosure is considered obsolete if any of its statuses has not been checked within the threshold interval, or if any disclosures used to support it, directly or indirectly, through internal intermediate claims, are also obsolete.

[0184] In other embodiments, the systems and methods described herein may utilize the concept of forced propagation via revocation, which involves the disclosure of claims but preserves confidentiality. However, this approach may carry a higher confidentiality risk due to its reliance on computational assumptions in the cryptographic techniques involved and the useful disclosure of revocation actions, which can potentially reveal correlations between dependent claims through the timing of propagating revocations. This also necessitates the concealment of the identification of the revocation issuer to mitigate potential correlations, resulting in a ZCash-like, private, one-time-use, add-on-only state commitment rather than a variable, publicly available user / state commitment map.

[0185] In the systems and methods described herein, the burden of periodic synchronization with other users in an obsolescence-based approach may be mitigated by a freeze period mandated by the framework, after which the record becomes immutable. A similar approach may be applied in a public revocation-based method, which may limit the size of the set of disclosures, whose revocation status must be checked for inclusion in the public revocation log. However, care may be taken not to enable frozen records in such a way that they allow opaque alteration of the unfrozen dependencies of the claims in the frozen record. This is not an issue if the nullifiers for all dependencies of a given claim, including indirect dependencies via intermediate claims, are known to the parties to whom the claim is disclosed. In this case, the revocation may not be censored by the intermediary, but this comes at the cost of increased correlation risk, as global identifiers for the claims' dependencies are necessarily known. (End-to-end overview of the system)

[0186] In the systems and methods disclosed herein, user nodes may be operated directly by the user, or they may delegate the task to a trusted party. These user nodes may be involved in maintaining records of the user's private status and any auxiliary data that may be useful for generating zero-knowledge proofs, such as intermediate nodes of authenticated data structures. In addition, user nodes may execute, aggregate, and verify user transactions and generate zero-knowledge proofs for peer-to-peer information exchange. The process may effectively isolate and reveal private user data only to a level of detail deemed appropriate to the receiving party, based solely on the need to understand it.

[0187] Users can contribute claims about objects through transactions on their user nodes that conform to the scheme and logic of the associated framework. The creation of claims and objects, along with links to objects via claim references, can establish a canonical narrative about the various states and events of the objects over time. The interpretation of this narrative is determined by the framework. These transactions are ultimately verified by the user via zk-SNARK, which is submitted to the public blockchain as an unrepealable proof of state update, updating the on-chain state commitment. zk-SNARK can guarantee the integrity of on-chain commitments and their consistency with framework definitions, and can ensure that the recorded information represents the history of objects as well as the history of claims made about them, including contradictions between previous claims by more recent ones.

[0188] User nodes may also handle the exchange of data underlying the disclosure and provide insights into aspects of the user's narrative. This includes both current claims about events and historical records of those claims, shared at a level of detail appropriate to the recipient. The disclosure may provide insights into relative relationships between subjects or global identification of subjects that are suitable for the recipient. Assuming that the on-chain commitment on which the disclosure is based is perfectly confidential, the underlying claims are shared, while the correlation with the commitment is cryptographically proven. This approach can ensure that the validity of the claims can be incorporated into the state update proofs of the recipient user's node and leveraged in their own derived claims and narrative structures. The structure of the on-chain commitment allows the user's state update proofs to verify and use the disclosure to support further claims without requiring public reference to specific underlying data, subject identification, or original creators.

[0189] The systems and methods disclosed herein are described in such a manner that a claim can be supported by the statement itself without requiring the exposure of underlying evidence. This maintains credibility because the existence of the evidence is still known. For example, in a scenario such as the child labor case illustrated in Figure 2, it is sufficient to know that a certain certificate or document is issued by a member of a specified set of issuing bodies, without requiring the specific identification of the issuing body. For any given product, it may be sufficient to demonstrate that all input products meet the definition of not using child labor and that the processing facility holds the relevant certificate, without requiring the identification of individual input products, their manufacturers, or the exact number of those products. The focus here is on demonstrating compliance with the correct definition, and if non-compliance occurs, the extent of the deviation can be demonstrated without revealing specific details. Confidentiality of data and relationships (Maintaining data and relationship confidentiality through authorized central entities)

[0190] The systems and methods described herein may contain various potential pitfalls regarding information leakage within their design space. Zero-knowledge proofs may play a role, but they may not completely guarantee anonymity, particularly in the context of supply chain participation. A significant risk is the potential compromise of the central entity entrusted with the task of maintaining the confidentiality of data and relationships within the system.

[0191] If a single entity holds all the information and interconnections of the System to ensure its integrity and operation, that entity may become a high-value target for compromise. This risk is particularly pronounced given the inherent value that may be associated with the confidentiality of the System.

[0192] To address this, the systems and methods disclosed herein are designed to maintain integrity and operate the system without relinquishing control over the underlying data. This approach distributes data among participants in such a way that they have precise access only to what they are permitted to know and no more, and that the original data remains with the original provider unless disclosed to other users. This method distributes the value of the data across multiple lower-value targets rather than creating a single central target for compromise in the system. This mitigation strategy is particularly relevant when, during transaction verification, public proof references data that is directly associated with the pseudonym identification of other users. (A public proof that directly references data associated with the (pseudonym) identification of another user when verifying a transaction.)

[0193] One identifiable risk arises when a public proof necessitates the public reference of data associated with specific users. This not only inadvertently exposes the direct relationships of the user publishing the proof, but can also facilitate the creation of graphs that map all relationships within the dependency chain, and subsequently highlight the supply chain. Even with anonymity, this can reduce the level of uncertainty about the identities involved for adversarial or curious users, and provide information about the quantity of distinctly different identities they interact with. For example, identifying that a large portion of assets were produced by a single entity may suggest a potential supply risk, which could be information that some parties may prefer to keep confidential.

[0194] To mitigate this risk, the systems and methods disclosed herein create public proofs of a global state, which ultimately act as an anonymity set of claims, rather than being tied to specific users or claims. This approach is particularly relevant when, during the verification of dependent claims, the public proofs refer to claims of other users that are not directly associated with their pseudonymous identifications. (A public proof that directly references a claim of another user that is not associated with the (pseudonym) identification of another user when proving a dependency claim.)

[0195] Even when not associated with any specific identification, if global dependencies between claims are known and those claims can be identified, a user may be able to verify this outside of the system, with the creator's consent, assuming an hypothesis about the creator of the claims in that dependency graph. This could potentially allow them to establish the relationship between their claims and dependent claims, potentially revealing sensitive information such as the identification of higher-level suppliers that intermediaries might prefer to keep confidential.

[0196] To mitigate this risk, the systems and methods disclosed herein, as described above, create proofs against a global state rather than against specific claims. This approach is particularly relevant when public proofs directly refer to claims, especially during processes of invalidation, revocation, or renewal. (Public proof that directly references the claim when invalidating / revoking / renewing)

[0197] Another identifiable risk is that, even if dependent claims are not explicitly specified, revealing the identification of invalidated, expired, or updated claims could lead to the sequential invalidation or updating of a chain of claims on which they depend. Because these subsequent invalidations are made public and correlated with the original invalidations—that is, one invalidation follows another, preferably in close proximity to minimize latency—they could potentially leak information about the dependencies between claims. These claims could also inadvertently disclose relationships between users if they are linked to user identification.

[0198] In response to this risk, the systems and methods disclosed herein implement alternative mechanisms for propagating updates based on active polling by the user for claim expiration and refreshed status. Since the design goal is to enable users to determine whether a claim has been altered and to make it impossible for malicious users to suppress this information, this active approach flags expired claims as questionable due to the omission of updated status. This bypasses the need to mandate the publication of updated claim IDs in response to changes in order to ensure knowledge of the current state of the claims. More passive alternatives, such as broadcasting verifiable encrypted events readable only by designated users, may also be acceptable. However, these carry the risk of being associated with publicly available encrypted data, which presents a higher risk to peer-to-peer encrypted messaging against post-recall attacks. (Timing correlation between transactions issued by related entities)

[0199] Another identifiable risk arises from timing correlations between transactions issued by related entities, even though weaker assumptions may be made. In account-based systems, the entities linked through timing correlations, whose transactions are interdependent, bear the risk. For example, if customers confirm receipt of a shipment on their systems and disclose this to their suppliers, and suppliers then make linked references to this within their own systems, there is a risk that these consecutive transactions will be linked with sufficient sample and transparency, especially if the process is automated and designed to minimize latency. This can happen even if the only information revealed is the identification of the issuing authority. As mentioned earlier, this can make it increasingly easier to infer supply chains and relationships.

[0200] To mitigate this risk, the systems and methods disclosed herein employ strategies consistent with public account-based models, while also offering alternative mitigation strategies with various trade-offs. Users can balance latency, cost, and anonymity by issuing state updates in batches rather than on a per-transaction basis. The frequency of these updates does not need to be associated with transaction details and may be based on regular intervals or a policy focused solely on fees. However, this approach involves a trade-off between cost and latency, leading to either frequent updates (or potentially empty updates) with low batch sizes or long propagation latency. This is particularly relevant in situations involving deep, fast, and fluctuating supply chains. Alternatively, the risk can be mitigated using an anonymous transaction model similar to ZCash, based on a nullifier. However, this results in reduced readability and may face similar problems, particularly in post-memory decryption scenarios where a participant's transactions are known to an adversary, which is not entirely impossible. (Onboarding correlation with supply chain members)

[0201] Another identifiable risk arises in scenarios where the System is self-contained and, causally, implies that everything established in the System must have its logical preconditions established by a first party in the System prior to any subsequent dependency claims being made. If the real-world identification of an onboarded account is either made public or can be inferred from the disclosures provided, the business relationship between entities is considered potentially, or at least likely to be inferred, by their joint existence in the System, even if the transaction itself is confidential.

[0202] To mitigate this risk, the systems and methods disclosed herein are adapted to transactions in this system that may refer to objects that are not uniquely identified. Transactions may provide evidence about external objects, or potentially interoperate with claims made in other systems as a form of evidence. Therefore, even if the presence of other members of the user's supply chain on this system is not involved, their presence is still reasonable. Given the privacy of transaction details, local claims, claims involving external dependencies, and simple evidence are indistinguishable. This ensures a reasonable alternative explanation regarding the presence of parties that may potentially act as the user's suppliers. Furthermore, this is feasible to mitigate the need to publicly disclose real-world identities associated with those accounts. Desirable characteristics, such as the uniqueness of the business associated with the account, can be guaranteed through zero-knowledge proofs while maintaining privacy. (State and objects)

[0203] The systems and methods described herein may have a hierarchical state organized and addressed at various levels, such as users, user frameworks, user framework records, and user framework record frameworks. Users may create records and separate entries for these records as transactions. These systems and methods provide a range of approaches to precisely define entries, establish disclosures within their context, and create dependencies between claims. (Entry as a whole)

[0204] In the systems and methods disclosed herein, an entry (ENT1) may represent an entirety of claims made about a specific subject, such as an asset, virtual asset, event, or recipe, fixed to a specific point in time. These entries are designed to be interdependent and may have the potential to invalidate each other (Figure 3). In this model, a disclosure (DIS1) may be a selection of these entries shared with another user. The invalidation process and enforcement of consistency between claims are managed through a set of entries (INV1) and a separate state mechanism.

[0205] Figure 3 shows an example of how entries within a record (301) are organized in the system according to several embodiments, with each entry corresponding to a different claim about a certain attribute. Specifically, the record consists of entry (302), which includes claim 1 (303) stating that attribute 1 is equal to 10, claim 2 (304) indicating that attribute 1 falls within the range of 5 to 15, and claim 3 (305) assigning attribute 2 to the range of 0 to 10. Furthermore, claim 4 (306) declares that the sum of attribute 1 and attribute 2 is within the range of 10 to 20, while claim 5 (307) extends this range to 5 to 25. This structure demonstrates the interdependence and potential for mutual invalidation of entries and presents the entirety of the claims about the record in question.

[0206] Figure 4 illustrates an example of how disclosures, which are selectively disclosed entries, function in the system, in several embodiments, particularly highlighting how their dependencies inherit their validation statuses. Disclosure (401) relating to user 1's record 1 selectively includes claim 1 (402) and claim 3 (403). User 1 (404) has record 1 (405) with entry (406) which includes claim 1 (407), claim 2 (408), and claim 3 (409). Similarly, user 2 (410) also has record 2 (411) with entry (412) which includes claim 1 (413), claim 2 (414), and claim 3 (415). The figure highlights the invalidation status (416) associated with each claim and shows how this status is inherited within the disclosed entries (417). This illustrates how selective disclosure (418) and dependency (419) operate within this system.

[0207] Figure 5 shows an example of how entries are created as transactions according to rules that depend on the record state and global state, as defined by the transaction method of the framework (501).

[0208] A transaction (502) can involve various operations such as reading (503), writing (504), and updating (505). These operations affect the state of the system (506), which is represented by different key / value pairs (507, 508, and 509).

[0209] The diagram also illustrates a record (510) having its own state (511), consisting of different key / value pairs (512, 513, and 514). Within this record (510), there are multiple entries (515), each representing a different claim (516, 517, and 518). This structure demonstrates the direct relationship between the framework's transactional method and the state resulting from the system and its records.

[0210] For entries with logical dependencies on the attributes of other local (i.e., user-created) and non-local objects / records, these are constrained by the validity status of the local entry (LDEP 1.1) and the non-local disclosure. Alternatively, in LDEP 1.2, entries with logical dependencies on the attributes of other local objects / records depend on the state of those records, but non-local objects / records are constrained by the validity status of the disclosure. (The entry as the most restrictive claim)

[0211] In the systems and methods disclosed herein, an entry (ENT2) may represent a foundational assertion, acting as the most restrictive predicate, which expresses specific attributes of a subject record. This record may be an asset, virtual asset, event, recipe, etc., fixed to a specific point in time. A disclosure may act as a predicate for the specific attributes of the subject record and metadata associated with entries such as when it was assigned and its history. Thus, disclosures and entries are interchangeable in a transaction, as they are both predicates for attribute values ​​(Figure 5). Alternatively, a disclosure may act as a predicate for several entries and associated transaction details relating to the transaction to which the entries were assigned, making disclosures and entries interchangeable in a transaction (Figure 6). Entries with logical dependencies on the attributes of other local (i.e., user-created) and non-local subjects / records may be constrained by disclosures. On the other hand, entries with logical dependencies on the attributes of other local subjects / records may depend on entries in those records, but non-local subjects / records are constrained by the validity status of the disclosure.

[0212] Figure 6 shows an embodiment of how entries, which are represented as the most restrictive claims about the attributes of the record in question, and disclosures, which are described as predicates relating to the attributes as defined by the individual entries, are organized within a record (601) in this system. Each entry (602) corresponds to a different claim, specifically claim 1 (603), which describes attribute 1 as equal to 10; claim 2 (604), which indicates that attribute 2 falls within the range of 0 to 10; and claim 3 (605), which assigns attribute 3 to the range of 10 to 20. The figure also features a constraint (606), represented by the equation {attribute 3 = attribute 1 + attribute 2}, which creates a link between claims 1, 2, and 3. Furthermore, there are two disclosures (608, 609), which each present a range of values ​​relating to the individual attributes. Disclosure 1 (608) presents a range of 5 to 15 for attribute 1, while disclosure 2 (609) gives a range of 5 to 25 for attribute 3. Derivation (607) further connects claim 1 to disclosure 1. This visual representation effectively illustrates the dynamic and interchangeable nature of entries and disclosures within the system's transactions and demonstrates the interdependence and connectivity of claims. (Constraints on transactional allocation of entries)

[0213] In the systems and methods disclosed herein, the transactional allocation of entries may be subject to certain constraints. Under the first scenario, the transaction setting up an entry is constrained by the entry and disclosure, and invalidation may occur retrospectively if the conditions are broken. Alternatively, the transaction may not be constrained by what may be set up. Instead, the disclosure itself is used to check compliance with the rules. Here, the state is used primarily to maintain historical and data structure integrity, rather than for business logic. The disclosure demonstrates double-spending protection by ensuring consistency between records, which is a requirement for scarcity and spend protection. (Scarcity and expenditure)

[0214] In the systems and methods disclosed herein, scarcity and expenditure may be managed via a UTXO-like expenditure model, referred to as Option 1. In this model, records represent that assets can be referenced by recording their consumption. These records reference each other, while new assets reference each other's consumption records, which represent, for example, the residual balance of scarce assets. The relationships between these output and input assets are governed by framework constraints regarding the relationships between the attributes of the referenced records (Figure 7).

[0215] Figure 7 illustrates an example of how entries as statements about attributes of a target record and disclosures as predicates about attributes constrained by the entries are structured within a record (701) and its associated entry (702). The figure includes two claims: Claim 1 (703), which states that attribute 1 is equal to 10, and Claim 2 (704), which indicates that attribute 2 falls within the range of 0 to 10. A derivation (705) is also depicted and connected to both Claim 1 and Disclosure 1 (706). The figure further shows three different disclosures: Disclosure 1 (706), which indicates that attribute 1 falls within the range of 5 to 15; Disclosure 2 (707), which indicates that the sum of attribute 1 and attribute 2 falls within the range of 10 to 20; and Disclosure 3 (708), which states that the sum of attribute 1 and attribute 2 falls within the range of 5 to 25. These visualizations effectively demonstrate the relationships and dependencies between claims and disclosures, and the structure of entries within a record.

[0216] In this specification, an alternative approach, referred to as the “State-Variable UTXO-like Model,” enforces scarcity and expenditure using a UTXO-like model. In this model, records representing assets can be referenced by records consuming them. This referencing act, in turn, modifies the state used to track the context in which the reference may occur. The relationships between these output and input assets are governed by framework constraints regarding the relationships between attributes of the referenced records. However, the act of expenditure is not considered an attribute of the record representing the consumed asset itself. In the “Transactional and Conditional Reference” variant of this approach, references are made in a transactional and conditional manner, and the record of the spent asset prevents such further references. In the “Flexible Transactional Reference” variant, references may be made as a transaction or otherwise, and the referencing record is recorded within the state. Subsequent references result in changes to the referencing record and can lead to the transparent invalidation of previous expenditure claims. (Balance-ephemeral state model)

[0217] In this specification, an alternative approach, referred to as the “ephemeral state model,” enforces scarcity and expenditure through ephemeral states, which are modified based on claims made by the user. This limits claims to be made in a manner that is both transactional and effective. The state has the ability to record the remaining balance of an asset according to the manner in which the asset is claimed to have been used. (Inductive claim regarding balance-log)

[0218] In this specification, another approach, referred to as the “inductive claim model on logs,” can implement scarcity as an inductive claim on logs. This is accomplished using mutually referenced records, similar to a double-linked list, starting from a predefined or default origin log. Additional cross-references exist between the subject and the log entry records. This log is equivalent to maintaining a list of asset expenditures and thus modifies the indexed remaining balance. Unlike the UTXO model, this approach reflects that the asset remains immutable except for the remaining amount (Figure 10).

[0219] Figure 10 shows an example of implementing an expenditure rule in the system that updates the remaining amount of an asset using a cross-referencing pattern. This example depicts the processing of a batch (batch-123) containing an asset (asset-123) and demonstrates how a quantity record can mimic the variable remaining balance of an asset, despite the record reflecting a static (albeit updatable) narrative about the subject. Inductive predicates on the quantity log can, according to some embodiments, ensure that the remaining amount matches the historical narrative. The asset has a defined batch and quantity, and a record of when it was created (1002). This is linked to a quantity (1003) that includes information about the asset, the previous quantity, the next quantity, and when it was consumed. This is further linked to another quantity that shows the asset, the previous quantity, the next quantity, and consumption details (1004). The figure also shows a process (process-123) with input and output batches leading to an output asset (1005). Another batch (batch-234) is shown in process (1006) and is linked to another asset (asset-345) (1007), with its own batch, quantity, and creation record, and the linked quantity details the asset, previous quantity, and when it was spent (1008). (Expenditures on non-local assets)

[0220] Non-local assets, that is, assets represented by records created by other users and subject to records indicating the transfer of their ownership, also require the preservation of scarcity. This can be achieved through the following various means:

[0221] In this specification, the approach referred to as “User Direct Claims” employs the principles of scarcity and expenditure, but the system state is extended, and claims are constructed to encompass users, frameworks, records, users, and frameworks. This implies that users can directly express claims about other users’ records as part of their own user state. This is also possible by recording receipts in the state as part of a transaction and thus prohibiting further receipt of the same asset, or by generating cross-references through their own entries regarding external records indicating transfers.

[0222] Alternatively, the “cross-referencing record model” uses cross-referencing of records in combination with the methods described above. In this case, the verified receipt of an asset represented in the recipient’s record is referenced by the sender of the asset in the record documenting the transfer. This allows the recipient to demonstrate, upon disclosure, that both records match. (Global stance)

[0223] Global claims may also be managed in the systems and methods disclosed herein. In one approach, referred to as the “inductive claim model for logs,” global claims may be implemented as inductive claims for logs. This is done using interreferential records, similar to a double-linked list, starting from a predefined or default origin log. Additional cross-references exist between the subject (e.g., a process or material shipment in a facility) and the log entry records (Figure 11).

[0224] Figure 11 shows a high-level schematic embodiment of how the log of records is organized in this system to mimic indexing using cross-referencing patterns. This embodiment depicts two records (1101 and 1102) and a framework initialization log (1103) that organizes and orders records that would otherwise be separate. The origin log entry designates the “official” log, and the inductive claim record acts as an index. These can, according to some embodiments, for example, calculate the utilization rate of warehouses or units in use or the volume of material inflows and outflows over a predetermined accounting period, and assist in material balance calculations. The log begins with the log origin (1104), which contains the “initial” field. This is followed by two additional logs (1105 and 1106), which contain fields for “subject,” “previous,” and “next,” respectively. This figure also includes three inductive claims (1107, 1108, and 1109), each with fields relating to "object," "accumulator," and "previous," respectively. This structure demonstrates how a global claim can be implemented as an inductive claim relating to a log. (Inductive proof predicates relating to state logs)

[0225] Another approach, referred to as the “inductive proof predicate model for logs,” may implement global claims as inductive proof predicates for logs, constructed within the state as a result of valid claims or record structures configured as transactions. This method involves creating a logical structure upon which each claim or record builds upon the previous one, thereby proving consistency and adherence to specified constraints. (State-based implementation:)

[0226] In a different approach, referred to as a "state-based implementation model," global claims may be implemented as a state aspect that is modified as a result of valid claims or record structures set up as transactions. This approach leverages state to track and validate global claims and ensure that any modifications made by the user reflect the overall consistency and validity of the claims. (Merkle tree / cryptographic accumulator mapping:)

[0227] In a strategy called the "Merkle Tree / Cryptographic Accumulator Mapping Model," user state updates are managed by maintaining a global public user / state root commitment mapping. This is accomplished using a Merkle tree or cryptographic accumulator. Updates occur concurrently between blocks, and each update refers only to the previously committed state of other users, ensuring they are interchangeable. In this state model, where the transaction issuer is publicly identified, updates and invalidations can be problematic. Instead of being publicly propagated and enforced by transaction / state update logic, the validity status of claims is understood to be dynamic and requires periodic checks (Figure 12).

[0228] Figure 12 shows an example of the state update process in this system using a user state root mapping approach. This visualizes the "Merkle tree / cryptographic accumulator mapping model," which, according to several embodiments, includes verification of the inclusion of user state commitments in the previous mapping and disclosure in the private user state commitments.

[0229] This diagram shows two blocks, namely block B (1201) and block B+1 (1204), each with references to the previous blocks (1202 and 1205) and user state routes (1203 and 1206), respectively. This schematic diagram represents the reading of user 1 state update (1208), which is validated against user 1 state (1210) (1209) along with user i, j, and k state commitments (1211, 1212, 1213). This also shows the non-validation (1214) of other user states. Disclosures from user i, j, and k states (1216, 1217, 1218) are validated and committed (1219, 1220, 1221). The execution of transactions 1-n (1223, 1224) (1222) is also depicted, and the resulting user 1 state (1225) is shown along with the user i, j, and k state disclosures (1226, 1227, 1228). Finally, the writing of the user 1 state commitment (1230) and user n state commitment (1231) is illustrated.

[0230] In this specification, in the sub-option of the "Merkle tree / cryptographic accumulator mapping model," referred to as "timestamped disclosures with framework-defined expiration dates," a communicated disclosure or a committed record version or committed entry against which disclosure is proven is accompanied by a timestamp (the timestamp of the block against which their existence is proven) and a framework-defined expiration date. After this expiration date, they become obsolete. This obsolescence is inherited by the dependencies that underpin them, and obsolescence is defined recursively such that a disclosure becomes obsolete if its expiration date is exceeded or if its dependencies become obsolete.

[0231] In another variation of this model, referred to as the “recorded set of revoked disclosures,” a committed set, or recorded version, or entry of revoked disclosures is recorded with each status update. The status of communicated disclosures can be proven by a set cross-proof between a set of communicated disclosures that are not previously known to be revoked and a set of revoked disclosures.

[0232] Managing the expiration status of each individual communicated disclosure may require continuous checks, which could impose a burden on the prover in proportion to the total number of communicated disclosures at each check. To limit this increase, the framework may define procedures or time requirements for freezing records as needed to prevent subsequent updates.

[0233] In another variation, referred to as “indexed communications,” communications, updates, and revocations of disclosures may be indexed by the prover and recipient in an incremental verifiable calculation (IVC). This allows, over each period, to prove only that, of the set of disclosures communicated, only transactions since the previous update of the disclosure status resulted in a specific log of the revoked disclosure. This imposes a burden that depends only on the number of transactions within that interval and the number of users to whom claims are communicated. It should be noted that these strategies are relevant, for example, to users who intend to derive claims from disclosures, rather than to end customers. (Epoch with a prunable nullifier set:)

[0234] In this specification, an alternative strategy, referred to as "epochs with prunable nullifier assets," employs epochs with distinctly different prunable nullifier assets. This approach allows for short latency within the epoch for referencing while maintaining minimal growth of the nullifier assets. This method utilizes ZCash-style note commitments for user state routes.

[0235] Several variations of this strategy exist. In the "opt-in epoch with forced termination state" variation, the epoch is opted in and forced into a terminated state. In the "opt-in epoch without termination state extraction" variation, opting in to the epoch is possible, but termination state extraction is not enforced, which may prevent other users from referencing the transaction or update. Finally, the "state channel-like epoch" variation enables an epoch similar to a state channel, where other users can anonymously submit a valid state if the initial user does not submit one. (Semi-pruneable nullifier set:)

[0236] In privacy preservation systems such as ZCash, nullifiers, also used within the systems and methods disclosed herein, can play a role in preventing duplicate spending of notes while keeping specific spent notes confidential. When a note commitment is spent in a system like ZCash, a nullifier is generated in a manner that is specific to the spent note but cannot be traced back to it. This nullifier is then added to a nullifier asset, which is a public list of all spent notes. This ensures that once a note is spent, it cannot be spent again without disclosing the specific note it spent on. The nullifier concept can generally be extended to invalidate or update states.

[0237] Similar systems, outlined in the systems and methods disclosed herein, may be used to ensure add-on-only record / entry version control and prevent ambiguity regarding a user's current state. This can be achieved by privately invalidating previous states or records without revealing the associated user. However, one potential challenge with nullifiers is that nullifier assets can grow linearly with the number of transactions or state updates. This can be problematic in systems used over long periods with a significant number of users, as nullifier assets can become considerably large, leading to increased storage and computational requirements.

[0238] Another approach, referred to as the "epoch-based data availability model," also utilizes epochs, but primarily to reduce data availability assumptions. This method employs ZCash-style note commitments and nullifiers to update user state routes, ensuring data availability only for the most recent epoch. Otherwise, users would have to remember witness and nullifier asset routes. In this model, note commitments represent the full user state, rather than aspects of asset or global state (Figure 13).

[0239] Figure 13 shows an example of the structure of user state commitments within a ZCash-like model in this system. This example depicts nulled state commitments in epoch n(1301) and epoch n+1(1307). User state commitments are added to a user state commitment tree, which is append-only. According to some embodiments, when a user's state is updated, a state commitment is added to the nulled user state commitment set for the current epoch in ZCash-like form.

[0240] Each epoch contains user state commitment routes (1303, 1308) and nulled user state commitment set routes (1304, 1309), linked to the previous state (1305, 1310) and prefix (1306). The diagram also shows several commitments (1311, 1312, 1313) and nullifiers (1315), and an empty set (φ) is similarly depicted (1314). This illustrates how user state routes are updated using note commitments and nullifiers to ensure data availability for recent epochs.

[0241] Another approach, referred to as the "Nurifier-Based State Update Model," allows for the forced propagation of invalidation without enabling a significant correlation between the user and the record. This is achieved through nullifier-based state updates, which enable the revocation or invalidation of history disclosures via the forced exposure of nullifiers. These nullifiers are constructed to be unique in the absence of concealed information and not identify revoked disclosures, but still identifiable to those given access to a given disclosure. The nullifiers used in state updates differ in that the user's local state is sufficient to prevent repeated revocations, making non-membership proof unnecessary (Figure 14).

[0242] Figure 14 shows an example of an extended version of the model depicted in Figure 12, which includes a nulled disclosure log in this system. This example shows an additional dedicated log of disclosures nulled up to epoch n (1401) and disclosures nulled or expired in epoch n (1402). Disclosures are globally identified by their commitments in the disclosure root and additionally concealed information. These may be invalidated as a side effect of state update logic by adding separate nullifiers to the nulled disclosure log, according to some embodiments.

[0243] Each epoch, such as epoch n (1403) and epoch n+1 (1412), contains disclosure routes (1404, 1413), user state commitment routes (1405, 1414), nulled disclosure logs (1406, 1415), nulled disclosure set routes (1407, 1416), and nulled user state commitment set routes (1409, 1418), all linked to previous states (1408, 1417) and prefixes (1410, 1411). The diagram also illustrates several disclosure commitments (1419, 1420, 1421) and nullifiers (1423), and an empty set (φ) is also depicted (1422). This highlights how nullifier-based state updates may allow the expiration or invalidation of historical disclosures. (Communication of claims)

[0244] In the systems and methods disclosed herein, claims are communicated externally in the form of disclosures. In one approach, referred to as the “zero-knowledge proof model for cryptographic commitments,” a disclosure is a zero-knowledge proof of a cryptographic commitment to a certain version of a record and its entry. These are communicated peer-to-peer, and the description of the disclosure proof may be based on different elements.

[0245] In the modified version of "Record Commitment as Proof," a cryptographic commitment of a record is made to a public bulletin board and has an expiration date. This commitment serves as proof. The validity of the record's expired or inconsistent status must be rechecked after this expiration date.

[0246] In the modified "User State Commitment as Proof" section, a cryptographic commitment of user state, including the record and its entries, is recorded and has an expiration date. This commitment serves as proof. The validity of the record's expired or inconsistent status must be rechecked against more recent user state after the expiration date.

[0247] In another approach, referred to as the "derived claim model," disclosure is a claim derived from the record, which is proven and registered as part of the user's state transitions.

[0248] In the modified version of "Disclosure Commitment as Proof," the cryptographic commitment of disclosure is made to a public bulletin board as part of a state transition and has an expiration date. This commitment acts as proof. After this expiration date, the validity of the disclosure's expired or inconsistent status must be rechecked.

[0249] In the modified version of "User State and Disclosure Commitment as Proof," the cryptographic commitment to user state and disclosure, including the record and its entries, is recorded and has an expiration date. This commitment serves as proof. The validity of expired or inconsistent status records must be rechecked against more recent user states after their expiration date. (Cross-reference pattern)

[0250] The cross-referencing patterns disclosed herein are an approach that effectively prevents duplicate spending of assets in scenarios without global user states. These patterns involve a consumption process that creates references to consumed assets, and conversely, assets generate reverse references to the consumption process, resulting in a one-to-one correspondence. These systems and methods enable consistent spending narratives to be verified in a read-only format. If proof of consistency is lacking, it is flagged as questionable and potentially indicates unsubstantiated claims or fraud. Thus, the disclosed systems and methods not only enforce accurate asset spending but also maintain the overall integrity and reliability of the system.

[0251] The systems and methods disclosed herein involve maintaining a history of previously claimed values ​​of attributes, such as inputs consumed at the location or process in which the asset was spent. This history provides flexibility in managing errors in data entries and flags the occurrence of such errors, thereby promoting correct data entries. In cross-referencing patterns, error doubt operates bidirectionally. For example, if an asset is claimed to have been used as input after being spent at any location, the claim becomes publicly invalid and is considered doubtful. Similarly, if an asset used as input does not conform to a previous claim, such deviations may be identified, such as in the case of a local depiction of an external asset before its global identification is known. However, these systems and methods enable the verification of consistency in previous claims despite these discrepancies.

[0252] The systems and methods disclosed herein demonstrate that cross-referencing patterns can be generalized to support the depiction of any form of history or variable state that evolves over time. This is illustrated in the section on the inductive claim regarding logs (Figure 9).

[0253] Figure 9 shows an example of an implementation of unused transaction output (UTXO)-like expenditure using a cross-referencing pattern in this system. Simplified for clarity, this example, according to several embodiments, depicts the creation of an asset record representing the remaining unconsumed input and another record representing the process output.

[0254] This diagram shows a chain of assets (Asset-123, Asset-234, and Asset-345) and their associated processes (Process-123 and Process-901). Each asset is linked to a batch (Batch-123 and Batch-234), which records the processes (901 and 905) (referred to as "Consume" and "Create") that consumed or created the asset. Processes are also linked to "Input" and "Input Residue," indicating the assets used and the remaining assets, respectively. Furthermore, "Output Asset" and "Output Batch" links depict the results of the processes. Each link within this chain demonstrates a cross-referencing pattern, ensuring a complete and verifiable record of the history and changes in state over time. account

[0255] The systems and methods disclosed herein enable flexibility in account management and authentication. While generality remains, the use of on-chain state and zk-SNARK allows for more complex approaches, such as key rotation, multi-signature schemes, and social recovery. Furthermore, these systems and methods enable the division of accounts into subaccounts, providing a more top-down management structure, which may be advantageous in larger organizations. In these instances, user nodes may aggregate data from multiple subaccounts, enabling further division and management of data requiring careful handling. (Enforcement of disclosure policy)

[0256] While the systems and methods disclosed herein acknowledge that it may be difficult to control the automatic transfer or sharing of copyable information outside of the System, alternative approaches are proposed. These systems and methods encourage demonstration of compliance with the disclosure policy set by the recipient, particularly with respect to elements of the disclosure that may be shared with other parties. Furthermore, the System proposes limiting the use of claims outside the permitted domain when creating derivative claims. Thus, while controlling the sharing of information in violation of the policy may be complex, such shared information outside the System may not have the same level of verifiability, as users are encouraged to verify compliance with the disclosure policy within the System. (Coordination regarding jointly exchanged data versus claims)

[0257] In the context of the systems and methods disclosed herein, strategies based simply on the exchange of zero-knowledge proofs may have limitations. These limitations arise from the different levels of information that the parties wish to disclose to intermediaries, authorized downstream parties, or as part of large, less identifiable aggregate information.

[0258] Despite these limitations, the commitment to original data does not restrict collaboration within this system. The exchange of disclosures, accompanied by verifiable homomorphic encrypted versions of committed data, can be effectively facilitated within this system.

[0259] In addition, the use of collaborative zk-SNARK through multi-party computation is also supported by this system. This is a distinctly different approach from non-uniform, private computation that relies on distributed ledgers and recursive proofs, and provides an alternative means of secure and private collaborativeness in this system. (Approaches to interoperability with W3C DID and VC)

[0260] While W3C verifiable certificates (VCs) primarily consist of signed documents, verifying only the signature does not encompass all information, as "verifiable data registries" such as blockchains or DNS records may also be used to deconstruct the subject and issuing authority's non-uniform identifier (DID). This can help associate public keys with identities and address revocation. Consequently, in the context of the disclosed systems and methods, various approaches may be utilized to improve interoperability. These approaches may include the use of a framework-approved bridge or on-chain client, notarization by a framework-approved notary, or presentation of a verifiable data registry where the claims are verified. (On-chain client)

[0261] As part of the framework, or on a global scale but with authorization from the framework, client implementations for relevant verifiable data registries may exist. For example, an Ethereum Lite client might use an Ethereum-based DID, or a DNS registry for DNS-based DIDs. Details of these implementations are not determined here and may vary. They can range from simple multi-signature mechanisms or notarization with a set of framework-approving parties that power traditional clients, to comprehensive Lite clients, or even more complex fraud-proof-based approaches. (Notarization of individual VC presentations)

[0262] In the disclosed systems and methods, authorized notaries may have the ability to independently verify the relevant verifiable certificates (VCs) or their presentation. These notaries may then notarize the verification event in the System. In addition, these notaries may have the ability to revoke the evidence if the certificates themselves can be revoked, adding another layer of flexibility and responsiveness to changes in the status of VCs in the System. (Presentation of an unambiguous and verifiable data registry status)

[0263] As part of the disclosed systems and methods, the state or block of a verifiable data registry or associated bridge may be presented along with a claim. Verification of the claim may then be performed on this state or block in the present system. In this scenario, no specific regular bridge or client exists. Instead, the claim recipient will determine their level of trust. To avoid fingerprinting, an anonymity set for the bridges may be presented, or a less detailed presentation of blocks may be used. This approach can help ensure that a user or asset is not identified by a unique block number or bridge option. (Constraints on Entries and Disclosures: How Framework Business Logic Is Represented) (Approach 1: Forward Propagation of Predicates Via Attribute Definition DAG)

[0264] The attributes of a record are defined by the framework, including their definitions or constraints in terms of other attributes. For example, the total cumulative greenhouse gas emissions (tcGHG) in CO2e of a process may be defined as the sum of the tcGHG for each input to the process and the total in-process greenhouse gas emissions (tGHG) related to the process, and tGHG may be defined as a weighted sum (weighted by appropriate conversion factors) of the breakdown of the process's greenhouse gas emissions.

[0265] Similar constraints may also be defined for other attributes, for example, constraining that the ratio of inputs and outputs matches the recipe conversion factor, that input and output assets can be the model defined in the process recipe, that the process does not exceed the maximum capacity of the associated machinery, and that the remaining quantity of a consumed asset matches the difference between the original and consumed quantities.

[0266] These constraints are propagated forward through the dependency DAG, so the validity of subsequent entries depends on them. For example, assigning 10T of CO2e to tcGHG in a process record and then later assigning 11T of CO2e to tGHG may invalidate the 10T of CO2e. Or assigning the same amount as the upper bound for tGHG may, in turn, invalidate the tcGHG assignment. ( Glossary)

[0267] (Cryptographic) Commitment Scheme: A process Comm(input, blinding) for producing a value from an input that is intended to be kept secret, and a blinding factor which is another value used to perform the concealment, wherein it is not feasible to convincingly claim that the input value was anything other than the one originally used to produce the output. Thus, the output value can represent a commitment that is binding to the input value without revealing the input itself.

[0268] Authenticated Data Structure: As used in the disclosed systems and methods, "authenticated data structure" refers to a data structure whose operations can be verified without requiring access to the entire data structure itself. In this context, this often refers to a conventional data structure in which pointers are replaced with the hash of the referenced node. The entire data structure may be referenced by the hash of the root node, which enables paths of hash-based references to every other node. This configuration enables efficient and secure data verification, contributing to the overall integrity and reliability of the systems and methods disclosed herein.

[0269] Hash Chain: A type of authenticated data structure representing a log, which can be efficiently appended, but proving the inclusion of an older value depends on the depth of the log. It is similar to a linked list that uses hashes instead of pointers.

[0270] A Merkle tree is a type of authenticated data structure that represents a fixed-length array of values ​​(leaves) where the value at a particular index can be efficiently proven, and writes to the index can also be efficiently proven. It is similar to a binary tree, but uses hashes instead of pointers.

[0271] Sparse Merkle tree: A type of Merkle tree that represents a sparse data structure, extended with the concept of empty leaves.

[0272] Merkle map: A map or set data structure, typically implemented as a sparse Merkle tree, where leaf indices, derived from collision-resistant hashes of keys (in the sense of a map data structure), can allow for an unlimited key space.

[0273] Indexed Merkle Trees: A way to implement a Merkle map that uses leaves to store nodes in a key-sorted linked list of key / value pairs, rather than having corresponding leaf indices for map keys.

[0274] (Merkle) Root: The hash of the root node of a Merkle tree or other authenticated data structure. Any single value that can represent the entire data structure.

[0275] Cryptographic accumulator: An implementation of a set data structure with efficiently verifiable containment and membership proofs, and a small commitment value (accumulator).

[0276] Zero-knowledge proof: A protocol by which one party (the prover) can convince another party (the verifier) ​​of the truthfulness of a statement without revealing any of the confidential witnesses (evidence) that underlie the statement's truthfulness. The protocol is sound, meaning the probability of the prover convincing the verifier that the statement is false is negligible. Typically, it is useful to consider the statement as the correct execution of a computer program. This is equivalent to proving that "when the program is executed on the confidential data (witness), the output will be obtained" without actually revealing the contents of the confidential data.

[0277] zk-SNARK: A type of non-bidirectional zero-knowledge proof in which the proof given to the verifier is far less than the witness, can be checked much more quickly, there is a computability difficulty assumption underlying the soundness, and the prover must know the non-public witness.

[0278] In the context of the disclosed systems and methods, “proof” refers to evidence supporting a specific description or statement. This evidence may take the form of a zero-knowledge concise non-interactive knowledge argument (zk-SNARK) or a witness that satisfies the description. This can provide evidence of the validity or truthfulness of a statement, maintain the confidentiality of the underlying information, and ensure the integrity of the data in the system.

[0279] "Proof synthesis," in the context of the disclosed system and method, refers to the process of creating a single proof by combining multiple proofs. This allows more complex statements or validations to be effectively supported by integrating several pieces of evidence or proof into one comprehensive proof. This technique can improve the efficiency and clarity of proof verification in the system.

[0280] "Recursive / inductive proof" refers to a type of proof that is defined recursively within the disclosed systems and methods. This implies that a portion of the description being proven involves verifying similar instances of itself. For example, a recursive proof of the execution of a virtual machine might be a description that states "either the virtual machine is initialized to output an initial state, or there exists a valid instance of this proof that outputs a certain state, and its execution continues from that state to the next step, outputting a new state." The recursive or inductive nature of the proof allows for the effective validation of complex computations and operations within the systems and methods disclosed herein.

[0281] "Incremental verifiable computation," in the context of the disclosed system and method, is a concept that enables the verification of computations in an incremental manner. This is analogous to the previously described embodiment of a virtual machine. In such a setting, a computation or operation is divided into smaller, manageable parts, each of which is verified independently. This incremental approach facilitates the validation of complex computations and improves the efficiency of the system.

[0282] Fully Homomorphic Encryption (FHE): An encryption scheme that allows an untrusted party to perform calculations on encrypted data and produce an encrypted output that can be decrypted by a party holding the decryption key.

[0283] (Secure) Multi-Party Computation (MPC): A protocol that enables parties to perform computations on data distributed among them, without needing to know any data they do not originally possess. This is distinctly different from zero-knowledge proofs in that parties can perform computations and arrive at results not only on what they know individually, but also on shared data.

[0284] Threshold (fully homomorphic) encryption / signature: A cryptographic scheme that requires a certain threshold number of participants from a fixed set of parties to execute. For example, it requires more than a certain number of partial decryptions to fully decrypt ciphertext, or more than a certain number of parties to participate in a joint signature ceremony to spend some co-owned assets, etc.

[0285] Consensus mechanism: A protocol for a computer network to agree on a certain value.

[0286] Blockchain: A distributed system that organizes consensus regarding an append-only ledger.

[0287] Block: Similar to a page in a ledger, and timestamping within the blockchain is performed at the block level.

[0288] Public blockchain: A blockchain whose consensus mechanism allows public participation and public verification, and whose security is built on the premise that no single malicious entity controls a certain percentage of scarce resources (in proof-of-stake, it is cryptocurrency, and in proof-of-work, it is computing power).

[0289] Succinct blockchain: A blockchain such as Mina, whose transactions and consensus can be entirely verified via a single zk-SNARK.

[0290] In the context of the disclosed systems and methods, "commit" refers to either making a cryptographic commitment to a blockchain public or creating and sharing such a commitment on a peer-to-peer basis. Typically, it most commonly refers to the act of making a public commitment on a blockchain. This cryptographic commitment serves as an assurance or binding pledge regarding specific data or transaction fragments, ensuring their integrity and authenticity in the systems and methods disclosed herein.

[0291] Nonce: A number used only once, like a counter, or a (pseudo) random value that is sampled uniformly.

[0292] UTXO Model: A transaction model used in Bitcoin where, as opposed to maintaining an account along with the asset balance, a transaction on an asset spends unused assets and creates new unused assets for use in subsequent transactions. UTXO represents the unused transaction output.

[0293] In the context of the disclosed systems and methods, the term "nullifier" is used in two distinctly different ways. Firstly, as used in platforms such as ZCash and Semaphore, a nullifier is a value that is inherently linked to a resource and can be consumed only once. This nullifier is made public at the time of resource consumption to prevent reuse. In some instances, the calculation of this nullifier is intentionally designed to be impossible for anyone other than the resource owner to perform.

[0294] The alternative use of “nullifier” in these systems and methods refers to a value that is publicly disclosed to facilitate an irrevocable revocation or invalidation process. In this context, the disclosed nullifier is specifically designed to identify only the resources to be revoked to the parties who originally knew of them, thereby ensuring the integrity of the revocation process while preserving confidentiality.

[0295] The term "ZCash-like" in the context of the systems and methods disclosed herein refers to a transaction model similar to that used in ZCash. This involves an append-only set of commitments, which can be "spent" or "used" only once by the user through a transaction. The transaction involves a zero-knowledge concise non-interactive knowledge argument (zk-SNARK) that proves a statement similar to, "I know of the commitment in the SET whose nullifier is NULLIFIER." This model ensures confidentiality by not revealing the specific commitment being used.

[0296] Following a transaction, a nullifier is added to the nullifier asset, which effectively prevents the commitment from being reused in future transactions. While proof may also exist that a nullifier is not part of the nullifier asset, this generally depends on whether the system is a traditional blockchain where transactions are validated through simple re-execution, or a zk-Rollup or concise blockchain where transactions are validated via zk-SNARKs.

[0297] In the transaction model of the disclosed system and methods, commitments have the ability to represent not only assets but also variable confidential states. For example, concealment may focus on modifying specific aspects of a state rather than on which assets were spent. The scope of this representation suggests the suitability of the disclosed system and methods for managing and tracking various types of commitments.

[0298] In the context of the disclosed systems and methods, "epoch" refers to a specific parameterized period in which the system is organized. This period does not necessarily represent the most detailed or granular level of time measurement in the system. However, it remains important in the system for configuring and coordinating the system's operation and functionality, and effectively serves as a critical unit of time for organizing transactions, updates, or other time-constrained processes.

[0299] In the context of the disclosed systems and methods, a “certificate” refers to a document or evidence issued to a subject by an identified entity. Typically, such certificates serve as evidence or proof of a particular claim or statement. They validate claims, provide authenticity, and act as a source of credit within the disclosed systems and methods. They are used to support statements and facilitate verification processes within the disclosed systems and methods.

[0300] In the context of the systems and methods disclosed herein, “self-sovereignty” refers to the principle that user data, in particular confidential witness data or evidence, remains under the user’s own ownership and control. Instead of relying on a central, trusted operator, this principle emphasizes user autonomy and their own control over their data. This ensures the privacy of user information and minimizes the risk of centralized data breaches or unauthorized access.

[0301] A “Non-Uniform Identifier” or “DID” is a standard from the World Wide Web Consortium (W3C) for defining decomposable identifiers without requiring a uniform operator. This standard, referred to as Non-Uniform Identifier (DID) v1.0, provides a framework for creating unique, persistent, and verifiable identifiers that do not rely on a central registry, entity, or intermediary. This de-uniformity ensures user control over digital identifiers and enhances privacy and security in the systems and methods disclosed herein.

[0302] VC: A W3C standard relating to verifiable certificates, which are issued by a trusted party with respect to a given subject, and which have cryptographically verifiable issuance and revocation.

[0303] "Selective disclosure," in the context of the system and method of disclosure, refers to the act of revealing a specific subset of a set of values ​​to another party at one's discretion. This typically applies to sets of values ​​that are jointly signed or verified, or compiled into a single document. Similar to concealing certain fields when presenting a passport, selective disclosure allows users to control the amount and type of information shared, thereby improving privacy and data security within the system. This feature allows for the flexibility to share only relevant or necessary information while keeping other data confidential. (Computing system)

[0304] Referring to Figure 18, a block diagram is shown depicting an exemplary machine, including a computer system 1800 (e.g., a processing system or computing system), in which a set of instructions can be executed to cause a device to perform or carry out one or more aspects and / or methodologies of the present disclosure. The components of Figure 18 are merely examples and do not limit the scope of use or functionality of any hardware, software, embedded logic components, or combinations of two or more such components that implement a particular embodiment.

[0305] The computer system 1800 may include one or more processors 1801, a memory 1803, and a storage device 1808, which communicate with each other and with other components via a bus 1840. The bus 1840 may also link a display 1832, one or more input devices 1833 (which may include, for example, a keypad, keyboard, mouse, stylus, etc.), one or more output devices 1834, one or more storage devices 1835, and various tangible storage media 1836. All of these elements may interface with the bus 1840 directly or via one or more interfaces or adapters. For example, various tangible storage media 1836 may interface with the bus 1840 via a storage media interface 1826. The computer system 1800 may have any preferred physical form, including, but is not limited to, one or more integrated circuits (ICs), printed circuit boards (PCBs), mobile handheld devices (such as mobile phones or PDAs), laptops or notebook computers, distributed computer systems, computing grids, or servers.

[0306] The computer system 1800 includes one or more processors 1801 (e.g., a central processing unit (CPU) or a general-purpose graphics processing unit (GPGPU)) that execute functions. The processors 1801 optionally include cache memory units 1802 for temporary local storage of instructions, data, or computer addresses. The processors 1801 are configured to assist in the execution of computer-readable instructions. The computer system 1800 may provide functionality for the components depicted in Figure 18 as a result of the processors 1801 executing non-transient processor-executable instructions embodied in one or more tangible computer-readable storage media such as memory 1803, storage device 1808, storage device 1835, and / or storage medium 1836. The computer-readable media may store software implementing a particular embodiment, and the processors 1801 may execute the software. Memory 1803 may read software from one or more other computer-readable media (such as mass storage devices 1835, 1836) or from one or more other sources through a suitable interface such as network interface 1820. The software may cause processor 1801 to perform one or more processes, or one or more steps of one or more processes, as described or illustrated herein. Performing such processes or steps may include defining data structures to be stored in memory 1803 and modifying the data structures as instructed by the software.

[0307] Memory 1803 may include, but is not limited to, various components (e.g., machine-readable media), including random access memory components (e.g., RAM 1804) (e.g., static RAM (SRAM), dynamic RAM (DRAM), ferroelectric random access memory (FRAM®), phase-change random access memory (PRAM), etc.), read-only memory components (e.g., ROM 105), and any combination thereof. ROM 1805 may act to communicate data and instructions unidirectionally to the processor 1801, and RAM 1804 may act to communicate data and instructions bidirectionally to the processor 1801. ROM 1805 and RAM 1804 may include any suitable tangible computer-readable media described below. In one embodiment, a basic input / output system 1806 (BIOS), which includes basic routines useful for transferring information between elements within the computer system 100 during startup, etc., may be stored in memory 1803.

[0308] The fixed storage device 1808 is optionally connected bidirectionally to the processor 1801 through the storage device control unit 1807. The fixed storage device 1808 provides additional data storage capacity and may also include any suitable tangible computer-readable media described herein. The storage device 1808 may be used to store the operating system 1809, executable files 1810, data 1811, applications 1812 (application programs), and equivalents. The storage device 1808 may also include an optical disc drive, a solid-state memory device (e.g., a flash-based system), or any combination of the above. The information in the storage device 1808 may, where appropriate, be incorporated as virtual memory in memory 1803.

[0309] In one embodiment, the storage device 1835 may be removably interfaced with the computer system 1800 via a storage device interface 1825 (for example, via an external port connector (not shown)). In particular, the storage device 1835 and its associated machine-readable medium may provide non-volatile and / or volatile storage devices for machine-readable instructions, data structures, program modules, and / or other data for the computer system 100. In one embodiment, the software may reside, fully or partially, in the machine-readable medium on the storage device 1835. In another embodiment, the software may reside, fully or partially, in the processor 1801.

[0310] Bus 1840 connects a wide variety of subsystems. In this specification, a bus reference may, where appropriate, encompass one or more digital signal lines that serve a general function. Bus 1840 may be one of several types of bus structures, including, but not limited to, memory buses, memory controllers, peripheral buses, local buses, and any combination thereof, using any of various bus architectures. Examples, but not limited to, include Industry Standard Architecture (ISA) buses, Extended ISA (EISA) buses, Microchannel Architecture (MCA) buses, Video Electronics Standards Association Local Bus (VLB), Peripheral Component Interconnect (PCI) buses, PCI Express (PCI-X) buses, Accelerated Graphics Port (AGP) buses, Hypertransport (HTX) buses, Serial Advanced Technology Attachment (SATA) buses, and any combination thereof.

[0311] The computer system 1800 may also include an input device 1833. In one embodiment, a user of the computer system 1800 may input commands and / or other information into the computer system 1800 via the input device 1833. Embodiments of the input device 1833 include, but are not limited to, alphanumeric input devices (e.g., keyboards), pointing devices (e.g., mice or touchpads), touchpads, touchscreens, multitouchscreens, joysticks, styluses, gamepads, audio input devices (e.g., microphones, voice response systems, etc.), optical scanners, video or still image capture devices (e.g., cameras), and any combination thereof. In some embodiments, the input device is Kinect, Leap Motion, or equivalent. The input device 1833 may interface to the bus 1840 via one of various input interfaces 1823 (e.g., input interface 1823), which include, but are not limited to, serial, parallel, game port, USB, FIREWIRE®, THUNDERBOLT, or any combination of the above.

[0312] In certain embodiments, when computer system 1800 is connected to network 1830, computer system 1800 may communicate with other devices, specifically mobile devices and enterprise systems, distributed computing systems, cloud storage systems, cloud computing systems, and equivalents, that are connected to network 1830. Communication to and from computer system 1800 may be transmitted through network interface 1820. For example, network interface 1820 may receive incoming communications from network 1830 in the form of one or more packets (such as Internet Protocol (IP) packets) (such as requests or responses from other devices), and computer system 1800 may store the incoming communications in memory 1803 for processing. Similarly, computer system 1800 may store outgoing communications (such as requests or responses to other devices) in the form of one or more packets transmitted from network interface 1820 to network 1830 in memory 1803. Processor 1801 may access these communication packets stored in memory 1803 for processing.

[0313] Examples of network interface 1820 include, but are not limited to, network interface cards, modems, and any combination thereof. Examples of network 1830 or network segment 1830 include, but are not limited to, distributed computing systems, cloud computing systems, wide area networks (WANs) (e.g., the Internet, corporate networks), local area networks (LANs) (e.g., networks associated with offices, buildings, campuses, or other relatively small geographical spaces), telephone networks, direct connections between two computing devices, peer-to-peer networks, and any combination thereof. Networks such as network 1830 may employ wired and / or wireless modes of communication. In general, any network topology can be used.

[0314] Information and data can be displayed through the display 1832. Embodiments of the display 1832 include, but are not limited to, cathode ray tubes (CRTs), liquid crystal displays (LCDs), thin-film transistor liquid crystal displays (TFT-LCDs), organic liquid crystal displays (OLEDs) such as passive-matrix OLEDs (PMOLEDs) or active-matrix OLEDs (AMOLEDs), plasma displays, and any combination thereof. The display 1832 may interface with other devices such as a processor 1801, memory 1803, and fixed storage device 1808, as well as an input device 1833, via a bus 1840. The display 1832 is linked to the bus 1840 via a video interface 1822, and the transfer of data between the display 1832 and the bus 1840 may be controlled via a graphics control 1821. In some embodiments, the display is a video projector. In some embodiments, the display is a head-mounted display (HMD), such as a VR headset. In further embodiments, preferred VR headsets include, in non-limiting embodiments, the HTC Vive, Oculus Rift, Samsung Gear VR, Microsoft HoloLens, Razer OSVR, FOVE VR, Zeiss VR One, Avegant Glyph, Freefly VR headset, and equivalents. In even further embodiments, the display is a combination of devices, such as those disclosed herein.

[0315] In addition to the display 1832, the computer system 1800 may include one or more other peripheral output devices 1834, including, but not limited to, audio speakers, printers, storage devices, and any combination thereof. Such peripheral output devices may be connected to the bus 1840 via an output interface 1824. Embodiments of the output interface 1824 include, but not limited to, serial ports, parallel connections, USB ports, FIREWIRE® ports, THUNDERBOLT ports, and any combination thereof.

[0316] In addition, or as an alternative, the computer system 1800 may provide functionality as a result of logic wired in a circuit or otherwise embodied, which operates in place of or with software and can perform one or more processes, or one or more steps of one or more processes, as described or illustrated herein. References to software in this disclosure may encompass logic, and references to logic may encompass software. References to computer-readable media may, where appropriate, encompass circuits (such as ICs) that store software for execution, circuits that embody logic for execution, or both. This disclosure encompasses hardware, software, or any preferred combination of both.

[0317] Those skilled in the art will understand that various illustrative logic blocks, modules, circuits, and algorithmic steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, computer software, or a combination of both. To clearly illustrate this hardware and software compatibility, various illustrative components, blocks, modules, circuits, and steps are described above in general terms of their functionality.

[0318] Various illustrative logic blocks, modules, and circuits described in connection with embodiments disclosed herein may be implemented or carried out using general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs) or other programmable logic devices, discrete gate or transistor logic, discrete hardware components, or any combination thereof, configured to perform the functions described herein. The general-purpose processor may be a microprocessor, but alternatively, the processor may be any conventional processor, controller, microcontroller, or state machine. The processor may also be implemented as a combination of computing devices, e.g., a DSP and a microprocessor, multiple microprocessors, one or more microprocessors combined with a DSP core, or any other combination of such configurations.

[0319] Steps of methods or algorithms described in relation to embodiments disclosed herein may be directly embodied in hardware, in software modules executed by one or more processors, or in a combination of the two. The software modules may reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disks, removable disks, CD-ROMs, or any other form of storage medium known in the art. The exemplary storage medium may be coupled to a processor, and such a processor may read information from and write information to the storage medium. Alternatively, the storage medium may be useful to the processor. The processor and storage medium may reside in an ASIC. The ASIC may reside in a user terminal. Alternatively, the processor and storage medium may reside as discrete components in a user terminal.

[0320] According to the description herein, suitable computing devices, in non-limiting embodiments, include cloud computing platforms, distributed computing platforms, server clusters, server computers, desktop computers, laptop computers, notebook computers, subnotebook computers, netbook computers, and netpad computers.

[0321] In some embodiments, a computing device includes an operating system configured to execute executable instructions. The operating system is software, for example, including programs and data, which manages the device's hardware and provides services related to the execution of applications. Those skilled in the art will recognize that, in non-limiting embodiments, preferred server operating systems include FreeBSD, OpenBSD, NetBSD®, Linux®, Apple® Mac OS X Server®, Oracle® Solaris®, Windows Server®, and Novell® NetWare®. Those skilled in the art will also recognize that, in non-limiting embodiments, preferred personal computer operating systems include Microsoft® Windows®, Apple® Mac OS X®, UNIX®, and UNIX®-like operating systems such as GNU / Linux®. In some embodiments, the operating system is provided by cloud computing. Those skilled in the art will also recognize that suitable mobile smartphone operating systems include, in non-limiting embodiments, Nokia® Symbian® OS, Apple® iOS®, Research in Motion® BlackBerry OS®, Google® Android®, Microsoft® Windows Phone® OS, Microsoft® Windows Mobile® OS, Linux®, and Palm® WebOS®. (Non-transient computer-readable storage medium)

[0322] In some embodiments, the platforms, systems, media, and methods disclosed herein include one or more non-transient computer-readable storage media encoded with a program containing instructions executable by the operating system of optionally networked computing devices. In further embodiments, the computer-readable storage media is a tangible component of the computing device. In yet another embodiment, the computer-readable storage media is optionally removable from the computing device. In some embodiments, the computer-readable storage media includes, in non-limiting embodiments, a distributed computing system, including CD-ROMs, DVDs, flash memory devices, solid-state memory, magnetic disk drives, magnetic tape drives, optical disk drives, cloud computing systems and services, and equivalents. In some cases, the program and instructions are encoded on the medium permanently, substantially permanently, semi-permanently, or non-transiently. (Computer program)

[0323] In some embodiments, the platforms, systems, media, and methods disclosed herein involve the use of at least one computer program or identical thereof. A computer program is executable by one or more processors of the CPU of a computing device and includes a sequence of instructions that are written to perform a defined task. Computer-readable instructions may be implemented as program modules such as functions, objects, application programming interfaces (APIs), computing data structures, and equivalents that perform a particular task or implement a particular abstract data type. In light of the disclosures provided herein, those skilled in the art will recognize that computer programs may be written in various languages ​​in various versions.

[0324] The functionality of computer-readable instructions can be combined or distributed as desired in various environments. In some embodiments, a computer program includes one sequence of instructions. In some embodiments, a computer program includes multiple sequences of instructions. In some embodiments, a computer program is provided from one location. In other embodiments, a computer program is provided from multiple locations. In various embodiments, a computer program includes one or more software modules. In various embodiments, a computer program includes, in part or in whole, one or more web applications, one or more mobile applications, one or more standalone applications, one or more web browser plugins, extensions, add-ins, or add-ons, or a combination thereof. (Software module)

[0325] In some embodiments, the platforms, systems, media, and methods disclosed herein involve the use of software, servers, and / or database modules, or the same. In light of the disclosures provided herein, software modules are produced by techniques known to those skilled in the art using machines, software, and languages ​​known in the art. Software modules disclosed herein are implemented in numerous ways. In various embodiments, a software module includes files, sections of code, programming objects, programming structures, distributed computing resources, cloud computing resources, or a combination thereof. In further various embodiments, a software module includes multiple files, multiple sections of code, multiple programming objects, multiple programming structures, multiple distributed computing resources, multiple cloud computing resources, or a combination thereof. In various embodiments, one or more software modules comprise, in non-limiting embodiments, a web application, a mobile application, a standalone application, and a distributed or cloud computing application. In some embodiments, a software module resides within a single computer program or application. In other embodiments, a software module resides within one or more computer programs or applications. In some embodiments, a software module is hosted on a single machine. In other embodiments, the software module is hosted on one or more machines. In further embodiments, the software module is hosted on a distributed computing platform such as a cloud computing platform. In some embodiments, the software module is hosted on one or more machines in one location. In other embodiments, the software module is hosted on one or more machines in one or more locations. (Database)

[0326] In some embodiments, the platforms, systems, media, and methods disclosed herein involve the use of one or more databases or identical ones. Those skilled in the art will recognize, in light of the disclosures provided herein, that many databases are suitable for storing and retrieving information. In various embodiments, suitable databases include, in non-limiting embodiments, relational databases, non-relational databases, object-oriented databases, object databases, entity-relational model databases, associative databases, XML databases, disclosure-oriented databases, and graph databases. Further non-limiting embodiments include SQL, PostgreSQL, MySQL, Oracle, DB2, Sybase, and MongoDB. In some embodiments, the database is internet-based. In further embodiments, the database is web-based. In yet further embodiments, the database is cloud computing-based. In certain embodiments, the database is a distributed database. In other embodiments, the database is based on one or more local computer storage devices.

Claims

1. A computer implementation method for creating and sharing verifiable information while maintaining anonymity and privacy, wherein the computer implementation method is: The user creates one or more claims about an object in a user node, wherein the one or more claims are constrained by a constraint system associated with the object. In the user node, updating the state related to the user node or user account based on one or more claims, wherein the state related to the user node or user account includes private data stored on the user node and not publicly shared. Updating or creating a cryptographic state commitment for validating proof of the updated state, wherein the cryptographic state commitment is associated with the user under a pseudonym or anonymously, recorded on the blockchain, and validating proof of the updated state includes proving that updating the state is a valid state transition from the previous state, or proving the validity of one or more claims about the state on which the cryptographic state commitment is based. To construct a zero-knowledge proof that demonstrates the validity of the updated state without revealing the aforementioned state. Computer implementation methods, including those mentioned above.

2. The computer implementation method according to claim 1, wherein the constraint system is a framework comprising one or more predefined rules that restrict the formal expression of one or more claims.

3. The computer implementation method according to claim 1, wherein one or more of the aforementioned claims include cooperative inductive claims.

4. The computer implementation method according to claim 3, wherein the aforementioned cooperative inductive argument refers to one or more other arguments.

5. The computer implementation method according to claim 4, wherein one or more of the aforementioned claims are made by another user.

6. The computer implementation method according to claim 4, wherein the one or more other claims are verified by the user node against a cryptographic state commitment associated with the other user recorded on the blockchain.

7. The computer implementation method according to claim 4, wherein the one or more referenced claims are predicates relating to a process, the process by which the one or more claims were created, and / or predicates relating to metadata.

8. The computer implementation method according to claim 1, wherein the zero-knowledge proof is a zero-knowledge concise non-interactive knowledge argument (zk-SNARK).

9. The computer implementation method according to claim 1, wherein the blockchain is a public blockchain.

10. The computer implementation method according to claim 1, wherein the cryptographic state commitment associated with the user on the blockchain is stored using an authenticated data structure.

11. The computer implementation method according to claim 10, wherein the cryptographic state commitment associated with the user is identified by an index of a leaf node in a Merkle tree.

12. The computer implementation method according to claim 11, wherein updating the cryptographic state commitment associated with the user includes maintaining a root commitment mapping using the Merkle tree or cryptographic accumulator.

13. The computer implementation method according to claim 12, wherein the root commitment is used as input to a proof in order to publicly verify the one or more claims and the updated state created by the user.

14. The computer implementation method according to claim 10, wherein the user is identified by a key in an indexed Merkle tree or by a key in the authenticated data structure that implements a map structure.

15. The computer implementation method according to claim 1, wherein one or more of the claims relating to the subject can be verified by verifying their authenticity or compliance with the constraint system.

16. The computer implementation method according to claim 1, wherein the zero-knowledge proof ensures that the claim conforms to predetermined rules and previous states.

17. The computer implementation method according to claim 1, wherein one or more claims relating to the subject are in the form of entries in a record.

18. The computer implementation method according to claim 17, wherein the entry stores information about one or more attributes of the object.

19. The computer implementation method according to claim 18, wherein the one or more attributes are defined by one or more predefined rules of the constraint system.

20. The computer implementation method according to claim 19, wherein the one or more attributes are constrained by forward propagation of predicates through an attribute-defining directed acyclic graph (DAG).

21. The computer implementation method according to claim 19, wherein the one or more attributes are constrained by the propagation of constraints through a dependency DAG.

22. A system for creating and sharing verifiable information while maintaining anonymity and privacy, wherein the system is: Processor and A memory containing executable instructions, wherein the executable instructions, as a result of being executed by the processor, (a) A user makes one or more claims about an object using the processor of the user node, wherein the one or more claims are constrained by a constraint system associated with the object, (b) Updating the state of the user node or user account based on one or more claims in the user node, wherein the state of the user node or user account is stored on the user node and includes private data that is not publicly shared. (c) Updating or creating a cryptographic state commitment for validating the proof of the updated state, wherein the cryptographic state commitment is associated with the user under a pseudonym or anonymously and recorded on the blockchain. (d) Constructing a zero-knowledge proof that demonstrates the validity of the updated state without revealing the state This involves performing operations that include memory and A system equipped with these features.

23. A computer implementation method for managing and verifying information via blockchain, wherein the computer implementation method is (a) A user node generates a cryptographic state commitment associated with the state of the user node, (b) The user node stores the state of the user node, wherein the state of the user node comprises data associated with one or more claims that cause an update of the state, and the data is not publicly shared. (c) The user node constructs a zero-knowledge proof (zk-SNARK) that proves the validity of the state update without revealing the data, (d) Broadcasting the zero-knowledge proof and the cryptographic state commitment to the blockchain, wherein the zero-knowledge proof ensures the validity of the state of the user node on the blockchain. Computer implementation methods, including those mentioned above.

24. The computer implementation method according to claim 23, further comprising the user node creating another cryptographic state commitment relating to the updated state.

25. The computer implementation method according to claim 24, further comprising publishing another cryptographic state commitment on the blockchain to serve as a verifiable and irreversible record accessible via the blockchain.

26. The computer implementation method according to claim 23, wherein the state of the user node further comprises data relating to cooperative inductive claims.

27. The computer implementation method according to claim 26, wherein the aforementioned cooperative inductive claim refers to one or more other claims.

28. The computer implementation method according to claim 27, wherein one or more of the aforementioned claims are made by another user.

29. The computer implementation method according to claim 23, wherein the state of the user node further comprises metadata about one or more claims, one or more previous claims, and the validity or invalidity of the update of the state.

30. The computer implementation method according to claim 23, wherein the state of the user node further comprises auxiliary data for creating the zero-knowledge proof.

31. The computer implementation method according to claim 30, wherein the auxiliary data comprises an intermediate node of an authenticated data structure.

32. The computer implementation method according to claim 23, wherein the cryptographic state commitment is stored on the blockchain using an authenticated data structure.

33. The computer implementation method according to claim 23, further comprising updating at least a portion of the global state commitment agreed upon by the consensus protocol of the blockchain in response to disclosing the cryptographic state commitment to the blockchain.

34. The computer implementation method according to claim 33, wherein a state commitment associated with a given user or a given user node is associated with all records relating to all frameworks associated with the given user.

35. The computer implementation method according to claim 34, wherein the global state comprises all state commitments associated with all users, or all user nodes in the network are made public on the blockchain.

36. The computer implementation method according to claim 35, wherein proving the validity of the update of the state includes determining whether one or more claims are valid.

37. The computer implementation method according to claim 36, wherein determining the one or more claims is valid when the one or more claims are consistent with the global state commitment, without relying on the source of user identification or recording, thereby avoiding the exposure of relationships between users.

38. The computer implementation method according to claim 23, further comprising verifying the zero-knowledge proof that the state update is the result of a valid transaction in accordance with global rules and previous state commitments.

39. The computer implementation method according to claim 23, wherein the cryptographic state commitment encodes metadata about predefined framework rules that restrict the formal representation of one or more claims.

40. The computer implementation method according to claim 23, wherein the one or more claims are stored in one or more entries of a record.

41. The computer implementation method according to claim 40, wherein the record is associated with an object, and the one or more entries are associated with one or more attributes of the object.

42. The computer implementation method according to claim 41, further comprising implementing a UTXO-like model or balance log through cross-referencing between records, enforcing consistency between said records, or restricting the multiplicity of relationships.

43. The computer implementation method according to claim 42, wherein the cross-references are enforced according to a constraint system.

44. The computer implementation method according to claim 43, wherein the constraints of the constraint system enforce the cross-referencing with respect to the relationships between the attributes of the records referenced by the plurality of records.

45. The computer implementation method according to claim 23, further comprising verifying the obsolescence status or validity status of one or more claims based at least in part on a time threshold.

46. The computer implementation method according to claim 23, wherein at least one claim is a relative claim about a second object based on a claim about a first object.

47. The computer implementation method according to claim 46, wherein the relative claim is verified based on the relationship between the first object and the second object, without relying on the identification of the first object and the second object.

48. The computer implementation method according to claim 41, wherein the update of the state includes correcting or updating the state of a record entry, and the updated state of the entry is used to determine the invalidity of a dependency entry based on a potential inconsistency with the updated entry.

49. The computer implementation method according to claim 23, wherein the update of the state includes modifying or updating one or more claims and determining the invalidity of the dependent claims based on a potential inconsistency between the dependent claims and the updated one or more claims.

50. The computer implementation method according to claim 23, wherein the state of the user node further comprises data associated with the claims or state of another user node that is in a transaction state with the user node.

51. The computer implementation method according to claim 50, wherein the claim or state of another user node is used to derive an inductive claim that matches the claim or state via a recursive zk-SNARK.

52. The computer implementation method according to claim 50, wherein the inductive argument is stored on the user node and is not made public on the blockchain.

53. The computer implementation method according to claim 23, wherein the blockchain is a simple blockchain, and the global state of the blockchain is validated through a single proof.

54. The computer implementation method according to claim 53, wherein all state updates within a given block or the blockchain are recursively aggregated into the single proof.

Images