How to Prepare for Partial State Execution

Traditional blockchains like Ethereum require every node to store and compute against the complete world state, creating a significant bottleneck for scalability. Partial State Execution fundamentally changes this model. Instead of processing all state, a node executing a transaction only needs access to the specific state it will read or modify. This is analogous to a database query that fetches only the required rows, not the entire table. The concept is central to scaling solutions like stateless clients and zk-rollups, where proving correctness replaces the need for full state replication.

The technical foundation of PSE relies on cryptographic accumulators, primarily Verkle Trees or vector commitments, which replace traditional Merkle Patricia Tries. These structures allow for compact proofs (witnesses) that a specific piece of state exists and is valid within the larger state root. When a user submits a transaction, they must provide a witness containing the state their transaction will access. The executing node verifies this proof against the known state root and then processes the transaction locally, updating only the relevant state fragments. This drastically reduces the data bandwidth and storage requirements for network participants.

For developers, preparing for a PSE environment means architecting state access to be explicit and minimal. Smart contracts should avoid unnecessary storage reads and writes across disparate slots, as each accessed key requires a proof. Gas costs will increasingly reflect the cost of witness generation and verification. Tools like the Ethereum Stateless Ethereum Prototype or zk-rollup SDKs (e.g., Starknet, zkSync) provide early testing grounds. Begin by auditing your contracts for state access patterns and exploring libraries for witness management, as this will be a core client-side responsibility in stateless paradigms.

The transition to PSE enables several key advancements: light clients can fully validate execution, block propagation becomes orders of magnitude faster as blocks contain proofs instead of full state, and historical data storage can be decentralized. However, it introduces new challenges like witness size optimization and managing state expiry for obsolete data. Projects like Ethereum's Verkle Tree transition (EIP-6800) and Celestia's data availability layer are critical infrastructure pieces making this future possible. Understanding these components is essential for building the next generation of scalable dApps.

The core prerequisite is a properly configured execution client capable of handling state queries. For Ethereum, this means running a full node like Geth or Erigon with the --gcmode archive flag to ensure access to all historical state. You will need a synced node with the JSON-RPC API enabled, particularly the eth_getProof endpoint, which is essential for generating Merkle proofs. Sufficient storage (typically 2TB+ for an archive node) and reliable, high-bandwidth internet are non-negotiable for maintaining sync and serving requests with low latency.

You must have a deep understanding of the chain's state trie structure. Partial execution relies on fetching and verifying specific slices of the global state, represented as Merkle-Patricia Trie nodes. Familiarize yourself with the concepts of state roots, storage roots, and account proofs. Tools like the trie library from the EthereumJS suite or Go-Ethereum's trie package are invaluable for programmatically interacting with and verifying these data structures. Understanding the difference between a full node's state and an archive node's historical state is critical for determining data availability.

Develop a strategy for proof generation and verification. This involves writing or integrating code that can request a Merkle proof for a given account and storage slot at a specific block height, then verify it against a trusted block header. The verification logic must check the proof's consistency all the way up to the known state root. For development and testing, use a local testnet (e.g., launched with Hardhat or Ganache) before moving to public testnets like Sepolia. This allows you to experiment with state queries and proof validation in a controlled, cost-free environment.

Finally, establish a data pipeline for fetching and caching state data. Partial execution often requires aggregating data from multiple sources: your local node for recent blocks, services like Etherscan or Infura for broad queries, and potentially decentralized storage for historical proofs. Implement efficient caching layers for frequently accessed state (like popular smart contract storage) to minimize latency and RPC calls. Your implementation's reliability will depend on this foundational setup being both robust and performant.

Statelessness is a design principle where a blockchain node validates transactions without maintaining the full global state locally. Instead of storing the entire state (e.g., all account balances and smart contract storage), a stateless client relies on a compact cryptographic proof, known as a witness, to verify state transitions. This dramatically reduces the hardware requirements for node operators, lowering the barrier to participation and enhancing network decentralization. The concept is central to Ethereum's Verkle tree roadmap and other scaling solutions like Stateless Ethereum.

A witness is the critical data structure that enables stateless verification. It contains the minimal set of Merkle or Verkle tree proofs required to prove the pre-state of the accounts and storage slots accessed by a specific block of transactions. When a block producer creates a block, they generate a witness. Validators and other nodes can then use this witness, alongside the block data, to execute transactions and verify the proposed new state root without needing the full state tree. This shifts the storage burden from all nodes to a smaller subset of block producers.

To prepare for partial state execution, developers must understand how their applications interact with state. Contracts that make widespread, random state accesses (e.g., looping over unbounded arrays) will generate larger, less efficient witnesses. Optimizing for state locality—grouping related data in contiguous storage slots—becomes a critical performance consideration. Tools like Ethereum execution APIs (eth_getProof) already allow you to fetch witnesses for specific accounts and storage keys, which is essential for building light clients or testing stateless execution logic in your development workflow.

The transition requires new standards and client behaviors. EIP-4444 (History Expiry) mandates nodes to stop serving historical block data beyond a certain age, pushing the ecosystem towards portal network clients that fetch data on-demand. For dApp developers, this means designing with the assumption that not all historical data is perpetually available from every node. Building with stateless friendliness in mind future-proofs applications against these coming architectural changes, ensuring they remain performant and cost-effective in a post-state-expansion era.

In blockchain systems like zk-rollups or optimistic rollups, a witness is the set of private inputs and auxiliary data needed to generate a proof or verify a state transition without re-executing the entire transaction. It typically includes account states, storage slots, and transaction details that are not publicly available on-chain. Preparing this data correctly is the first step for any partial state execution, where only a subset of the global state is processed. This is essential for scaling solutions that compute transactions off-chain and submit compressed proofs or fraud challenges to a base layer.

To prepare a witness, you must first define the circuit or execution trace that your proof system will verify. For a simple token transfer, the witness might include the sender's private key (or signature), the recipient's address, the amount, and the sender's current nonce and balance. In a zkEVM context, this expands to include opcode execution traces, memory/stack states, and storage accesses. The data must be serialized into a format your proving system accepts, such as a JSON file for snarkjs or a binary buffer for direct circuit input. Tools like circom or Halo2 provide libraries to structure this data.

Here is a conceptual JavaScript example using a pseudo-SDK to collect witness data for a balance check. This simulates gathering the necessary off-chain state to prove a user has sufficient funds.

javascriptCopy
async function prepareBalanceWitness(userAddress, tokenContractAddress, chainId) {
  // 1. Fetch the private state data (simulated off-chain database)
  const privateStorage = await offChainDB.getAccountState(userAddress);
  const balance = privateStorage.balances[tokenContractAddress];
  const nonce = privateStorage.nonce;
  
  // 2. Fetch the public state root against which we are proving
  const latestBlockHeader = await publicRPC.getBlockHeader('latest');
  const stateRoot = latestBlockHeader.stateRoot;
  
  // 3. Construct the witness object
  const witnessData = {
    publicInputs: {
      stateRoot: stateRoot,
      userAddress: userAddress,
      tokenContract: tokenContractAddress,
      chainId: chainId
    },
    privateInputs: {
      balance: balance,
      nonce: nonce,
      // A Merkle proof would be included here in a real scenario
      balanceProof: privateStorage.merkleProof
    }
  };
  return witnessData;
}

This structure separates public inputs (known on-chain) from private inputs (the witness).

After generating the raw witness data, it must be formatted for your specific proof backend. For a Groth16 zk-SNARK proof via snarkjs, you would convert the JavaScript object into the wtns file format using the circuit's witness calculator. For STARKs or other VM-based proofs, the witness is often a direct execution trace. A critical best practice is to validate the witness against the public inputs before proof generation to catch errors early. This involves ensuring the witness satisfies all the circuit constraints locally, which is faster and cheaper than a failed on-chain verification.

Common pitfalls in witness preparation include data inconsistency (e.g., using a state root from a different block), serialization errors (incorrect field ordering or type), and omitting necessary pre-images for hash functions. Always use deterministic methods to fetch state and include cryptographic proofs of inclusion (like Merkle proofs) for any data claimed to be part of a public root. The integrity of the entire proof system depends on the correctness and completeness of this witness. Libraries such as ffjavascript for finite field serialization or vendor-specific SDKs from rollup providers abstract away some of this complexity.

The final step is integrating witness generation into your application flow. For a rollup sequencer, this is a automated process post-transaction execution. For a user proving membership, it's a client-side operation. The witness, once prepared, is fed into a proving key to generate a zero-knowledge proof or into a fraud-prover module to create a fraud proof. By mastering witness preparation, developers can build efficient layer-2 applications, privacy-preserving proofs, and custom verification logic, which are foundational to the next generation of scalable blockchain infrastructure.

Partial state execution occurs when a smart contract processes a transaction that depends on state data not fully available on-chain at execution time. This is common in optimistic rollups like Optimism and Arbitrum, and validiums like StarkEx, where state is managed off-chain. Testing this requires simulating the interaction between the on-chain verifier contract and the off-chain state provider. You must validate that the contract correctly handles scenarios where required state roots or proofs are missing, invalid, or delayed.

Develop a modular testing suite that separates concerns. Unit tests should mock the off-chain state interface, allowing you to inject specific test vectors: valid proofs, invalid proofs, and missing data. Use a framework like Foundry's forge with vm.mockCall or Hardhat's hardhat-network-helpers to simulate these conditions. For example, you can mock a call to a StateCommitmentChain contract to return a specific historical state root, then test your contract's logic for accepting or rejecting a proof against it.

Integration testing requires a local development network that mimics the partial execution environment. Tools like Optimism's op-geth or Arbitrum Nitro's local devnode allow you to run a mini-sequencer and verifier. Deploy your contracts and simulate the full flow: submit a transaction to the sequencer, generate a state update, and then challenge it on the L1 verifier. This tests the liveness and security assumptions of your system under realistic network latency and adversarial conditions.

For advanced simulation, implement fuzz testing and differential testing. Fuzz tests (e.g., with Foundry's forge fuzz) can bombard your state verification function with randomly generated proofs and inputs to uncover edge cases. Differential testing involves comparing the output of your partial execution logic against a reference implementation or a simpler, fully on-chain version of the same logic. This helps ensure correctness even when the execution path is non-deterministic or depends on external data availability.

Finally, prepare for mainnet by conducting testnet deployments on networks like Sepolia, Goerli, or protocol-specific testnets (Optimism Sepolia, Arbitrum Sepolia). Use gas profiling to understand the cost of state verification under load and monitoring to track proof validation times. Your testing strategy should prove that your application remains secure and functional even when the underlying data availability layer experiences faults or delays, a core requirement for systems built on sovereign rollups or modular blockchains.