See also: this earlier post from Barnabe Decoupling throughput from local building - Economics - Ethereum Research
One of the unavoidable consequences of raising the L1 gaslimit, especially larger increases that have been proposed, is that the hardware and bandwidth requirements of running a full node will increase.
In my view, these changes in tradeoffs are likely net good. This is true for a few reasons:
- Today, we are paying the costs of low node requirements (low gaslimit) but we are not actually getting the benefits (wide-scale personal full node operation)
- 2010s-era thinking assumed symmetry between block production and verification: you can only verify by re-executing - which implies one class of node. Newer 2020s era technologies - access lists, statelessness, zk proving - all break that symmetry, and all have the format of one powerful actor doing more work to make verification much easier for everyone else.
- Newer block building designs also introduce new forms of decoupling, eg. breaking up transaction inclusion authority (sufficient to ensure non-censorship) from optimal block building.
All of these factors hint in the direction of a more heterogeneous architecture, where some nodes become larger, but in exchange the ability to ensure core guarantees becomes accessible to many more people. Even as full-node requirements increase, an Ethereum where most users’ wallets are running light clients that ZK-verify the chain is slowly coming within reach.
However, if we start going in this direction, we need to be very clear about what our underlying goals in terms of decentralization are: what properties are we trying to give to users, and what red lines are we not willing to cross?
This post will sketch out one framework for thinking about this.
I will define three types of nodes:
- Light node: sufficient to (i) verify the chain, including correctness and availability, and (ii) access any needed data privately, assuming the existence of at least 1 honest heavy node (for liveness; safety is unconditional)
- Medium node: any type of node that Ethereum has a n/2-of-n trust assumption in (eg. attesters in staking, FOCIL)
- Heavy node: any type of node that Ethereum has a 1-of-n assumption in (eg. optimal block building, proving)
FOCIL goes in the medium category because even though the trust assumption is not quite n/2-of-n, it’s definitely bigger than 1-of-n: we want lots of people to participate in FOCIL honestly to ensure rapid inclusion guarantees.
A possible rubric for these might be:
- We want running a light node to be so trivial that it is included in browser and mobile wallets by default (as well as newer categories of clients like eg. AI agent frameworks that specialize in blockchains)
- Running a medium node should cost roughly what it costs now, maybe a little more but not too much more
- Running a heavy node can be more resource-intensive (because we only need one of them to be honest for Ethereum to work), but we still need to put some limits to ensure a competitive market
The latter category will likely be the most controversial, and I expect heavy requirements on block building will be more controversial than equally heavy requirements on proving (because proving is a “dumb pipe” task, there is no way to “abuse the authority”, whereas even with FOCIL a malicious dominant block builder can do some damage).
If we want to set limits, we can start asking the question: what is the goal of those limits? Some possible answers are:
- Fixed costs should be low enough to ensure a highly competitive market
- Energy requirements should be low enough to run from a home (ie. max ~15 kW), so that Ethereum is strongly protected from dependency on data centers, which are easy censorship choke points
One tricky one to think about is internet (both bandwidth and latency). Having reasonable bandwidth and latency requirements is critical to geo-decentralization and censorship resistance, but what requirements are reasonable is more difficult to measure - there isn’t a clean equivalent of “for $30,000 you can buy an H200”. For many people in many locations, internet bandwidth above a certain speed is not available at all. Internet is also challenging to rely on because, unlike hardware, it can be easily and suddenly taken away. Finally, we do not want to become wholly dependent on one type of internet (eg. Starlink). In general, we should probably be more conservative on bandwidth than on hardware specs.
This is a sketch with numbers still to be filled in, and even some of its underlying assumptions are perhaps disputable (to give one example of many: FOCIL has strong consensus within some circles, but other circles have barely even started thinking about it - and if we don’t do FOCIL, that has implications for optimal block building)
We need to get to a much clearer collective view on our answers to these questions ASAP. The answers will define both what L1 gaslimits are safe, and what EIPs are most important to prioritize to maximize the gaslimit/decentralization tradeoff curve.