Skip to content

Light clients in Glamsterdam

In favor for Glamsterdam:

Acceptable in Glamsterdam (but also okay in H*):

Defer to H* (see below for rationale):

Execution

Wallets and dApps access Ethereum data using JSON-RPC. While Helios and Nimbus enable trust-minimized access to current account data (ETH and token balances, eth_call, eth_estimateGas and so on), historical data cannot be fetched reliably and efficiently. This is problematic, as trusted infrastructure can be misconfigured, unavailable, region-locked, or have questionable default privacy. Invalid data, e.g., due to inconsistent responses or due to a hack, can also lead to UI manipulation.

Even when running a personal full-node, JSON-RPC does not provide a complete picture. Any balance may potentially increase as a side-effect of a SELFDESTRUCT opcode in an arbitrary transaction, without emitting any logs. To support certain smart-contract based wallets using that mechanism, exchanges thus have to rely on trusted indexing infrastructure to trace every single transaction for potential side effects and credit user deposits in a timely manner.

It is essential for good user experience that a basic wallet can be implemented that:

  • Only trusts infrastructure for availability, but not for correctness
  • Has interactive latency even when using a privacy-preserving link
  • Contains the complete account history (completeness proof)
  • Uses no external trusted indexers

Glamsterdam

The following roadmap is proposed for Glamsterdam:

  1. Implement SSZ libraries (EIP-7916, EIP-7495, EIP-8016, Specs, Implementations)

    SSZ is easy to implement, natively supports proofs of partial data (tree hashes), offers forward compatibility, and is battle-tested in the beacon chain across the years. No more MPT / RLP should be added; SSZ "is significantly better in many ways". Exhaustive tests are available, implementations can be cross-checked. The proposed scope for Glamsterdam only involves hashing of simple objects; no serialization, no large nested objects.

  2. Use SSZ for hashing transactions / receipts (EIP-6404, EIP-6466, RPC add-on, EPF prototype)

    On-chain transactions / receipts do not contain all the information from JSON-RPC. Notably, the RPC txhash is not on-chain, it cannot be proven to be included in a transactions-root. from, contractAddress, authority, logIndex, logsBloom and gasUsed are also inefficient to prove and require downloading extra data. Certain L2s (e.g., Optimism, Offchain Labs) would benefit from proving partial transactions. Web3 purifiers (e.g., Helios, Nimbus) would benefit from general provability. If also selected, EIP-8011, EIP-8053, and EIP-8059 should be aligned with the SSZ gas types.

  3. Deprecating Bloom filters (EIP-7668)

    The log Bloom filters have a very high false positive rate and are unreliable for practical use. SSZ receipts no longer contain Bloom filter. In the block header, they could be deprecated in a backwards-compatible way by replacing the field with an all-1's value, effectively raising the false positive rate to 100%.

  4. Chunk based code (EIP-2926)

    Hashing code as a tree would be in line with the proposed change for transactions / receipts, and likely shares some maintenance burden for buidlers consuming Ethereum data in a verifying manner. ProgressiveByteList should be considered as an alternative to the current MPT based proposal.

Future

These EIPs need more time to design and are aimed at readiness for a fork after Glamsterdam.

  1. ETH transfer logs (EIP-7708, add-on, EIP-7799, EIP-6465, EPF prototype)

    Ensuring that the ETH balance is exactly the difference of all inputs minus all outputs is essential for reliable accounting, and removes the requirement for external indexers for basic wallet and dApp usecases. This should cover all initiated transactions, all inner non-zero value transfers, all fee payments (base + priority have different recipients!), beacon chain operations, as well as original genesis balances. How exactly this is done needs more discussion. Only doing EIP-7708 is insufficient to remove external indexers as certain ETH balance changes are still not covered.

  2. SSZ execution blocks (EIP-7807, EPF prototype)

    Completing the transition to SSZ harmonizes the serialization across both consensus and execution layers, and provides a clear path to a binary engine API, which will become important for scaling.

  3. SSZ serialization based networking

    By now everything is hashed with SSZ, and we should transition all networking, databases, RPCs etc to use SSZ serialization as well. This can happen side by side to the existing JSON-RPC to be backwards compatible, i.e., new verifying clients use SSZ, existing non-verifying clients continue to use JSON and don't break.

  4. Native SSZ transactions (EIP-6493)

    Any future transaction types (e.g., EIP-7793, EIP-7932, EIP-8030) should be based on native SSZ to reduce processing overhead for computing the signing root. Using native SSZ could be encouraged by providing a gas fee discount in a backwards compatible way, avoiding legacy transactions getting more expensive than commonly assumed 21k gas.

  5. Log index (EIP-7745, EIP-7792, Guide, EPF prototype, Geth proofs, Geth database, Reth database)

    A structure is needed to query eth_getLogs efficiently, and to prove correctness and completeness, i.e., no results were withheld. There are multiple distribution approaches for the log index, either enshrining an index on-chain, or distributing in an external zk based system. While the current log index proposal has well-thought-through concepts and solves a real need for any wallet or dApp, it is quite tough to implement, the syncing mechanism is still undefined, and the SSZ usage is partially non-standard. The proof format could also benefit from more validation, making this something more fitted as an individual headliner.

Consensus

On the consensus side, light clients would benefit from these in Glamsterdam:

  1. Forward compatible data structures (EIP-7688, Spec)

    This reduces the maintenance churn (involving security councils) for builders that consume beacon data in their smart contracts, and is mostly benefiting staking pools (e.g., Rocket Pool, Diva, Lido). Last proposed to discuss on ACDC. There are a few cleanup unlocks that should also be considered, e.g., EIP-8015 removes legacy fields from the CL state.

  2. Decentralized checkpoint sync (Idea, Notes, Scratchpad)

    The default method to set up a new Ethereum node is to point it to a trusted beacon-API to download a finalized checkpoint. In practice, this is frequently not verified. Checkpoint distribution services have also proven unreliable during Goerli and Holesky incidents. The bootstrap mechanism should be updated to download the checkpoint via libp2p. This is still in idea stage, but was already confirmed to be possible without consensus changes; it can be shipped incrementally, similar to the existing light client protocol. Steps involve: (1) Efficient SSZ multiproof implementation, (2) Backfill protocol for historical light client data, (3) Adding a historical trusted root into eth-client configs, (4) Integrate safe long range syncing, (5) Develop the beacon snap sync protocol.