Partial Nodes Under Stateless Ethereum

Running a full Ethereum node requires storing the entire world state (~1TB+ and growing), imposing a massive hardware and bandwidth tax that centralizes participation.\n- Eliminates the need for terabyte-scale SSDs and multi-day sync times.\n- Reduces the hardware barrier from a dedicated server to a consumer laptop or even a mobile device.\n- Enables a 10-100x increase in viable node operators, directly attacking client diversity.

Partial nodes, powered by Verkle proofs, can verify execution without local state, making the 'light client' security model the default. This is the death knell for trusted RPC providers.\n- Enables trust-minimized wallets and dApps to verify chain data directly, breaking dependency on centralized Infura/Alchemy endpoints.\n- Unlocks secure bridging and cross-chain messaging for layer 2s and appchains without introducing new trust assumptions.\n- Creates a native verification layer for oracles like Chainlink and intent solvers like UniswapX.

Decoupling state storage from verification allows nodes to specialize. We move from monolithic generalists to a network of optimized, application-aware verifiers.\n- Enables ZK-rollup nodes that only verify proofs for specific L2s like Starknet or zkSync, slashing costs.\n- Allows MEV searchers and solvers to run ultra-lean nodes focused solely on mempool and block validation.\n- Facilitates corporate or institutional nodes that only track and verify state relevant to their specific treasury or compliance needs.

Current light clients (e.g., Helios, Nimbus) are crippled by the need to sync and verify the entire state, making them slow and unreliable for high-frequency applications like DeFi or gaming. They rely on centralized RPCs, reintroducing trust.

• State growth exceeds ~1 TB, impossible for mobile.
• Trust assumption in RPC provider for state proofs.
• Latency for proof retrieval kills UX for real-time apps.

Stateless clients verify blocks using a witness (~1-10 MB per block) instead of holding state. This enables truly trust-minimized light clients that can run anywhere.

• Witness size is decoupled from total state growth.
• Client diversity explodes: browsers, phones, IoT devices.
• Foundation for portal network (e.g., Trin, Ultralight) to serve witnesses.

Full node software like Reth and Erigon will shift from being state-holding archives to optimized witness generators. Their performance will be measured by proof generation speed, not just sync time.

• New metric: Witness generation latency becomes critical.
• Archival nodes become a specialized, incentivized service.
• Data availability layers (e.g., EigenDA, Celestia) become crucial for witness storage.

Block builders currently rely on fast, local state access to simulate bundles. Statelessness forces them to fetch state proofs for every transaction, adding latency and complexity to the MEV supply chain.

• Builder latency increases, potentially reducing extractable value.
• Relay-builder protocols (e.g., Flashbots SUAVE) must integrate witness handling.
• Centralization risk if only a few can afford low-latency proof infrastructure.

A new market emerges for zk-proof aggregators and state proof oracles that serve builders and applications. Projects like RiscZero and Espresso Systems could provide fast, verifiable state proofs as a service.

• Proof marketplace: Competing on latency and cost for witness generation.
• Application-specific proofs: Rollups (e.g., Arbitrum, zkSync) already model this.
• Hardware acceleration (GPUs/FPGAs) becomes a moat.

The stateless transition is an infrastructure shift, not a consumer-facing feature. Investment theses must focus on the new primitives: witness distribution networks, proof acceleration hardware, and stateless SDKs for L2s and Omnichain apps.

• Avoid investing in 'just another RPC provider'.
• Target teams building portal network clients or zk-proof hardware.
• Convergence with modular blockchain (e.g., Celestia, EigenLayer) narratives is inevitable.

Full nodes require storing the entire Ethereum state (~1TB+), creating prohibitive hardware costs and centralization pressure. This limits validator participation and network resilience.

• State growth outpaces consumer hardware.
• Sync times can take days, harming node churn.
• Centralization risk as only large entities can run full nodes.

The core cryptographic upgrade replacing Merkle Patricia Tries. Verkle Trees enable compact cryptographic proofs (witnesses) that a node can use to verify state without holding it.

• Witness size reduced from ~1MB to ~1KB per block.
• Enables stateless validation: nodes verify execution with proofs, not local state.
• Paves the way for single-slot finality by speeding up consensus.

Post-Verkle, nodes can choose their state footprint. This creates a spectrum from full to light clients, with 'partial nodes' holding selective state (e.g., for a specific rollup or application).

• Specialized nodes for L2s like Arbitrum or Optimism become trivial.
• Resource requirements drop, enabling nodes on mobile or edge devices.
• Network security increases via greater validator decentralization.

Statelessness fundamentally changes data availability and proving assumptions. Rollups like zkSync and Starknet can design around leaner, more verifiable base layer proofs.

• Faster dispute resolution in optimistic rollups with compact fraud proofs.
• Cheaper ZK validity proofs due to smaller witness verification.
• dApps can run their own verifying nodes for ultimate self-custody security.

Proposer-Builder Separation (PBS) becomes more critical. Builders will need to generate state witnesses for validators. This creates a competitive market for efficient witness generation services.

• New builder role: witness generation as a service.
• MEV strategies may evolve to optimize proof creation speed.
• Relays like Flashbots may bundle blocks with optimized witnesses.

Stateless execution is a massive client implementation lift. Teams like Geth, Nethermind, and Erigon must integrate Verkle logic and new networking for witness propagation.

• Protocol risk during transition if client bugs emerge.
• Networking upgrades (e.g., Portal Network) essential for witness distribution.
• Long-term benefit: breaks Geth dominance by resetting client complexity.