This document describes the end-to-end flow of circuits involved in processing user transactions and aggregating them into a final block proof within the QED system. It highlights the assumptions made at each stage and how they are progressively verified, ultimately enabling horizontal scalability.

Phase 1: User Proving Session (UPS) - Local Execution

This phase happens locally on the user's device (or via a delegated prover). The user builds a recursive chain of proofs for their transactions within a single block context.

1. UPSStartSessionCircuit

  • Purpose: Initializes the proving session for a user based on the last finalized blockchain state.
  • What it Proves:
    • The starting UserProvingSessionHeader is valid.
    • This header is correctly anchored to a specific checkpoint_leaf_hash which exists at checkpoint_id within the checkpoint_tree_root from the last finalized block.
    • The session_start_context within the header accurately reflects the user's state (start_session_user_leaf_hash, user_id, etc.) as found in the user_tree_root associated with the starting checkpoint.
    • The current_state within the starting header is correctly initialized (user leaf last_checkpoint_id updated, debt trees empty, tx count/stack zero).
  • Assumptions:
    • The witness data (UPSStartStepInput) provided by the user (fetching state from the last block) is correct initially. Constraints verify its consistency.
    • The constant empty_ups_proof_tree_root (representing the start of the recursive proof tree for this session) is correct.
  • How Assumptions are Discharged: Internal consistency checks verify the relationships between the provided header, checkpoint leaf, state roots, user leaf, and the Merkle proofs linking them. The assumption about the previous block's checkpoint_tree_root being correct is implicitly carried forward, as this circuit uses it as the basis for initialization.
  • Contribution to Horizontal Scalability: Establishes a user-specific, isolated starting point based on globally finalized state, allowing this session to proceed independently of other users' sessions within the same new block.
  • High-Level Functionality: Securely starts a user's transaction batch processing.

2. UPSCFCStandardTransactionCircuit (Executed potentially multiple times)

  • Purpose: Processes a single standard transaction (contract call) within the user's ongoing session, extending the recursive proof chain.
  • What it Proves:
    • The ZK proof for the previous UPS step is valid.
    • The previous step's proof was generated by a circuit listed in the ups_circuit_whitelist_root specified in the previous step's header.
    • The public inputs (header hash) of the previous step's proof match the provided previous_step_header.
    • The ZK proof for the current Contract Function Call (CFC) exists within the current current_proof_tree_root.
    • This CFC proof corresponds to a function registered in the GCON tree (via checkpoint context).
    • Executing this CFC correctly transitions the state from the previous_step_header to the new_header_gadget state (updating CSTATE->UCON root, debt trees, tx count/stack).
  • Assumptions:
    • The witness data (UPSCFCStandardTransactionCircuitInput) for this specific step (CFC proof, state delta witnesses, previous step proof info) is correct initially.
    • The current_proof_tree_root provided matches the actual root of the recursive proof tree being built.
  • How Assumptions are Discharged:
    • Verifies the previous step's proof using VerifyPreviousUPSStepProofInProofTreeGadget. This discharges the assumption about the previous step's validity and its public inputs.
    • Verifies the CFC proof and its link to the contract state using UPSVerifyCFCStandardStepGadget.
    • Verifies the state delta logic, ensuring the transition is correct based on witness data.
    • The assumption about the current_proof_tree_root is passed implicitly to the next step or the End Cap circuit.
  • Contribution to Horizontal Scalability: User processes transactions locally and serially for themselves, maintaining self-consistency without interacting with other users' current block activity.
  • High-Level Functionality: Securely executes and proves individual smart contract interactions locally.

3. UPSCFCDeferredTransactionCircuit (Executed if applicable)

  • Purpose: Processes a transaction that settles a deferred debt, then executes the main CFC logic.
  • What it Proves: Similar to the standard circuit, but additionally proves:
    • A specific deferred transaction item was removed from the deferred_tx_debt_tree.
    • The item removed corresponds exactly to the call data of the CFC being executed.
    • The subsequent CFC state transition starts from the state after the debt was removed.
  • Assumptions: Same as the standard circuit, plus assumes the witness for the deferred transaction removal proof (DeltaMerkleProofGadget) is correct initially.
  • How Assumptions are Discharged: Verifies previous step proof. Verifies the debt removal proof and its consistency with the CFC call data. Verifies the subsequent state delta.
  • Contribution to Horizontal Scalability: Same as standard transaction circuit (local serial execution).
  • High-Level Functionality: Enables settlement of asynchronous transaction debts within the local proving flow.

4. UPSStandardEndCapCircuit

  • Purpose: Finalizes the user's entire proving session for the block.
  • What it Proves:
    • The proof for the last UPS transaction step is valid and used an allowed circuit.
    • The ZK proof for the user's signature (authorizing the session) is valid and exists in the same UPS proof tree.
    • The signature corresponds to the user's registered public key (derived from signature proof parameters).
    • The signature payload (QEDUserProvingSessionSignatureDataCompact) correctly reflects the session's start/end user leaves, checkpoint, final tx stack, and tx count.
    • The nonce used in the signature is valid (incremented).
    • The final UPS state shows both deferred_tx_debt_tree_root and inline_tx_debt_tree_root are empty (all debts settled).
    • The last_checkpoint_id in the final user leaf matches the session's checkpoint_id and has progressed correctly.
    • (If aggregation proof verification included): The UPS proof tree itself was constructed using circuits from a known proof_tree_circuit_whitelist_root.
  • Assumptions:
    • Witness data (UPSEndCapFromProofTreeGadgetInput, potentially agg proof witness) is correct initially.
    • Known constants (network_magic, empty debt roots, known_ups_circuit_whitelist_root, known_proof_tree_circuit_whitelist_root) are correct.
  • How Assumptions are Discharged:
    • Verifies the last UPS step proof.
    • Verifies the ZK signature proof.
    • Connects signature data to the final UPS header state.
    • Checks nonce, checkpoint ID, empty debt trees.
    • Verifies proofs against whitelists using provided roots.
    • The output of this circuit (the End Cap proof) now implicitly carries the assumption that the starting checkpoint_tree_root (used in the UPSStartSessionCircuit) was correct. All internal UPS assumptions have been discharged.
  • Contribution to Horizontal Scalability: Creates a single, verifiable proof representing all of a user's activity for the block. This proof can now be processed in parallel with proofs from other users by the GUTA layer.
  • High-Level Functionality: Securely concludes a user's transaction batch, authorizes it, and packages it for network aggregation.

Phase 2: Global User Tree Aggregation (GUTA) - Parallel Network Execution

The Decentralized Proving Network (DPN) takes End Cap proofs (and potentially other GUTA proofs like user registrations) from many users and aggregates them in parallel. This involves specialized GUTA circuits.

(Note: The provided files focus heavily on UPS and GUTA gadgets. The exact structure of the GUTA circuits using these gadgets is inferred but follows standard recursive proof aggregation patterns.)

Example GUTA Circuits (Inferred):

5. GUTAProcessEndCapCircuit (Hypothetical)

  • Purpose: To take a user's validated UPSStandardEndCapCircuit proof and integrate its state change into the GUTA proof hierarchy.
  • Core Logic: Uses VerifyEndCapProofGadget.
  • What it Proves:
    • The End Cap proof is valid and used the correct circuit (known_end_cap_fingerprint_hash).
    • The checkpoint_tree_root claimed by the user in the End Cap result existed historically.
    • Outputs a standard GlobalUserTreeAggregatorHeader representing the user's GUSR tree state transition (start leaf hash -> end leaf hash at the user's ID index) and stats.
  • Assumptions:
    • Witness (End Cap proof, result, stats, historical proof) is correct initially.
    • The known_end_cap_fingerprint_hash constant is correct.
    • A default_guta_circuit_whitelist root is provided or known.
  • How Assumptions are Discharged: Verifies the End Cap proof and historical checkpoint proof. Packages the result into a standard GUTA header. The assumption about the default_guta_circuit_whitelist is passed upwards. The assumption about the current checkpoint_tree_root (from the historical proof) is passed upwards.
  • Contribution to Horizontal Scalability: Allows individual user session results to be verified independently and prepared for parallel aggregation.
  • High-Level Functionality: Validates and incorporates user end-of-session proofs into the global aggregation process.

6. GUTARegisterUserCircuit (Hypothetical)

  • Purpose: To process the registration of one or more new users.
  • Core Logic: Uses GUTAOnlyRegisterUsersGadget (which uses GUTARegisterUsersGadget, GUTARegisterUserFullGadget, GUTARegisterUserCoreGadget).
  • What it Proves:
    • For each registered user, their public_key was correctly inserted at their user_id index in the GUSR tree (transitioning from zero hash to the new user leaf hash).
    • The public_key used matches an entry in the user_registration_tree_root.
    • Outputs a GlobalUserTreeAggregatorHeader representing the aggregate GUSR state transition for all registered users, with zero stats.
  • Assumptions:
    • Witness (registration proofs, user count) is correct initially.
    • guta_circuit_whitelist and checkpoint_tree_root inputs are correct for this context.
    • default_user_state_tree_root constant is correct.
  • How Assumptions are Discharged: Verifies delta proofs for GUSR insertion and Merkle proofs against the registration tree. Outputs a standard GUTA header, passing assumptions about whitelist/checkpoint upwards.
  • Contribution to Horizontal Scalability: User registration can be batched and potentially processed in parallel branches of the GUTA tree.
  • High-Level Functionality: Securely adds new users to the system state.

7. GUTAAggregationCircuit (Hypothetical - Multiple Variants)

  • Purpose: To combine the results (headers) from two or more lower-level GUTA proofs (which could be End Cap results, registrations, or previous aggregations).
  • Core Logic:
    • Verifies each input GUTA proof using VerifyGUTAProofGadget.
    • Ensures all input proofs used circuits from the same guta_circuit_whitelist and reference the same checkpoint_tree_root.
    • Combines the state_transitions from the input proofs:
      • If transitions are on different branches, uses TwoNCAStateTransitionGadget with an NCA proof.
      • If transitions are on the same branch (e.g., one input is a line proof output), connects them directly (old_root of current matches new_root of previous).
      • If only one input, uses GUTAHeaderLineProofGadget to propagate upwards.
    • Combines the stats from input proofs using GUTAStatsGadget.combine_with.
    • Outputs a single GlobalUserTreeAggregatorHeader representing the combined state transition and stats.
  • What it Proves: That given valid input GUTA proofs operating under the same whitelist and checkpoint context, the combined state transition and stats represented by the output header are correct.
  • Assumptions:
    • Witness (input proofs, headers, NCA/sibling proofs) is correct initially.
  • How Assumptions are Discharged: Verifies input proofs and their headers. Verifies the logic of combining state transitions (NCA/Line/Direct). Passes the common whitelist/checkpoint root assumptions upwards.
  • Contribution to Horizontal Scalability: This is the core of parallel aggregation. Multiple instances of this circuit run concurrently across the DPN, merging proof branches in a tree structure (like MapReduce).
  • High-Level Functionality: Securely and recursively combines verified state changes from multiple sources into larger, aggregated proofs.

8. GUTANoChangeCircuit (Hypothetical)

  • Purpose: To handle cases where no user state changed but the checkpoint advanced.
  • Core Logic: Uses GUTANoChangeGadget.
  • What it Proves: That given a new checkpoint_leaf verified to be in the checkpoint_tree_proof, the GUSR tree root remains unchanged, and stats are zero. Outputs a GUTA header reflecting this.
  • Assumptions: Witness (checkpoint proof, leaf) is correct initially. Input guta_circuit_whitelist is correct.
  • How Assumptions are Discharged: Verifies checkpoint proof. Outputs a standard GUTA header passing assumptions upward.
  • Contribution to Horizontal Scalability: Allows the aggregation process to stay synchronized with the checkpoint tree even during periods of inactivity for certain state trees.
  • High-Level Functionality: Advances the aggregated checkpoint state reference.

Phase 3: Final Block Proof

9. Checkpoint Tree "Block" Circuit (Top-Level Aggregation)

  • Purpose: The final aggregation circuit that combines proofs from the roots of all major state trees (like GUSR via the top-level GUTA proof, GCON, etc.) for the block.
  • Core Logic:
    • Verifies the top-level GUTA proof (and proofs for other top-level trees if applicable).
    • Takes the previous block's finalized CHKP root as a public input.
    • Constructs the new CHKP leaf based on the newly computed roots of GUSR, GCON, etc., and other block metadata.
    • Computes the new CHKP root.
    • The only external assumption verified here is that the input previous_block_chkp_root matches the actual finalized root of the last block.
  • What it Proves: That the entire state transition for the block, represented by the change from the previous_block_chkp_root to the new_chkp_root, is valid, having recursively verified all constituent user transactions and aggregations according to protocol rules and circuit whitelists.
  • Assumptions: The only remaining input assumption is the hash of the previous block's CHKP root.
  • How Assumptions are Discharged: All assumptions from lower levels (circuit whitelists, internal state consistencies) have been verified recursively. The final link to the previous block state is checked against the public input.
  • Contribution to Horizontal Scalability: Represents the culmination of the massively parallel aggregation process, producing a single, succinct proof for the entire block's validity.
  • High-Level Functionality: Creates the final, verifiable proof of state transition for the entire block, linking it cryptographically to the previous block. This proof can be efficiently verified by any node or light client.