Olivia
Online
adamnk.eth
@adamnk_eth
Joined March 2021
107 Following
72 Followers
515 Posts
New EIP-8272: Recent Roots for Frame Transactions
by @soispoke, @nero_eth and @VitalikButerin
Another EIP to enable native, trustless, censorship-resistant privacy on Ethereum.
tldr: Private transactions on Ethereum often need to prove against a recent commitment tree root. This EIP lets a FrameTx carry that root directly in its signed envelope.
The protocol checks that the root was written onchain for the referenced slot and is still inside the usable window. This means validation can use the root without reading arbitrary application storage.
The goal is to help private transactions get FOCIL inclusion guarantees by making recent roots part of the partial state attesters will store after the transition to zkEVM.
Target fork: Hegota
Links below 👇
If we ship FOCIL (EIP-7805), Frame Transactions (EIP-8141), Keyed Nonces (EIP-8250) and Recent Roots (EIP-8272) in Hegota, we get native, trustless, censorship resistant private transactions on Ethereum next year.
.@kassandraETH @ncsgy and others have been working hard for nearly a year on Kohaku.
Kohaku's goal is to make two twin properties:
* Security (and trustlessness)
* Privacy (read and write)
a reality on the access layer.
Security and privacy on Ethereum must be normal.
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.
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.
Getting increasingly bullish on just vibe-coding the important things in Lean.
eg. see:
https://t.co/YOdVyJMNAv
https://t.co/XbDCD0BCEu
Life pro tip: You can now disable Shorts in the YouTube app
Go to settings (the top right gear icon) —> time management —> daily limits —> shorts feed limit —> select 0 minutes.
Boom. Shorts gone.
Hallelujah. Nature has healed. 🙏🏼
@emilykschrader So exposing a global child sex trafficking ring is now antisemitic? Gotcha.
https://t.co/TNX86qUYLw
Today marks an inflection in the Ethereum Foundation's long-term quantum strategy.
We've formed a new Post Quantum (PQ) team, led by the brilliant Thomas Coratger (@tcoratger). Joining him is Emile, one of the world-class talents behind leanVM. leanVM is the cryptographic cornerstone of our entire post-quantum strategy.
After years of quiet R&D, EF management has officially declared PQ security a top strategic priority. Our journey began in 2019, with the "Eth3.0 Quantum Security" presentation at StarkWare Sessions. Since 2024, PQ has been central to the @leanEthereum vision. The pace of PQ engineering breakthroughs since then has been nothing short of phenomenal.
It's now 2026, timelines are accelerating. Time to go full PQ:
→ PQ ACD: Antonio Sanso (@asanso) kicks off a bi-weekly All Core Devs PQ transactions breakout call next month. These sessions focus on user-facing security, covering dedicated precompiles, account abstraction, and longer-term transaction signature aggregation with leanVM.
→ PQ foundations: Today we are announcing a $1M Poseidon Prize to harden the Poseidon hash function. We are betting big on hash-based cryptography to enjoy the strongest and leanest cryptographic foundations. Check out our other $1M PQ initiative, the Proximity Prize.
→ PQ devnets: Multi-client PQ consensus devnets are live! Shoutout to pioneers @zeamETH, @ReamLabs, @PierTwo_com, @geanclient, @ethlambda_lean, as well as established consensus teams Lighthouse, Grandine, and soon Prysm. This incredible teamwork is coordinated by @corcoranwill via weekly PQ interop calls.
→ PQ workshops: Building on last year's PQ workshop in Cambridge (see photo), the EF is hosting another 3-day PQ event in October. Top experts from around the world will convene. In addition, a PQ day is set for March 29 in Cannes just ahead of EthCC.
→ PQ FV and AI: Last week Alex Hicks (@alexanderlhicks) ran a specialised maths AI for 8 hours, at a $200 cost. It one-shotted a formal proof one of the hardest lemmas in the foundations of hash-based snarks. Mind-blowing. Applied cryptography will never be the same.
→ PQ roadmap: A comprehensive breakdown of the EF's proposed PQ strategy will be shared soon™ on pq[.]ethereum[.]org. The roadmap targets a full transition in coming years with zero loss of funds and zero downtime. Stay tuned :)
→ PQ education: The ZKPodcast (@zeroknowledgefm) is producing a 6-part video series on Ethereum's PQ strategy. EF Enterprise Acceleration is also preparing material for enterprises and nation-states. Finally, Ethereum is now represented on the PQ advisory board that Coinbase announced yesterday.
Believe in something. Believe in PQ security.
Final numbers are in: In 2025, we prevented 27,385,000 kg of trash from reaching the ocean, making it our most impactful year yet.
Stay tuned for our progress in 2026, as we scale up through our 30 Cities Program.
I'm definitely more in favor of native rollups than before.
Before a big reason why I was against, is that a native rollup precompile must either be used in "zk mode" or in "optimistic mode", and ZK-EVMs were too immature for ZK mode, and so if we give L2s the choices "have 2-7 day withdrawal time with proofs backed by ethereum's full faith and credit" vs "instant withdrawals but you're on your own for proofs", they'll pick the former, and that's really bad for ethereum's composability, we'll see even more multisig bridges adopted, etc etc.
But now it looks like the timelines for ethereum being fully comfortable embracing ZK at L1, and the realistic timeline for adding a native rollup precompile, actually match up. So, problem solved.
Additionally, I'm seeing more work embracing synchronous composability as a core value proposition of "why do an L2" (I've suggested https://t.co/9jy6v1X6Fw as one approach for combining based rollups with L2 preconf low-latency).
So it feels like the right direction to move towards.
I do think we should be non-lazy and spend more effort figuring out the right way to do this precompile. A key property I want is, if you make an "EVM + a few features" rollup, then you should be able to use the native rollup precompile for the EVM, and bring your own prover that operates over just your new features. Perhaps use a lookup table to glue the two together in a standardized way.
Now that ZKEVMs are at alpha stage (production-quality performance, remaining work is safety) and PeerDAS is live on mainnet, it's time to talk more about what this combination means for Ethereum.
These are not minor improvements; they are shifting Ethereum into being a fundamentally new and more powerful kind of decentralized network.
To see why, let's look at the two major types of p2p network so far:
BitTorrent (2000): huge total bandwidth, highly decentralized, no consensus
Bitcoin (2009): highly decentralized, consensus, but low bandwidth - because it’s not “distributed” in the sense of work being split up, it’s *replicated*
Now, Ethereum with PeerDAS (2025) and ZK-EVMs (expect small portions of the network using it in 2026), we get: decentralized, consensus and high bandwidth
The trilemma has been solved - not on paper, but with live running code, of which one half (data availability sampling) is *on mainnet today*, and the other half (ZK-EVMs) is *production-quality on performance today* - safety is what remains.
This was a 10-year journey (see the first commit of my original post on DAS here: https://t.co/Fa0jKFgObW , and ZK-EVM attempts started in ~2020), but it's finally here.
Over the next ~4 years, expect to see the full extent of this vision roll out:
* In 2026, large non-ZKEVM-dependent gas limit increases due to BALs and ePBS, and we'll see the first opportunities to run a ZKEVM node
* In 2026-28, gas repricings, changes to state structure, exec payload going into blobs, and other adjustments to make higher gas limits safe
* In 2027-30, large further gas limit increases, as ZKEVM becomes the primary way to validate blocks on the network
A third piece of this is distributed block building.
A long-term ideal holy grail is to get to a future where the full block is *never* constituted in one single place. This will not be necessary for a long time, but IMO it is worth striving for us at least have the capability to do that.
Even before that point, we want the meaningful authority in block building to be as distributed as possible. This can be done either in-protocol (eg. maybe we figure out how to expand FOCIL to make it a primary channel for txs), or out-of-protocol with distributed builder marketplaces. This reduces risk of centralized interference with real-time transaction inclusion, AND it creates a better environment for geographical fairness.
Onward.
How do we scale the ETHEREUM L1 10x ??
🚨 Part 1: Block-Level Access Lists (EIP-7928)
(0:00) Intro to BALS
(0:34) How @ethereum L1 works now
(2:49) Parallel IO + Parallel EVM
(4:18) Modification in Block Structure
Like & RT for Ethereum
> Crypto is building toward human empowerment, as it has been since the beginning
"Empowerment" was the code of the philosophy of the Pirate Party, before crypto even existed.
JPM’s money market fund is on Ethereum
JPM’s tokenized deposits are on Base, an Ethereum L2
The financial system is quickly moving onto secure global public infrastructure. Ticker is $ETH.
We're hiring on the @ethereumfndn Enterprise team
→ Enterprise Lead - US (East Coast)
→ Enterprise Lead - APAC
We're looking for a key connector between traditional finance and the Ethereum ecosystem. Someone who can serve as the go-to point of contact for enterprises wanting to engage with Ethereum in the region.
Apply 👇
Most Popular Users
Elon Musk 
@elonmusk
240.2M followers
Barack Obama
@barackobama
119.3M followers
Donald J. Trump
@realdonaldtrump
111.6M followers
Cristiano Ronaldo
@cristiano
109.3M followers
Narendra Modi
@narendramodi
106.9M followers
Rihanna
@rihanna
97.4M followers
NASA
@nasa
92.1M followers
Justin Bieber
@justinbieber
90.6M followers
KATY PERRY
@katyperry
87M followers
Taylor Swift
@taylorswift13
80.8M followers
Lady Gaga
@ladygaga
72.4M followers
Kim Kardashian
@kimkardashian
69.5M followers
Virat Kohli
@imvkohli
68.9M followers
YouTube
@youtube
68.6M followers
Bill Gates
@billgates
63.5M followers
The Ellen Show
@theellenshow
62.5M followers
CNN
@cnn
61.9M followers
Neymar Jr
@neymarjr
61.5M followers
X
@x
60.9M followers
Selena Gomez
@selenagomez
60.1M followers