Ethereum should be much faster. A faster Ethereum is better for both Ethereum and ETH. Many discussions in our offsite revolved around what I’d call fast Ethereum. We’ve already mentioned fast Ethereum in some of our updates, and I wanted to share a few notes on motivations, principles and concrete work. --- Ethereum is the hardest credible settlement layer in the world, with hundreds of billions of dollars of assets attached to it. Its speed matters to onboard the global economy: payments, swaps, credit, all at the speed of the Internet. Fast Ethereum is about making our network move at the pace of users, agents and assets, between L1 and Ethereum’s growth engines, its L2s. Fast Ethereum is about latency, about friction, about capital cost and about delightful experiences. Every second spent waiting for confirmation, or every minute capital sits idle between domains, or every minute that an asset issuer waits for settlement is friction imposed on the people and businesses using the network. We think Ethereum can remove much of that friction without compromising the properties that make it valuable in the first place. This unlocks value that all users receive from Ethereum and its applications, in particular financial applications that are powered by natively onchain assets. Bottom line: greater user value increases network value through network effects, increasing the value of the Ethereum platform and ETH the asset. --- This informs some of the principles behind Fast Ethereum. → Security is non-negotiable. Safely operating onchain is the base of the pyramid of user needs. Clear signing was for instance number 1 user priority for a long time. Latency reductions cannot come at the cost of increased user risk. → Fast Ethereum 🤝 lean Ethereum. Lower in the stack, the Ethereum protocol’s value to the world is its hardness. lean Ethereum is a broad effort to upgrade Ethereum’s protocol for a new age driven by formal verification and cryptographic innovation. Fast Ethereum works to complement lean Ethereum with a strong focus on protocol design and performance engineering for a faster network. → User value is at the centre of fast Ethereum. This is not about showing better headline numbers than other chains and platforms. As long as the network remains at the security level that all have come to expect from Ethereum, speed improves everything on our network, on our own terms: fewer clicks to get what you want, less time spent waiting for an action to terminate, less idle capital blocked by settlement, better prices, lower costs, less intermediation and more open markets. --- So how do we do this? Ethlabs is already active on multiple fronts, some shorter term, some longer term, some iterative, some transformative. No single upgrade will fix everything. But fixes compound with each other, each new fix unlocking more and more value over time. We’re in it for the long haul, as are core developers and builders working on these issues. The main deliveries we’re currently active on: fast blocks, fast finality, fast confirmation rule and fast interoperability. → Fast blocks is Mainnet’s block time, set today to 12 seconds. Faster blocks improve UX, onchain markets and liquidity, censorship resistance and finality itself. Block time is hard-coded to 12 seconds in many places, and removing this dependency is the first step. I proposed kicking off slot time decreases in Hegotá, with a one-time refactor to remove the hard-coded 12 seconds, and a first decrease from 12 to 10 seconds. → Fast finality is faster settlement of Ethereum, backed by the strongest assurances of any network. Faster finality reduces the time and the cost for capital to flow, between Mainnet, L2s and the broader economy. A first major improvement to finality is developed by @fradamt, EF Protocol and Consensys TX/RX, towards inclusion in I* (the fork following Hegotá), bringing time-to-finality down from a quarter of an hour to a couple minutes. → The Fast Confirmation Rule (FCR) is faster settlement in the order of tens of seconds we can deliver today, for many use cases that don’t require the economic security of full finality, speeding up deposits from L1 to other domains. FCR is provably secure under formally explicit conditions in ways that other confirmation rules (such as waiting for some number of blocks) are not. These less secure rules are currently in use by some centralised exchanges, bridges and L2s, and they also happen to be usually much slower than what FCR achieves. FCR is close to production in all major Ethereum clients, and our team @_julianma @decentrek and @ox_shaman is actively working on its go-to-market. A major bridge has recently committed to offering FCR to its customers, as @decentrek noted in his last update! → Fast interoperability is about the free flow of all assets on our network, offering asset issuers the foundations of a robust stack powered by Ethereum. Each of the previous items enhances interop speed in its own right. Beyond these compounding gains, a concerted move to real-time zk proving is a different tier of unlock: bridge flows from L2s to L1 remain slow, either due to the long challenge period of optimistic rollups, usually set to 7 days, or due to infrequent settlement of zk-rollups to L1, given the opportunity of amortising costs in batches. With zk becoming a commodity, we must ensure our ecosystem is ready to plug in to this new basic utility in order to reduce latency and improve security at scale. We also remain active on broader interoperability UX questions, having worked on fast liquidity from intent-based bridges and execution standards such as ERC-8211. --- To wrap up, we’re currently interested in two engagements from the community: 1. Hegotá priorities are currently debated for the next few weeks. We’ve already given our view as Ethlabs, ranking faster blocks as our S-tier choice: ethlabs.org/writings/hegota-… Continuing to express public support for faster blocks, as users, builders or core developers is a critical signal to ensure block time is reduced asap. Hegotá is possibly the last window to get started for a few years—let’s not miss it. 2. As go-to-market for the fast confirmation rule continues, we’re reaching out to L2s, bridges, RPCs and centralised exchanges for integration. If your product relies on some form of confirmation from Ethereum L1, we think a conversation would be valuable. Please reach out to @_julianma 🙂 Let’s grow Ethereum and ETH with a faster Ethereum.

Aug 26, 2026 · 11:28 AM UTC

29
54
295
45,716
Sort replies: Relevant Recent Liked
Replying to @barnabemonnot
re zkEVM proving overhead concerns, i wonder if there is some design space where slots are fast e.g. 2 seconds but proving only happens every few slots, e.g. 6 slots (12s). it'd be some sort of delayed execution right? re-executing nodes can still provide state updates every 2s
1
9
551
Yes that would be delayed execution. I'd say the design space here is relatively under-explored, I was more bullish 7886 rather than ePBS for Glamsterdam because it was a much better setup to move to async execution. Though there are also complications with native AA.. This would stratify the chain in three parts: unproven-available, proven-available, proven-finalised. Each chain prefix is relevant for certain categories of nodes, unproven-available can still issue confirmations from re-executing nodes, proven-available can offer fast light clients based on the availability committee (particularly post-decoupled consensus) and proven-finalised is obviously the hardest, most onchain- and offchain-actionable confirmation (particularly post-leanVM with succinct proofs of finality).
5
275
Replying to @barnabemonnot
We need faster Ethereum
7
409
Replying to @barnabemonnot
Faster [Ethereum] is better [UX]
4
262
Replying to @barnabemonnot
faster forks?
1
283
Replying to @barnabemonnot
10s is a solid start but we really need that sub 1s dream for true speed
1
226
Replying to @barnabemonnot
We need faster Ethereum ,@EthLabsCommu always support
2
Replying to @barnabemonnot
latency budget is the part im watching most here
21
Replying to @barnabemonnot
That is exactly why L2's like Linea matter.
133
Replying to @barnabemonnot
10s is a start but lets aim for sub 5s eventually
263
Replying to @barnabemonnot
How will a worldwide network of home operaters be able to sync up that fast? It feels like we'd be sacrificing something. Also the list of commies here in the comment section cheering doesn't offer much comfort.
36
> Fast Ethereum 🤝 lean Ethereum this is the gwei
11
358
Replying to @barnabemonnot
Yes please! I would love to see a 2 second reduction each hard fork until we reach 2 seconds
1
117
Replying to @barnabemonnot
@andrewdsouza I know people on L2, bridge, RPC and exchange teams who’d care about faster confirmations. Happy to connect the right ones to Ethlabs. nitter.net/messages/compose?recip…

162
Replying to @barnabemonnot
make ETHereum block times 1s
1
1
69
Replying to @barnabemonnot
Won't faster slot times make real time proving harder?
1
154
Replying to @barnabemonnot
Also help eth memes 🦖@YeeErc20
20
⤴️ Not everyone will understand
40
Replying to @barnabemonnot
10s is a start but lets aim for sub 1s eventually. Need that speed
181
Replying to @barnabemonnot
Hard to argue with this. Speed is the one thing users actually feel.
102
Replying to @barnabemonnot
Till then, get more on @megaeth ?
1
Replying to @barnabemonnot
Why do the French ETH heads have the worst ideas?
7
Replying to @barnabemonnot
Still trying to catch up with #XRP?
29