[AMA] We are EF Protocol (Pt. 15: 16 September, 2026)
NOTICE: This AMA is now closed! Thanks to everyone for participating, and see you for the next one.
---
Members of the Protocol Cluster at Ethereum Foundation are back to answer your questions throughout the day! This is their 15thAMA. There are a lot of members taking part, so keep the questions coming, and enjoy!
Oh! And to make it easier for us to respond to everyone, please post just one question per comment.
Setting the mechanism aside, does EF Protocol consider an unbounded staking ratio a problem for Ethereum, and is there a level at which it would become urgent? I hold ETH and do not stake it. The current curve pays a positive yield at every ratio, the ratio is about 35% today and the entry queue is over a month long, so I would like to know whether the cluster sees a problem at all, or only a venue question.
does EF Protocol consider an unbounded staking ratio a problem
The following is my opinion, not an official EF Protocol take :)
I do see current staking incentives as problematic, unsustainable so. Regardless of total stake, Ethereum prints ETH to guarantee stakers at least 1.5%/year nominal yield. There is no market-driven backpressure, no price discovery driving the staking yield towards the organic cost of money.
In six years of proof-of-stake we have accumulated 43.2M ETH stake, about one third of the supply. It's economic quicksand. Year after year, increasing amounts of ETH held by rational actors is sucked down the staking pit. Net staking inflows have held surprisingly steady, at roughly 20K ETH/day.
As far as I can tell no defi application can plausibly compete in size with the 1.5%+/year subsidy: the opportunity cost of money simply isn't that high. This imbalance should continue pulling staking inflows. I expect we'll blow past 50% of the supply staked by decade end. Such high staking ratios are unhealthy for a number of reasons detailed below.
erosion of optionality: Dilution is a transfer from non-stakers to stakers. So as the staked share grows, abstaining from staking gets more expensive and staking gradually shifts from an option to a rational imperative. This is especially detrimental with smaller stakers that can't afford the 32 ETH minimum deposit to stake natively. Those are naturally funnelled to staking pools like exchanges and LSTs.
processed ETH: The staking industrial complex can be viewed as a machine turning pristine ETH into processed ETH. This processed ETH is of a lower grade, encumbered by counterparty risk, governance risk, smart contract risk. It creates fragmentation (stETH, rETH, cbETH) which erodes network effects for ETH as a unit of account and a unit of collateral. Large pools of processed ETH also bear systemic risks. Lido is a $23B pool backed by a $280M governance token, the kind of concentration that made The DAO systemic.
stakefi crowds defi: Collateral-intensive defi products, like decentralised stablecoins, can't compete with 1.5%/year. Stakefi, i.e. the subset of defi pertaining to the tokenisation and distribution of staking yield, is sucking up the air for broader defi innovation. Things like LST looping, i.e. the leveraged extraction of staking yield, are symptomatic of an Ethereum-native Cantillon effect and distorted incentives.
special interests: Cantillon effects breed lobbies. Similar to the banking world, those lobbies form to defend special interests. The ETH holderbase foots the bill despite stakefi being a cottage industry with a combined marketcap less than 1% of ETH's marketcap.
tax drag: In various jurisdictions staking is taxed as income. For example, in the UK I pay 50% income tax on my staking rewards. While it's impossible to precisely measure income tax across stakers, estimating a double-digit percentage blended tax burden seems reasonable. For the sake of argument, call it 20%. That's hundreds of millions of dollars of yearly sell pressure from unnecessarily high staking yields, potentially billions per year should ETH surge.
too-big-to-slash: Proof-of-stake enjoys social slashing as a powerful deterrent from 51% attacks. A high-stake environment erodes the credibility of this last-resort recovery mechanism because of too-big-to-slash dynamics.
unbounded staking ratio a problem
Today's unbounded staking is a Moloch trap for stakers. When total stake is low there's an incentive to join early, but as more stake accumulates the diluted yield tends to zero. Eventually the nominal yield loses it's meaning, and externalities like like taxes flip the whole staking game into a lose-lose situation.
is there a level at which it would become urgent?
Unlike the switch to post-quantum cryptography, changing the issuance curve is not urgent to Ethereum's survival. I do however believe fixing issuance is necessary for Ethereum and ETH to thrive. IMO the current issuance is bad enough that issuance as a topic will get louder and louder. I'm optimistic a fix is a matter of when, not if.
> changing the issuance curve is not urgent to Ethereum's survival
I strongly disagree on this point. Ethereum's issuance policy creates the conditions for eventual capture. Once we reach the very high staking ratios that make capture most likely, we probably can't reverse them. And once captured, Ethereum has no value at all. I realise I'm an outlier in this belief but it seems like an existential question to me.
Speaking for myself, yes we need a design that ensures economic security, moderates the costs of achieving it, and upholds decentralization. We are already overpaying for economic security today at 35% (the month-long entry queue you mention indicates that we pay more than the marginal staker requires at this ratio), and the current reward curve increases total issuance as more ETH is staked. I expect welfare to decrease as the ratio rises under reasonable supply curves and would favor a change already, without waiting for the ratio to cross some particular threshold.
The current reward curve compels users to incur higher costs than necessary for securing Ethereum (costs broadly defined to include hardware, labor, risks, illiquidity, taxes, etc.). Reducing issuance improves welfare by lowering these costs in aggregate. All ETH holders gain directly from the reduced dilution. As a non-staker, you would clearly benefit from reducing it. Those who stop staking give up the rewards but also avoid the associated costs. They lose only the surplus above their reservation yield, and may come out ahead once the reduced dilution is counted. Even remaining stakers may profit directly, if the stake supply curve is sufficiently flat, such that the reduction in inflation rate is greater than the reduction in yield.
All else equal, a money that brings more welfare to its users should command stronger demand. Stakers must therefore not only consider the narrow accounting of staking yield and dilution, but also how a reduction in issuance improves welfare across the board and strengthens the trustless properties of Ethereum. It is valuable to have trustless sound money as the primary currency in a decentralized economy. High issuance can lead an LST to dominate as money. Lower issuance helps protect app developers and users from monopolistic pressure by LST issuers and reduces their exposure to LST failures, which could even threaten consensus if an LST becomes “too big to fail”.
Regardless of any arguments, the current state of the entry queue is exactly that, current. It has dropped of late. Furthermore, it would be extremely naive to assume that the deposit queue is not affected by ETH price. That is, if ETH price appreciated to, or beyond, ATH, I would guess the queue dynamics would change substantially as stakers moved to withdraw and take capital profits.
Ergo, using the current state of the deposit queue as evidence of anything on a long timescale is probably flawed. Many of the arguments made around ETH issuance seem reasonable in a theoretical equilibrium, whereas Ethereum is currently anything but. We would probably do well to monitor the situation as ETH price, and relevant factors like the regulatory environment, changes over time.
I'm not EF but I believe this is a serious flaw in Ethereum's issuance curve. I believe in the long run it will undermine ETH as a permissionless asset (since the opportunity cost associated with holding unstaked ETH keeps increasing), and will increase the likelihood of capture by centralised entities.
At present the signs are not good. The Robust Incentives Group is no more. EF leadership figures have by and large chosen not to participate in the issuance debate.
I would welcome the EF playing a leadership role in consensus building on this topic, because many loud voices are not incentive aligned with the long term health of the protocol.
Some community members, like Trent, have expressed concern over client funding sustainability. I understand this isn't a Protocol question; yet Protocol can only be successful as downstream is, and client diversity is our crown jewel of decentralization. What is your view on the overall health and sustainability levels here?
Speaking for myself again, and I will keep this shorter since I covered the funding mechanics in my reply to 5dayoldburrito (linked below).
My read on health: the depth of talent is incredible, the client count is fantastic, but building a revenue model that lets client teams stay credibly neutral is still unsolved.
Ethereum has more independent production clients than any other L1 (and new ones are still entering), which is remarkable given how hard the last year has been. However, a healthy client ecosystem can change fast and that is the thing Trent and others are sounding the alarm about.
What I can say from inside Protocol: we are close with these teams. We are on calls with them every week, we see the challenges as they happen, and we are working through several of them together right now, this week included. It has not been an easy year for many kinds of teams in this ecosystem. I think we get there, and I think we get there faster if the parties that depend most on a healthy L1 decide they have a stake in paying for it.
I read from multiple sources that several client teams have a funding crisis. After so many years and so many initiatives, we are as a eco system apparently stil incapable of securing funding for teams that do crucial CROPS work. How do we solve this and preserve client diversity?
Would you mind linking those sources so that readers have shared context?
> incapable of securing funding
I have an optimistic stance on the matter. As far as I can tell money hasn't historically been much of a bottleneck for critical Ethereum development. Somehow money always finds a way to support the talented devs that address our biggest needs. As a side note, I know of two serious multi-million public goods funding initiatives cooking in the background. I expect one, if not both, to be announced this year :)
Thanks for the question. Speaking for myself here, as one of the people coordinating the Protocol cluster at the EF. Not for the EF, and not for any client team.
I care a lot about client diversity, public goods funding, and governance. These are all difficult and important topics. Client diversity in particular is a property that makes Ethereum resilient in a way no other L1 has managed.
Where I think the framing of your question goes a bit sideways is "we are incapable of securing funding." The harder truth is that two things we want are in tension: credible neutrality and centrally planned funding. We want client teams to be independent and credibly neutral, and we want someone (or a fund or a mechanism) to reliably fund them. Unfortunately, any single payer that reliably pays, whether the EF, a consortium of the largest stakeholders, or an in-protocol mechanism, or single coordinator of allocating funds becomes a point of influence over the thing it funds.
None of that makes the current pressure less real. I am hearing the same thing you are: several client teams are under real strain right now.
Consider EF Protocol an interested party that takes this seriously. We work with these teams every week, the network depends on them and the fork upgrade process process depends on them, and we want to do what we can to be part of a durable and sustainable answer.
EF Protocol's budget is shaped in large part by the EF Treasury Policy, and we try to manage it as well as we can. A substantial portion goes to grants, and client teams are a primary recipient, since they are key collaborators in the fork process. Since the June restructuring that funding has had to shift from being open-ended funding for fork prep, etc to more deliverable-driven grants. While the change in policy has reduced the certainty around funding for several client teams, it has helped Protocol keep grants focused on funding CROPS-aligned initiatives that may not otherwise get done.
So we are doing what we can with the funds available to us. On the bigger question, I think there are two paths: client teams build revenue paths of their own with ecosystem support, or the community agrees on some form of pooled or in-protocol funding, argued for in the open (similar to an issuance change). Speaking only for myself, I am skeptical of protocol-level funding mechanisms because allocation bodies risk get captured or gamed. That said, I hope to see these discussions and debates continue, this is much healthier than ignoring the issue.
what is missed by a lot of people dismissing in protocol funding is the alternative is closed door funding by interested parties. it's very easy to say "in protocol funding risks being gamed" but the alternative is literal capture: teams being paid to develop by staking pools or defi
there is no credible neutrality when the person paying your team's bills asks for a protocol change.
on the contrary, in protocol funding would be by design transparent and not attached to any particular interests other than the health of the network
The tier list declines EIP-8363 on venue grounds, calls that 'not a judgement on the merits' and expects a 'multi-node ecosystem process' it intends to take part in. Who convenes that process, when does it start, and does it start from the EIP-8363 spec as the working draft or from a blank page?
Who convenes the process? To me, “multi-node” means that no single party decides the outcome. Different participants can help convene discussions, while any eventual change requires rough community consensus. In practice, the process should involve researchers inside and outside the EF, client teams, staking operators, etc., to each produce their input and argue it out in the open on ethresear.ch, Ethereum Magicians and the core dev calls. The protocol cluster should participate in that as part of the ecosystem. That is how I read the tier list.
When does the process start? The process started around half a decade ago with early research posts on issuance policy, and has been ongoing ever since in the relevant forums. We are all part of the process and it does not need to be started anew.
Does it start from the EIP-8363 spec as the working draft or from a blank page? The process started a long time ago and we have been writing the pages ever since. EIP-8363 is one design among several possible ones, and these ideas should all be evaluated on their merits.
I would argue that the failure to reach a workable consensus so far is evidence that the existing setup is insufficient. Just as we learned in core devs early on, a workable process needs a convener. If, as many have argued, the existing ACD process is not able to handle the matter of issuance, a separate process with convener is required.
Hegiotá is also being used to start Ethereum’s path toward post-quantum accounts. How much of that migration do you expect Frames to unlock immediately, and what will still require later hard forks before a user can realistically move away from secp256k1 entirely?
Frames unlocks the important part immediately: cryptographic agility. With EIP-8141, account validation becomes programmable at the protocol level, so new signature schemes can be introduced without a hard fork for each one. That gives accounts a native path toward PQ authentication instead of being permanently tied to secp256k1.
But Frames alone does not fully retire secp256k1 for existing EOAs. The Hegotá package also needs EIP-8298 and EIP-8151: the first turns a delegated account into a real smart-contract account, and the second prevents legacy ecRecover-based authentication once code is installed. Together, those are the path for removing secp256k1 as the account’s master key.
What comes later is mostly efficiency and standardization. Hegotá deliberately does not enshrine a specific PQ scheme such as ML-DSA; the point of Frames is that schemes can compete and evolve without another fork. The roadmap currently places leanSPHINCS transactions in future forks, together with the broader minimum-viable PQ milestone.
So I would frame it as: Hegotá gives us the account architecture needed to leave secp256k1; later forks make a concrete PQ path efficient and deployable at scale.
So, if these two EIPs are going into Hegotá in combination with Frame accounts, users will be able to migrate their EOA (secp256k1) to a Frame PQ account, e.g. ultra-cheap PQ SPHINCS- (https://x.com/ncsgy/status/2065791130457747707), such that the EOA private key loses all authority over the account, thus enabling Ethereum accounts to go PQ-resilient!
Frames makes it possible to have quantum-safe accounts that have all the same properties that you expect of EOAs (alongside other features).
The main problem that it does not solve is efficiency. An ECDSA signature costs ~4000 gas (including computation and data). A quantum-safe SPHINCS- signature costs 100k-250k gas depending on parameters. This is a large increase in cost.
The EIP that is most likely to deliver large improvements in cost efficiency is EIP-8288 (see also: my post here https://firefly.social/post/x/2097711433073172837 ), which allows these signatures to get aggregated and replaced by proofs in the mempool, so the computation and data never needs to go onchain directly. That will also make privacy on Ethereum vastly cheaper. I am hoping we can get 8288 included in I* (the fork after Hegota).
Makes sense to me :) I maintain a minimal Protocol org chart and will discuss with Will the possibility of publishing something on protocol.ethereum.foundation/teams, a page which is now extremely outdated.
u/abcoathup curious what you would want a detailed org chart to do for you. Is it about knowing who to reach for a given topic, seeing how the reorg impacted headcount, or something else?
I agree it is nice to have, and I will admit I take a lot pride in seeing my name up there.
The reason it is not as detailed as it used to be is that a few people have real security and opsec concerns about being listed publicly with their role and team, and we are trying to balance that against transparency. If the underlying need is "who do I talk to about X," there may be a better way to solve that than a full chart.
Privacy, opsec & security are very valid. I am pro the use of anon and pseudo anon identities.
As part of my work at Ethereal news, my primary use cases are does this person posting on X work at the EF (and what team) and what is the X handle for this person mentioned. Team names and sizes are helpful. This only requires whatever identity people want to use and there are already examples where people use a single name or a pseudo anon identity.
What does an issuance change need to have produced before it is eligible for a fork? For example a settled spec with client prototypes, or a research consensus, or a community signal of some kind. Naming the bar now would let supporters and critics work toward the same test.
An issuance change requires rough community consensus. The community decision process is difficult to define top-down, but I believe that the following three things would be required for consensus:
A simple design with well-understood incentive effects that preserves positive regular yield for diligent solo stakers under normal network conditions. I favor the approach outlined here, which can be implemented in just a few lines in the pyspec. In this design, there is always a positive staking yield, and issuance is maintained at a level relative to the base rewards where solo stakers receive steady rewards even without special-duty assignments (like proposing).
A probabilistic equilibrium model of the quantity and composition of stake that accounts for the costs (broadly defined to include hardware, labor, risks, illiquidity, taxes, etc.) associated with staking. This is the appropriate format for discussing how a reduction affects the ecosystem.
A rationale that clearly explains the expected welfare gains and trade-offs, and which may extend beyond the EIP as general community outreach.
Naturally, client implementations and testing would also need to meet the normal requirements for fork inclusion.
I have worked on an EIP along these lines. If you think it could be worthwhile and would like to support it, or have objections or cost data that should inform it, feel free to reach out.
"We would expect this to be carried forward via a multi-node ecosystem process with the technical rigour and breadth of engagement the question deserves, and we intend to participate in such a process."
But the question of how such a process is expected to emerge is left unanswered. I'd welcome a statement from EF Protocol that they will not only participate in such a process but that they will convene it. As they say themselves, issuance touches a diverse range of stakeholders. EF Protocol is best placed therefore to investigate and manage the process.
Anti correlation penalties (7716) are described as "Adds slashing-logic surface for validator correlation with no CROPS or PQ contribution. Not a priority in a fork, we are trying to keep the CL scope light." This EIP has no slashing logic surface area, it is absolutely pro CROPS, and it has no pre-quantum cryptography involved. Was this description a mistake, an oversight, or what? I don't think the EF should continue to take the chain's decentralisation for granted. Please re-consider this or any EIP that aims to prevent the validator set's capture before its too late. You can't re-decentralise a captured validator set once it has happened, this is not something we can correct after the fact. Either Ethereum is a permissionless world computer or its not. FOCIL doesn't work with a captured validator set, so that doesn't make centralisation okay either, there's no point in making it an S-tier objective and then it ships to a chain that refuses to attest to blocks containing no-no transactions.
There was some miscommunication regarding EIP-7716 internally and the note has been modified as follow:
"EIP-7716 increases penalties for correlated missed attestations. The impact on the current and future staker landscape, how effectively it reduces centralization forces, and edge cases such as multi-client setups that pause together during client disagreement all need more research and community discussion first. EIP-7716 is a good idea, but not a high priority in a fork where we are keeping CL scope light."
Do we need to be concerned about client diversity? According to https://clientdiversity.org/#distribution Lighthouse is at 51%; We don't have a good picture of execution layer client diversity but previously Geth & Nethermind were estimated at 43%. The EF Protocol tier list recommended DFI EIP8359 Beacon Block Reporting Field which may have given us a better view of client diversity.
Do we need to be concerned about client diversity?
I would distinguish CL client diversity from EL client diversity. CL clients are fundamental to the security of Ethereum L1. They are the substrate through which stakers exercise their duties, and as such will remain perennially close to the metal and relevant to L1 security. Lighthouse's dominance is indeed cause for concern.
On the other hand, I expect EL client diversity to eventually lose most of its relevance and meaning for L1 security. Today's EL clients are consensus-bearing through their enforcement of the EL state transition function (STF). This EL STF is a purely deterministic function which makes it a perfect fit for formal verification (FV).
The current plan is to leverage this FV-friendliness in the context of zkEVM proofs. We can have implementations of the EL STF in RISC-V assembly which are proven to be equivalent to the EL STF spec. In such an environment the spec (and the equivalence class of its faithful implementations) can effectively be the canonical implementation, with attesters enforcing the EL STF by verifying cheap zkEVM proofs.
With mandatory zkEVM proofs EL clients may no longer be relevant for validators. I expect ancillary non-STF duties currently performed by EL clients, e.g. mempool maintenance, to get reimplemented by CL clients. (See validity-only partial state (VOPS), currently slated for J* on the strawmap.)
The EF Architecture team has now gotten into the rhythm of hosting a week-long retreat every 6 months or so. The first such retreat, in Jan, led to the birth of the strawmap announced in Feb. We had another retreat in June, which led to a significant strawmap revision announced in July.
The next Architecture retreat is scheduled Jan 2027, which means a revision could be announced Feb 2027. For continuous maintenance and more minor revisions there's a fairly detailed changelog (which you linked to) available on Github here. As a side note, I'm slated to present about the strawmap (with an emphasis on PQ) at Devcon as well at a Ethereum Institutional event on Nov 12 in London.
As Ethereum simultaneously pursues L1-zkEVM, post-quantum security, and new consensus designs, which existing protocol machinery could realistically be removed or simplified so that Ethereum’s total complexity does not continue growing with every upgrade?
removed or simplified so that Ethereum’s total complexity does not continue growing with every upgrade?
Massive protocol simplifications are part of the lean Ethereum project, at the CL and EL.
At the EL the plan is to enshrine RISC-V as the native ISA, which is a couple orders of magnitude simpler that the today's EVM ISA. For forward compatibility the EVM and its complexity would be relegated to a string of RISC-V bytecode, see evm-asm.
At the CL the plan is to have a minimal CL STF as part of the lean consenus fork. This is currently slated for L* (coincidentally, "L" for "lean") on the strawmap. This CL STF, recently named "cl-asm", would also be written in RISC-V. Unlike the EL, there are no forward compatibility concerns at the CL, which means cl-asm can feature a thorough debt tech reset and lay minimalist foundations for the extremely lean chain.
I think there is a real opportunity to delete tech debt as these projects mature.
With L1-zkEVM, validators could eventually verify execution proofs without locally re-executing every transaction. EIP-8025 starts by making those proofs optional, which gives us time to deploy and test the proving infrastructure before considering changes to the current execution model.
Consensus can be simplified much more aggressively. Decoupled consensus changes how availability and finality interact, while the PQ transition removes BLS and introduces STARK aggregation. Once we have that proving infrastructure inside consensus, we can also move things such as validator accounting out of the state transition and prove them when needed. Some proposals already explore reducing per-validator state from roughly 120 bytes to only a few bytes.
I also think sharing infrastructure matters a lot. leanVM is currently being developed for PQ signature aggregation, but similar machinery can potentially serve execution proofs, transaction-signature aggregation through EIP-8288, and leanDA. Maintaining one small, formally verified proving stack would be much simpler than introducing independent systems for each of these.
We should measure these upgrades partly by what they allow us to remove: BLS aggregation, mandatory local execution, parts of validator accounting, old cryptographic paths, and eventually other legacy state and consensus machinery. Ideally Ethereum in 2030 has more capabilities than today while having a smaller consensus-critical surface.
One possibility is to rely on a single zkVM for both PQ of CL and EL scaling and privacy needs. This is an active discussion within the Research Engineering team, since lowering engineering complexity matters. If we can rely on a single VM to cover both CL and EL needs, that would simplify the engineering (and FV efforts) landscape a lot, compared to having separate leanVM and zkEVM machinery. One interesting opportunity (dreaming bigger!) that arises from VM and proof-system unification is proof composition: a single proof to rule them all. Consensus, data availability and execution proofs could ultimately be composed into a single proof of just a few hundred kilobytes, attesting to the validity of Ethereum’s state and history. What makes this particularly interesting in the post-quantum setting is that much of the cryptographic machinery we are considering is converging on the same primitive: hashing. Hash-based signatures, commitments and proof systems can all be built around a relatively small set of hash-based primitives.
My longer-term ambitious hope is that we can eventually de-enshrine the EVM itself.
We are already starting to move in the direction of enshrining RISC-V as an ISA, both for internal use and to expose to users (eg. in EIP-8288). RISC-V is simply a much simpler, more modern and more efficient (eg. no need to put everything including yes/no flags and counters into 256-bit registers) ISA than the EVM, and furthermore current zkEVMs are being implemented by writing an EVM interpreter in RISC-V. So if you expose RISC-V as an ISA to users directly (including for all smart contract writing), you are cutting out the middleman, potentially with massive efficiency savings.
At that point, there is no reason for the EVM to be an "official" part of the protocol. We already have ways to translate EVM into RISC-V. We would already have the ability to execute RISC-V as an execution ISA in ethereum directly. So all we have to do is properly separate out those components, and have the EVM-to-RISC-V compilation happen as a higher-level construction for those who need it (eg. it's a specialized delegation contract), and then it's not consensus-critical for anyone else who does not need to bother with it.
Precompiles (especially the ones we almost never use already) - do a fork that swaps each precompile in-place with a blob of EVM bytecode that does the same thing. The only chance people would notice is that those ops get 10-100x more expensive, but that's fine if they're almost never used anyway.
The Merkle patricia tree - the proposed partitioned binary tree (PBT) ( https://eips.ethereum.org/EIPS/eip-8297 ) is significantly cleaner and more efficient
RLP - SSZ is significantly cleaner and more efficient
Finally getting rid of the SELFDESTRUCT opcode more fully
The concept of delegation - with PBT we're moving to a world where contracts store pointers to code that lives in a separate tree, so deploying many copies of a contract with the same code is cheap, and there are EIPs already being proposed to make that code hash editable.
The current LMD-GHOST Gasper consensus - the proposed few-slot-finality designs are significantly simpler and more rigorous, at the same time as being more performant.
Single-slot finality has been talked about for years and now it seems to have been folded into "decoupled consensus". Is SSF as originally pitched dead, and what finality time should a normal user realistically expect going forward?
Tl;dr In my view, SSF as originally pitched is indeed dead. Nevertheless, we are working towards similar time to finality in the endgame.
The challenge with jumping straight to single-slot finality (or its evolution, three-slot finality) is that you need to solve everything before you can really deliver anything. Many factors play into time to finality: validator consolidation, networking design, efficient post-quantum aggregation, to name a few. If we have a hard target of, say, three slots to gather attestations from the whole validator set (twice), we have to make progress simultaneously on all these fronts, and there would be no finality improvement until they are all solved. With this constraint, faster finality could still be many years away.
Decoupling consensus allows us to make continual progress towards faster finality: improving time to finality (TTF) in steps as we incrementally roll-out improvements, measure and observe their behaviour, and feed those learnings into the next round of upgrades. This is better project management, better risk management, and delivers much earlier benefits both to users and the protocol (a more secure fork choice and a clearer path to PQ). We no longer need to swallow the elephant whole, but can take it in smaller bites (not that I approve of eating elephants). Our first bite is likely to be a 4x improvement in TTF, from ~16 mins to ~4 mins.
As for the ultimate goal, we believe that a TTF of the order of one to two slots is achievable eventually, if we can make use of all possible improvements. Check out the Finality Explorer linked below to see how we get there. Note that the demands of post-quantum cryptography might slow this down a little, but that is still to be explored.
u/yannvonEthereum Foundation - Yann Vonlanthen26d agoedited 26d ago
Regarding the second part of your question, i.e., what finality time a normal user can expect going forward, while I believe we have a lot of exciting research in the work to improve the protocol (decoupled consensus and one-round finality), in my opinion the resulting time to finality will probably also largely depend on how much validators consolidate.
As Ben also already brought up, we've been trying to visualize this in finality.watch, feedback welcome!
What has formal verification actually proven about Ethereum so far, in the strict mathematical sense? Consensus specs? An EVM implementation? A zkVM circuit?
Most of our formal verification pointed towards cryptography. One of the foundational libraries is VCVio, which stands for "verifiable cryptography via interactions and oracles".
Using VCVio we have security proofs for signature schemes, e.g. see the leanXMSS proof and the leanSPHINCS proof. We also have a library of SNARK proofs related called ArkLib, seehere.
Yep, nowadays we can easily prove circuit compliance, including complex circuits that implement RISC-V in the context of zkVMs like OpenVM and SP1. See also zk.golf which heavily leans on circuit formal verification: every submission to the autoresearch challenge comes with a proof.
on the EVM side, we have several formal specifications of the EVM. These open up opportunities for smart contract verification and fully verified EVM implementations. Like u/bobthesponge1 said, we are very close to a fully formally verified evm implementation that we will be able to autoresearch to make it efficient and extremely high assurance. (evm-asm is nearly all formally verified, no compiler in the trust base.) This effort has already exposed some incomplete areas in the EEST tests that we're working to report and fill.
on the zkVM/proof system side, four zkVMs (SP1, OpenVM, Pico, and Zisk) have to some extent formally verified their RISC-V constraints and other parts of their zkVMs, with SP1 and OpenVM providing the most coverage of their zkVMs, although everything has not yet been publicly released. (Serious bugs have been found and rectified during development using formal verification on the constraints).
We are very near having everything we need to formally verify proof systems; we have our first PR to formally verify all of Plonky3 open.
Lastly - smart contracts have a storied verification history, especially these days from Certora.
Four zkVMs (SP1, OpenVM, Pico, and Zisk) have to some extent formally verified their RISC-V constraints and other parts of their zkVMs, with SP1 and OpenVM providing the most coverage of their zkVMs (although everything has not yet been publicly released). https://github.com/succinctlabs/sp1-leanhttps://github.com/openvm-org/openvm-fvhttps://github.com/NethermindEth/pico-fvhttps://github.com/eth-act/zisk-fvThere is still work to be done, both with respect to obtaining end-to-end coverage of the zkVM, proof system, and guest program, but also with respect to better integration of formal verification into the development process and making sure that there aren't any issues with the work but there has been significant progress, including bugs being found and fixed, and our understanding of how to deal with the individual components and putting everything together to obtain end-to-end assurances has improved along the way.
More generally, we have progress across that board that can also be observed through several projects worth highlighting, although there is so much activity right now that I will surely be forgetting some. The fairly recent ethproofs call on formal verification provides a good overview: https://youtu.be/6tExs7i1y9A?si=1K4WK5xUVuH3qOPM.
zkSecurity’s Clean (https://github.com/Verified-zkEVM/clean) makes it possible to write circuits directly in Lean, avoiding the need to extract constraints from Rust for example, yielding much nicer proofs, maintainability and making it much more feasible to reason about the witness generation and chip interactions. SP1 now targets clean with the extraction of their constraints (still written in Rust for now), and zkSecurity have been working on backends for clean as well. I’ve also been enthusiastic about MLIR based compilers for circuits (eventually in Lean via https://github.com/opencompl/veir/), particularly LLZK which Veridise have been developing (and using, applying Picus to more circuits as more frontends have been added to LLZK), and for which I did a bit of work on adding a clean frontend that I’m hoping to see fully developed in due course.
We have ongoing work on evm-asm (https://github.com/Verified-zkEVM/evm-asm), an implementation of a guest program directly in RISC-V assembly, using Lean as the macro assembler.
VCV-io (https://github.com/Verified-zkEVM/VCVio) and ArkLib (https://github.com/Verified-zkEVM/ArkLib) host numerous relevant specifications for the cryptographic components of the zkVMs and guest programs (e.g. signature schemes). Improvements in hax and Aeneas, tools that extract Rust to Lean, mean that we finally have the ability to extract code from libraries like plonky3 to verify it against our specifications in Lean (https://github.com/Plonky3/Plonky3/pull/2154) and as this further improves proofs of theorems about the code which are actually interesting will follow.
We also finally have a number of great examples of Lean being used as the nice general purpose programming language that it is. For example, Powdr’s implementation of autoprecompiles in Lean (https://github.com/powdr-labs/apc-optimizer) runs faster than the original Rust implementation.
There has also been work on consensus protocol specifications, which is being driven by Francesco and (now at ethlabns) and Roberto.
Finally, formal verification has also enabled several successful auto-research projects such as zk.golf, better.codes, and precompile.fast (with more to come) that have helped identify more optimisations that could be implemented and deployed, as well as research breakthroughs.
I will also add that there is a lot of nice work going on on the smart contract side of things, including new DSLs in Lean (like verity) and verified compilers.
Yes Ethereum will natively support shielded transactions (even though the exact properties differ from what Zcash is doing) here is the plan:
By Hegota (2027), if we ship EIP-8250 and EIP-7272, this unlocks native privacy on the L1, meaning all the transactions from privacy applications on Ethereum will benefit from the trustless and censorship resistance guarantees given by the public mempool and FOCIL. The biggest difference with Zcash is that we don’t enshrine one single privacy pool in the protocol, instead we make private transactions first class citizens but allow many different privacy apps to flourish on Ethereum.
The next crucial step will be to unlock post quantum privacy transactions, and for this we need something like EIP-8288 that allows to recursively aggregate PQ privacy proofs in the mempool at scale. My personal opinion is that it should be possible to ship the second part by the end of 2028 if we dedicate enough resources to it.
After completing both steps we get native, PQ privacy on Ethereum L1 and users can transact anonymously, at scale.
Will Ethereum have properties of Zcash (eg. shielded txs), so that users may transact annonymously
IMO we have an exciting roadmap for Zcash-grade shielded ETH transactions at Ethereum L1. The current strawmap suggests having staked ETH be shielded by default, with non-staked ETH having the option to plug into it via so-called wormholes. (For details see the "CL-enshrined shielded pool" and "wormholes" boxes under the "longer term" strawmap column. See also the privacy section of Vitalik's extremely lean chain idea.)
With stake capping at 50% of the ETH supply we can expect the CL-enshrined pool to enjoy on the order of 60M ETH from stakers. At current ETH prices that's over $100B, sufficient to bootstrap a best-in-class anonymity set. For comparison, there's currently roughly $6B of shielded ZEC.
Why does the EF not see quick slots as a Hegota S or A tier priority when the community does? If J* could be 3 years away do you think that is acceptable?
> Why does the EF not see quick slots as a Hegota S or A tier priority
The following is a personal take, not an EF-wide one.
I don't have a strong opinion on the fundamentals of 10-sec quick slots in H*. I do however lean supportive of the proposal in so far that I'm sympathetic to the Ethlabs team and their potential to blossom as second R&D engine complementing the Ethereum Foundation.
Having said the above, I do expect post-quantum to continue sucking the air out of the room. This may come at the expense of performance upgrades (like shorter slots, faster finality, more blobs, increased gas limit) receiving comparatively less love in I*, J*, K*.
In my opinion, Quick Slots is a good idea but it's just not the right time to make such a change. It will make accomplishing our other objectives (most notably PQ) more difficult. For example, PQ will increase message sizes and shorter slots will reduce the time nodes have to propagate messages. I suspect that PQ signatures will also be slower to sign/verify than BLS. And I believe that changing the slot duration will be more complex than we imagine; within the protocol it's fairly well-understood but I'm afraid there are edge cases outside of the protocol we haven't thought of yet. The big benefit of Quick Slots is faster inclusion time and I just don't think it's worth it. I believe that waiting until after J* to reduce the slot duration is acceptable. Other improvements, such as the fast confirmation rule and decoupled consensus, will improve user experience.
I think quick slots are very worthwhile, and the benefits of the EIP probably a little underestimated. At the same time, I cannot speak to all nuances concerning the effects across the CL. I suppose if we had 8s on the table, we'd see stronger enthusiasm, which is a bit unfortunate.
ePBS packages many different things (builder bids, slot restructuring, payments) into a single, huge EIP. Shipping ePBS is already decided, but considering it retroactively, is it worth shipping such a complex change as a monolith instead of breaking it up into multiple EIPs?
Just dropping in to say thank you for all that you do, and to ask if you are also voting for the Hegotá emoji to be a 🐐 and not a 🦖. While I get the FOCIL and dinosaur reference, a Hegotá goat is undoubtedly funnier.
Thank you for your kind consideration of this deeply important matter.
If the available chain is basically memoryless and depends on the finalized chain as its anchor, doesn't that make the tip more reorg-prone in the short term?
With respect to today, in some respects it does, and in others it doesn't
Where Goldfish reduces reorg risk
Goldfish guarantees that, under synchrony and honest-majority participation, any block proposed by an honest proposer will never be reorged out. Gasper does not provide the same guarantee. An adversary that can control the network can perform ex-ante reorg or balancing attacks on a block proposed by an honest validator.
Goldfish also allows committees to be selected via VRFs, so committee membership is not known far in advance. This reduces the risk of targeted DoS attacks or bribery against committee members, which further improves reorg resilience.
Where Goldfish can be more reorg-prone
The reorg-resilience guarantee above holds with certainty only under network synchrony. During even a short network disruption, that guarantee no longer holds with certainty, regardless of how deep a block is in the available chain.
This does not mean that a network disruption will necessarily cause those blocks to be reorged. It means that, once synchrony is lost, there are scenarios in which a reorg becomes possible.
Gasper provides better resilience to short periods of network disruption once a block has accumulated enough votes. This is normally correlated with its depth in the chain, although this is not always necessarily the case.
Memoryless Mitigation
We also plan to add some "memory" to the available chain through a stabilization gadget with memory. This would not stabilize the tip of the chain, but rather a prefix of the available chain that is not too far behind the tip.
Ethereum’s post-quantum migration is a sequence of upgrades across execution, consensus, and data availability rather than a single fork.
On execution, EIP-8141 makes account authentication programmable. Today EOAs are tied to ECDSA; with programmable authentication, accounts can adopt a post-quantum signature scheme such as leanSPHINCS and later change schemes again without having to move funds to a new account.
Consensus is harder because BLS gives us both small signatures and native aggregation. The current path starts with a post-quantum public-key registry, allowing validators to generate and register their leanXMSS keys well before they are needed. We can then deploy a PQ heartbeat on the smaller ~512-validator available chain, using raw leanXMSS signatures without aggregation. This lets us test PQ signatures and their networking impact on the real protocol before making the proving system consensus-critical.
For the full validator set, sending raw signatures is not viable. Instead, leanVM verifies and recursively aggregates the leanXMSS signatures into a single STARK proof. Essentially, we replace BLS’s mathematical aggregation with proof aggregation.
The same infrastructure can later be reused by execution through EIP-8288, aggregating PQ signatures and other proofs, while leanDA replaces KZG with Merkle commitments plus STARK proofs that the committed data is correctly erasure-coded. The current Protocol target is a quantum-resistant Ethereum L1 across execution, consensus, and data by December 2029.
I would add to the EL part PQ STARKs (both for privacy protocols, and as a kind of "universal wrapper" if you want to use some other signature algorithm that Ethereum does not support). The current EIP-8288 spec supports both SPHINCS and STARKs, though there are quite a few implementation details to figure out and optimize.
Maybe some recency bias here...but ePBS is a very large and complex upgrade. Moving forward we're only going to continue growing complexity. It feels like maybe the time horizon between hardforks will need to increase or headliners will need to decrease?
I think we should move towards smaller upgrades rather than large ones. On top of taking longer between upgrades, the larger the hardfork is the more complex the testing, security and other work becomes from my experience. The longer it takes between upgrades, the more important it also becomes to get a feature into an early hardfork as people often don't want to wait another 1.5 years to get their feature in, which then grows the upgrades even more.
Historically, the reasons for not doing more frequent smaller upgrades has in part been due to the complexity around coordinate upgrades and ensure people were able to upgrade their nodes in time. I believe this has improved quite significantly overall, with some potential paths for further improvements - especially for security updates.
I would like to see Ethereum adopt a tick-tock upgrade cycle. We'd ship big features in the "tick" cycle followed by a shorter "tock" cycle focused on removing tech debt and other maintenance work.
I think with the above approach, consistently shipping around 2 upgrades/year would be much more feasible than it is today.
It would make it easier to pick specific EIPs for every upgrade and we wouldn't constantly need to fight for maintenance EIPs to be included over shiny new feature EIPs.
It wouldn't mean the end of headliners either, a single small headliner could still ship as part of the "tock" cycle. But we'd leave the large headliners like ePBS for the "tick" cycle.
I’m personally a big fan of breaking/unbundling changes into smaller, coherent units. It’s more digestible and easier to evaluate the complexity and the exact goal a given EIP is trying to achieve.
Yes, I fully agree. With increasing complexity of the protocol, in the triangle of team size, timelines and feature size something has to give. We did get much better at parallelizing work than a few years ago and at anticipating and preparing work for the next couple of hardforks. But nonetheless testing effort increases significantly with every feature we ship. There is some push to reduce complexity, but sometimes these efforts will actually lead to increased complexity (e.g. getting rid of the SELFDESTRUCT opcode increased testing complexity quite significantly=
I generally agree with this, although I think there is a balance to get right with each fork and each layer, and AI advances accelerating us. More EIPs don't necessarily mean a longer fork but rather total fork complexity, spec line changes in the EL/CL specs repos is a useful metric. I am extremely hopeful we will meet shorter fork times in the medium term, partly due to AI but mostly due to improved co-ordination and real work (many client teams contributing) on N+1 fork headliners much earlier in the process.
I work on EL specs/testing, and something Glamsterdam showed me personally was how much of a lift we get from working on headliners earlier in the process, specifically regarding BALs (toni/felipe/rahul did an incredible job).
For Hegoat, real work (many client teams contributing) on FOCIL/Frames started many months ago, with the first EF devnets hopefully launching very soon. We have never started this "far ahead" on a fork since I joined the EF imo. Overall I feel like co-ordination improvements have the biggest unlock for us in terms of fork times. For example, deciding on the headliners for N+2/I* ASAP would help us offload complexity much earlier in the process. That being said, the co-ordination for Hegoat thus far has been incredible, we are DFI'ing/CFI'ing EIPs much quicker than any fork.
To me, and not to jinx it, Hegoat has the opportunity to become the fastest post merge (non-bpo) fork. We have 209 days to beat... this is the energy I want us to attack it with! 🐐
What is the state of Rainbow Staking? It never got to be addressed at the Lean Ethereum meetings and I never heard about it afterwards. Is it waiting on libp2p optmitizations in order to handle more small validators?
Block building on mainnet is already quite centralised, and we agree that adding proof generation pushes it further in that direction. Regarding distributed proving, Jordi from the Zisk team has this Ethresearch post that you might find interesting. Distributed proving may face challenges with proof-building latency, mainly depending on upcoming changes to the gas limit and available proving time. A simpler strategy is to keep pushing for better efficiency in single-prover hardware requirements (e.g., less than 16 GPUs) so this doesn't become a strong centralisation force. To take a step back, Ethereum has already implicitly accepted that builder resource requirements can be significantly higher than those of the average validator, and Glamsterdam further enshrines this direction. With zkEVMs, we double down on this asymmetry: builders and provers may require more specialised hardware, but in return we can dramatically reduce the work required of validators by making payload validation effectively independent of the block gas limit. This is an important part of the trade-off. Rather than requiring every validator to scale its hardware alongside execution throughput, expensive computation can be concentrated in the builder/prover role while keeping validation cheap and broadly accessible. The goal is therefore not necessarily to make proving feasible on validator-class hardware, but to ensure that proving remains accessible to a sufficiently broad and competitive set of participants that it does not become a significant additional centralisation force.
[...] Is the strawmap's "lean privacy pool" meant to carry real settlement volume, or is it a baseline for simple shielded transfers with privacy L2s doing the rest?
In my opinion the idea of an enshrined privacy pool is only worth pursuing if meant to carry real settlement volume, but ofc it wouldn’t be able to accommodate all privacy use cases. Its most likely shape is to be the canonical pool for private ETH transfers, but to me it’s still an open question whether we even need to go all the way and enshrine it in the first place. After Hegota upgrades (8141/8250/8272) it could also live as a private, immutable app with almost the same exact properties.
To answer the second part of your question, I think we will see a large range of private applications on L1 that compose or offer different features (e.g., private DeFi, private stablecoins, etc…) than the canonical lean privacy pool. And privacy L2s will be very useful for users that want to benefit from other properties (e.g., private contracts on Aztec).
Is the single question per comment rule actually enforced or just a suggestion, cause I've seen these threads get messy fast when people dump a wall of text with five different topics
With the Protocol Cluster now targeting a quantum-resistant Ethereum L1 by December 2029, how are you thinking about readiness beyond the core protocol, particularly across wallets, account-abstraction infrastructure, rollups, bridges, custody/signing providers, and applications that may retain classical cryptographic dependencies? Is there an existing workstream for ecosystem-wide cryptographic dependency mapping and migration-readiness assessments? If not, what is the best route for independent researchers to propose and seek funding for work in this area?
There are really two problems here: making the protocol quantum-resistant and making sure the broader ecosystem actually migrates.
At the protocol level, the work is already quite structured. On consensus, for example, we are building the PQ reference specification, test vectors, devnets, and interoperability infrastructure so client teams can implement and test the transition against the same reference. We also have public PQ interop calls where this work is coordinated.
But protocol readiness does not automatically make the ecosystem quantum-resistant. Wallets, rollups, bridges, custodians, and applications can still depend on ECDSA, BLS, KZG, pairing-based proofs, or classical upgrade keys even after L1 has migrated. Bridges and immutable or difficult-to-upgrade contracts are particularly important because there may not be a simple user-driven migration path.
I’m not aware of a comprehensive Ethereum-wide dependency map covering all of these systems today. I think that would be valuable work: identify which vulnerable primitives each system uses, whether it can be upgraded, who can authorize that upgrade, what PQ replacement exists, and whether the migration has actually been tested.
For independent researchers interested in this, I would suggest coordinating with the existing PQ community and joining the public interop calls so the work aligns with the protocol migration.
Real-time proving of a mainnet block on a few home-grade GPUs: how close are we honestly, and what happens to the roadmap if latency stalls at, say, 10 seconds?
For current mainnet blocks, OpenVM has recently posted their latest benchmarks, which you can find useful. In our team, we’re standardising the guest programs and running cluster hardware runs to provide more neutral face-to-face comparisons, which we will publish soon to make this easier to track. Regarding proving latency stalling, it will mainly depend on how gas limits increase in the coming months, protocol changes that make proving harder (e.g., new precompiles that are hard to prove), or slot architecture changes that affect proving time. Although zkEVMs keep improving performance, if things go south, a mandatory proofs protocol change should probably be delayed until it is no longer a concern. State growth will probably be another big factor in avoiding gas limit increases, so it might be the bottleneck rather than proving times stalling. We should also put the current state of proving performance in perspective. Only a few years ago, the idea of proving the entire EL in real time was met with considerable doubt. Today, multiple teams are competing to drive proving latency and hardware requirements down, with substantial improvements arriving almost monthly. While we shouldn't assume that this rate of progress will continue indefinitely, the trajectory so far gives us good reason to be optimistic about reaching practical real-time proving.
As astonishing as it may sound, I believe real-time proving for Ethereum L1 has now been cleanly derisked. RISC-V zkVMs (e.g. OpenVM, SP1, ZisK) are capable of proving mainnet with all the requirements set by the EF. On power draw and GPU count, the EF is targeting a 16-GPU 10kW setup. Teams like ZisK are breezing through with significantly fewer GPUs, e.g. just 4.
what happens to the roadmap if latency stalls at, say, 10 seconds?
I'd question the premise that proving latency may stall at 10 seconds. By today's standards 10-sec latency is already sluggish. Proving latency should continue dropping like a rock. I have discussed 2-sec proving for 99.9% of mainnet blocks with each of OpenVM, SP1, ZisK. None of these teams doubt this is achievable, with several bullish on 2-sec proving by 2027.
What would it take to rename Hegotá to Hegiotá?...FOCIL and Frames are both treated as core Hegiotá work. What is the hardest unresolved interaction between censorship-resistant inclusion and programmable Frame transactions, and what failure mode worries you most before mainnet?
There isn’t any fundamental incompatibility between Frames and FOCIL. The hardest part is deciding whether a Frame transaction was legitimately left out when its validation depends on state that can change during the block. We need clear rules for which state validation can read, how much work checking it can require, and where in the block its validity is checked.
> What would it take to rename Hegotá to Hegiotá?.
Hegotá Upgrade: Named after the combination of "Heze" (consensus layer upgrade, named after a star) and "Bogotá" (execution layer upgrade, named after a Devcon location).
Shadow forks were a big deal for the Merge. Are they still the main tool for catching client bugs before a fork, and what have you learned from the Glamsterdam testnets that changed how you test?
I wouldn't say that they are "the main tool," but they are definitely one more way of testing and preparing for a hard fork. Shadow forks normally happen toward the end of the release cycle, once we've completed most of the testing in our devnets.
The advantage of a shadow fork is that we have access to the execution-layer state of mainnet or a specific testnet, such as Sepolia. Our devnets normally start from no state or a relatively small state. So, doing a shadow fork toward the end of the cycle allows us to test the clients against more realistic, production-like state and uncover issues that may not appear in our earlier devnet testing.
Right now the biggest tool for catching bugs is probably AI. The security team uses AI to automatically scan the code of all clients for divergences with the spec and other security issues.
As for shadowforks, there will be a few more of mainnet and the testnets soon, once the clients have proper images they feel good about.
Glamsterdam was different from previous HFs in that the timings and mechanisms on the beacon chain changed quite significantly (due to epbs) so a lot of new tooling was created for non-finality tests as well as for benchmarking (for the repricings).
Only tangentially related, but one type of fork that I hope we can get to having is a "war mode testnet". Literally a test network that you can join where we explicitly assign a team to try to strike down the network with eg. a P2P DoS, or transactions, or a full-on 51% attack, and the defending team has to recover the network. I think this could be very valuable for discovering more big-picture holistic issues, like what we learned from the Holesky incident last year.
There has been debate in the community lately about the nature of devtax (zcash) vs prior allocation (ethereum). Are these fundamentally similar concepts, why or why not? Do you agree with concerns that funding into the far future for eth dev is currently unsustainable?
[...] With Frames and keyed nonces, many users share one sending account, so a contract can't tell who a transaction is for. How should a "this user was screened" attestation be keyed without unmasking them: to the nullifier, or something else?
Strawmap has tapered issuance as a potential I* candidate (but may never ship) https://strawmap.org
Given the impact, should it be proposed as a headliner candidate?
Headliners are usually assigned to technically challenging EIPs, which an issuance change is not. Having said that, I wouldn't be against making an exception and having two CL headliners in I*: decoupled consensus as the technical headliner, issuance as the social headliner.
Application developers have to actually convert over to using it, and learn new programming habits.
UTXOs don't solve privacy (keyed nonces do, and ideas like bloom filters can make them more efficient)
Of course, UTXOs are not a good fit for absolutely every application. Some apps just need to have objects with fixed addresses that can be modified multiple times - that's what Ethereum is about. Though if the majority of activity moves over to UTXOs, gas prices should decrease even for those applications that don't.
The end state I want for Ethereum is one where an app chain like Lighter matches orders at the speed of a centralised exchange while drawing on mainnet liquidity, instead of bootstrapping a liquidity island of its own. How far are we from that today, and what is the road: based sequencing with preconfirmations, native rollups, shared bridging and intents, or something not on the roadmap yet? Concretely, which piece is the binding constraint right now, and which upgrade after Glamsterdam moves it? And is there a version of this where speed always implies a separate liquidity pool, so the end state is not reachable at all?
Lowering issuance is defended with surveys of existing stakers, but surveys measure retention while the thing at risk is entry and composition. Solo exits are mostly life events and yield-insensitive, solo entry is a yield decision, and institutional entry, issuers running validators for guaranteed inclusion rather than for yield, does not respond to issuance at all. So: is there a composition metric with an alarm threshold, for example the share of stake held by operators that cannot be served a subpoena as a legal entity, and what reading of it would make you stop lowering? If no such number is tracked, what evidence is the current direction being chosen on?
Shipping L* in December 2029 requires an average cadence of 7.2 months. Shipping MV-PQ requires a 12 month cadence. We had hoped to move to twice yearly network upgrades, instead Glamsterdam will likely be (at least) 12 months since Fusaka. How can we ensure that network upgrade scope is sufficiently focused to meet the required cadence?
I believe one of the key things is making people aware of why we need to focus on making Ethereum quantum-safe, and what the consequences are for Ethereum if we end up being late due to for example adding too many non-critical features to upgrades.
One way is to keep the upgrades as small as possible on each layer which means Execution Layer or Consensus Layer may be "light" one hard fork, as this allows client teams to start focusing on the next upgrade sooner.
Right now we're targeting before 2030, but this could very well be accelerated given advancements in LLMs and more interest in PQ.
has the EF been able to secure private access to the best LLM models from frontier labs for security research, as more normal large "tech companies" have done? if not, does this concern you and is there a plan to get such access? has such access been attempted and the frontier labs won't do it for ethereum because "it's crypto"? any other thoughts/discussion relevant to this issue you can share?
A good harness matters a lot. I think the engineering and security expertise around a model can matter more than which model you’re running. Better models help, but access alone isn’t a security capability.
Ethereum’s Nakamoto and Staking Gini Coefficients (how much stake points at how few withdrawal setups) are consistently declining for the last 2+ years. What EIPs are EF Protocol pushing forward to halt this degradation of the chain’s security and CROPS? (E.g. 7716 being DFI’d)
One thing I am personally excited about, that we do really need to put resources toward, is making it easier to run nodes.
We need to walk back from the present-day world where node-running is perceived as a scary thing for either devops professionals or hobbyists with extra cash and lots of spare time, and back to a world where a few components are like that (eg. provers and builders) but everything else is only as difficult to run as eg. a local LLM. The qwen 3.8 flash next that's currently sitting and running two parallel tasks on my laptop as I'm typing this is not a small thing: it takes up over half my RAM, it decreases my battery life 4x if I run it unplugged, and it was nontrivial to install. But nevertheless, not only does it run on my laptop, it does so without interfering with the rest of my work. With ZK-EVMs and BALs and other recent tech, it should be possible to get node running down to this level, or even further. The minimum that a properly-participating node would need to hold is the VOPS, everything else can be managed with proofs.
Given the inherent limitations of ECDSA, it is advisable to conduct a deeper analysis of its vulnerabilities; hacker attacks are becoming increasingly sophisticated and effective year by year you can see for yourself just how many hacking incidents have occurred in 2026 alone.
Given the inherent limitations of ECDSA, it is advisable to conduct a deeper analysis of its vulnerabilities
At the cryptography level ECDSA (specifically, secp256k1 DLOG) is generally considered secure, at least prior to qday. There have been slip-ups in the context of k-of-n ECDSA threshold signing, but that's more of a reflection of hacky MPC protocols than anything inherent to ECDSA.
There is a non-zero possibility, IMO greater than 1%, that superintelligent AI will break ECDSA prior to quantum computers. As such, the post-quantum cryptography we are deploying on Ethereum L1 can also be seen as post-AI :)
Security remains our primary focus. Currently, dedicated teams of researchers, engineers, and security experts are working on hardening the security of the active Ethereum protocol, while other teams advance research for post-quantum transitions.
We allocate resources to post-quantum readiness while continuing to maintain and monitor the live protocol where ECDSA is deployed. Monitoring ongoing cryptanalysis and implementation security allows us to manage current protocol safety alongside long-term post-quantum development.
I don't think its advisable for us to spend more resources on ECDSA or secp256k1. Its a well established signature scheme without major known flaws. The hacking incidents we see usually fall into two categories (1) Wrong/bad randomness (2) user issues (e.g. double signing, bad opsec, ...).
With quantum computers becoming more likely, we will need to move off of secp256k1 sooner or later.
If a large quantum computer showed up earlier than expected, would having L1-zkEVM deployed make the transition easier, because verification is already hash-based and clients don't rely on re-executing signature-heavy blocks?
Even if all L1-zkEVMs use post-quantum proving systems, this will not help the protocol since attestations and end-users still rely on elliptic-curve cryptography; what is being proven is already vulnerable. Said differently, the attacker can’t create a proof of an invalid STF, but we would still have attack vectors on attestors voting for blocks or EOAs forged signatures.
If a large quantum computer showed up earlier than expected, would having L1-zkEVM deployed make the transition easier
Yes, thanks to technological synergies. The PQ and zkEVM roadmaps are converging towards RISC-V zkVMs being the foundational technology for both. All the work that went into RISC-V zkVMs (e.g. proof system breakthroughs, formal verification, prover optimisations) in the zkEVM context is paying dividends for PQ.
Your new priorities post defines a maturity pipeline for protocol changes: Research → EIP → Prototype → Devnet → PFI → CFI → SFI → Mainnet. What should the corresponding process be after mainnet? Should Ethereum have an explicit maturity/ossification framework for existing protocol properties, where the burden of proof for changing a property rises as it matures and some properties can eventually leave the normal design space?
If you had to name one Ethereum protocol property today that should be considered an ossification candidate, and one that should remain deliberately mutable, what would you choose, and why?
For ETH the asset I would ossify minimum viable issuance. This deliberately frames the current issuance curve (which is far from minimum viable issuance) as mutable.
On EIP-8163 (Reserve EXTENSION 0xae opcode): the note says a reservation can ride any future fork, and technically it can. The constraint is on the consumer side. No chain will commit to an opcode design while the byte may still be assigned on L1, so a "committed consumer ships this fork" criterion cannot be met before the reservation exists. Still, there are designs currently considering it, here: https://ethereum-magicians.org/t/eip-8163-reserve-extension-0xae-opcode/27756/8. Would evidence of that kind be enough to revisit the grade?
Also on EIP-8163: could you expand on "the moment an object-format design commits" in the note? The EIP does not depend on any object-format work on L1. If you're refering to the encoding built on top of the prefix, a draft MIP-7 (https://mips.monad.xyz/MIPs/MIP-7) specifies one. We want to be sure we address the condition you had in mind.
The post's own Forkcast link places 8163 in A Tier, please clarify
Vitalik’s April 2026 note on remote LLMs and the Crapis/Buterin ZK-API usage-credits writeup both describe the same shape: pay for inference without an account, hide origin (mixnet), sanitize the prompt before it leaves the device, and keep settlement from becoming a usage biography. On the payments side, public x402 makes machine payments easy and also writes a receipt (who paid, whom, how much). A privacy layer on that rail would treat the payment as an action and the proof of payment as a dependency closer to the action/dependency split in the recent 8141 discussion. Is private, unlinkable API metering (ZK or similar) something Protocol wants as a user-facing pattern on L2s, or is that considered application-layer only?
I see that pattern as being application-layer primarily.
That said, there are intersections with access layer, both L2s and even L1. One strategy for improving privacy of RPC access is anonymization - send the request through a mixnet and get the answer back. This can even be combined with PIR, so you get a sort of hybrid guarantee: you PIR over buckets of 10 gigabytes at a time, and then you anonymize the requests to the full state+history (assume 1 terabyte); assuming there are more than 100 users making requests simultaneously, all that the network sees is "someone accessed something in chunk #69" but you'll be getting multiple accesses for each chunk simultaneously anyway. But if you do this, you have to pay for requests, and avoid leaking your identity through the payment layer. This is where ZK-API can help.
Have people on the Protocol / dAI side actually used or reviewed any live implementation of that stack (mixnet + local redaction + per-call proof-of-payment with no account) One example that matches the published shape almost perfectly is PRXVT AI (prxvt.ai): no KYC, one-shot proofs per call, mixnet, redact, px402/privacy preserving payments for agents, confidential balances. Not asking for a token opinion. Asking whether this is the design you meant, and whether anyone has tested and/or researched the product and tech itself.
There's a lot of talk about "guest programs" for L1 zkEVM. Is there one canonical guest program per EL client, or is the idea that each client team compiles their existing EVM into a guest for a standard RISC-V zkVM? How much duplicated work is this?
For mandatory proofs, there are two main outcomes possible: the protocol relies on multiple guest programs (ideally existing EL codebases compiled to the RISC-V target), or we rely on a single canonical guest program. Both approaches have pros and cons for protocol efficiency (e.g. the bandwidth cost of proofs), security, and duplicated engineering work. Relying on multiple guest programs adds an extra layer of security using the same rationale as current EL diversity, but return on investment may diminish since we could also formally verify them fully or partially. In practice, engineering costs may lead us toward combinations such as many lightly verified guests, fewer more heavily verified guests, or a single highly verified guest, but this is not a strict trade-off.
How should users and app devs think about the ever compressing timelines associated with PQ? Do you see the goal having to be moved even earlier than expected?
The next few years are going to be exciting with agentic dev, PQ work, formal verification, etc. With all the excitement and tumult, how do we culturally and operationally continue to understand that 100% uptime must never fail?
I think the key is to keep experimentation and production on very different timelines. Agentic development can dramatically accelerate how quickly we write specs, implementations and proofs, but it should not accelerate how quickly unproven changes reach mainnet.
For the PQ transition in particular, the goal is to introduce changes progressively: specifications first, multiple independent client implementations, extensive test vectors and cross-testing, devnets and interop, audits and formal verification, and only then mainnet. We are also deliberately sequencing the migration so that we can test pieces such as PQ signatures on a smaller validator committee before making the full aggregation machinery consensus-critical.
AI actually makes this discipline more important. We can generate and change much more code than before, so human review and traditional testing alone will increasingly struggle to provide enough assurance. That is one reason I think formal verification becomes so important: use agents to move faster, but simultaneously raise the standard of evidence that the resulting software is correct.
The cultural principle should remain simple in my opinion: Ethereum mainnet is the last place where we experiment. We can move extremely fast everywhere else precisely so that when something reaches mainnet, it is boring.
A cultural shift for me has been being explicit about post-AI security. It's not sufficient to withstand nation states, crazy billionaires, or quantum computers. Superintelligence should feature prominently in our threat model, and may indeed be the most pressing threat to Ethereum L1. I hope Ethereum becomes an inspirational example of post-AI digital infrastructure.
agreed with u/tcoratger here - formal verification is crucial. it can add such high-assurance guarantees to software, and is so accessible now agentically, that we should be (1) building the tooling necessary to formally verify everything that we can that is load-bearing, and (2) fostering the expectation of formal verification (in addition to all traditional testing infrastructure) for all serious projects shipped. we are moving very fast on the former; before long I think we will be able to formally verify just about anything you could care about
What is the probability of natively private ETH transfers live on L1 by Dec 31, 2028? If successful, what privacy capabilities do you expect to be delivered? For users, how these capabilities compare to other major privacy L1s or apps like Tornado?
Probabilities are really high, because the goal is to ship changes to the protocol (EIPs 8141, 8250 and 8272) which would allow native private transactions on L1 in 2027.
In terms of capabilities, the easiest way to think about it is TC/privacy pools/railgun but without trusted third parties (relayers/broadcasters).
Yes, quantum resistance was a big reason for the shift, alongside making ZK proofs more efficient. The current proposal is a Partitioned Binary Tree (PBT).
There’s already a devnet running across Geth, Besu, Nethermind and Erigon. The next big steps are testing the full migration (EIP-8347) and benchmarking it at mainnet scale. So implementation is well underway, but there’s still work before a mainnet rollout and no confirmed date yet.
We normally list all the devnets we run on our website. You can find them at https://ethpandaops.io/networks/. Currently, these are mainly Glamsterdam devnets, although we occasionally have other networks up and running as well.
Before running any devnet, we prefer to have a locally functional Kurtosis network. This allows us to iterate more quickly and saves both time and resources. We normally set up a devnet once there are already some clients that can interoperate and this interoperability has been proven on a local Kurtosis network.
We did have a small scale FOCIL and decoupled consensus devnets to gather some data.
Additionally, in case you are curious about the decoupled consensus devnet specifically, here is the link to the Kurtosis setup that was run. You can also find a description and an analysis of the devnet there.
What happened to the Soldøgn Interop short film? Will we ever get to see it?
Here's a bit of context. On Sep 1, Louie, our in-house film maker, announced his departure from the EF. I believe he captured Soldøgn footage and would had led production of the video. Others (possibly Will?) may be able to provide a more comprehensive answer.
What concrete progress has the L1-zkEVM effort made over the past year, what is now the largest obstacle to production deployment, and what milestones should the community watch next?
What is currently the most promising post-quantum replacement for KZG in Ethereum’s blob data-availability system, and can it preserve PeerDAS-style sampling efficiency without prohibitive bandwidth, proof-size, or computation costs?
The most promising direction today is leanDA: keep Reed–Solomon erasure coding and PeerDAS-style sampling, but replace KZG with hash-based Merkle commitments plus a STARK proving that the committed data is actually a valid codeword. That extra proof is important because a Merkle root authenticates sampled cells, but unlike KZG it does not by itself prove that the committed data was correctly erasure-coded. (LeanDA design and benchmarks)
The current benchmarks are encouraging. The best measured configurations are around 0.9 MiB/s of LeanVM proving throughput and roughly 0.6 MiB/s end-to-end DAS throughput on a desktop CPU, with better numbers on a server-class CPU. Sampling remains PeerDAS-like: validators still download only selected cells and Merkle openings and not the full data object.
The main open question is whether we can push proving cost and proof overhead low enough for Ethereum’s eventual blob-throughput targets. The dominant costs today are hashing and Reed–Solomon membership checks inside LeanVM, so there is still significant optimization work ahead.
Security is also being treated seriously. A follow-up work formalized the cryptographic core in Lean and proved position-binding and code-binding for the optimized construction, under explicit assumptions on the commitment and proof system. It does not yet prove the security of a production implementation, but it gives us much stronger confidence in the underlying construction. (Formal verification of leanDA)
So the short answer is: yes, the current design preserves the core sampling model of PeerDAS and the early performance looks plausible, but it is still research rather than a settled KZG replacement.
One further direction we are exploring is distributed proving with recursive aggregation. Proof aggregation enables a decentralised set of peers to prove the correct encoding for distinct subsets of blobs. Peers can gossip these proofs in the blob pool and aggregate them, yielding a proof covering the union of these subsets. In practice, this realises a sharded blob-proving architecture in which each peer contributes a small amount of the proving effort. To make this practical, it may need to be coupled with a sparse blob pool and asynchronous blob tickets, but the potential exists.
Proof composition lets us take this a step further. Proof composition aggregates proofs of distinct statements. This could allow the builder to generate an execution proof using a zkEVM and a DA proof (or consume one already created and gossiped in the blob pool) and combine them into a single proof attesting to both the payload's correctness and the encoding of blobs. This amortises the network's resource consumption across both bandwidth and compute (proof verification).
I would note that these two ideas are deep research directions; if and how they will land in the protocol is still TBD. For the baseline construction defined by u/tcoratger, I am confident we can deploy it on a devnet in H1 of next year.
Heard Justin's quantum date estimate in May where he mentioned the rapid development of Neutral Atom Quantum Computers and set the deadline for post-quantum transition at 2029. How has the situation evolved since then?
I don’t think the picture has fundamentally changed since May. Neutral-atom systems are still one of the most performant and scalable hardware approaches worth watching closely, alongside superconducting and trapped-ion systems, but we still do not have a cryptographically relevant quantum computer or a reliable date for one.
What has changed on the Ethereum side is that 2029 has moved from an estimate to an explicit Protocol commitment. The Protocol cluster is now targeting a quantum-resistant L1 across execution, consensus and data by December 2029, while using Q-day in 2030 as an intentionally aggressive planning assumption. We plan to reassess that assumption with external quantum experts soon as the hardware picture evolves.
We have also turned the transition into concrete tentative fork milestones. I* tentatively introduces the PQ public-key registry. J* tentatively targets a minimum viable PQ Ethereum with the PQ consensus heartbeat, leanSPHINCS transactions and leanDA sampling. Full PQ consensus, including post-quantum attestations and proof aggregation, follows on the path to full resistance by the end of 2029.
So the main evolution since May is not that we suddenly know Q-day is closer. We still have enormous uncertainty there. The difference is that Ethereum is now planning against the early end of that uncertainty and has a concrete delivery schedule to get there.
Frame transactions put a lot of burden on wallet and dapp devs. It's general purpose instead of "shipping with good defaults". How will the EF ensure adoption?
Since this summer, a new cluster was created within the EF called the Access Layer. This cluster works on the layer above the Protocol, and has teams such as "App enablement" and "Builder enablement" which focus on these types of efforts. To learn more about the access layer you can see a video about it here which discusses what the cluster is focusing on
One of the big historical impediments towards native support of ETH shielded transfers has been SNARK soundness bugs. Zcash has historically had two critical bugs which allowed an attacker to stealthily print unlimited amounts of counterfeit shielded ZEC. This is not an acceptable risk for Ethereum L1.
The solution to SNARK soundness bugs is end-to-end formal verification. This is a form of extreme due-diligence which has become particularly practical in recent months thanks to AI. The Ethereum Foundation is going big on cryptographic formal verification (see verified-zkevm.org), and now has explicit "wormhole" and "CL-enshrined shielded pool" boxes on the strawmap :)
Recently we've seen teams quitting (or being laid off) from the EF, and many alternative organizations started appearing (EthLabs, EthSystems, etc). How will the EF collaborate with these?
So far I have mostly collaborated with Ethlabs and Ethereum Institutional. The Ethlabs collaboration is to be expected, with Ansgar, Barnabé, Caspar, Francesco, Josh, Julian previously being close EF colleagues. Relevant Ethlabs members are attending EF events, e.g. the Cambridge workshops and the Architecture retreat.
The collaboration with Ethereum Institutional is materialising via a London event where we'll discuss the post-quantum roadmap and the strawmap more generally.
I think usage varies a lot across researchers, but personally I use AI throughout most of my research and development workflow.
For software development, agents like Claude Code or Codex can implement features, run experiments, write tests and review PRs. They become much more useful when you build battle-tested skills and specialized subagents around them. For example, we can have agents specifically focused on performance, security, testing or formal verification review, each with the right tools and instructions.
For research, I use LLMs to analyze papers, explore ideas, challenge assumptions and quickly understand areas outside my immediate expertise. They are particularly strong in cryptography and formal verification, where they can reason through constructions, generate tests and write surprisingly complex Lean proofs.
One tip is to invest in the environment around the model. A good agent with access to the repository, tests, benchmarks, documentation and specialized skills is much more useful than repeatedly prompting an isolated chatbot. Also use different models and agents to review each other's work. AI can produce a huge amount of code and proofs very quickly, so independent verification becomes increasingly important.
I think we are still very early here. The amount of protocol research, testing and formal verification a small team can do has already changed significantly over the last year, and I expect that gap to keep growing.
If you mean “how fast do we think proven computation can be relative to unproven”, 10x would be amazing. Earlier this year we saw Flock achieve a <250x multiplier on specific computation, so there’s still a long way to go to get to 10x in general (but we shouldn’t forget that ZK is still a young field!). However, having only a 10x factor on a fixed set of computational resources is not needed for Ethereum. For instance, zkVM teams such as ZisK, OpenVM and Succinct have already demonstrated sufficient proving performance on relatively modest GPU resources for real time execution proofs. Of course, ideally the overhead should be as low as possible, but it is hard to say today there is an end-goal number, and we think it is better to always look at the e2e needs and think backwards.
What is the "endgame" for zkVMs? Is it 10x computational overhead?
It's hard to tell. For certain types of structured compute (e.g. AI inference or pure hashing) getting close to 10x overhead may indeed be possible under some circumstances. For general purpose compute, e.g. the emulation of a RISC-V zkVM, we're currently at roughly 10,000x overhead. Ballpark, one CPU core can run RISC-V at 1GHz but only prove it at 100KHz.
One reasonable-sounding potential endgame for general compute is that overhead converges towards the security parameter. In other words, with 128-bit security, every proving every bit of compute may cost ~128 bits of compute. I could see a path reducing today's four orders-of-magnitude (OOM) overhead to just two OOMs: one OOM via software, and one OOM via hardware.
Recently Vitalik posted about his relative optimism regarding the practical feasibility of FHE and iO. If these cryptographic primitives become practical, what impact will that have on Ethereum, and more generally on the world?
For me one of the clearest use cases is shared private state, like an AMM (e.g., Uniswap) that processes trades while keeping amounts and the pool’s reserves encrypted.
If Frames becomes Ethereum's general transaction interface, how far should the protocol go toward making dependencies—especially authorization scope and state dependencies—statically legible across different EVM execution domains? Is the long-term objective only L1 parallelization/proving, or could that common dependency/action vocabulary become part of cross-L2/EEZ account and authority portability?
Why are privacy features being added to L1 when there are already smart contracts and L2s that provide privacy (and in some cases more advanced privacy features than what you’re planning)?
One might say you’re just building for the intellectual stimulation of it, and likely making the same mistakes that private L1s and private L2s made: building infra without thinking about whether it unlocks any new or useful apps.
If the outcome of the new privacy features is that you’ll only be able to rebuild existing apps/L2s like Railgun, Privacy Pools, TC, Miden, Aztec, Semaphore, then that seems like a bad approach. You’ll waste resources, make the protocol more complicated, won’t have unlocked any more use cases, and might kill projects that chose to build on Ethereum.
Have you stepped back and thought about whether your privacy features will actually unlock new use cases and apps that aren’t already possible on Ethereum L1/L2?
Have you tried to build on existing L2s?
Have you tried to design ambitious apps on L1 testnets that contain the proposed privacy features?
I imagine you’ve not tried to build much beyond private transfers (which are already possible), because you’d quickly realise things like private shared state become important.
I am concerned about the aggressive nature of the current issuance reduction proposals. Altering issuance parameters carries substantial risk given its systemic, far-reaching effects across the entire ecosystem. If the primary objective is to prevent the staking rate from exceeding 50%, it is unclear why we should reduce staking yields at—and well below—our current staking levels.
This type of economic adjustment feels like a one-way street. Overshooting the reduction could cause irreversible damage. Even if the network attempted to correct course later by increasing issuance, doing so would severely damage its credibility regarding economic predictability.
While there is a general consensus that the current issuance curve is imperfect, many view the newly proposed changes as far too aggressive—a sentiment I share. What specific data or modeling are researchers relying on that makes such a drastic reduction necessary, especially if the core concern is simply capping higher staking percentages?
Furthermore, if network usage scales, the inflationary pressure of current issuance levels becomes negligible because the burn rate from user activity naturally offsets it. Taking on this level of economic risk seems unnecessary when user activity can organically balance the supply.
Instead of the current aggressive proposals, why not consider a more conservative, targeted mechanism? For example:
Cap the maximum issuance at half of its current limit.
Maintain the current issuance curve until that new cap is reached.
Gradually taper issuance down to 0% as the staking rate approaches 50%.
What are people that oppose these proposals so strongly missing? Is reducing current staking levels just about minimal issuance or is there risk involved to keeping it this high?
Can Ethereum be used to build a system of trust and aligned incentives in our world, such that we overcome the current race dynamics towards achieving AGI/ASI? More specifically, can we enable coordination efforts between AI labs and across countries to ensure we continue making progress, while ensuring safety and alignment efforts come as a first priority?
I've always understood Ethereum to be the enabler of "trust". With the looming dangers that come with exponentially more capable AI systems, wouldn't now be a good time to investigate this type of use case?
I have some ideas for how a system like this could look like, but surely I can't be the only one worried about what our world is headed towards.
Can Ethereum be used to build a system of trust and aligned incentives in our world, such that we overcome the current race dynamics towards achieving AGI/ASI?
How much privacy does Ethereum ultimately aim to provide at the protocol level? There seems to be an inherent tension between strongly privacy-focused designs like Monero and the transparency and compliance requirements of regulators.
Regarding timing games, I think that since Ethereum is currently not an optimistically responsive protocol (and as far as I am aware, doesn't plan to become one), this significantly simplifies the design space. There was some interesting research done on this topic recently: https://arxiv.org/pdf/2510.25144
The recent proposal to reduce ETH issuance if staking participation becomes too high was rejected. Given that reaching consensus could become increasingly difficult as the amount of ETH staked grows, there seemed to be some urgency around addressing this issue. Going forward, what process does the Ethereum Foundation envision for reaching consensus on changes to its issuance policy?
Not addressing the question, but a comment about urgency.
Say another 60m ETH were to be staked, taking us from ~35% to ~85% of all ETH staked. As long as all this stake is consolidated, that translates to only 30k more validators, which is just 3.2% more than we handle today. Basically trivial.
The main problem would be if some proportion of that stake were not consolidated. In the worst case (all of it unconsolidated) we'd end up another 1.9 million validators. This would be a big challenge, not least for achieving faster finality.
In summary: validator consolidation is really important!!
As companies increasingly launch their own L2s and EVM-compatible chains, with more activity potentially shifting away from Ethereum L1, what role does Ethereum envision for the L1 in the broader ecosystem? And what kind of value does Ethereum aim to accrue to ETH in this evolving landscape?
As AI increasingly enhances the ability of attackers to identify vulnerabilities, what additional security measures does Ethereum plan to strengthen to prevent critical bugs as the protocol becomes more complex?
If a critical bug or vulnerability were to be discovered on mainnet, who would be responsible for determining the response, and what process would be followed? Shouldn’t there be a predefined incident-response and crisis-management framework in place for such scenarios?
AI will probably increase both sides of this problem. Attackers can use agents to search much larger codebases for subtle vulnerabilities, but we can use the same capabilities continuously across Ethereum clients, specifications and cryptographic libraries.
A lot can already be done with agents: security-focused PR reviews, fuzzing, generating adversarial tests, differential testing between implementations, and specialized subagents that actively try to break new code. These techniques can run continuously and explore far more cases than a human security review alone.
I think formal verification becomes especially important here. We are increasingly using Lean to formally specify parts of Ethereum and prove properties of cryptographic constructions and implementations. AI is extremely good at accelerating this work because it can generate large amounts of proof code that is then independently checked by the Lean kernel. The long-term direction I find particularly interesting is connecting formally verified specifications all the way to production client code.
Protocol complexity itself also needs attention. Better security tooling cannot compensate indefinitely for an increasingly complicated protocol. Some of the current work around zkEVM, consensus redesign and PQ gives us opportunities to remove old machinery and reduce the consensus-critical surface.
So AI increases the amount of code an attacker can inspect, but it also changes how much testing, verification and adversarial analysis defenders can perform. We should use that asymmetry as aggressively as possible.
On preventing bugs: I’d like security researchers perhaps working more closely with client teams to help catch bugs before they even ship. AI makes code cheaper to produce and so the review and testing need to keep up.
AI can help write tests and support ongoing security checks. More tests, of course, only help if they check the right things. (We want more tests that are at the same time also trustworthy.)
On incident response: Speaking personally, I think responsibilities and communication paths should be clear and practiced in advance.
Disclosure can be tricky. It needs to account for how quickly someone can infer a vulnerability from a public patch because AI makes that inference faster.
I think Ethereum will be ready, and our current objective is to be ready significantly before cryptographically relevant quantum computers become commercially accessible.
The difficult part is that nobody can predict Q-day with confidence. It could take much longer than expected, but we cannot design Ethereum around that assumption. We currently use 2030 as an aggressive planning date and are targeting a quantum-resistant L1 across consensus, execution and data availability by December 2029.
We also do not need to wait until the entire transition is complete to reduce the risk. The roadmap introduces PQ capabilities progressively: validators can register PQ keys ahead of time, accounts gain the ability to move to PQ authentication, and intermediate milestones such as the PQ heartbeat let us deploy and test the new cryptography before the full consensus transition.
The important deadline is also earlier than the moment quantum computers become cheap or broadly commercialized. Once a machine capable of running Shor’s algorithm against Ethereum’s elliptic-curve cryptography exists, even access by a small number of governments, companies or well-funded actors would matter. That is the deadline we are designing against.
Yes, and I think AI can improve Ethereum security at several levels.
The most immediate use is fairly straightforward: agents can continuously inspect code, search for vulnerabilities, generate adversarial tests, fuzz edge cases, and compare independent implementations. As models improve, we can run much more security analysis across clients and protocol code than humans could realistically review manually.
The part I find more interesting is combining AI with formal verification. AI can already write substantial Lean proofs, which makes it realistic to formally specify much larger parts of Ethereum and prove properties about them. We are experimenting with this today across specifications, cryptographic constructions and the PQ work.
Longer term, I would like to have critical protocol components specified and proved in Lean, then connect those specifications to the actual client implementations. The same applies to cryptography: we can prove the construction, prove properties of the implementation, and test that independent implementations agree with the formal specification.
AI does not provide the security guarantee itself. The useful combination is AI generating and reviewing enormous amounts of work, with tests, independent implementations and proof assistants such as Lean providing independently checkable evidence that the result is correct.
To add to Thomas' reply, I believe that AI will greatly favour defence over offence in the end.
First, simply with respect to the ability to find bugs, it helps both sides equally given they have access to the same tools, but the offence only ever needed to find one critical bug whereas the defence needed to find them at scale, and will therefore benefit more from this new ability.
It's worth noting that whilst I believe we are seeing more bugs being exploited now, loss of funds has decreased as it is low hanging bugs being found in less valuable systems which are being exploited as the more valuable bugs in more valuable systems are being found and fixed at greater scale in the more valuable systems.
I also want to highlight that software can also be designed with defence in depth, such that finding a bug does not always result in an exploit (for example, the bug may not be reachable), so headlines about numbers of bugs should not be assumed to imply a corresponding amount of exploits.
Beyond this, as Thomas was saying, AI is greatly helping deploy more advanced tooling, such as formal verification, at a much greater scale because the economics and time efficiency of doing so are now very favourable to these tools, which can finally keep up (and directly help) with software development cadences.
Yes. Finding and fixing vulnerabilities in the software Ethereum runs on is one way to protect it, and AI is already helping with that.
The hard part is separating real bugs from convincing nonsense. AI makes generating candidate findings cheaper; much of the work shifts to verifying them, understanding their impact, and getting real issues fixed. Human judgment (still) remains essential.
I wrote about this, including a publicly disclosed bug that was fixed, in the triage is the product.
EIP-8151 would deactivate it for the incoming PQ accounts (which I personally like: it's simple). Alternative designs exist, see for instance this recent EthResearch post
16
u/Ethereum_AMA pre-submitted community Qs 29d ago
user jmiehau asks:
Setting the mechanism aside, does EF Protocol consider an unbounded staking ratio a problem for Ethereum, and is there a level at which it would become urgent? I hold ETH and do not stake it. The current curve pays a positive yield at every ratio, the ratio is about 35% today and the entry queue is over a month long, so I would like to know whether the cluster sees a problem at all, or only a venue question.