BITE Phase 2: Secure Catchup via State Diff Set (SDS)

General
1

BITE Phase 2: Secure Catchup via State Diff Set (SDS)

1. Abstract & Motivation

The x402 protocol, through BITE Phase 2, enables the execution of EVM operations over confidential, encrypted state (e.g., updating encrypted token balances). A fundamental design contradiction exists in all confidential blockchains: How can a catching-up node synchronize the ledger history if the decryption keys required to re-execute the transactions are ephemeral and no longer exist?

The system must ensure:

  1. Privacy Constraint: Decrypted state (plaintext) must never be stored on the ledger.
  2. Synchronization Requirement: New nodes (“Catchup nodes”) must be able to securely and efficiently reach the current, correct state from genesis.

Our solution, the State Diff Set (SDS) mechanism, resolves this by separating confidential EVM execution from state application. Instead of re-computing the private EVM execution result, catchup nodes apply a cryptographically authenticated batch of state changes containing only the re-encrypted state.

2. Core Architecture: The State Diff Set (SDS)

2.1. Problem that we need to solve.

  • Ephemeral Decryption: Decryption keys are only available for the block in which the confidential transaction (CTX) is executed.
  • Impossibility of Re-execution: Storing the initial encrypted inputs for future re-execution is futile, as the decryption keys will have expired, making the initial plaintext impossible to recover. Storing decryptions is forbidden by the privacy requirement.

2.2. Solution: The SDS Mechanism

The SDS mechanism decouples EVM Execution (only possible during new block processing) from State Diff Application (possible by a catching-up node).

  1. Live Execution: Nodes use threshold decryption to decrypt the necessary state, perform the private EVM execution (e.g., onDecrypt in the contract), and re-encrypt the new state values.
  2. Batching & Commitment: All storage slot updates (sstore operations) resulting from the execution of all Phase 2 CTXs in a block are aggregated into a State Diff Set (SDS).
  3. Consensus Root: The cryptographic root (Merkle Root) of the SDS is included as part of the Block Header’s State Root. By signing the Block Header, the validator set cryptographically attests that the contents of the SDS are the correct and sole result of the confidential EVM execution.

2.3. The Catchup Workflow

When a new node syncs the chain:

  1. Skip Decryption and Execution: The node does not attempt to decrypt inputs or re-compute the onDecrypt EVM execution result.
  2. Verification: The node verifies the block signature and, implicitly, the commitment to the SDS root within the State Root.
  3. Blind Application: The node treats the SDS as a trusted, validated diff set and applies it directly to its local state database.

The catchup node achieves the correct final state without ever possessing the decryption keys or viewing the plaintext, thereby preserving the privacy invariant while maintaining synchronized consensus.

3. Architecture Flow Diagram

[ BLOCK N: LIVE VALIDATORS ]
        |
        +---> 1. Decrypt State (using Ephemeral Key)
        |
        +---> 2. Perform EVM Execution (Plaintext)
        |
        +---> 3. Re-Encrypt New State (Resulting Ciphertext)
        |
        +---> 4. Generate State Diff Set (SDS)
        |
        +---> 5. Commit SDS Root to Block Header (Signed)

                    |
                    | (Time Passes...)
                    v

[ CATCHUP NODE ]
        |
        +---> A. Verify Block Signature & SDS Root
        |
        +---> B. Read SDS from Block Body
        |
        +---> C. Blind Application (Update Local DB with Encrypted Vals)
        |
        v
[ FINAL SYNCHRONIZED STATE ]

4. Data Structures

The State Diff Set (SDS) is generated by the EVM runtime during Phase 2 execution and serialized into the block body.

struct StorageUpdate {
    address contractAddress;
    bytes32 storageSlot;
    bytes newEncryptedValue; // The Ciphertext resulting from Re-encryption
}

struct StateDiffSet {
    StorageUpdate[] updates;
    bytes32 sdsRoot; // Merkle Root of the updates
}

// Block Header Inclusion (Pseudocode)
struct BlockHeader {
    bytes32 ParentHash;
    bytes32 StateRoot; // Commitments include the SDS Root
    bytes32 TransactionsRoot;
    // ... other fields
}

5. Security Property: Correctness and Privacy

The Catchup Node workflow maintains two essential properties:

1. Correctness (Integrity): A Catchup Node assumes the final state s correct if the SDS is signed by the validator supermajority.

The Catchup Node, therefore, blindly applies the cryptographically attested SDS

2. Privacy (Non-Disclosure): The plaintext values are only visible to the validator supermajority during the ephemera execution window.

The Catchup Node achieves synchronization purely by applying ciphertext-to-ciphertext transitions, thereby protecting the core privacy invariant of the protocol.