Horizontally scaling blockchain platform

Abstract

Methods, systems, and apparatus, including computer programs encoded on computer storage media, for a horizontally scalable blockchain. One of the methods includes maintaining a global tree structure having a plurality of different subtrees, wherein each subtree is a Merkle tree of leaf nodes belonging to the subtree. The plurality of subtrees include a checkpoint subtree whose leaf indices are checkpoint hashes that each represent a state of the system at a respective point in time, a global user subtree whose leaves identify different respective users of the blockchain system, and a global contract subtree whose leaves are associated with different respective contracts.

Description

[0001] HORIZONTALLY SCALING BLOCKCHAIN PLATFORM

[0002] CROSS REFERENCE TO RELATED APPLICATIONS

[0003] This application claims priority to U.S. Provisional Patent Application No. 63 / 526,334, filed on July 12, 2023, entitled “HORIZONTALLY SCALING BLOCKCHAIN PLATFORM,” the entirety of which is herein incorporated by reference.

[0004] BACKGROUND

[0005] This specification relates to blockchain technologies.

[0006] Blockchain computing systems implement distributed ledgers. A distributed ledger is a list of blocks, a “blockchain,” that are securely linked together by cryptographic hashes such that each block includes information about the previous block, e.g., a hash of the previous block’s contents. This makes the data in the blocks irreversible because any alteration to any block would alter all subsequent blocks, a change that would be easily detected by any of the computing nodes in the blockchain system.

[0007] Computing nodes in a blockchain system typically store an entire copy of the blockchain and cooperate to add new transactions to the newest block in the chain. To do so, the nodes typically use a consensus mechanism to reach a distributed agreement about the state of the blockchain. As one example, in a proof-of-work algorithm, all nodes compete to solve an encryption problem that is hard to solve but which has a fast verification process. In other words, it takes much longer to solve the problem than it does to verify the solution. The first computing node to solve the next encryption problem wins the right to add new transactions to the latest block. Other computing nodes in the network will use the fast verification process to verify the result, and, if verified, will add the same transactions to their own copies of the blockchain. In this way, the computing nodes continually reach distributed consensus about the state of the blockchain.

[0008] A key advantage of this arrangement is trustless computing, which means that anyone, be it a computing node in the network or out of the network, does not need to trust any node in the network about the state of the blockchain. This is because anyone can verify the state themselves by simply verifying the correctness of the hashes that chain together the blocks. However, this arrangement has several severe and notorious disadvantages. First, a blockchain computing network requires all nodes to be full nodes in the sense that they all run or verify every transaction in order. This means that every node has to have a particular minimum amount of computing resources that must be utilized at all times so that the node doesn’t fall behind in processing the transactions. If a node falls behind, it becomes useless because it cannot process new transactions.

[0009] Second, the distributed consensus process requires transactions to be added serially. This places a severe limit on the number of transactions that can be processed per second. For example, if a user submits two transactions to be processed, the first transaction must be processed in full before the second transaction can begin processing. This is because the first transaction can affect the result of the second transaction. Typically there are no restrictions on what state of the blockchain that transactions can modify. In fact, some transactions deploy new contracts that are required to even execute the second transaction at all.

[0010] Therefore, adding additional computing nodes to a traditional blockchain network does not provide the same type of horizontal scaling as other types of computing processes that can process transactions in parallel. For example, social media updates currently cannot be executed in the blockchain because no blockchain system can process millions of updates per second. Similarly, no massively multiplayer gaming system can be executed in a blockchain for the same reason. These fundamental limitations of traditional blockchain systems therefore greatly limit the types of applications for which advantages of blockchains can be realized.

[0011] SUMMARY

[0012] This specification describes a horizontally scalable blockchain system having a unique topology that allows the system to scale horizontally without compromising the security of traditional blockchain systems. In particular, the system maintains a state represented by a hierarchical tree structure having a number of different subtrees that can split user state data at the user level. This provides for fast and parallelized zeroknowledge proofs to be computed that verify a user’s ownership and which recursively verify a chain of transaction proofs on the legality of modifications to the system. Notably, these proofs can be performed in parallel and on the client side, which provides the system with unbounded horizontal scalability in terms of transactions per second. The subtrees in the hierarchical tree structure can themselves be Merkle trees representing different types of data. In addition, the entire hierarchical tree structure can also itself be one over-arching Merkle tree of several Merkle subtrees to represent the entire state of the system. In this specification, a Merkle tree is a tree structured data structure having nodes and edges that define parent-child relationships such that each parent node is associated with a hash value that is a hash of an aggregation of hash values of all child nodes of the parent node. At the leaf nodes, each node is associated with an element of data, which can be referred to as the leaf index, as well as a leaf hash of the element of data that is used to generate the hash of the leaf s parent node. For brevity, when data is described as belonging to a leaf node or being associated with a leaf node, this refers to the leaf index of a leaf node, in contradistinction to a leaf hash of the data associated with the leaf node that forms the basis of parent hashes in the Merkle tree. Thus, a leaf in a Merkle tree is generally associated with both a leaf index and a leaf hash.

[0013] The hash value of the root of a Merkle tree can be referred to as the Merkle root of the Merkle tree. Each interior parent node of the Merkle tree is associated with a hash of an aggregation of child hash values associated with all child nodes of the parent node. In this specification, because of the importance of Merkle trees to maintaining the global system state, a reference to a tree can be understood to refer to a Merkle tree, unless there is a contrary indication.

[0014] In this specification, an aggregation of hash values can refer to any appropriate joining together of hash values for the purposes of computing a new hash value from the joined together hash values. Thus, for example, an aggregation can be a concatenation of hash values, an addition or multiplication of hash values, or any other function that takes multiple hash values as an input and generates a single output value that can be an argument to a hash function. Alternatively or in addition, an aggregation can result from a hash function that takes multiple arguments as input to generate a single output hash value.

[0015] In this specification, a hash value being referred to as being a hash of data means that the data is one input of one or more inputs to the hash function. In other words, a hash function can optionally include additional data as an input when computing a hash function. Thus, for example, a hash value that is described as being a hash of a particular identifier means that the particular identifier was necessarily one of the inputs to the hash function and that other values were possibly also inputs to the hash function. In this specification, a Merkle proof set is a set of data that can be used to verify that a leaf index belongs to a particular Merkle tree having a particular Merkle root. A Merkle proof set can be verified by performing a Merkle proof, which involves verifying the hash value of all ancestors of a leaf node having the leaf index. Typically, performing a Merkle proof for a leaf node having a leaf hash requires at least the hash values of all ancestors of the leaf node, as well as siblings of ancestors of the leaf node. To perform a Merkle proof for a leaf node, a computer system can verify that a hash of the leaf hash and its sibling’s leaf node’s leaf hash matches the leaf node’s parent node hash, ensure that a hash of the parent node hash and its sibling’s hash value matches a hash value of the parent node’s parent node, and so on all the way to the Merkle root of the Merkle tree. When a Merkle proof can verify that a leaf index belongs to a Merkle tree, for brevity the leaf index can be referred to as having a Merkle proof relationship with the Merkle root of the Merkle tree.

[0016] In this specification, a delta Merkle proof set is a set of data that can be used to verify a change to a Merkle tree. A delta Merkle proof set can be verified by performing a Merkle proof on a Merkle tree after one of the leaf nodes has been changed according to the delta Merkle proof set to demonstrate that the state of the Merkle tree changed from state X to state Y as a result of the change.

[0017] In this specification, a contract refers to a blockchain program having functions that when executed affect a state of the blockchain. Contracts can be composed from contract functions, in which each contract function effectuates a state change in execution of the contract. As mentioned above, functions of traditional blockchain contracts must be executed serially by the entire system together, and there are typically on restrictions on which part of the blockchain a contract can modify.

[0018] The systems and techniques described in this specification overcome those limitations of traditional blockchain systems by maintaining a separate per-user state of each contract. Users can modify their own contract state, but can only read from the contract states of other users. This allows parallel modifications to the blockchain system because writing to the contract states need not depend on each other. Then, all the user modifications can be aggregated in parallel and verified through higher levels of the global tree structure.

[0019] In the systems described below, the state of a contract can be maintained per-user in user-specific contract state Merkle trees. The system can also maintain, for each user, a user contract Merkle tree whose leaf indices are contract state tree identifiers. Each contract state tree is a Merkle tree whose leaf indices identify data slots that can be used to effectuate contract functions. In other words, each data slot is a storage location to which data required for contract function execution can be written. As mentioned above, executing a contract for a particular user can allow writing to data slots for that particular user’s contract state tree, but not to the contract state tree of any other user.

[0020] Contracts deployed to the system can be maintained by a global contract Merkle tree whose leaf indices are contract identifiers of contracts deployed to the system. In order to perform whitelisting of contract functions, the system can maintain each contract function in a contract function Merkel tree whose leaves are contract function identifiers.

[0021] The systems and techniques described below can enforce these aspects of the system in a trustless way by using zero-knowledge circuits. The zero-knowledge circuits generate zero-knowledge proofs that prove that particular trees can be updated according to rules of the system. This ensures that it is impossible to tamper with the state of the blockchain, to execute unauthorized functions, or to write to unauthorized locations.

[0022] In this specification, a zero-knowledge circuit, or for brevity, a circuit, is a software module or subsystem that is associated with a set of constraints, e.g., a set of arithmetic constraints that can be used to generate a proof of the correct execution of a corresponding function when provided with particular inputs. A separate verification process can then verify that the proof is correct.

[0023] Thus, typically the function itself is executed, and then a proof is generated by a circuit that others can use to verify execution of the function by the corresponding verification process. A circuit can be generated by compiling the source code of a function into a set of constraints.

[0024] For a circuit with N constraints, typically it takes O(N) time to generate a proof, but only O(log(N)) time to verify the proof. Therefore, verifying the proof for a function takes far less time than executing the function in the first instance or generating the proof itself.

[0025] To generate a proof for execution of a function, the inputs to the function and the function result can be provided to a circuit. The circuit then uses the inputs to generate proof data corresponding to constraints of the circuit. The proof data can then be used by others to verify the execution of the function.

[0026] The systems and techniques described in this specification speed up the process of generating proofs and verifying proofs using parallel proving techniques and recursive verification. In this specification, recursive verification means that executing the logic of a particular circuit for generating a proof includes and encapsulates the logic for verifying a proof of a different circuit. In other words, the process of generating a proof can itself involve verifying another proof. In the overall process of verifying that updates to the global tree structure are legal, the system can essentially perform ascending sequences of recursive verifications using a plurality of circuits that respectively verify the legality of updating different subtrees of the plurality of subtrees from the bottom-most leaves of the subtrees in an ascending order toward a root of the top-most checkpoint subtree. The system can also use, as part of this verification process, Merkle proofs that verify the inputs to the circuits, e.g., that verify that a particular user belongs to a global user subtree, that a contract function belongs to a contract function subtree, or that a user is associated with a contract id that occurs in the global contract subtree, to name just a few examples.

[0027] The systems and techniques described in this specification also solve the fundamental scalability limitations of traditional blockchain systems by providing a mechanism for parallel proving. In particular, different computing nodes can generate proofs in parallel that can be used to verify the legality of updates of the global tree hierarchy.

[0028] Particular embodiments of the subject matter described in this specification can be implemented so as to realize one or more of the following advantages. The techniques described in this system provides several key benefits for scalability, security, efficiency, utility, privacy, and verifiability:

[0029] • Succinct Full-History Block Proofs - Each block yields a succinct zeroknowledge proof of all transactions executed in the current block and all previous blocks via a recursive verification of the previous block proof. Using current benchmarks, this means the entire blockchain state history can be verified in less than 5 ms on consumer hardware.

[0030] • Local Transaction Proving - Users prove transactions locally and generate a chain of recursive proofs which ties the initial state of the proving session to the final state after all transactions in the proving session are executed. Since each transaction proof verifies the previous transaction proof, only the final proof in the chain needs to be submitted to the chain for recursive verification, allowing users to submit an unlimited number of transactions for a fixed usage fee. And because transactions are proved locally, data used to call smart contracts is private by default and only data stored in contract state ever leaves the user’s machine. When combined with the in-circuit cryptography suite provided by the system’s standard library, this can be used to build fully private smart contracts without sacrificing data availability or non-repudiation.

[0031] • Horizontal Scalability - Block proofs are constructed in parallel using a decentralized network of proving nodes which generate increasingly higher order recursive proofs that verify the proofs generated by user transaction proving sessions, culminating in a succinct proof of all contract state updates made by transactions in a given block. Since the entire process is fully parallelized, increasing the number of user transaction session proofs the network can process per second is simply a matter of adding more nodes to the decentralized proving network.

[0032] • End-to-End Trustless Security - All transactions can be proved end-to-end via recursive zero-knowledge proofs, and thus it is impossible to forge a transaction unless the entire underlying proof system is compromised (as difficult as forging an ECC signature to send transactions on Ethereum).

[0033] • Software Defined Public Key Cryptography - Transaction signatures take the form of user-defined zero-knowledge proofs that include context of the previous block’s blockchain state, enabling standard ECC signatures (a zero-knowledge circuit which proves the verification of a secp256kl signature, for example), multisigs, and more complex logic that interacts with the state of the blockchain.

[0034] • zk-Native Smart Contracts - Unlike other zk blockchain protocols which employ the use of massive zk-VM circuits that execute smart contract bytecode, smart contracts are stored as a Merkle tree of zk-Circuits which govern the mutation of the smart contract’s state tree. This approach dramatically reduces the number of constraints per transaction proof, decreasing proof time and improving efficiency.

[0035] • Easy on-boarding for Web2 Developers - The system can make use of the Dapen Smart Contract compiler, which can compile standard ES6 JavaScript and Python (the world’s two most popular programming languages) directly to efficient ZKP circuits, thus allowing any Web2 developer to build compatible smart contracts in a matter of minutes.

[0036] The details of one or more embodiments of the subject matter of this specification are set forth in the accompanying drawings and the description below. Other features, aspects, and advantages of the subject matter will become apparent from the description, the drawings, and the claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0037] FIG. 1 illustrates a tree structure for recursive tree verification

[0038] FIG. 2A is a zk-PARTH state diagram.

[0039] FIG. 2B is a detail view of a Checkpoint Tree.

[0040] FIG. 2C is a detail view of a Global User Tree.

[0041] FIG. 2D is a detail view of a User Contract Tree User.

[0042] FIG. 2E is a detail view of a Contract State Tree.

[0043] FIG. 2F is a detail view of a Global Contract Tree.

[0044] FIG. 2G is a detail view of a Contract Function Tree.

[0045] FIG. 2H is a detail view of an External Chain Tree.

[0046] FIG. 21 is a detail view of an External Event Data Tree.

[0047] FIG. 3 is a diagram of verification circuits that enforce rules about updating the global tree.

[0048] FIG. 4 is a diagram of an example network system.

[0049] FIG. 5 is a flowchart of an example process for maintaining a global tree structure that supports a horizontally scalable blockchain platform.

[0050] Like reference numbers and designations in the various drawings indicate like elements.

[0051] DETAILED DESCRIPTION

[0052] This specification describes a horizontally scalable blockchain protocol powered by recursive zero knowledge proofs. In addition, this specification describes zk-PARTH, a blockchain architecture paradigm that enables massive parallel block construction and state fragmentation. Using zk-PARTH allows for the execution of a new class of applications with high concurrent usage requirements to become trustless and allows for existing applications of blockchain to scale to without compromising security. The protocol can be used to create a secure and efficient blockchain implementation capable of processing millions of transactions per second, which is far beyond the capabilities of conventional blockchain systems.

[0053] The techniques described in this specification rely on the following concepts.

[0054] Zero-Knowledge Succinct Non-Interactive Arguments of Knowledge (zk- SNARKs) are cryptographic primitives that enable proving the correctness of a computation without revealing the underlying data involved in the computation, zk- SNARKs have three main properties: completeness, soundness, and zero-knowledge. Completeness ensures that if the statement being proven is true, the verifier will accept the proof. Soundness guarantees that if the statement is false, no adversary can convince the verifier to accept the proof. Zero-knowledge ensures that the verifier learns nothing about the private input used in the proof, other than the fact that the statement is true.

[0055] Recursive Zero Knowledge proofs is a process by which zero knowledge circuits contain constraints that verify one or more other zero knowledge proofs. This allows many proofs to be condensed via a zero knowledge circuit, which “recursively” verifies several others, yielding a single succinct proof.

[0056] Recursive tree proving / verification is a method using recursive zero knowledge proofs to generate a single succinct proof that is equivalent to verifying many other proofs using a tree structure. FIG. 1 illustrates such a tree structure 100 for recursive tree verification. A tree 100 with a root node having a Proof G can be recursively verified by proofs of its descendent nodes. The advantage of tree proving / verification is that the process of generating a single proof from many can be parallelized since different branches of the tree (for example, the proofs of E 105 and the proof of F 107 as shown) can be proved in parallel.

[0057] To address the scalability shortcomings of existing blockchains, the system described in this specification can be architected using a novel paradigm called zk- PARTH (Parallel Ascending Recursive Tree Hierarchies). zk-PARTH defines a novel state topology design strategy for “state-circuit” symbiosis: guaranteed parallelizability with O(log2(n)) block times (where n is the number of users submitting transactions during a given block), while retaining the full security of the underlying proof system (each transaction must be proved end-to-end via recursive proving).

[0058] The zk-PARTH paradigm accomplishes scale and security by organizing the state of a given blockchain into a hierarchy of Merkle trees and hash junctions culminating in a single “PARTH root” hash, which can be used along with corresponding Merkle / preimage proofs to prove any / all state data used by the blockchain. In particular, the protocol’s state hierarchy is organized according to the logic that governs how each piece of state data can be updated, grouping sets of data that share the same update rules into distinct Merkle trees with a fixed set of zero-knowledge circuits that enforce the distinct update logic of the tree. The zk-PARTH paradigm also prioritizes grouping of trees representing the overall state of a user whenever possible (e.g. the tree of user’s is positioned as high as possible within the PARTH Merkle tree hierarchy), thus maximizing the number of concurrent users that a given protocol can serve within a given block.

[0059] In order to ensure that a zk-PARTH tree is parallelizable, the following general laws can be enforced:

[0060] 1. If the rules that govern updates to two or more pieces of state data are the same, they should be grouped into a Merkle tree (PARTH group).

[0061] This law ensures that the state is divided into clearly delineated update-logic domains, so that one can easily identify whether a state update is legal based on the target state’s domain membership.

[0062] 2. The rules that govern updates to members of the same PARTH group should be blockwise independent whenever possible. In other words, the rules for updating a leaf in a PARTH group Merkle tree should not contain logic that is dependent on the state of other leaves in the same tree in the current block.

[0063] When Law 2 is followed, the order of updates to a PARTH group’s Merkle tree during a given block does not matter (eliminates the possibility of race conditions), and thus the updates to a PARTH group’s Merkle tree can be proved in parallel.

[0064] 3. Any PARTH group’s update logic can be dependent on the state of the blockchain at the end of the previous block. If a PARTH group’s logic is dependent on the state of the blockchain at the end of a previous block, the attested PARTH root hash used by the group to reference the previous state of the blockchain must be included in the public inputs of the PARTH group’s proofs as well as in the proofs of all PARTH groups above the dependent group in the hierarchy.

[0065] Law 3 ensures that PARTH groups following Law 2 can still reference the global state of the blockchain during the last block, thus enabling massively parallel smart contract platforms and other useful applications to be built using the zk-PARTH paradigm.

[0066] 4. PARTH groups should be organized on a 1-to-many basis where the PARTH group representing users (the users / agents that perform actions causing updates to the blockchain state) is placed as close to the top of the PARTH hierarchy as possible.

[0067] Law 4 ensures that actors can prove updates to state trees under the actor PARTH group’s tree locally without the risk of race conditions caused by proof submissions by other actors, enabling protocols to take advantage of ZKP’s privacy (if you prove transactions locally, all of the transactions are private by default, and sensitive data never has to leave a user’s machine!). If local transactions are proved using a recursive transaction proof chain, this also means the protocol can be designed such that protocol proving nodes only perform a fixed amount of work to verify an unlimited number of transactions proved locally by the user, allowing for unlimited transactions to be executed by a user for a fixed gas fee.

[0068] 5. The PARTH group representing the actors must be block-wise independent (the actor / user tree must follow law 2 ).

[0069] Law 5 ensures that proofs submitted by actors can be processed in parallel, achieving zk-PARTH’s goal of maximizing the number of concurrent users who can submit transactions during a block. If the laws of PARTH are followed, proofs generated locally by actors can be recursively verified in parallel, and thus block time can be reduced to O(log2(n)), where n is the number of actors who submitted transactions / transaction proof chains that were included in the block.

[0070] 6. If a PARTH group has one or more PARTH groups under it in the hierarchy, the PARTH group’s zk-circuits must recursively verify the proofs from the lower groups when an update is processed, ensuring that illegal state updates are impossible (all updates are inductively / recursively proved end-to-end, from the leaves of the lowest tree to the final proof of the entire blockchain state). PARTH groups also must check to ensure that the verifier data of lower groups matches the lower group’s whitelist.

[0071] Law 6 ensures that a PARTH group’s zk-circuit enforces the rules of all lower PARTH groups, and thus that the final succinct ’’block proof’ of the protocol is a proof that all state updates made during a given block followed the rules of all lower PARTH groups.

[0072] 7. If there are multiple rule sets that can govern updates to data in the same PARTH group, compile each rule set to a zero-knowledge circuit and construct a ’’PARTH circuit whitelist” Merkle tree where each leaf is the hash of one of the rule set zk-circuit’ s verifier data. The circuits that govern the PARTH group above PARTH groups with multiple rule sets should recursively verify the lower PARTH group’s proof along with a Merkle proof proving the lower PARTH group’s proofs verifier data is in the circuit whitelist.

[0073] Law 7 ensures flexibility for different sets of logic that are legal without making a single large circuit with lots of conditions, recursive “tree building” circuit groups, and user deployed smart contract circuits (as the Merkle root of a given PARTH group’s circuits can also be dependent on the state of the protocol after the completion of the previous block due to law 3). Unlike all other blockchain systems, where any global contract state slot can be modified by any user, the state topology described in this specification instead splits the contract state at the user level, allowing for any user to read the state of another user's smart contract state tree, while only allowing users to write to their own UCON tree. This guarantees that “end-cap” proofs which verify the user's ownership of their private key and recursively verify a chain of transaction proofs (these proof the legality of modifications to the user's UCON tree) can be proved by each user in parallel on the client side, containing unlimited transaction proofs, and can later be processed in parallel to generate a final block proof of all transactions of all users in a block.

[0074] FIG. 2A is a zk-PARTH state diagram. FIG. 2A provides a concise visual representation of a zk-PARTH compliant state hierarchy. FIG. 2A illustrates how a number of different subtrees, which are themselves Merkle trees and which represent different types of data, can be combined into one overall Checkpoint Tree 210, with a single Checkpoint Tree Merkle Root representing the state of the entire system at a particular point in time. Importantly, the Merkle roots of some tree types are the leaf nodes of other tree types. This allows all the subtrees to be combined into the overall Merkle tree shown in FIG. 2A.

[0075] As shown in FIG. 2A, there are 8 unique subtree types that compose the PARTH state of the system: a Checkpoint Tree 210, a Global User Tree 220, a Global Contract Tree 230, an External Chain Tree 240, a User Contract Tree 250, a Contract Function Tree 260, an External Event Data Tree 270, and a Contract State Tree 280. Each of these subtrees will be described and illustrated in more detail with respect to FIGS. 2A-2I.

[0076] FIG. 2B is a detail view of a Checkpoint Tree 210. The Checkpoint Tree (CHKP) 210 stores all the checkpoint hashes (a snapshot of the state of the chain after each block) in the history of the chain. The checkpoint tree is governed by the Checkpoint Circuit. A Checkpoint Hash Function 212 hashes together the Merkle roots of one or more subtrees and possibly other data, such as a mining reward hash.

[0077] FIG. 2C is a detail view of a Global User Tree 220. The Global User Tree (GUSR) 220 holds the state of each user along with their public key, last checkpoint ID, and last nonce via a PARTH hash junction. The output of this hash junction is also known as a “User Leaf Hash” or “User Snapshot Hash.” The Global User Tree 220 can be governed by the Global User Tree Aggregation (GUTA) circuits for verification. The user snapshot hash can be generated by combining or hashing together all of these data items along with the Merkle root of the user’s User Contract Tree 230. The last checkpoint ID represents a last checkpoint of the blockchain system that included modifications made by transactions executed on behalf of the user. The user’s public key is a user-specific cryptographic public key.

[0078] FIG. 2D is a detail view of a User Contract Tree User 230. The User Contract Tree (UCON) stores the state roots for each contract for a given user. Each leaf node of the User Contract Tree is thus a contract id for a user. In other words, the leaf indices of the User Contract Tree identify contracts recognized by the system by virtue of being in the Global Contract Tree 250. Each leaf node corresponds to a different Contract State Tree.

[0079] FIG. 2E is a detail view of a Contract State Tree 240. The Contract State Tree (CSTATE) 240 stores the state of a contract for a given user. Each leaf node is a slot to which data can be written in execution of a contract and can thus represent a memory address. In other words, each leaf index identifies respective storage locations that can be modified by execution of a contract associated with the user of the parent User Contract Tree.

[0080] FIG. 2F is a detail view of a Global Contract Tree 250. The Global Contract Tree (GCON) 250 stores in its leaves the root hash of the PARTH circuit whitelist tree for each contract. The GCON leaf with index n contains the root of a PARTH circuit whitelist tree that governs CSTATE trees whose root is stored in a UCON tree at leaf n. In other words, each leaf of the Global Contract Tree is associated with a different respective Contract Function Tree and can store a Merkle root of a respective Contract Function Tree.

[0081] FIG. 2G is a detail view of a Contract Function Tree 260. The Contract Function Tree (CFUNC) 260 has leaves that contain the hash of the verifier data or “circuit fingerprint” for proving execution of a given contract function.

[0082] FIG. 2H is a detail view of an External Chain Tree 270. The External Chain Tree (ECHAIN) 270 has leaves that store the roots of the External Event Data Tree 280, where each leaf index represents a different external chain, e.g., 0 = Ethereum, 1 = Bitcoin, etc.

[0083] FIG. 21 is a detail view of an External Event Data Tree 280. The External Event Data Tree (EDATA) has leaves that store the hashes of events or other data sent from an external chain. This data is then accessible by smart contracts on the system, and the tree’s correctness is guaranteed via submission of checkpoint / block proofs to the corresponding chain for verification. FIG. 3 is a diagram of verification circuits that enforce rules about updating the global tree. The system employs a hierarchy of recursive circuits that enforce rules that determine which circuits are allowed to update the data of each tree, ensuring that all updates to all sub-tree's leaves are legal, which, when combined with tree building circuits that allow for proof updates to partitions of the sub-trees to be recursively verified or combined in parallel, culminate in a single, succinct checkpoint proof of all transactions processed in the current block, as well as a recursive verification of the previous checkpoint proof. This means that each block proof not only proves every transactions in a given block, but also inductively proves every transaction executed in all previous blocks.

[0084] A block proof of the entire blockchain's history can be verified on consumer personal computers and smart phones in less than 5 milliseconds, and can also be verified on other trustless computing platforms, which, when combined with a proof verification on another trustless compute platform such on a traditional blockchain's smart contract, can be used to trustlessly synchronize state data between any other compute platform and the system’s state.

[0085] When updating the state of the global tree, e.g., due to execution of a contract, the verification circuits are executed in a recursive and ascending fashion towards the checkpoint subtree. The ascending sequence of verification circuits includes a contract function circuit 310, a user contract tree circuit 320, a global user tree aggregation circuit 330, a global user tree aggregation circuit root 340, a checkpoint tree block circuit 350, an external event data tree circuit 360, an external chain bridge tree circuit 370, and a contract function tree aggregation circuit 380.

[0086] A Zero Knowledge Circuit, or a verification circuit, is a list of constraints on a set of input variables. The constraint system can be then compiled, and we can use the compiled circuit to generate a proof that some inputs satisfy the constraints of the circuit.

[0087] When we "compile" the circuit we generate:

[0088] 1. "Prover Data" - The optimized parameters that can be used along with inputs to generate a proof

[0089] 2. "Verifier Data" - The generic parameters that can be used to verify a proof generated by the circuit. The verifier data is unique to the circuit and can only be used to verify proofs from the corresponding circuit (trying to verify proofs generated by other circuits would result in verification failing) 3. "Verifier Data Fingerprint"- The cryptographic hash of the verifier data. Since the verifier data is unique to the circuit, so is the fingerprint.

[0090] A Zero Knowledge Proof is unique in that we can choose to keep some of the inputs "private" (people who want to verify the proof don't need to know the value of the private inputs are in order to verify the proof) and make other inputs to our constraint system "public" (people who want to verify the proof do need to know the value of the public inputs to verify the proof).

[0091] Observe the simple circuit below which only has one constraint and three inputs, a, b, and c: a * b = c

[0092] If we made a and b private inputs and made c a public input, any proof we generated from the circuit would contain the number c in plain text, but not a and b. Therefore, this circuit could be used to prove to a third party that c is not a prime number, without revealing the counter example factors which prove c is not prime.

[0093] It turns out that we can transform any function into a corresponding zero knowledge circuit which proves correct execution in result of a function. In addition, if you have O(log(n)) constraints in your circuit, it is possible to generate a proof with size O(log(N)) and which can be verified in O(log(n))time. This means that the system can do some long computation, generate a proof, and other users of the system can trustlessly verify the computation in much less time than it takes to run the computation from scratch.

[0094] In addition, the system can even verify a zero knowledge proof inside of a zero knowledge circuit.

[0095] Verifying a zero knowledge proof inside of a zero knowledge circuit is known as recursive verification. This means that the system can chain proofs together and even turn two proofs into one. Additionally, the system can take advantage of the fact that each circuit's verifier data has a unique fingerprint, and the system can whitelist which circuits' proofs we want to allow users to recursively verify.

[0096] To register users, the system can use user registration circuits. The system’s blockchain system stores users as a Merkle tree whose leaves contain the hash of the user’s public key, the user’s user contract tree root, the user’s last submission nonce, and the user’s last checkpoint id. The core user registration circuit allows for new users to be appended to the tree and generates a proof with public inputs showing the correct transformation of the global user tree from its previous root to a new root where new, valid user leaves have been appended to the tree. The core user registration circuit checks to ensure that the users public key is non-zero, that the new user’s state tree’s root is the root of a Merkle tree of height H (where H is log2(maximum number of contracts that can exist on the blockchain)), that the last checkpoint id is 0 and that the user’s last submission nonce is 0.

[0097] To parallelize the user registration proving process, multiple nodes can generate core user registration proofs and link them using user registration joining proofs, whose circuits recursively verify two or more of the core user proofs or other joining proofs and use Merkle proofs to tie the joining proofs from the start root of the first proof to the end root of the last proof via constraints which constrain the (n+l)-th core proof / joining proofs start root equal the n-th core proof / joining proof s end root. The public inputs of a core user joining proof have the same layout as the core user proof, and join proofs are eventually recursively verified by the checkpoint circuit during checkpoint construction. This system allows users to be verifiably added to the tree according to public keys they specify without it being possible for the provers to modify existing users’ public keys, ensuring security.

[0098] To deploy contracts, the system can use contract deployment circuits. The global contract tree can store each smart contract’s function data. Specifically, the global contract tree is a tree whose leaves are the Merkle roots of contract function trees whose leaves are the hash of the contract’s whitelisted function circuits. Whitelisted contract function circuits constrain the various state transformations made to the contract’s state tree for each user stores by each smart contract function. Smart contract functions are compiled symbolically to an intermediate language and then to constraints which ensure the correct execution of the function. The constraints of each contract function are used to generate a zero knowledge contract whitelisted function circuit whose public inputs contain the start and end Merkle roots of the smart contract’s state tree.

[0099] The contract deployment circuits append contract function tree roots to the global contract tree and serve a similar function as deploying a smart contract does on a traditional blockchain. The contract deployment circuits have constraints which ensure that leaves can only be appended where the leaves are empty (zero). To parallelize the contract deployment proving process, multiple nodes can generate core contract deployment proofs and link them using contract deployment joining proofs, whose circuits recursively verify two or more of the core contract proofs or other joining proofs and use Merkle proofs to tie the joining proofs from the start root of the first proof to the end root of the last proof via constraints which constrain the (n+l)-th core proof / joining proofs start root equal the n-th core proof / joining proof s end root. The public inputs of a core contract joining proof have the same layout as the core contract proof, and join proofs are eventually recursively verified by the checkpoint circuit during checkpoint construction. This guarantees that once a contract has been deployed, its contract function tree cannot be modified and that, in conjunction with the user proving session circuits, each user’s contract state tree for a given contract can only be modified according to the constraints defined in each of the contract function tree’s zk circuits, where were in turn generated by compiling the smart contract’s code. This ensures that the code of the smart contract functions much like a traditional blockchain smart contract in terms of the fact that it is the only logic which can update the smart contract’s state tree.

[0100] A user proving session allows a user to execute and prove transactions locally using a series of recursive proof verifications. The end-result of a completed user proving session is a succinct End Cap zero knowledge proof that the user has updated their user leaf hash NewLeaf (the hash which contains the root of the user contract state tree, the user’s public key, last checkpoint id and last nonce) in accordance with the rules / logic set out by the contracts deployed to a blockchain which has a checkpoint history tree with root R and where the user in question previously has a user leaf hash OldLeaf. The end cap proof has constraints which recursively verify a signature proving the user’s identity and intention to submit the transactions they have proved locally, as well as, the last UPS circuit proof generated by the user proving session. The end cap proof is then submitted to global user tree aggregation nodes who work together in parallel to update the global user tree according to the end cap proofs submitted by the network. Each global user tree aggregation node is assigned a portion of the global user tree (user id / leaf index X through Y) and is responsible for processing end cap proofs submitted by users that have ids in the leaves of their designated sub tree. The global user tree aggregation nodes process user end cap proofs by generating Global User Tree Aggregation (GUTA) proofs. There are several Global User Tree Aggregation circuits, each of which have their own function. GUTA End Cap Aggregation circuits contain constraints which recursively verify the user end cap proofs submitted by the blockchain’s users and verify delta Merkle proofs linking the OldLeaf value exposed in the public inputs of the end cap proof with the previous state of a subtree within the subtree that GUTA node is responsible for, and also use a zero Merkle proof to prove that the checkpoint tree root in the public inputs of the user end cap proof is the current checkpoint tree root or was previously the checkpoint tree root after an earlier checkpoint. This ensures that the user’s UPS proving assumptions (the user’s old state, global blockchain state, public key, nonce, etc) are accurate for the given GUTA proofs attested checkpoint tree root and global user tree sub-tree root. Multiple End Cap Aggregation proofs are generated in parallel by each GUTA node, and after the end cap aggregation proofs are finished proving, the GUTA nodes then generate GUTA joining proofs which recursively verify end cap aggregation proofs and other GUTA joining proofs along with corresponding delta Merkle proofs which have roots that approach the root of the sub-tree the GUTA node is responsible for. Once a GUTA node has generated a single joining proof which has inductively recursively verified all of the user end-cap proofs that they are responsible for (via recursively verifying joining proofs which have verified end cap aggregation proofs which have verified user end cap proofs) the GUTA node passes the proof to a GUTA parent node who is responsible for generating a single GUTA joining proof which recursively verifies and links the GUTA joining proofs generated by other GUTA nodes to the Merkle root of a larger sub-tree’s Merkle root within the global user tree. This process of joining join proofs to generate single proofs which inductively verify larger and larger sections of the global user tree is repeated until a single join proof which inductively recursively proves all of the user end cap proofs submitted for the checkpoint is generated. This final GUTA join proof that the root of the global user tree has been updated from old root A to old root B for users submitted signed user end cap proofs during the checkpoint, and exposing public inputs which reflect the circuit logic’s attested current blockchain checkpoint root tree Merkle root and GUTA circuit whitelist Merkle root (the root of a Merkle tree containing the hash of the verification data of the user end cap circuit and the allowed GUTA join circuits).

[0101] To support securely appending new events, the system can use External Event Data Circuits, which are responsible for securely appending new events to their respective external event data trees, ensuring that the leaf being modified was previously zero and is the lowest index zero-valued leaf in the tree. These circuits compute the same linear hash (state = hash(state, event)) as the one computed on the external chain, exposing the new and old external event data Merkle tree roots and the new and old linear hashes in their public inputs. Additionally, the system maintains an external event data tree for each external chain it needs to transfer data to and from, and the External Event Data Circuits are responsible for managing these trees. The linear hash is included in the public inputs and hashed to generate a Merkle tree by the external bridge chain circuits, and the root of this tree is included in the public inputs of the checkpoint proof sent to the external blockchains, enabling them to verify the proof and ensure that the external event linear hash they expected the blockchain implementing the system to have (and therefore, the events recorded / received by the blockchain) matches the hash in the public inputs of the proof.

[0102] To verify External Event Data Circuits, the system can use External Bridge Chain Circuits, which are responsible for recursively verifying the External Event Data Circuits, ensuring that all the external event data is valid, and building a final root hash for the external bridge chain tree. These circuits also construct a Merkle tree with a height equivalent to the external bridge chain circuit tree, where the leaves of this tree are formed by hashing the old linear hash state with the new linear hash state. The root of this tree is provided as a public input. The External Bridge Chain Circuits parallelize the proving and joining process in a manner similar to other circuits mentioned in the system. They aggregate the proofs from individual External Event Data Circuits and generate a single proof that inductively verifies all the external events.

[0103] Furthermore, the generated proof and the Merkle tree root are integrated into the checkpoint circuits. This allows external blockchains to verify the proof and ensures that the start and end linear hashes reflect the data sent to the blockchain implementing the system. By utilizing the functionalities provided by External Event Data Circuits and External Bridge Chain Circuits, the system ensures secure and efficient data transfer between the blockchain implementing the system and external blockchains while maintaining the integrity of the data being transferred.

[0104] The system can also use checkpoint circuits. As described above, the checkpoint tree is a Merkle tree whose n-th leave contains the checkpoint hash for checkpoint / block n. The checkpoint hash is the hash of the global user tree Merkle root, global contract tree Merkle root and external chain bridge tree Merkle root, and thus the checkpoint hash cryptographically represents the entire state of the blockchain and can be used to verify the state of the blockchain by providing the correct preimage of the checkpoint and performing Merkle proofs on the aforementioned trees. Hence, the checkpoint tree stores the hash of a “snapshot” of the entire chain’s state after at checkpoint, and the checkpoint tree’s root can be used to prove the existence of historical data in the chain.

[0105] The checkpoint circuits assemble the final checkpoint proof (also referred to as “block proof’) which is a single succinct proof that inductively proves all transactions submitted during the checkpoint and has public inputs indicated a start checkpoint tree root (the merkle tree whose leaves are the checkpoint hashes). The checkpoint recursively verifies the root GUTA joining proof (proves the validity of all the modifications to the global user tree from old root A to new root B), the root contract deployment joining circuit’s proof (proves the validity of all the newly deployed contracts and that the global contract tree’s root transitions legally from root A to root B), and the root external bridge chain circuit, attesting to the events sent by various chains to the blockchain implementing the system. Finally the checkpoint circuit recursively verifies the previous checkpoint proof and ensures that the end checkpoint merkle root of the previous checkpoint proof equals the root of the checkpoint merkle tree before the current checkpoint hash is appended to the checkpoint tree (verified using a delta merkle proof). The checkpoint checks the internal circuit whitelists of the various join circuits to ensure the verification data for the recursively verified proofs is correct and has public inputs which contain the checkpoint tree hash, the checkpoint hash, and the external event linear hash tree merkle root. Since the checkpoint circuit recursively verifies the root global user tree aggregation proof, the checkpoint proof inductively proves the correctness of every transaction in the block and the start and end global user tree merkle roots. Since the checkpoint circuit recursively verifies the root contract deployment circuit, the checkpoint proves the correctness of every modification / deployment to the global contract tree. Since the checkpoint circuit recursively verifies the external chain bridge proof, it inductively proves that the new state / old linear hash state that it expects the external chains to have. Since the checkpoint circuit recursively verifies the previous checkpoint proof, it also inductively proves the correctness of every transaction / contract deployment / extemal event linear hash processed by the blockchain previously. Since the new checkpoint tree merkle root is a public input of the checkpoint proof, any third party or other trusted compute platform can use series of merkle proofs to verify the existence / correctness any state information of the blockchain at the current or a previous checkpoint.

[0106] This proof can then be sent to other external blockchains which can quickly verify the proof on-chain and check the start / end states and linear hash states to ensure the proof and reported events are valid, likewise allowing data to be sent from the blockchain implementing the system to other trusted compute platforms as one can just perform a transaction on a contract which stores some state data that needs to be sent to an external blockchain or trusted compute platform, and then the external blockchain or trusted compute platform can verify the proof and perform Merkle roots to verify the existence of data that a user wants to sent from the blockchain utilizing the system. FIG. 4 is a diagram of an example network system 400. The example system 400 includes a decentralized network of provers who are incentivized to work together to generate a single succinct checkpoint (block) proof, which proves all of the transactions, user registrations, contract deployments, and attested external events in a given block.

[0107] When a user wishes to call a smart contract function, they first compute a witness by executing the contract’s byte code definition and use the relevant contract function’s CFUNC circuit to generate a proof of the correct state transformation from the contract’s previous state to a new state (the contract’s CSTATE tree’s root is modified from A to B) as a result of the contract call’s execution.

[0108] After this, a circuit in the User Proving Session PARTH circuit whitelist is used to generate a proof which recursively verifies the previous UPS proof and the contract function proof, as well as a Merkle proof proving the inclusion of the contract function circuit’s verifier data’s hash within the contract function (CFUNC) tree of the corresponding contract whose CSTATE tree is being updated.

[0109] In this way, updates to a CSTATE tree whose root is in the leaf with index n in the User Contract tree is governed by a PARTH circuit whitelist Merkle tree whose root is stored in leaf n of the global contract tree. This ensures correct execution while also preserving user privacy as the transaction inputs (the arguments to functions called in a transaction) never leave the user’s machine, unless the relevant smart contract stores the inputs to the contract state. For cases where it is desirable for sensitive data to be stored to global state in encrypted form, the system also supports in-circuit encrypt / decrypt primitives with non-repudiation.

[0110] When users wish to submit their locally proved transactions to the system, they can generate a signed end-cap proof which recursively verifies the last proof in their proving session’s recursive proof chain (this proves all transactions executed locally) as well as a signature proof corresponding to the user’s global contract tree’s state change as a result of the transactions in the session (which proves the user’s identity).

[0111] The end-cap proof, e.g., end cap proof 405, is then sent to the decentralized proving network (decentralized proof miners), which then use parallel recursive tree proving (generate a proof that verifies multiple proofs to generate a single proof) to eventually generate a single zero-knowledge proof of all user updates to their respective GCON trees. The decentralized proof miners aggregating updates to each user’s GCON tree within the GUSR tree prove modifications via circuits included in the corresponding PARTH circuit whitelist “Global User Tree Aggregation Circuits” or GUTA circuits. In addition, the decentralized provers are incentivized to store and make available the part of the state tree that is relevant for the proofs they generate (mining rewards are contingent on the completion of a pseudo-random “Merkle challenge” via a checkpoint / block-wise commit reveal process that all decentralized provers participate in and which is included in all GUTA circuits).

[0112] Users on external chains, the user 415, can pipe arbitrary data (token deposits, bridge events, cross-chain staking, calls to system contracts, etc.) to the system bridge contract. This external event data is then made available to smart contracts deployed on the system via the External Event Data Tree maintained for the chain in question, with the external events attested on the system via the parallel construction of an external chain bridge tree zero-knowledge proof by incentivized decentralized proof miners (participants in the decentralized proving networks).

[0113] To facilitate token bridging to the system, for example, contracts can allow users to mint tokens if an event contains an event from a given contract (e.g., a transfer to a system event), marking the event as used in the state of the contract. In addition, tokens can be bridged to external chains via burning the tokens on the system, storing a record of the destination of the burned tokens (which chain, and to which address). Token / token bridge contracts on external chains can then verify a Merkle proof tied to the root state of the system stored in the bridge contract, which proves that the tokens were burned on the system, record the cross-chain transfer as claimed, and mint / transfer tokens to the appropriate user.

[0114] New contracts to be deployed and new user registrations are similarly incorporated into their corresponding trees by a similar parallel, append only, recursive tree proving process which culminates in a single zero-knowledge proof of all updates (from Merkle root A to B) for each of the respective trees. The logic these PARTH circuit groups allow anyone to append to the tree, so long as the leaf is valid (in the case of the user), and that the leaf being updated has a value of 0, and is the lowest index leaf in the tree with a zero value (hence, append only). In the case of the user registration circuits operating on the global user tree, there is no violation of PARTH (even though there are other circuits which operate on the GUSR tree), as the user registration circuits have constraints which restrict all updates to only modify the right side of the tree where all the leaves are zero, while the GUTA circuits are restricted to the non-zero left side of the tree (ie. a race condition is impossible because writes cannot overlap between the PARTH groups). A checkpoint proof is then generated by one of the elected checkpoint leaders who generates a zero knowledge proof which recursively verifies proofs corresponding to new contract deployments, user registrations and event attestations from external chains, as well as the previous checkpoint proof. Hence, each checkpoint / block proof is a proof of all the actions that have occurred during the checkpoint, as well as all previous checkpoints / blocks.

[0115] The checkpoint leader then submits the resulting signed checkpoint (block) proof to the supported external chains’ QED bridge contracts which then verify the zero knowledge proof and validate the public inputs, checking to ensure continuity from the last submitted checkpoint proof, as well as ensuring that the attested events on QED from the given chain match the events actually sent by the bridge contract. The root of the checkpoint tree (a tree containing the state root of the entire QED blockchain at each checkpoint / block where the index of a leaf corresponds to checkpoint number) is then stored in bridge contract, making all current and historical state data of the QED blockchain available for contracts on the external chains to verifiably query via a Merkle proof.

[0116] To ensure that the same proof is submitted to all external chains, checkpoint leaders must stake significant quantities of tokens on all supported external chains to stand for election, and if the checkpoint leader submits different signed proofs to the external chains, any user can submit the proofs to all of the external chains to claim the miscreant checkpoint leader’s staked token.

[0117] The following paragraphs describe notable properties of the systems and techniques described in this specification. First, all proofs of transactions / contract calls, deployments, user registrations and external events in a checkpoint / block, as well as the previous checkpoint proof, are all proved end-to-end by the checkpoint proof via recursive verification, meaning that verifying the checkpoint proof is equivalent to verifying proofs of every action that took place during the given checkpoint, as well as, all actions performed in previous checkpoints via induction (due to the recursive verification of the previous checkpoint proof).

[0118] Verifying the checkpoint proof takes less than 5 milliseconds on consumer hardware (Mac-Book Pro Ml Max (2021)), meaning that anyone on any device can verify the entire history of a chain implementing the protocol, even if the history contains billions of transactions from users around the world. In addition, the system supports massive parallelism. All circuits / state trees modified by the decentralized provers follow the PARTH laws, and are massively parallel and have block times on the order of O(log2(n)) as a result of the tree proving topology used by the decentralized proving network in line with PARTH design. And since decentralized provers only need to access a small section of the state tree to perform work for the network, there are no significant storage or bandwidth requirements for those who wish to participate in proof mining, again thanks to the isolated tree proving structure in line with PARTH design principles.

[0119] Therefore, the systems described in this specification provide a horizontally scalable blockchain protocol powered by recursive zero knowledge proofs based on the zk-PARTH paradigm, a new blockchain architecture that enables parallel block construction and state fragmentation. The system provides succinct full-history block proofs, local transaction proving, horizontal scalability, end-to-end trustless security, zk- native smart contracts, and easy onboarding for Web2 developers. These techniques offer a promising solution to the scalability and efficiency limitations of existing blockchains. By leveraging recursive zero knowledge proofs and parallelized block construction, the system achieves high throughput, scalability, and trustless security. The zk-PARTH paradigm thus allows for the efficient organization of state data and the parallel proving of transactions and state updates. This enables QED to process millions of transactions per second while maintaining the privacy and security guarantees of blockchain technology.

[0120] With its innovative architecture and powerful features, the systems and techniques described in this specification open up new possibilities for blockchain applications and provides a scalable and efficient platform for decentralized computation. As blockchain technology continues to evolve, QED represents a significant step forward in realizing the full potential of trustless and scalable blockchain systems.

[0121] FIG. 5 is a flowchart of an example process for maintaining a global tree structure that supports a horizontally scalable blockchain platform. The example process can be performed by a distributed computing system comprising a plurality of computers in one or more locations. The example process will be described as being performed by a system of computers.

[0122] The system maintains a global tree structure having a plurality of different Merkel subtrees (510). As described above, the global tree structure contains a plurality of different types of subtrees, which are each Merkel trees. The topmost subtree is the checkpoint subtree, whose leaves each represent different checkpoints of the system.

[0123] The system receives an indication of execution of a contract function that modifies a contract state tree for a user (520). For example, a user can execute a whitelisted contract that modifies the user’s contract state tree. In some implementations execution of the contract can happen on the user's device, while other tree-maintenance operations happen in a distributed computing system.

[0124] The system performs an ascending sequence of recursive verifications from the bottom of the tree toward the checkpoint subtree (530). For example, a contract function can have an associated contract function circuit. The system can generate a contract function proof using one or more inputs to the contract function. Then the user contract tree circuit can perform a proving process that involves recursive verification of the contract function proof. As part of this process, the system can perform Merkle proofs using verifier data associated with the contract function circuit in order to verify that verifier data of the contract function circuit is represented in a leaf of the contract function subtree.

[0125] In this way, each level of the tree performs recursive verification of the subtrees under it. For example, a user contract tree circuit can generate a user contract tree circuit proof. A non-root global user tree aggregation circuit can then perform a proving process that involves recursive verification of the user contract tree circuit proof. If the recursive verification succeeded, a non-root node of the global user tree can be updated.

[0126] As another example, a root global user tree aggregation circuit can perform a proving process that includes a recursive verification of the updated non-root node in the global user tree and can then update a root node of the global user tree. As another example, a checkpoint tree circuit can perform a proving process that includes a recursive verification of the root node of the global user subtree, and the system can update the checkpoint subtree with a leaf node having a checkpoint identifier representing all transactions processed by the system since a previous checkpoint.

[0127] As another example, an external event data subtree can have an associated external event data tree circuit that generates a proof for events added to the external event data subtree. The external event data subtree can have leaf indices that identify external events, where each leaf hash of the external chain bridge subtree is associated with a Merkle root of an external event data subtree. The external chain bridge subtree can have leaf indices that identify external chains. The external chain bridge subtree can have an associated external chain bridge subtree circuit that recursively verifies proofs generated by the external event data tree circuit and generates a proof for updates to the external chain bridge subtree. The proving process of the checkpoint tree circuit can recursively verify proofs generated by the external chain bridge tree circuit.

[0128] In addition, each contract function subtree can have an associated contract function tree aggregation circuit that generates proofs to verify updates to the contract function subtree. The proving process of the checkpoint tree circuit can recursively verify proofs generated by the contract function tree aggregation circuit.

[0129] In some implementations, each circuit of the blockchain system has unique and immutable verifier data that is a private input for each respective circuit.

[0130] In order to support horizontal scalability, some operations of maintaining the tree are performed locally by user devices, and others are performed by a distributed proving network having a plurality of computers. For example, the user contract tree circuit and the contract function circuit can executed locally by user devices of users in the system, while the global user tree aggregation circuits and the checkpoint tree circuit can be executed by the distributed proving network having a plurality of computers.

[0131] Embodiments of the subject matter and the functional operations described in this specification can be implemented in digital electronic circuitry, in tangibly-embodied computer software or firmware, in computer hardware, including the structures disclosed in this specification and their structural equivalents, or in combinations of one or more of them. Embodiments of the subject matter described in this specification can be implemented as one or more computer programs, i.e., one or more modules of computer program instructions encoded on a tangible non-transitory storage medium for execution by, or to control the operation of, data processing apparatus. The computer storage medium can be a machine-readable storage device, a machine-readable storage substrate, a random or serial access memory device, or a combination of one or more of them. Alternatively or in addition, the program instructions can be encoded on an artificially- generated propagated signal, e.g., a machine-generated electrical, optical, or electromagnetic signal, that is generated to encode information for transmission to suitable receiver apparatus for execution by a data processing apparatus.

[0132] The term “data processing apparatus” refers to data processing hardware and encompasses all kinds of apparatus, devices, and machines for processing data, including by way of example a programmable processor, a computer, or multiple processors or computers. The apparatus can also be, or further include, special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application-specific integrated circuit). The apparatus can optionally include, in addition to hardware, code that creates an execution environment for computer programs, e.g., code that constitutes processor firmware, a protocol stack, a database management system, an operating system, or a combination of one or more of them.

[0133] A computer program which may also be referred to or described as a program, software, a software application, an app, a module, a software module, a script, or code) can be written in any form of programming language, including compiled or interpreted languages, or declarative or procedural languages, and it can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. A program may, but need not, correspond to a file in a file system. A program can be stored in a portion of a file that holds other programs or data, e.g., one or more scripts stored in a markup language document, in a single file dedicated to the program in question, or in multiple coordinated files, e.g., files that store one or more modules, sub-programs, or portions of code. A computer program can be deployed to be executed on one computer or on multiple computers that are located at one site or distributed across multiple sites and interconnected by a data communication network.

[0134] For a system of one or more computers to be configured to perform particular operations or actions means that the system has installed on it software, firmware, hardware, or a combination of them that in operation cause the system to perform the operations or actions. For one or more computer programs to be configured to perform particular operations or actions means that the one or more programs include instructions that, when executed by data processing apparatus, cause the apparatus to perform the operations or actions.

[0135] As used in this specification, an “engine,” or “software engine,” refers to a software implemented input / output system that provides an output that is different from the input. An engine can be an encoded block of functionality, such as a library, a platform, a software development kit (“SDK”), or an object. Each engine can be implemented on any appropriate type of computing device, e.g., servers, mobile phones, tablet computers, notebook computers, music players, e-book readers, laptop or desktop computers, PDAs, smart phones, or other stationary or portable devices, that includes one or more processors and computer readable media. Additionally, two or more of the engines may be implemented on the same computing device, or on different computing devices.

[0136] The processes and logic flows described in this specification can be performed by one or more programmable computers executing one or more computer programs to perform functions by operating on input data and generating output. The processes and logic flows can also be performed by special purpose logic circuitry, e.g., an FPGA or an ASIC, or by a combination of special purpose logic circuitry and one or more programmed computers.

[0137] Computers suitable for the execution of a computer program can be based on general or special purpose microprocessors or both, or any other kind of central processing unit. Generally, a central processing unit will receive instructions and data from a read-only memory or a random access memory or both. The essential elements of a computer are a central processing unit for performing or executing instructions and one or more memory devices for storing instructions and data. The central processing unit and the memory can be supplemented by, or incorporated in, special purpose logic circuitry. Generally, a computer will also include, or be operatively coupled to receive data from or transfer data to, or both, one or more mass storage devices for storing data, e.g., magnetic, magneto-optical disks, or optical disks. However, a computer need not have such devices. Moreover, a computer can be embedded in another device, e.g., a mobile telephone, a personal digital assistant (PDA), a mobile audio or video player, a game console, a Global Positioning System (GPS) receiver, or a portable storage device, e.g., a universal serial bus (USB) flash drive, to name just a few.

[0138] Computer-readable media suitable for storing computer program instructions and data include all forms of non-volatile memory, media and memory devices, including by way of example semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices; magnetic disks, e.g., internal hard disks or removable disks; magnetooptical disks; and CD-ROM and DVD-ROM disks.

[0139] To provide for interaction with a user, embodiments of the subject matter described in this specification can be implemented on a computer having a display device, e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor, for displaying information to the user and a keyboard and pointing device, e.g, a mouse, trackball, or a presence sensitive display or other surface by which the user can provide input to the computer. Other kinds of devices can be used to provide for interaction with a user as well; for example, feedback provided to the user can be any form of sensory feedback, e.g., visual feedback, auditory feedback, or tactile feedback; and input from the user can be received in any form, including acoustic, speech, or tactile input. In addition, a computer can interact with a user by sending documents to and receiving documents from a device that is used by the user; for example, by sending web pages to a web browser on a user’s device in response to requests received from the web browser. Also, a computer can interact with a user by sending text messages or other forms of message to a personal device, e.g., a smartphone, running a messaging application, and receiving responsive messages from the user in return.

[0140] Embodiments of the subject matter described in this specification can be implemented in a computing system that includes a back-end component, e.g., as a data server, or that includes a middleware component, e.g., an application server, or that includes a front-end component, e.g., a client computer having a graphical user interface, a web browser, or an app through which a user can interact with an implementation of the subject matter described in this specification, or any combination of one or more such back-end, middleware, or front-end components. The components of the system can be interconnected by any form or medium of digital data communication, e.g., a communication network. Examples of communication networks include a local area network (LAN) and a wide area network (WAN), e.g., the Internet.

[0141] The computing system can include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other. In some embodiments, a server transmits data, e.g., an HTML page, to a user device, e.g., for purposes of displaying data to and receiving user input from a user interacting with the device, which acts as a client. Data generated at the user device, e.g., a result of the user interaction, can be received at the server from the device.

[0142] In addition to the embodiments described above, the following embodiments are also innovative:

[0143] Embodiment l is a computer-implemented method for implementing a blockchain system, the method comprising: maintaining a global tree structure having a plurality of different subtrees, wherein each subtree is a Merkle tree of leaf nodes belonging to the subtree, wherein the plurality of subtrees comprise: a checkpoint subtree whose leaf indices are checkpoint hashes that each represent a state of the system at a respective point in time; a global user subtree whose leaves identify different respective users of the blockchain system, and a global contract subtree whose leaves are associated with different respective contracts, wherein each checkpoint hash of the checkpoint subtree is a hash of data comprising a root of the global user subtree and a root of the global contract subtree at a respective point in time.

[0144] Embodiment 2 is the method of embodiment 1, wherein each leaf hash of the global user subtree is a user snapshot hash that is or is a hash of data comprising a user contract tree Merkle root of a user contract tree for a particular user.

[0145] Embodiment 3 is the method of embodiment 2, wherein the user snapshot hash further comprises a last checkpoint id representing a last checkpoint of the blockchain system that includes modifications made by transactions executed on behalf of the user.

[0146] Embodiment 4 is the method of embodiment 3, wherein the data for the user snapshot hash further comprises a user public key.

[0147] Embodiment 5 is the method of any one of embodiments 2-4, wherein the user contract subtree for a user has leaf indices that identify contracts represented in the global contract subtree.

[0148] Embodiment 6 is the method of embodiment 5, wherein each leaf of each user contract subtree is associated with a contract state subtree whose leaf indices identify respective storage locations that can be modified by execution of a contract associated with the user of the user contract subtree.

[0149] Embodiment 7 is the method of embodiment 6, wherein each leaf hash of the user contract subtree is a contract state tree Merkle root of a respective contract state subtree representing a state of a contract.

[0150] Embodiment 8 is the method of any one of embodiments 1-7, wherein each leaf in the global contract subtree is associated with respective contract function trees.

[0151] Embodiment 9 is the method of embodiment 8, wherein each leaf hash of the global contract subtree is a contract function tree Merkle root of a respective contract function tree.

[0152] Embodiment 10 is the method of any one of embodiments 1-9, where each contract function subtree has leaf indices that identify whitelisted contract functions that each perform one or more transactions. Embodiment 11 is the method of embodiment 10, wherein leaf hashes of each contract function subtree are hashes of verifier data for a respective circuit for proving execution of a contract function.

[0153] Embodiment 12 is the method of any one of embodiments 1-11, wherein every leaf node of the plurality of different subtrees has a Merkle proof relationship with a root of the checkpoint subtree.

[0154] Embodiment 13 is the method of embodiment 12, wherein the checkpoint hash of the checkpoint subtree is based on Merkle roots of five or more different subtrees.

[0155] Embodiment 14 is the method of any one of embodiments 1-12, further comprising: receiving an indication of execution of a contract function that modifies a contract state tree for a user; and performing an ascending sequence of recursive verifications using a plurality of circuits that respectively update different subtrees of the plurality of subtrees in an ascending order toward the checkpoint subtree.

[0156] Embodiment 15 is the method of embodiment 14, wherein performing a recursive verification with a circuit comprises performing, by the circuit, a proving process that includes verifying a proof generated by a different circuit.

[0157] Embodiment 16 is the method of any one of embodiments 1-15, further comprising: receiving an indication of execution of a contract function represented in the contract function tree; generating, by a contract function circuit associated with the contract function, a contract function proof using one or more inputs to the contract function; and performing, by a user contract tree circuit, a proving process that includes a recursive verification of the contract function proof.

[0158] Embodiment 17 is the method of embodiment 16, further comprising: performing a Merkle proof of verifier data associated with the contract function circuit to verify that the verifier data of the contract function circuit is represented in a leaf of the contract function subtree.

[0159] Embodiment 18 is the method of embodiment 16, wherein a public input to the contract function proof is a checkpoint identifier of a particular checkpoint in the checkpoint subtree.

[0160] Embodiment 19 is the method of embodiment 16, further comprising verifying that execution of the contract function is allowed to update a leaf of the user contract subtree. Embodiment 20 is the method of embodiment 16, further comprising: generating, by the user contract tree circuit, a user contract tree circuit proof; and performing, by a non-root global user tree aggregation circuit, a proving process that includes a recursive verification of the user contract tree circuit proof; and determining that the recursive verification of the user contract tree circuit proof succeeded; and in response, updating a non-root node in the global user tree.

[0161] Embodiment 21 is the method of embodiment 20, further comprising: performing, by a root global user tree aggregation circuit, a proving process that includes a recursive verification of the updated non-root node in the global user tree; and updating a root node of the global user tree.

[0162] Embodiment 22 is the method of embodiment 21, further comprising: performing, by a checkpoint tree circuit, a proving process that includes a recursive verification of the root node of the global user subtree; and updating the checkpoint subtree with a leaf node having a checkpoint identifier representing all transactions processed by the system since a previous checkpoint.

[0163] Embodiment 23 is the method of any one of embodiments 1-22, wherein the plurality of subtrees further comprise an external chain bridge subtree whose leaf indices identify external chains.

[0164] Embodiment 24 is the method of embodiment 23, wherein the plurality of subtrees further comprise an external event data subtree whose leaf indices identify external events, wherein each leaf hash of the external chain bridge subtree is associated with a Merkle root of an external event data subtree.

[0165] Embodiment 25 is the method of embodiment 24, wherein the external event data subtree has an associated external event data tree circuit that generates a proof for events added to the external event data subtree.

[0166] Embodiment 26 is the method of embodiment 25, wherein the external chain bridge subtree has an associated external chain bridge subtree circuit that recursively verifies proofs generated by the external event data tree circuit and generates a proof for updates to the external chain bridge subtree.

[0167] Embodiment 27 is the method of embodiment 26, wherein the proving process of the checkpoint tree circuit recursively verifies proofs generated by the external chain bridge subtree circuit. Embodiment 28 is the method of any one of embodiments 1-27, wherein each contract function subtree has an associated contract function tree aggregation circuit that generates proofs to verify updates to the contract function subtree.

[0168] Embodiment 29 is the method of embodiment 28, wherein the proving process of the checkpoint tree circuit recursively verifies proofs generated by the contract function tree aggregation circuit.

[0169] Embodiment 30 is the method of any one of embodiments 1-29, wherein each circuit of the blockchain system has unique and immutable verifier data that is a private input for each respective circuit.

[0170] Embodiment 31 is the method of any one of embodiments 1-30, wherein the user contract tree circuit and the contract function circuit are executed by user devices of users in the system.

[0171] Embodiment 32 is the method of embodiment 31, wherein the global user tree aggregation circuits and the checkpoint tree circuit are executed by a distributed proving network computing a plurality of computers.

[0172] Embodiment 33 is a system comprising: one or more computers and one or more storage devices storing instructions that are operable, when executed by the one or more computers, to cause the one or more computers to perform the method of any one of claims 1 to 32.

[0173] Embodiment 34 is a computer storage medium encoded with a computer program, the program comprising instructions that are operable, when executed by data processing apparatus, to cause the data processing apparatus to perform the method of any one of claims 1 to 32.

[0174] Embodiment 35 is a blockchain system comprising a plurality of user devices; and a proving network comprising a plurality of computing nodes, wherein the plurality of user devices and the computing nodes of the proving network are configured to maintain a global tree structure having a plurality of different subtrees, wherein each user device stores instructions that are operable, when executed by the user device, to cause the user device to perform operations comprising: performing a sequence of contract functions, and for each contract function, performing a proving process that recursively verifies a previous contract function in the sequence, and generating an end cap proof that recursively verifies a last contract function in the sequence, and providing the end cap proof to the proving network for verification.

[0175] Embodiment 36 is the blockchain system of embodiment 35, wherein the plurality of user devices execute a plurality of contract functions in parallel.

[0176] Embodiment 37 is the blockchain system of any one of embodiments 35-36, wherein a computing node of the plurality of computing nodes of the proving network is operable to execute instructions that cause the computing node of the proving network to perform operations comprising: receiving an end cap proof from a user device; performing a proving process to recursively verify the end cap proof from the user device; and performing a partial update to a portion of a global user subtree of the plurality of different subtrees.

[0177] Embodiment 38 is the blockchain system of embodiment 37, wherein a plurality of computing nodes perform proving processes that update different portions of the global user subtree in parallel.

[0178] Embodiment 39 is the blockchain system of embodiment 38, wherein an increasing smaller number of computing nodes update different portions of the global user subtree until a single computing node updates a root node of the global user subtree.

[0179] Embodiment 40 is the blockchain system of any one of embodiments 35-39, wherein each computing node of the proving network is configured to recursively verify an unbounded number of contract functions performed locally by a user device.

[0180] Embodiment 41 is the blockchain system of any one of embodiments 35-40 wherein the plurality of user devices perform contract functions based on a last checkpoint of the blockchain system.

[0181] Embodiment 42 is the blockchain system of any one of embodiments 35-41, wherein multiple of the plurality of user devices use different checkpoints when locally performing contract functions.

[0182] Embodiment 43 is the blockchain system of any one of embodiments 35-42, wherein the proving network is configured to aggregate contract functions performed locally on user devices based on a plurality of different checkpoints. Embodiment 44 is the blockchain system of any one of embodiments 35-43, wherein the computing nodes of the proving network are configured to perform parallel proving processes.

[0183] Embodiment 45 is the blockchain system of any one of embodiments 35-44, wherein increasing a number of user devices performing transactions or increasing a number of computing nodes in the computing network horizontally scales the number of transactions processed in the blockchain system per second.

[0184] Embodiment 46 is the blockchain system of any one of embodiments 35-45, wherein each user device associated with a user is able to read from other contract state subtrees belonging to other users but can only write to a contract state subtree belonging to the user.

[0185] Embodiment 47 is a method comprising performing the operations performed by the blockchain system of any one of embodiments 35-46.

[0186] Embodiment 48 is a computer storage medium encoded with a computer program, the program comprising instructions that are operable, when executed by data processing apparatus, to cause the data processing apparatus to perform the operations of one of embodiments 35-46.

[0187] Embodiment 49 is a blockchain system comprising a plurality of computers and one or more storage devices storing instructions that are operable, when executed by the plurality of computers, to cause the plurality of computers to perform operations comprising: maintaining a blockchain system that isolates a user's state from other users; and performing recursive proving processes for parallel transaction processing.

[0188] Embodiment 50 is the blockchain system of embodiment 49, wherein the operations further comprise maintaining a Merkle tree as a contract function whitelist for recursive proof verification.

[0189] Embodiment 51 is the blockchain system of any one of embodiments 49-50, wherein the operations further comprise using tree recursive verification processes that build and update a Merkle tree while generating recursively verified zero knowledge proofs.

[0190] Embodiment 52 is a computer-implemented method performed by a decentralized network of proving nodes for executing, verifying, and storing transactions in a distributed ledger system, the method comprising: establishing the decentralized network of proving nodes; generating, by the decentralized network of proving nodes, a single checkpoint proof which verifies all transactions in a given block.

[0191] Embodiment 53 is the method of embodiment 52, wherein the single checkpoint proof further verifies all user registrations, contract deployments, and attested external events in a given block.

[0192] Embodiment 54 is the method of any one of embodiments 52-53, further comprising: generating, by the decentralized network, a state representation through the division of a blockchain state into separate and distinct trees, each tree representing a unique section of the blockchain state.

[0193] Embodiment 55 is the method of embodiment 54, further comprising isolating state updates and parallel computation by independent sets of proving nodes.

[0194] Embodiment 56 is the method of any one of embodiments 52-55, further comprising updating the state of the ledger system by independently processing transactions, user registrations, contract deployments, and external events within respective isolated state trees.

[0195] Embodiment 57 is the method of embodiment 56, further comprising performing parallel computation across the isolated state trees.

[0196] Embodiment 58 is the method of any one of embodiments 52-57, further comprising: generating a signed checkpoint proof which recursively verifies all actions performed during a given block.

[0197] Embodiment 59 is the method of embodiment 58, wherein the signed checkpoint proof recursively verifies all previous blocks.

[0198] Embodiment 60 is the method of embodiment 59, wherein the checkpoint proof is a verifiable proof of the entire history of the ledger system.

[0199] Embodiment 61 is the method of embodiment 60, further comprising performing a full history verification through using the signed checkpoint proof.

[0200] Embodiment 62 is the method of embodiment 61, further comprising performing the full history verification verifies every action that took place during a given checkpoint, as well as all actions performed in previous checkpoints.

[0201] Embodiment 63 is the method of embodiment 60, further comprising submitting the checkpoint proof to external chain bridges for verification and storage to establish a uniform and universally verifiable state across multiple chains.

[0202] Embodiment 64 is the method of any one of embodiments 52-63, further comprising: providing an interface for secure user interaction with the distributed ledger system in which transaction inputs remain private and do not leave a user's device unless executing a contract that stores the transaction inputs to the contract state.

[0203] Embodiment 65 is the method of any one of embodiments 52-64, further comprising: employing data sharding within the isolated state trees, wherein the state is divided into independently verifiable sections, thereby reducing the storage and bandwidth requirements for participants in proof mining.

[0204] Embodiment 66 is the method of any one of embodiments 52-65, further comprising: operating an incentivization mechanism for decentralized proof miners based on completion of a pseudo-random Merkle challenge using a checkpoint or block-wise commit reveal process.

[0205] Embodiment 67 is the method of any one of embodiments 52-66, further comprising: providing an interface for new contract deployments and user registrations to be incorporated into respective state trees in an append-only manner.

[0206] Embodiment 68 is the method of any one of embodiments 52-67, further comprising: ensuring data integrity and accuracy when interfacing with external chains, with checkpoint leaders staking a number of tokens on all supported external chains.

[0207] Embodiment 69 is a method comprising performing the operations performed by the blockchain system of any one of embodiments 49-51.

[0208] Embodiment 70 is a computer storage medium encoded with a computer program, the program comprising instructions that are operable, when executed by data processing apparatus, to cause the data processing apparatus to perform the operations of one of embodiments 49-51.

[0209] Embodiment 71 is a system comprising: one or more computers and one or more storage devices storing instructions that are operable, when executed by the one or more computers, to cause the one or more computers to perform the method of any one of embodiments 52 to 68.

[0210] Embodiment 72 is a computer storage medium encoded with a computer program, the program comprising instructions that are operable, when executed by data processing apparatus, to cause the data processing apparatus to perform the method of any one of embodiments 52 to 68.

[0211] While this specification contains many specific implementation details, these should not be construed as limitations on the scope of any invention or on the scope of what may be claimed, but rather as descriptions of features that may be specific to particular embodiments of particular inventions. Certain features that are described in this specification in the context of separate embodiments can also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable subcombination. Moreover, although features may be described above as acting in certain combinations and even initially be claimed as such, one or more features from a claimed combination can in some cases be excised from the combination, and the claimed combination may be directed to a subcombination or variation of a subcombination.

[0212] Similarly, while operations are depicted in the drawings in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. In certain circumstances, multitasking and parallel processing may be advantageous. Moreover, the separation of various system modules and components in the embodiments described above should not be understood as requiring such separation in all embodiments, and it should be understood that the described program components and systems can generally be integrated together in a single software product or packaged into multiple software products.

[0213] Particular embodiments of the subject matter have been described. Other embodiments are within the scope of the following claims. For example, the actions recited in the claims can be performed in a different order and still achieve desirable results. As one example, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In certain implementations, multitasking and parallel processing may be advantageous.

[0214] What is claimed is:

Claims

CLAIMS1. A computer-implemented method for implementing a blockchain system, the method comprising: maintaining a global tree structure having a plurality of different subtrees, wherein each subtree is a Merkle tree of leaf nodes belonging to the subtree, wherein the plurality of subtrees comprise: a checkpoint subtree whose leaf indices are checkpoint hashes that each represent a state of the system at a respective point in time; a global user subtree whose leaves identify different respective users of the blockchain system, and a global contract subtree whose leaves are associated with different respective contracts, wherein each checkpoint hash of the checkpoint subtree is a hash of data comprising a root of the global user subtree and a root of the global contract subtree at a respective point in time.

2. The method of claim 1, wherein each leaf hash of the global user subtree is a user snapshot hash that is or is a hash of data comprising a user contract tree Merkle root of a user contract tree for a particular user.

3. The method of claim 2, wherein the user snapshot hash further comprises a last checkpoint id representing a last checkpoint of the blockchain system that includes modifications made by transactions executed on behalf of the user.

4. The method of claim 3, wherein the data for the user snapshot hash further comprises a user public key.

5. The method of any one of claims 2-4, wherein the user contract subtree for a user has leaf indices that identify contracts represented in the global contract subtree.

6. The method of claim 5, wherein each leaf of each user contract subtree is associated with a contract state subtree whose leaf indices identify respective storagelocations that can be modified by execution of a contract associated with the user of the user contract subtree.

7. The method of claim 6, wherein each leaf hash of the user contract subtree is a contract state tree Merkle root of a respective contract state subtree representing a state of a contract.

8. The method of any one of claims 1-7, wherein each leaf in the global contract subtree is associated with respective contract function trees.

9. The method of claim 8, wherein each leaf hash of the global contract subtree is a contract function tree Merkle root of a respective contract function tree.

10. The method of any one of claims 1-9, where each contract function subtree has leaf indices that identify whitelisted contract functions that each perform one or more transactions.

11. The method of claim 10, wherein leaf hashes of each contract function subtree are hashes of verifier data for a respective circuit for proving execution of a contract function.

12. The method of any one of claims 1-11, wherein every leaf node of the plurality of different subtrees has a Merkle proof relationship with a root of the checkpoint subtree.

13. The method of claim 12, wherein the checkpoint hash of the checkpoint subtree is based on Merkle roots of five or more different subtrees.

14. The method of any one of claims 1-12, further comprising: receiving an indication of execution of a contract function that modifies a contract state tree for a user; and performing an ascending sequence of recursive verifications using a plurality of circuits that respectively update different subtrees of the plurality of subtrees in an ascending order toward the checkpoint subtree.

15. The method of claim 14, wherein performing a recursive verification with a circuit comprises performing, by the circuit, a proving process that includes verifying a proof generated by a different circuit.

16. The method of any one of claims 1-15, further comprising: receiving an indication of execution of a contract function represented in the contract function tree; generating, by a contract function circuit associated with the contract function, a contract function proof using one or more inputs to the contract function; and performing, by a user contract tree circuit, a proving process that includes a recursive verification of the contract function proof.

17. The method of claim 16, further comprising: performing a Merkle proof of verifier data associated with the contract function circuit to verify that the verifier data of the contract function circuit is represented in a leaf of the contract function subtree.

18. The method of claim 16, wherein a public input to the contract function proof is a checkpoint identifier of a particular checkpoint in the checkpoint subtree.

19. The method of claim 16, further comprising verifying that execution of the contract function is allowed to update a leaf of the user contract subtree.

20. The method of claim 16, further comprising: generating, by the user contract tree circuit, a user contract tree circuit proof; and performing, by a non-root global user tree aggregation circuit, a proving process that includes a recursive verification of the user contract tree circuit proof; and determining that the recursive verification of the user contract tree circuit proof succeeded; and in response, updating a non-root node in the global user tree.

21. The method of claim 20, further comprising: performing, by a root global user tree aggregation circuit, a proving process thatincludes a recursive verification of the updated non-root node in the global user tree; and updating a root node of the global user tree.

22. The method of claim 21, further comprising: performing, by a checkpoint tree circuit, a proving process that includes a recursive verification of the root node of the global user subtree; and updating the checkpoint subtree with a leaf node having a checkpoint identifier representing all transactions processed by the system since a previous checkpoint.

23. The method of any one of claims 1-22, wherein the plurality of subtrees further comprise an external chain bridge subtree whose leaf indices identify external chains.

24. The method of claim 23, wherein the plurality of subtrees further comprise an external event data subtree whose leaf indices identify external events, wherein each leaf hash of the external chain bridge subtree is associated with a Merkle root of an external event data subtree.

25. The method of claim 24, wherein the external event data subtree has an associated external event data tree circuit that generates a proof for events added to the external event data subtree.

26. The method of claim 25, wherein the external chain bridge subtree has an associated external chain bridge subtree circuit that recursively verifies proofs generated by the external event data tree circuit and generates a proof for updates to the external chain bridge subtree.

27. The method of claim 26, wherein the proving process of the checkpoint tree circuit recursively verifies proofs generated by the external chain bridge subtree circuit.

28. The method of any one of claims 1-27, wherein each contract function subtree has an associated contract function tree aggregation circuit that generates proofs to verify updates to the contract function subtree.

29. The method of claim 28, wherein the proving process of the checkpoint tree circuit recursively verifies proofs generated by the contract function tree aggregation circuit.

30. The method of any one of claims 1-29, wherein each circuit of the blockchain system has unique and immutable verifier data that is a private input for each respective circuit.

31. The method of any one of claims 1-30, wherein the user contract tree circuit and the contract function circuit are executed by user devices of users in the system.

32. The method of claim 31, wherein the global user tree aggregation circuits and the checkpoint tree circuit are executed by a distributed proving network computing a plurality of computers.

33. A system comprising: one or more computers and one or more storage devices storing instructions that are operable, when executed by the one or more computers, to cause the one or more computers to perform the method of any one of claims 1 to 32.

34. A computer storage medium encoded with a computer program, the program comprising instructions that are operable, when executed by data processing apparatus, to cause the data processing apparatus to perform the method of any one of claims 1 to 32.

35. A blockchain system comprising a plurality of user devices; and a proving network comprising a plurality of computing nodes, wherein the plurality of user devices and the computing nodes of the proving network are configured to maintain a global tree structure having a plurality of different subtrees, wherein each user device stores instructions that are operable, when executed by the user device, to cause the user device to perform operations comprising: performing a sequence of contract functions, and for each contract function, performing a proving process that recursively verifies a previous contract function in the sequence, andgenerating an end cap proof that recursively verifies a last contract function in the sequence, and providing the end cap proof to the proving network for verification.

36. The blockchain system of claim 35, wherein the plurality of user devices execute a plurality of contract functions in parallel.

37. The blockchain system of any one of claims 35-36, wherein a computing node of the plurality of computing nodes of the proving network is operable to execute instructions that cause the computing node of the proving network to perform operations comprising: receiving an end cap proof from a user device; performing a proving process to recursively verify the end cap proof from the user device; and performing a partial update to a portion of a global user subtree of the plurality of different subtrees.

38. The blockchain system of claim 37, wherein a plurality of computing nodes perform proving processes that update different portions of the global user subtree in parallel.

39. The blockchain system of claim 38, wherein an increasing smaller number of computing nodes update different portions of the global user subtree until a single computing node updates a root node of the global user subtree.

40. The blockchain system of any one of claims 35-39, wherein each computing node of the proving network is configured to recursively verify an unbounded number of contract functions performed locally by a user device.

41. The blockchain system of any one of claims 35-40 wherein the plurality of user devices perform contract functions based on a last checkpoint of the blockchain system.

42. The blockchain system of any one of claims 35-41, wherein multiple of the plurality of user devices use different checkpoints when locally performing contract functions.

43. The blockchain system of any one of claims 35-42, wherein the proving network is configured to aggregate contract functions performed locally on user devices based on a plurality of different checkpoints.

44. The blockchain system of any one of claims 35-43, wherein the computing nodes of the proving network are configured to perform parallel proving processes.

45. The blockchain system of any one of claims 35-44, wherein increasing a number of user devices performing transactions or increasing a number of computing nodes in the computing network horizontally scales the number of transactions processed in the blockchain system per second.

46. The blockchain system of any one of claims 35-45, wherein each user device associated with a user is able to read from other contract state subtrees belonging to other users but can only write to a contract state subtree belonging to the user.

47. A method comprising performing the operations performed by the blockchain system of any one of claims 35-46.

48. A computer storage medium encoded with a computer program, the program comprising instructions that are operable, when executed by data processing apparatus, to cause the data processing apparatus to perform the operations of one of claims 25-46.

49. A blockchain system comprising a plurality of computers and one or more storage devices storing instructions that are operable, when executed by the plurality of computers, to cause the plurality of computers to perform operations comprising: maintaining a blockchain system that isolates a user's state from other users; and performing recursive proving processes for parallel transaction processing.

50. The blockchain system of claim 49, wherein the operations further comprise maintaining a Merkle tree as a contract function whitelist for recursive proof verification.

51. The blockchain system of any one of claims 49-50, wherein the operations further comprise using tree recursive verification processes that build and update a Merkle tree while generating recursively verified zero knowledge proofs.

52. A computer-implemented method performed by a decentralized network of proving nodes for executing, verifying, and storing transactions in a distributed ledger system, the method comprising: establishing the decentralized network of proving nodes; generating, by the decentralized network of proving nodes, a single checkpoint proof which verifies all transactions in a given block.

53. The method of claim 52, wherein the single checkpoint proof further verifies all user registrations, contract deployments, and attested external events in a given block.

54. The method of any one of claims 52-53, further comprising: generating, by the decentralized network, a state representation through the division of a blockchain state into separate and distinct trees, each tree representing a unique section of the blockchain state.

55. The method of claim 54, further comprising isolating state updates and parallel computation by independent sets of proving nodes.

56. The method of any one of claims 52-55, further comprising updating the state of the ledger system by independently processing transactions, user registrations, contract deployments, and external events within respective isolated state trees.

57. The method of claim 56, further comprising performing parallel computation across the isolated state trees.

58. The method of any one of claims 52-57, further comprising: generating a signed checkpoint proof which recursively verifies all actions performed during a given block.

59. The method of claim 58, wherein the signed checkpoint proof recursively verifies all previous blocks.

60. The method of claim 49, wherein the checkpoint proof is a verifiable proof of the entire history of the ledger system.

61. The method of claim 60, further comprising performing a full history verification through using the signed checkpoint proof.

62. The method of claim 61, further comprising performing the full history verification verifies every action that took place during a given checkpoint, as well as all actions performed in previous checkpoints.

63. The method of claim 60, further comprising submitting the checkpoint proof to external chain bridges for verification and storage to establish a uniform and universally verifiable state across multiple chains.

64. The method of any one of claims 52-63, further comprising: providing an interface for secure user interaction with the distributed ledger system in which transaction inputs remain private and do not leave a user's device unless executing a contract that stores the transaction inputs to the contract state.

65. The method of any one of claims 52-64, further comprising: employing data sharding within the isolated state trees, wherein the state is divided into independently verifiable sections, thereby reducing the storage and bandwidth requirements for participants in proof mining.

66. The method of any one of claims 52-65, further comprising: operating an incentivization mechanism for decentralized proof miners based oncompletion of a pseudo-random Merkle challenge using a checkpoint or block-wise commit reveal process.

67. The method of any one of claims 52-66, further comprising: providing an interface for new contract deployments and user registrations to be incorporated into respective state trees in an append-only manner.

68. The method of any one of claims 52-67, further comprising: ensuring data integrity and accuracy when interfacing with external chains, with checkpoint leaders staking a number of tokens on all supported external chains.

69. A method comprising performing the operations performed by the blockchain system of any one of claims 49-51.

70. A computer storage medium encoded with a computer program, the program comprising instructions that are operable, when executed by data processing apparatus, to cause the data processing apparatus to perform the operations of one of claims 49-51.

71. A system comprising: one or more computers and one or more storage devices storing instructions that are operable, when executed by the one or more computers, to cause the one or more computers to perform the method of any one of claims 52 to 68.

72. A computer storage medium encoded with a computer program, the program comprising instructions that are operable, when executed by data processing apparatus, to cause the data processing apparatus to perform the method of any one of claims 52 to 68.

Images