RE: LeoThread 2026-03-01 21-48

Now, scaling

There are two buckets: short-term and long-term

Short-term scaling has been discussed elsewhere. Key points:

• Block-level access lists (in Glamsterdam) enable blocks to be verified in parallel

• ePBS (in Glamsterdam) adds features that make it safe to use a large fraction of each slot — not just a few hundred milliseconds — to verify a block

• Gas repricings align operation costs with actual execution time (and other costs). Early steps toward multidimensional gas cap different resources differently. Together these changes let larger fractions of a slot be used for verification without fear of exceptional cases

A multi-stage roadmap for multidimensional gas is planned. In Glamsterdam, "state creation" costs are separated from "execution and calldata" costs. For example, an SSTORE that changes nonzero→nonzero now costs 5,000 gas, while zero→nonzero costs 20,000; Glamsterdam increases that extra amount (eg. to ~60,000), so an SSTORE might charge 5,000 "regular" gas plus ~55,000 "state creation" gas

State creation gas will not count toward the ~16M tx gas cap, so creating larger contracts will be possible

The EVM assumes one gas dimension, so the approach keeps two invariants: a call made with X gas gives that call X gas usable across dimensions, and GAS reports Y gas such that after making a call with X gas at least Y−X remains for post-operations. The system creates N+1 gas "dimensions" (default N=1 for state creation) plus a "reservoir." Execution consumes specialized dimensions first, then the reservoir. Example: (100k state-creation, 100k reservoir) after three new-state SSTOREs goes (100k,100k) → (45k,95k) → (0,80k) → (0,20k). GAS returns reservoir; CALL forwards the specified reservoir amount plus all non-reservoir gas

Later, pricing becomes multi-dimensional with different floating prices per dimension for long-term economic sustainability; the reservoir mechanism also addresses the sub-call problem

Long-term scaling has two parts: ZK-EVM and blobs

For blobs, PeerDAS will be iterated toward an end-state that can ideally handle ~8 MB/s — enough for Ethereum's needs rather than a global data layer. Blobs are for L2s today; the plan is for Ethereum block data to go into blobs so a hyperscaled chain can be validated without re-execution: ZK-SNARKs remove re-execution need, and PeerDAS on blobs enables availability verification without full download

For ZK-EVM, adoption is staged: clients allowing attestation with ZK-EVMs are expected in 2026 (not yet safe to run the network; ~5% reliance acceptable — failure risks building on invalid blocks and losing revenue but not slashing). In 2027, recommendation will shift toward a larger minority running ZK-EVMs while focusing on formal verification and hardening; ~20% usage could allow much higher gas limits by preserving a cheap path for solo stakers. Eventually move to 3-of-5 mandatory proving, where a valid block contains 3 of 5 proof types from different systems, and most nodes (except indexers) will rely on ZK-EVM proofs. Continuous improvement, formal verification, and possible VM changes (eg. RISC-V) will follow