KHYK🦇🔊

Ξ ETH Maxi 🐰
Ethereum Acceleration

[RYAN SΞAN ADAMS @RyanSAdams]

The Ethereum not ETH stuff is the mental fallacy that triggered me into writing and podcasting in the first place.

There is no strong Ethereum without an ETH worth trillions. Without ETH as a global store of value, Ethereum is a failed project. Full stop.

ETH is economic bandwidth for DeFi. It is the only asset maximized for CROPs, fail at high value ETH, fail at CROPs, fail at Ethereum.

Saying you’re bullish Ethereum not ETH is like saying you’re bullish America not the American economy. They are one and the same - economic engines.

Better to admit Ethereum is a failed project than “Ethereum not ETH”.

So spew that weak blockchain not crypto stuff out of your mouth, it doesn’t make sense for BTC, ZEC, ETH, or any truly crypto native project.

[vitalik.eth @VitalikButerin]

Some of my perspective on where the @ethereumfndn is going.

First of all, this is only my own view. The board is not just me, and I have no extra special powers on the board that the other board members do not. @aerugoettinea is the one executing much of this transition. My input has been largely on technical questions. The board is in the process of expanding, and my own power within the org will continue to decrease, which is honestly what I want.

The 2025 era brought many important improvements to EF and its ability to execute. Many issues were resolved, and EF continues to benefit from its improved efficiency and greater focus on concrete goals to this day. And so with those problems resolved, early this year, the largest remaining hole that I perceived was something different nagging at me: I would regularly spot people saying things like "vitalik says these beautiful things about ethereum needing to be decentralized, and have privacy, and be a sanctuary technology, but why do the EF's actions not reflect that?"

Now, you may have been hearing something different. You may not have been sensing a feeling of crisis at all, and maybe were hearing people saying that finally we were taking execution and BD seriously and the main task for us is to keep going that way and be even better and faster. Then probably there is genuine difference between you and me, in what kinds of criticism I take most seriously, and what kinds of critics through their criticism are most able to make me feel pain.

As an analogy, let's briefly switch over to a different domain.

One belief you can have about Google is that it is a success story, and has brought a lot of good to humanity in organizing the world's information. Another belief you can have about Google is that they had a beautiful idealistic beginning, but at some point the corruption of mainstream corporate attitudes seeped in, and they slowly bit by bit completely abandoned the "don't be evil" slogan.

My belief on Google specifically is probably somewhere between the two. BUT, if you had taken me back in time to ~2008, and offered me a button to press to make Google one or two standard deviations more "dogmatic", eg. give Richard Stallman permanent veto power over some key policies, I would immediately press it.

Why? Because a choice for one company is not a choice for the world, or even one country. Google existed and exists in the context of a technology industry generally drifting away from early idealistic don't-be-evil roots and toward greed for financial gain, totalizing visions of accelerated superintelligence, infiltration by sociopaths, and craven capitulation to (or worse, active participation in) government pressure for ideological control, surveillance and war. And so *one company* doing something different, positioning itself to be what George Bernard Shaw calls the Unreasonable Man, resisting the trend of the times, would have been better for freedom, balance of power and stability of society as a whole, than *all* large companies bending to dominant trends. This is a part of my version of pluralism.

This line of thinking is not just mine, but I also is not too far off from what Aya and others had in mind with the Mandate.

Now how does this all get to the role of the EF?

EF is not a "center of Ethereum", rather EF is "one node, with a defined purpose, alongside other nodes". We've always said that the EF should be the latter, but many in the Ethereum ecosystem (and even within the EF) wanted us to be the former. Now, we are taking action to ensure that we will be the latter.

This is particularly important because EF is a limited organization, with limited resources and limited organizational capacity. The EF has only ~0.16% of all ETH (less than many other individual ETH holders), whereas among other blockchains it's common for "the central foundation" to have 10-50%. Fiscally, the EF was originally designed to fulfill a limited work scope defined in the token sale docs and other pre-launch materials (building the chain software; getting through Frontier, Homestead, Metropolis, Serenity), which was fully completed in 2022; it was not designed to be an eternal steward.

And so today, the EF is choosing to use its remaining resources to pursue longevity over breadth (yes, this means we sell less ETH). The EF focuses *specifically* on those activities critical to the success of ethereum as a censorship/capture-resistant, open, private and secure system, that would not happen otherwise. This means making hard choices, and in some cases even activities that we highly approve of and people that we highly respect becoming outside of the EF. People of great technical talent, public respect and even alignment with the mission and CROPS being outside of the EF is in fact necessary if we want important tasks to be able to attract outside capital. This also means the EF taking opinionated stands culturally.

This is all intended in cooperation with all other parts of ethereum. We recognize that many other parts of the ethereum world highly respect CROPS and related values. But highly respecting is not the same as choosing to specialize and totally dedicate to a domain (Compare in a different domain: I think reducing animal cruelty is important, and I like vegan food, but am not full unconditional vegan myself)

EF is still in a transition period, and we expect its new long-term form to stabilize over the next few months. What are the guiding principles of this new form? Again, I am only one person, but I can give my answer from a technical perspective (there are also critical non-technical aspects).

At the core, *Ethereum must be impressive*. We are living in an age of highly intelligent AI and all kinds of other technological acceleration. "Status quo EVM, with a hard fork or two a year to optimize for short-term needs of users" is not interesting.

To some, "impressive" means: 250ms latency and 1M TPS. I think Ethereum trying to go that route is a mistake. Being as fast and as scalable as possible, and only a small epsilon more decentralized than the others, is a route to mediocrity, and if we try it we will lose.

I think Ethereum should scale. But I think Ethereum should strive the hardest to be deeply impressive in a different dimension: the CROPS dimension. This means things like:

* Provably bug-free Ethereum. This is a goal that all cybersecurity researchers would have thought is absurd and impossible, up until roughly 6 months ago. Now, it's on the cusp of being possible, thanks to AI-assisted formal verification. So we should be frontrunners in doing this.

* Available chain consensus. Ethereum is, and with lean consensus will cotninue to be, the ONLY chain that has both (i) traditional-BFT style properties that it's safe under asynchrony up to a high level of fault tolerance, and (ii) the bitcoin PoW-style property that under synchrony it's safe up to 49% attackers. As far as I can tell, literally no other chain has this or is planning for it; bitcoin goes for (ii) only and most other chains go for (i) only. Some will remember I fought hard for this, Unreasonably insisting that it is not OK for ethereum to rely on social consensus and hard forks to rescue ethereum from 34% of nodes going offline. It's OK for chains like hyperledger, bnb, solana, tempo, etc. It's not OK for bitcoin or ethereum or eg. zcash.

* Intermediary minimization. The fact that smart contract wallets, protocols like railgun, etc have to send transactions through intermediaries to get included onchain is honestly embarrassing, and it's a constant point of fragility. Hence the work on FOCIL and EIP-8141 (and 7701 and years of work before) to make transaction sending intermediary-minimized with public mempool and strong inclusion properties, in a truly general-purpose way, that covers not just eg. secp256r1, but also privacy protocols and much more. Kohaku is pushing intermediary minimization at the user layer, pulling Ethereum away from the dystopian status quo world where our wallets don't even verify the chain, send our private data out to a dozen third-party servers, and toward a brighter CROPS future.

Some of these goals are Unreasonable - maybe Ethereum would be "fine" getting only 50% of the way - what if we depend on intermediaries, but make it easy to switch? But going 50% of the way would not make Ethereum Deeply Impressive in the CROPS way. So we push for 100%.

Fortunately all these goals are compatible with high TPS, this is a major focus of research (esp. on scaling the state). Well-designed L2s can also help, especially L2s optimized for specific applications (eg. high-volume trading, privacy...). These goals are even compatible with significantly lower slot times, thanks to Raul's work on erasure-coded P2P, and many other optimizations.

The most high-value "product" of the ethereum blockchain, financially speaking, is ETH the asset. Ethereum secures $250 billion of ETH. The types of properties of Ethereum that I mentioned above are very good for ETH the asset. Nearly 90% of my net worth is in ETH, and most of the remainder is ~$40m of onchain fiat of which every dollar has already been allocated for some open-source biotech or software or hardware initiative. That said, there are aspects of supporting ETH the asset - *necessary* aspects even - that are outside the scope of the EF. This is where we need other heroes (some of whom hold more ETH than the EF does) to step in and help. EF has been recently thinking more about how it will relate to other such organizations, and give them needed initial support.

EF will be a smaller ship than in previous years, a more opinionated one - in some cases more opinionated in ways that might be difficult to comprehend - but a longer-lasting one, and one suited to making sure that ethereum brings something meaningful to the world. We are grateful to all those inside and outside the EF who are helping to make this happen.

[Toni Wahrstätter ⟠ @nero_eth]

Ethereum is about to fundamentally change how blocks are executed. With the upcoming Glamsterdam hardfork, it's shipping EIP-7928: Block-level Access Lists, a proposal that brings parallelization to the EVM.

Here's a short explainer of what it is, how it works, and why it's a big deal for scaling.

Let's start from the top. Alongside EIP-7732 (ePBS), EIP-7928 is the execution-layer (EL) headliner for Glamsterdam. Like ePBS, the main focus has been scaling Ethereum, though both proposals come with a bunch of other, equally important properties on the side e.g. removing trust requirements from the PBS pipeline or improving sync.

EIP-7928 adds a Block Access List (BAL) to every Ethereum block. A BAL is a list of accounts and storage slots that the block touches, but that's not all: it also contains post-transaction state diffs (this part is critical!).

Post-transaction state diffs tell you what the state looks like after each transaction. Quick example: user A swaps 1 ETH for DAI on DEX B. The BAL tells you that user A's ETH balance decreased by 1 ETH + tx fees and their nonce went up by 1; that DEX B's ETH balance went up by 1 ETH; and that inside the DAI contract, user A's DAI balance increased while DEX B's decreased.

In other words, all of that info becomes statically available, something that previously required tracing the transaction.

Client software (Geth, Nethermind, Besu, Erigon, Reth, Ethrex, Nimbus) can use this to do a few very powerful things:

1. Parallelize transaction execution. Knowing the post-state of each tx resolves the dependencies between them. No transaction has to wait on the previous one anymore, so execution can be perfectly parallelized. Instead of large parts of block validation sitting idle waiting on sequential execution, clients can finally make much better use of modern hardware.

2. Batch prefetch. One of the most cumbersome jobs for a node has been fetching the state needed for execution from disk. Because state locations (e.g. the exact storage slot in the DAI contract where user A's balance lives) are only discovered along the way, while executing, state-fetching has been a real drag on scaling: it blocks execution, takes time, and eventually slows everything down. With BALs, everything a node needs for execution is known upfront and can be loaded into cache in one go, in parallel. This speeds things up even further.

3. Parallelize post-state root calculation. Another expensive task is walking the updated state tree to compute the post-state root, which is needed so that everyone agrees on what's on disk after executing the block. With the post-tx state already in the BAL, nodes can do this in parallel while executing. A heavy task that used to wait until all transactions had finished can now run alongside prefetching and execution.

4. Snap sync (v2). An often overlooked, less sexy aspect of blockchains is syncing. Nodes need to catch up with the chain, and they need to catch up faster than the chain progresses. Today, most nodes do snap sync: downloading blocks, headers, and state in parallel while chasing the tip, and then "healing" the database once they're close to the head. Healing means asking peers for trie nodes, receiving them, validating them, and updating the local DB. It's iterative, networking-heavy, can take a while, and especially higher throughput pushes that phase to its limits. BALs help here too: with snap v2, nodes can catch up to the tip and skip the healing phase entirely. Syncing at higher throughput becomes more robust and reliable.

So, to summarize, a BAL contains two things:
-> The state locations the block accesses
-> The state changes after each tx (incl. the new values)
We're already seeing big performance gains today: on 6-core machines, EL clients validate blocks up to 5x faster, making block gas limits of 300M a very realistic outcome. ePBS will add to that by decoupling the block from the payload, giving validators 2-4x more time for execution.

To not overshoot (security stays priority #1), the fork will likely ship with a 200M gas limit, but we shouldn't be stuck there for long before pushing to 300M and beyond. That's a 10x in scaling since we started taking the topic seriously, without touching hardware requirements.

None of this would have happened without people going all-in, heads down, shipping: so many hours spent in calls debating the right design, so many iterations refining the specs, and tons of test cases written (and still being worked on). The road from whiteboard to production-ready code has been a journey, and we're not at the finish line yet, but from what I can tell, things look super bullish for Ethereum.

Glamsterdam will be a fork that shows what's possible when a distributed, decentralized community works on a shared goal, laser-focused on providing enough block space to onboard the next wave of users.

[Pudgy Penguins @pudgypenguins]

We’re excited to announce that Pudgy World, our free to play browser-based game, is now live.

Explore 12 unique towns across The Berg, help Pengu find Polly, and play mini-games, all on @PudgyWorld_.

Play now: https://t.co/x7lkMt8Rre

[vitalik.eth @VitalikButerin]

This is quite an impressive experiment. Vibe-coding the entire 2030 roadmap within weeks.

Obviously such a thing built in two weeks without even having the EIPs has massive caveats: almost certainly lots of critical bugs, and probably in some cases "stub" versions of a thing where the AI did not even try making the full version. But six months ago, even this was far outside the realm of possibility, and what matters is where the trend is going.

AI is massively accelerating coding (yesterday, I tried agentic-coding an equivalent of my blog software, and finished within an hour, and that was using gpt-oss:20b running on my laptop (!!!!), kimi-2.5 would have probably just one-shotted it).

But probably, the right way to use it, is to take half the gains from AI in speed, and half the gains in security: generate more test-cases, formally verify everything, make more multi-implementations of things.

A collaborator of the @leanethereum effort managed to AI-code a machine-verifiable proof of one of the most complex theorems that STARKs rely on for security.

A core tenet of @leanethereum is to formally verify everything, and AI is greatly accelerating our ability to do that. Aside from formal verification, simply being able to generate a much larger body of test cases is also important.

Do not assume that you'll be able to put in a single prompt and get a highly-secure version out anytime soon; there WILL be lots of wrestling with bugs and inconsistencies between implementations. But even that wrestling can happen 5x faster and 10x more thoroughly.

People should be open to the possibility (not certainty! possibility) that the Ethereum roadmap will finish much faster than people expect, at a much higher standard of security than people expect.

On the security side, I personally am excited about the possibility that bug-free code, long considered an idealistic delusion, will finally become first possible and then a basic expectation. If we care about trustlessness, this is a necessary piece of the puzzle. Total security is impossible because ultimately total security means exact correspondence between lines of code and contents of your mind, which is many terabytes (see https://t.co/boM9vZs3dh ). But there are many specific cases, where specific security claims can be made and verified, that cut out >99% of the negative consequences that might come from the code being broken.

[YQ @yq_acc]

Two weeks ago I made a bet with @VitalikButerin that one person could agentic-code an @ethereum client targeting 2030+ roadmap. So I built ETH2030 (https://t.co/2k83PyUP4z | https://t.co/P0A6aHDZBX).

702K lines of Go. 65 roadmap items. Syncs with mainnet. Here's what I found.

[YQ @yq_acc]

https://t.co/iPl6IG3cHa

[Tomasz K. Stańczak @tkstanczak]

5 Steps to Make Ethereum Driven by LLMs
1/ Validator operators delegate to agents the decision-making on accepting/rejecting network upgrades and setting the parameters.
2/ EIP authors use LLMs to create and submit EIPs.
3/ EIP editors use LLMs to review and approve EIPs.
4/ All Core Devs use LLMs to moderate meetings and vote on EIP inclusion and spec changes.
5/ Client teams generate codebases from specs.
It is important for Ethereum to be the first chain to be LLM-driven; it is an advantage akin to being the first PoW chain. Ethereum has a natural advantage because it already has an existing spec that LLMs were trained on, and a very transparent governance process that LLMs can be trained on (all past ACD calls, EIP processes, open discussions) and participate in.

The EF recently hired tooling coordinators and established a dAI team. Between ACD moderators, tooling coordinators, Ethereum Cat Herders, EIP editors, and the dAI team, there should be a high-priority process on:
1/ Ensuring that agentic participation in the EIP submission process is simple and functional.
2/ EIP editors have tooling for AI review of all EIPs.
3/ There is AI support for real-time ACD moderation (connected to chat, analyzing the discussion content in real time, and making suggestions).
4/ Expanding https://t.co/gwjaDMpEGV over time to be a real-time, listener-context-aware broadcast of the Ethereum governance process.
5/ Establish a cross-client team of core devs that would work on an AI-generated client codebase driven by specs only. Such a client should be fully formally verified, test-covered, and developed in parallel to other codebases until it becomes a canonical client codebase.

[vitalik.eth @VitalikButerin]

Hyper-scaling Ethereum state by creating new forms of state:

https://t.co/7nL9qOQqxO

Summary:

* We want 1000x scale on Ethereum L1. We roughly know how to do this for execution and data. But scaling state is fundamentally harder.
* The most practical path for Ethereum may actually be to scale existing state only a medium amount, and at the same time introduce newer forms of state that would be extremely cheap but also more restrictive in how you can use them.
* In such a design, the present-day state tree would over time become dominated by user accounts, defi hub contracts, code, and other high-value objects, while all kinds of individual per-user state objects (eg. ERC20s balances, NFTs, CDPs) would be handled with cheaper but more restrictive tools. Making the developer abstractions to make this easy to implement for the use cases that make up >90% of state today seems very doable.

[sassal.eth/acc 🦇🔊 @sassal0x]

It's done - the Ethereum L1 gas limit is now 60 million!

Onwards to even greater increases in 2026 - let's aim for at least a 3x to 180 million!

[sassal.eth/acc 🦇🔊 @sassal0x]

The Ethereum gas limit is creeping up - next stop, 60 million!

[Justin Drake @drakefjustin]

Craaazy 365 days of @leanEthereum progress. Cheers to the builders. Cheers to the dreamers. Cheers to anti-fragility, too :)

Devcon, Bangkok — Nov 12, 2024. The suspense is real. The room overflows; hundreds can't get in. An "announcement of an announcement" had sparked wild speculation about my "most ambitious initiative".

Who knew the beam chain vision would evolve into lean Ethereum? Next-level ambition, seeping into all layers of L1. Snarks for consensus and execution. Fort mode and beast mode.

What's new? zkEVMs. Real-time proving. Full validation in a tab, on a phone. Let's pump L1 gas with the exponential snark curve. Starting in months, not years. To me it all points to 10K TPS, the gigagas frontier.

Dream bigger dreams for L1. Believe in something.

———

part 1—lean consensus

devnets

→ clients: 4 new lean CL clients (Zeam, Ream, Qlean, Lantern)
→ languages: 3 new CL languages (Zig, C++, C)
→ specs: by @tcoratger + 14 others; 3SF-mini subspec by @vitalikbuterin
→ testing: revamped test framework by @fselmo2; @Sib_Katya metrics
→ devnets: multi-client 3SF with 4s slots and 12s finality; PQ soon™

coordination

→ hires: EF Protocol coordinators @corcoranwill and @ladislaus0x
→ CL teams: led by @Gajpower, @unnawut, @kamil_abiy, @mstore80
→ 7 consensus calls: teams, PQ, p2p, exit queue, APS, 3SF, PQ specs
→ Cannes workshop: 1 day at EthCC in June; interop kicked off
→ 13 interop calls: by @corcoranwill on Wednesdays at 2pm UTC
→ Cambridge Oct workshops: 1 day leanVM, 3 days PQ, 3 days CL

cryptography

→ leanSig: 3 papers on hash sigs by Benedikt, @khovr, @kudinov_mikhail
→ leanVM: fast minimal aggregation zkVM by Emile
→ WHIR: fast Plonky3 implementation by @tcoratger
→ optimisoors: @AngusGruen, @GiacomoFenzi, @lambdaclass, @kiliconu
→ Poseidon2: 4 cryptanalysis workshops by @khovr, @asanso
→ maths: $1M Millennium-like proximity prize; papers flowing
→ formal verification: ArkLib by @QuangVDao

research

→ consensus team: hires @yannvon and lead @robsaltini join @luca_zanolini
→ faster finality: 1- or 2-round designs with Ethereum-grade liveness
→ 3sf-gold: new fast inclusion by @fradamt, @vitalikbuterin from Cambridge
→ p2p: @qdrvm_io simulator; @raulvk ethp2p; @soispoke leanp2p
→ rainbow staking: new Cambridge ideas; specs by Dan Goron & Alex Vlad

———

part 2—lean execution

zkEVM tech

→ real-time proving: ~100 engineers pushing across ~10 zkVM teams
→ GPU proving: 16 5090s (10kW) proving mainnet; $0.01/block
→ guests: revm (Reth), levm (Ethrex), evmone (Zilkworm), ZKSync OS
→ more guest programs: Geth, Besu, Nethermind and others soon™
→ RISC-V: de facto ISA of choice for zkEVM proving
→ Picus: prolific Veridise tool to identify under-constraints
→ formal verification: $4M across 40 grants by @alexanderlhicks

Ethproofs community

→ zkVM integrations: Airbender, OpenVM, Pico, R0VM, SP1, Ziren, ZisK
→ other integrations: Cysic, Fermah, Marlin, Snarkify, Zilkworm, ZkCloud
→ website: driven by @fbwoolf under new EF Ethproofs team
→ 7 calls: zkVMs, RTP, gigagas, RISC-V, native rollups, proximity gaps
→ Ethproofs day: Nov 22 at Devconnect; register at ethproofs[.]day
→ zkAttester demo: my home validator on zkEVM proofs at Ethproofs day

EF zkEVM team

→ new team: led by @kevaundray with Cody, Han, Ignacio, Radek, Sophia
→ EF blog post: real-time proving requirements by @_sophiagold_
→ zkLighthouse: modified Lighthouse client by @kevaundray
→ zkEVM/acc: @ignaciohagopian benchmarks; @codytouchgrass tests
→ more zkEVM/acc: @kevaundray standardisation; Ere by @han__0110

future of EL

→ Fusaka: per-tx gas limit (EIP 7825); MODEXP killer (EIPs 7823, 7883)
→ EVM 2.0: @vitalikbuterin proposal to enshrine RISC-V under the EVM
→ native rollups: championed by @lucadonnoh; wrote book and draft EIP
→ gas auto-pumps: 3x/year gas pumps (EIP-7938 by @dankrad)
→ gigagas L1: champion wanted—reach out :) [email protected]

[sassal.eth/acc 🦇🔊 @sassal0x]

It looks like Ethereum client defaults will be set to a 60 million gas limit *before* Fusaka goes live in early December.

This would be a ~33% increase from the current 45 million gas limit.

Bullish Ethereum L1 scaling!

[sassal.eth/acc 🦇🔊 @sassal0x]

I know I'm going to get heat for this, but I'm most excited about the crypto ecosystem breaking away from being Bitcoin-centric and moving into a paradigm of being Ethereum-centric.

Bitcoin is dead weight - it does nothing and doesn't push this industry forward - in fact, it actively holds the industry back. It becomes less secure and more centralized over time with both quantum computing and security budget issues being critical systemic risks.

On the other hand, Ethereum is a breeding ground for innovation and radical new ideas that have disrupted and will continue to disrupt finance and other industries. The Ethereum ecosystem meets any and all challenges heads on and, while it can be a slow moving beast, it can reprioritize its focus when needed.

Ethereum is about looking forward - it's about building a better future - it's about upholding the cypherpunk vision and ethos. We aren't just content with how things are - we want to make the world a better and more fair place.

I'll keep fighting until ETH flips BTC and becomes the flag bearer of this industry - then I'll keep fighting to ensure Ethereum stays decentralized while becoming the backbone of the global financial system.

[Justin Drake @drakefjustin]

Yesterday Ethereum turned 10. Today, lean Ethereum is unveiled as a vision—and personal mission—for the next 10 years.

We stand at the dawn of a new era. Millions of TPS. Quantum adversaries. How does Ethereum marry extreme performance with uncompromising security and decentralization?

TLDR: next-generation cryptography is central to winning both offense and defense.

Disclaimer: This is a Drake take™ aimed at a broad audience. A technical deep dive into hash-based post-quantum signatures and SNARKs will follow. A healthy diversity of views across Protocol, the EF, and the broader Ethereum community is expected and welcome. It strengthens us.

defense—fort mode

Ethereum is special. 100% uptime since genesis. Unrivaled client diversity. $130B in economic security (35.7M ETH staked × $3.7K)—maybe soon $1T.

Ethereum is poised to become the bedrock of the internet of value, securing hundreds of trillions over decades, even centuries.

Ethereum must survive anything: nation states, quantum computers. Whatever comes. Call it fort mode. If the internet is up, Ethereum is up. If the world is online, the world is onchain.

offense—beast mode

Ethereum is hungry. “Scale L1, scale blobs” is a strategic urgency inside the EF’s Protocol cluster. Expect low-hanging performance gains over the next 6–12 months.

Longer term? Think gigagas L1, teragas L2. Call it beast mode.

→ 1 gigagas/sec on L1: 10K TPS, ambitious vertical scale
→ 1 teragas/sec on L2: 1M TPS, sprawling horizontal scale

Scale vs decentralization? Why not both. The moon math we need is now tamed:

→ real-time zkVMs for lean execution
→ data availability sampling (DAS) for lean data

A delicious cherry on top: full chain verification across every browser, wallet, phone.

lean upgrades

Lean Ethereum proposes bold upgrades across all three L1 sublayers:

→ lean consensus is beacon chain 2.0: hardened for ultimate security and decentralization, plus finality in seconds; formerly branded as “beam chain”
→ lean data is blobs 2.0: post-quantum blobs, plus granular blob sizing for a calldata-like developer experience
→ lean execution is EVM 2.0: a minimal, SNARK-friendly instruction set (possibly RISC-V; pronounced “risk five”), boosting performance while preserving EVM compatibility and its network effects

The consensus layer (CL), data layer (DL), execution layer (EL) have each been reimagined from first principles. Together, they unlock fort mode and beast mode.

The goal: performance abundance under the constraint of non-negotiable continuity, maximum hardness, and refreshing simplicity.

lean cryptography

Hash-based cryptography is emerging as the ideal foundation for lean Ethereum. It offers a compelling, unified answer to two megatrends reshaping the ecosystem:

→ the explosive rise of SNARKs
→ the looming quantum threat

Imagine the leanest cryptographic brick—the hash function—singlehandedly powering L1:

→ CL: hash-based aggregate signatures upgrade BLS signatures
→ DL: hash-based DAS commitments upgrade KZG commitments
→ EL: hash-based real-time zkVMs upgrade EVM re-execution

A cryptographic jewel in each of lean CL, lean DL, lean EL.

lean craft

Lean Ethereum is more than a blueprint for hardening and scaling Ethereum. More than just doubling down on security, decentralisation, and cutting-edge cryptography. It is an aesthetic. An art form. A craft. Think Jiro in Dreams of Sushi. When we can go the extra mile, we do.

Minimalism. Modularity. Encapsulated complexity. Formal verification. Provable security. Provable optimality. These are subtle yet important technical considerations. Stay tuned for the post on post-quantum cryptography that will make them explicit.

lean legacy

After 10 fantastic years, lean Ethereum is a generational oath. To keep Ethereum online no matter what. To scale it without compromise. To make it worthy of those who come next.

This is about legacy. We are builders, we are missionaries. We are Ethereum. I hope you join us.

[Ethereum Foundation @ethereumfndn]

Ethereum’s 10 Year Anniversary Celebration
https://t.co/huLK5kleM0

[Ethereum @ethereum]

0/ 11 years ago, the Ethereum Whitepaper outlined the vision, purpose, and technical design of Ethereum.

[sassal.eth/acc 🦇🔊 @sassal0x]

The Ethereum L1 gas limit has now been increased to 45 million (up from 36 million).

Next up is an increase to 60 million.

Accelerate!

[terence @terencechain]

45M block has arrived 🚀

[Ethereum @ethereum]

0/ The Ethereum Torch is now lit.

The Torch is an NFT honoring the people and values that have shaped Ethereum’s first decade and will help build its future.

It will be symbolically passed from wallet to wallet in the 10 days leading up to Ethereum’s 10 year anniversary.