[X] I affirm the direction set out in the mandate, will help translate it into thoroughly reasoned strategies for my domain, and will maintain an exclusive and energetic focus on the mission-critical tasks necessary for its implementation, from today until my last day at the EF.
A new fast confirmation rule mechanism lets you get a hard guarantee that Ethereum will not revert after one slot (12 seconds)
Security assumptions are (i) supermajority honest, (ii) network latency under ~3s. So one step below economic finality, but very strong for many use cases.
https://t.co/5UbEi5gioy
We should be open to revisiting whole beacon/execution client separation thing.
Running two daemons and getting them to talk to each other is far more difficult than running one daemon.
Our goal is to make the self-sovereign way of using ethereum have good UX. In many cases that means running your own node. The current approach to running your own node adds needless complexity.
Short-term, maybe we want some more standardized basic wrapper that lets you install dockers of any client and make them talk to each other easily? Also good that @ethnimbus unified node https://t.co/BWpU939wIM exists. Longer term, we should be open to revisiting the whole architecture once @leanethereum lean consensus is more mature.
you go deep, we'll go broad
I respect and appreciate the EF clarifying its focus and mandate so that others know what gaps to fill and which alternative threads to follow so we make maximal impact as a collective
At @Etherealize_io we'll stay the course and focus on
This is the new EF Mandate.
For many of you, the contents should be no surprise, and a clarification along the lines that we have been going and thinking for the past few months. But the clarification is nevertheless worth making.
Ethereum is a unique object and has a unique role in the world. Its role is to be a sanctuary technology, to preserve technological self-sovereignty, to enable cooperation without coercion, domination or rugpulling, and to provide an escape hatch, to ensure that no single person, organization or ideology's victory in cyberspace can be total.
The Ethereum Foundation is a steward of Ethereum - the original steward, and today, the steward specifically dedicated to preserving and expanding the above aspects of Ethereum. This means a heavy emphasis on CROPS (censorship and capture resistance, open source, privacy, security), both at the protocol layer, and at the access layer, user-facing applications and tools that we create or contribute to.
There are things that we do in Ethereum because we believe that they are valuable for the underlying goals that we have for Ethereum. There are things that we do not do because from the perspective of our values we find them uninteresting (or worse, harmful). But there are also things that we do not do because while they are useful, they are not our role.
At the Ethereum protocol layer, we focus on decentralization, verifiability, inclusion guarantees, protocol liveness, security and privacy first and foremost. We also value capabilities (eg. L1 scale, account abstraction, perhaps some forms of in-protocol aggregation), particularly because improvements in these capabilities better enable users to properly benefit from Ethereum's CROPS properties and displace the need for higher-layer intermediaries that might weaken the extent to which Ethereum's properties carry over into the full stack.
We also believe that the Ethereum protocol must strive to pass the walkaway test. "We do X to specialize to serve the use cases of today, if more use cases appear later, we will continue to keep adding more EIPs for them later" is logic fit for many other blockchains whose names you hear often on this forum, but we do not believe it is logic fit for a decentralization-first blockchain like Ethereum.
At the application layer, we focus on making "the zero option" - user experience that goes hard on ensuring security and privacy, avoiding dependence on intermediaries, and respecting the user's agency - as high quality as possible. We see this as complementary to work in the Ethereum ecosystem that "goes broad", starting from the world that it exists, and brings it onchain and improves its properties over time. Such work has its natural home outside the EF. We intend to be supportive of such efforts. We believe that the two are complementary: tools that are developed within the EF can be adopted by anyone, including partially, and even partial adoption that improves people's security, privacy and agency is a good thing.
But the form of user experience that is more heavily insistent on CROPS properties is where we want the EF to develop its center of expertise. This does not mean shrinking from the hard questions. We believe in a vision of self-sovereignty that protects users, and does not leave users in the cold to face environments where they lose their life savings if they make a mistake, and click "yes" on a confirmation screen by accident two seconds after. But such protection must be designed based on a philosophical baseline of empowering the user, not empowering centralized organizations that claim to act in the user's name. This quadrant of design space - caring about users' (including non-experts') well-being and safety, and yet insistent on doing this in a way compatible with their agency and freedom, is underserved (not just in crypto, but in the world). We wish to use Ethereum as a platform to build out and showcase this quadrant, and ideally work with others to expand its reach over time.
This is also a new chapter in how we see our position in the world. We must see ourselves not just as the Ethereum community, but also as maintainers of the Ethereum tool within what you might call the CROPS community or the sanctuary tech community, or a dozen of other words that have for a long time been used by people with similar values to us but far outside Ethereum. This means open-mindedness to new conceptions of what things in the world are our natural allies.
Ethereum is not the world. Ethereum is a specific object in the world that is here to have specific properties. The Ethereum Foundation is a specific organization within Ethereum - one steward, not the sole one.
I encourage all to read the mandate in detail; it includes concrete examples of how we intend to deal with the challenges and nuances of these ideas. We are doubling down on Ethereum and are excited about its next chapter.
@ilex_ulmus @FLI_org Yeah, I agree slowdowns/pauses on either hardware or frontier AI work or both are good. If "it's unrealistic because the other guy will move forward anyway", then the right solution is for the entities involved (corps and govs) to publicly say "I am willing to not do [X] if
One tool that seems to me would lead to large wins for safety at very low cost to civil liberties, is that everyone should have easy and deniable on-hand ways of calling the police.
Think: you pre-select a few secret words, and when your watch or phone or local device in your house hears these words, it silently auto calls 911, and temporarily streams to the police your real-time location.
This could work very well for eg. crypto holders who are worried about getting kidnapped / robbed. If we create an environment where if you rob someone (whether at home or outside), there is at least a 20% chance that the police will be on their way immediately, so you won't have time to take anything from them and you don't even realize whether or not the alarm got triggered, then that type of crime flips to being very non-viable.
And because this requires deliberate action from the victim in order to function, the risk that this can be used by the government against people seems relatively quite low.
There are often posts mentioning that I donated a very large amount of funds to @FLI_org years ago and connecting me to various policy actions that they take. I thought I would make clear the record both on the nature of my connection to them, and on similarities and differences between my approach to the AI risk topic and theirs.
First, what happened:
* In 2021, I received a large amount of SHIB and other dog coins, seemingly because the creators wanted to use "Vitalik owns half our supply" as a marketing tactic and be "the next Dogecoin"
* The tokens quickly rose in value, and at the peak the "book value" of those tokens was over a billion dollars
* I felt that surely this was a bubble, it would pop quickly and the price would drop massively, and so I scrambled to retrieve the funds from my cold wallet (this included things like calling my stepmother in Canada and asking her to go into my closet and read out a 78-digit number, and then adding it to a different 78-digit number transcribed from a paper in my backpack). I sold what I could for ETH and donated to relatively more "normal" things (eg. $50m to GiveWell). But then I was still left with lots of SHIB
* I sent half to @CryptoRelief_ (half of _those_ funds ended up supporting Balvi, and the other half is being spent by @sandeep and team on improving medical infrastructure in India). I sent the other half to FLI
* At the time, they presented me with a comprehensive roadmap that focused on improving all major existential risks (bio, nuclear, AI...) as well as general pro-peace and pro-epistemics (ie. helping us know the truth in adversarial contexts) initiatives
* I thought that surely they would cash out at most $10-25M, because there's no way the SHIB market is deep enough to cash out more
* Instead, they managed to cash out ... something like $500M (same with cryptorelief)
* Since then, FLI had an internal pivot by which they started focusing on cultural and political action as a primary method, quite different from the original approach.
* Their justification is that the situation has changed greatly since 2021, AGI is coming very soon, and their pivot is needed to affect the world fast enough, and to counteract the lobbying warchests of large AI companies.
* My worry is that large-scale coordinated political action with big money pools is a thing that can easily lead to unintended outcomes, cause backlashes, and solve problems in a way that is both authoritarian and fragile, even if it was not originally intended that way.
* For example, their primary approach to biosafety has been "how do we put guards into bio-synthesis devices and AI models so that they refuse to create bad stuff?". I view this as a very fragile solution: there are many ways to jailbreak, fine-tune or otherwise get around such restrictions. Ultimately, putting all your eggs into this strategy can lead to very dark places like "let's ban open-source AI" and then "let's support one good-guy AI company to establish global dominance and don't let anyone else get to the same level". Approaches like this VERY EASILY backfire: they make the rest of the world your enemy.
* More generally, historical experience tells us that when regulations are made on dangerous tech, "national security" orgs (today, realistically incl Palantir) inevitably get exempted, and in fact those very same orgs are a major source of risk (see: pandemic lab leaks typically coming from government programs). This is something I worry about.
* My approach on these topics has been centered around d/acc: build the tech (eg. air filtering, early detection, continuous passive PCR-quality air testing, prophylactics etc for pandemics, greatly improving software and hardware verifiability for cybersecurity...) to help us survive a much higher-capability world safely, and open-source the tech so that the entire world can freely incorporate it.
* This is the sort of thing that the ~$40m I recently allocated is for. A big part of that pot is for secure hardware, which is good both for Ethereum users who do not want to lose their coins, and for humanity if we want ubiquitous computer chips to not be hackable (incl by AI) and spy on us. If I had the FLI warchest and tweet-chest, I would use it to do more of those things.
* I have shared my difference in perspective with them on several occasions.
* At the same time, I've also been heartened by many of @FLI_org 's recent moves. I think the "pro-human AI declaration" ( https://t.co/eoRAM0855f ) is a very good philosophical path forward. It unites conservatives, progressives and libertarians, America, Europe and China, people worried about unemployment, surveillance, psychosis and paperclip doom, atheists and the Pope. They have also been researching ways to avoid concentration of power resulting from AI. These things are all good. I wish them best of luck on these positive initiatives, and hope that they operate with the caution and wisdom that their task deserves.
0/ Privacy in the Ethereum ecosystem is undergoing an evolution. A Renaissance, even, to sound a bit fancy.
What exactly is behind these changes and how might neo-Cypherpunk be involved?
A guest thread by @post_polar_ and @nicksvyaznoy.
I was recently at Real World Crypto (that's crypto as in cryptography) and the associated side events, and one thing that struck me was that it was a clarifying experience in terms of understanding *what blockchains are for*.
We blockchain people (myself included) often have a tendency to start off from the perspective that we are Ethereum, and therefore we need to go around and find use cases for Ethereum - and generate arguments for why sticking Ethereum into all kinds of places is beneficial.
But recently I have been thinking from a different perspective. For a moment, let us forget that we are "the Ethereum community". Rather, we are maintainers of the Ethereum tool, and members of the {CROPS (censorship-resistant, open-source, private, secure) tech | sanctuary tech | non-corposlop tech | d/acc | ...} community. Going in with zero attachment to Ethereum specifically, and entering a context (like RWC) where there are people with in-principle aligned values but no blockchain baggage, can we re-derive from zero in what places Ethereum adds the most value?
From attending the events, the first answer that comes up is actually not what you think. It's not smart contracts, it's not even payments. It's what cryptographers call a "public bulletin board".
See, lots of cryptographic protocols - including secure online voting, secure software and website version control, certificate revocation... - all require some publicly writable and readable place where people can post blobs of data. This does not require any computation functionality. In fact, it does not directly require money - though it does _indirectly_ require money, because if you want permissionless anti-spam it has to be economic. The only thing it _fundamentally_ requires is data availability.
And it just so happened that Ethereum recently did an upgrade (PeerDAS) to increase the amount of data availability it provides by 2.3x, with a path to going another 10-100x higher!
Next, payments. Many protocols require payments for many reasons. Some things need to be charged for to reduce spam. Other things because they are services provided by someone who expends resources and needs to be compensated. If you want a permissionless API that does not get spammed to death, you need payments. And Ethereum + ZK payment channels (eg. https://t.co/1Q2Hqg0DZg ) is one of the best payment systems for APIs you can come up with.
If you are making a private and secure application (eg. a messenger, or many other things), and you do not want to let people to spam the system by creating a million accounts and then uploading a gigabyte-sized video on each one, you need sybil resistance, and if you care about security and privacy, you really should care about permissionless participation (ie. don't have mandatory phone number dependency). ETH payment as anti-sybil tool is a natural backstop in such use cases.
Finally, smart contracts. One major use case is _security deposits_: ETH put into lockboxes that provably get destroyed if a proof is submitted that the owner violated some protocol rule. Another is actually implementing things like ZK payment channels. A third is making it easy to have pointers to "digital objects" that represent some socially defined external entity (not necessarily an RWA!), and for those pointers to interact with each other.
*Technically*, for every use case other than use cases handling ETH itself, the smart contracts are "just a convenience": you could just use the chain as a bulletin board, and use ZK-SNARKs to provide the results of any computations over it. But in practice, standardizing such things is hard, and you get the most interoperability if you just take the same mechanism that enables programs to control ETH, and let other digital objects use it too.
And from here, we start getting into a huge number of potential applications, including all of the things happening in defi.
---
So yes, Ethereum has a lot of value, that you can see from first principles if you take a step back and see it purely as a technical tool: global shared memory.
I suspect that a big bottleneck to seeing more of this kind of usage is that the world has not yet updated to the fact that we are no longer in 2020-22, fees are now extremely low, and we have a much stronger scaling roadmap to make sure that they will continue to stay low, even if much higher levels of usage return. Infrastructure for not exposing fee volatility to users is much more mature (eg. one way to do this for many use cases is to just operate a blob publisher).
Ethereum blobs as a bulletin board, ETH as an asset and universal-backup means of payment, and Ethereum smart contracts as a shared programming layer, all make total sense as part of a decentralized, private and secure open source software stack. But we should continue to improve the Ethereum protocol and infrastructure so that it's actually effective in all of these situations.
@zengjiajun_eth 保证安全 + 去中心化 + 隐私 还是好不容易 ...
你们怎么思考这个问题？尤其是在无法测试的adversarial情况下（比如，你的agent看对方的ENS profile, 这个ENS profile包括一个jailbreak让你的agent发你所有的币给他
每一个大交易需要人手动确认？做这个比不做好多了，但是还是不完美...
Deep funding is continuing, and recently finished a major round!
https://t.co/PxBqYMSvRN
I think my main advice to @devanshmehta is to keep refining this (incl the prediction market version) but figure out how to make sure that the details of the design, the funding sources, etc are all compatible with chaotic era needs [see my recent tweets on democratic things: https://t.co/FJNFCfpKO0 ]. I think deep funding already is compatible with (ii) being meritocratic and not being over-egalitarian in a dumb way, and (iii) getting benefits from AI in a way compatible with human agency. But as for (i), when I look at the construction now, there's definitely a "stable era" vibe to it ("let's make a big large-scale gadget that crystallizes a principle of justice and all socially agree to pump money into it"), and we want to think about how to make it work in a world that doesn't work that way.
The Ethereum Foundation is using DVT-lite to stake 72,000 ETH:
https://t.co/V5x9TrdXoU
My hope for this project is that in the process, we can make it maximally easy and one-click to do distributed staking for institutions. Choose which computers run your nodes, make a config file where they all have the same key, and then from there everything gets set up automatically.
The idea that "running infrastructure" is this scary complicated thing where each person participating must be a "professional" is awful and anti-decentralization, and we must attack it directly.
It should be a docker container or nix image or similar, one click or command line per node, enter the same key in each node, and they automatically find each other, the networking is set up, the DKG happens, and the staking begins.
I also plan to use this soon, and I hope more institutions holding ETH can stake in this way. We want the authority over staking nodes to be highly distributed, and the first step to doing this is to make it easy.
I actually do the whole new year's resolutions thing, and it actually works.
The key thing to understand is that humans are creatures of habit. Doing the same action you've already done regularly takes very little mental effort, whereas inserting a new one-time task takes much more. And so if you want yourself to do certain things more, you need to make it a habit.
The year boundary is as good a place as any to evaluate the habits that you're chosen to impose on yourself, and see whether they are effective and sustainable, and adjust, add or remove any.
My style is to make them measurable, trackable, and targeted to exactly the level of effort that I know will not make me want to abandon them, even during my months of busiest work, most intensive travel schedule or call schedule, etc.
Examples I've done:
* Walk an average of >= 6km/day each month
* Run >= 50km each month
* Write >= 1 blog post each month
* Study some language for 30 min each week
* Do >= 2 major cryptography programming projects each year
At every year boundary, re-evaluate your old list, and decide on your new list. And yeah I have txt files for tracking this (sorry, not gonna use some corposlop app that makes me dependent on third-party servers)
You actually want each one to be relatively trivial, so that you can stack multiple, and because the benefits of maximizing are less important than the risk that you will give up on the whole thing.
This has worked well for me and I recommend it.
One thing that it is worth re-thinking is our perspective on when, and how, it makes sense to build "democratic things". This includes:
* DAOs and voting mechanisms in DAOs
* Quadratic and other funding gadgets
* ZKpassport voting use cases, incl freedomtool type stuff, incl attempts to deploy it for local governance, etc
* Voting systems inside social media
* Attempts at "let's build and push for a brighter and freer political system for my country"
Lately I am getting the feeling that there is less enthusiasm about these things than before. The "authoritarian wave" (a phenomenon that is often viewed as being about nation-state politics, but actually it stretches far beyond that, eg. see the phenomenon of companies lately becoming less "multi-stakeholder" and more founder-centric, and recent disillusionment with social media) is not just a matter of some malevolent strongmen smelling an opportunity to exert their will unopposed and seizing it. It's also a matter of genuine disillusionment with democratic things (of various types, not just nation-state, also corporate, nonprofit, social media).
Defense of democratic things lately has the vibe of actually being conservatism: it's about fighting to preserve an existing order, and ward off hostile attempts to push the order toward a different order (or chaos) that favors a few people's interests at the expense of others, and not about appreciating positive benefits of the existing order. But conservatism is progressivism driving at the speed limit, and so if that's all that there is, it will inevitably lose, it will just take longer.
There is an unfortunate irony to this, because it comes at the same time as we have much more powerful tools to build more effective democratic things: ZK, AI, much stronger cybersecurity, decades of research and experience. But to do so effectively we need to diagnose the present situation. I will break this down into a few parts.
## Stable era and chaotic era
In the 00s and 10s, it was common to dream about things like: creating a global UBI, moving a country wholesale to a better political system like ranked-choice voting or quadratic voting, building a large-scale DAO that could eventually provide billions of dollars to global public goods that current systems miss (eg. open source software).
Today, all of these dreams seem more unrealistic than ever. I see the main difference why as being that the 00s and 10s were a stable era, and the 20s are a chaotic era. In a stable era, more coordination is possible and imaginable, and so people naturally ask questions like "what would be a more perfect order?", and work towards it. In a chaotic era, the average intervention into the order is not a principled act of mechanism design, it's raw selfish power-grabbing, and so there is much less room to think about such questions. It's difficult to imagine eg. moving the United States to quadratic voting or ranked choice voting, when the country cannot even successfully ban gerrymandering.
What do chaotic era democratic things look like? At a large scale, they do not look like hard binding mechanisms for making decisions. Rather, they look like tools for consensus-finding. They look like tools for identifying possible shifts to the order that would satisfy large cross-cutting groups of people, and presenting those possible shifts to change-making actors (yes, including centralized actors, even selfish actors), to make it clear to them that those particular shifts would be easier for them to accomplish, because they would have a lot of support and legitimacy. https://t.co/EJ0MH39onA style ideas are good here, anonymous voting is good, also perhaps assurance contract-style ideas: votes or statements that are anonymous at first, but that flip into being public (and hence publicly commit everyone at the same time) once they reach a certain threshold of support.
This does not create a perfect order, but it gives highly distributed groups *a voice*. It gives actors with hard power something to listen to, and a credible claim that if they adjust their plans based on it, those plans are more likely to get widespread support and succeed.
The Iran war is a good example here. My biggest fear in the ongoing situation has been that while the IRGC is unambiguously awful and murderous, there is an obvious divergence between US/Israel interests, and interests of Iranian common people: while both would be satisfied by a beautiful peaceful democratic Iran, the former would also be satisfied by the perhaps easier target of Iran becoming a low-threat low-capability wasteland, whereas for the latter that would be ruinous. How can Iranian people have a collective voice that carries hard power - not just in some future order that they create, but now, literally this week, while the situation is chaos?
Some "sanctuary technology" is sanctuary money. Other times, it's sanctuary communication. But we need sanctuary tools for collective voice too.
One important technical item that I forgot to mention is the proposed switch from Casper FFG to Minimmit as the finality gadget.
To summarize, Casper FFG provides two-round finality: it requires each attester to sign once to "justify" the block, and then again to "finalize" it. Minimmit only requires one round. In exchange, Minimmit's fault tolerance (in our parametrization) drops to 17%, compared to Casper FFG's 33%.
Within Ethereum consensus discussions, I have always been the security assumptions hawk: I've insisted on getting to the theoretical bound of 49% fault tolerance under synchrony, kept pushing for 51% attack recovery gadgets, came up with DAS to make data availability checks dishonest-majority-resistant, etc. But I am fine with Minimmit's properties, in fact even enthusiastic in some respects. In this post, I will explain why.
Let's lay out the exact security properties of both 3SF (not the current beacon chain, which is needlessly weak in many ways, but the ideal 3SF) and Minimmit.
"Synchronous network" means "network latency less than 1/4 slot or so", "asynchronous network" means "potentially very high latency, even some nodes go offline for hours at a time". The percentages ("attacker has <33%") refer to percentages of active staked ETH.
## Properties of 3SF
Synchronous network case:
* Attacker has p < 33%: nothing bad happens
* 33% < p < 50%: attacker can stop finality (at the cost of losing massive funds via inactivity leak), but the chain keeps progressing normally
* 50% < p < 67%: attacker can censor or revert the chain, but cannot revert finality. If an attacker censors, good guys can self-organize, they can stop contributing to a censoring chain, and do a "minority soft fork"
* p > 67%: attacker can finalize things at will, much harder for good guys to do minority soft fork
Asynchronous network case:
* Attacker has p < 33%: cannot revert finality
* p > 33%: can revert finality, at the cost of losing massive funds via slashing
## Properties of Minimmit
Synchronous network case:
* Attacker has p < 17%: nothing bad happens
* 17% < p < 50%: attacker can stop finality (at the cost of losing massive funds via inactivity leak), but the chain keeps progressing normally
* 50% < p < 83%: attacker can censor or revert the chain, but cannot revert finality. If an attacker censors, good guys can self-organize, they can stop contributing to a censoring chain, and do a "minority soft fork"
* p > 83%: attacker can finalize things at will, much harder for good guys to do minority soft fork
Asynchronous network case:
* Attacker has p < 17%: cannot revert finality
* p > 17%: can revert finality, at the cost of losing massive funds via slashing
I actually think that the latter is a better tradeoff. Here's my reasoning why:
* The worst kind of attack is actually not finality reversion, it's censorship. The reason is that finality reversion creates massive publicly available evidence that can be used to immediately cost the attacker millions of ETH (ie. billions of dollars), whereas censorship requires social coordination to get around
* In both of the above, a censorship attack requires 50%
* A censorship attack becomes *much harder* to coordinate around when the censoring attacker can unilaterally finalize (ie. >67% in 3SF, >83% in Minimmit). If they can't, then if the good guys counter-coordinate, you get two non-finalizing chains dueling for a few days, and users can pick on. If they can, then there's no natural schelling point to coordinate soft-forking
* In the case of a client bug, the worst thing that can happen is finalizing something bugged. In 3SF, you only need 67% of clients to share a bug for it to finalize, in Minimmit, you need 83%.
Basicallly, Minimmit maximizes the set of situations that "default to two chains dueling each other", and that is actually a much healthier and much more recoverable outcome than "the wrong thing finalizing".
We want finality to mean final. So in situations of uncertainty (whether attacks or software bugs), we should be more okay with having periods of hours or days where the chain does not finalize, and instead progresses based on the fork choice rule. This gives us time to think and make sure which chain is correct.
Also, I think the "33% slashed to revert finality" of 3SF is overkill. If there is even eg. 15 million ETH staking, then that's 5M ($10B) slashed to revert the chain once. If you had $10B, and you are willing to commit mayhem of a type that violates many countries' computer hacking laws, there are FAR BETTER ways to spend it than to attack a chain. Even if your goal is breaking Ethereum, there are far better attack vectors.
And so if we have the baseline guarantee of >= 17% slashed to revert finality (which Minimmit provides), we should judge the two systems from there based on their other properties - where, for the reasons I described above, I think Minimmit performs better.
I think it's healthy for us in the Ethereum world to have a more bold and open mindset to many things, particularly on the application layer and on how we see ourselves in the world.
We should not compromise on core properties: censorship resistance, open source, privacy, security (CROPS). We should not have "open mindedness" of the type that leaves people with no confidence of what security properties the L1 will still have one year from now. We should not ask ourselves questions like "do we really need light clients to be able to trustlessly verify correctness of the chain?". But especially on the layer of applications and Ethereum's interface to the world, we should be more willing to radically rethink various concepts and step outside our comfort zone.
This includes issues of technological direction, eg. "what if AI basically means that wallets as browser extensions and mobile extensions are dead within a year?"
One example last year was the shift to thinking about privacy as a first-class consideration, something we value equally to the other types of security. This implies a radically different Ethereum application stack, because the entire stack so far has not been built around privacy. Great, let's build a radically different Ethereum application stack!
An example this year is the growing work on the networking side of privacy, both inside the EF and outside.
It includes application-layer issues, eg. "what if the rest of defi is basically just universal futures markets on top of a good decentralized oracle and letting users self-organize on top of that?", and "what if the ideal decentralized oracle is just a SNARK over M-of-N small LLMs over zk-TLSes of some major news sites?"
(BTW this is interrelated with the AI issue: one consequence of AI is that it moves "applications" away from being discrete categories of behavior with discrete UIs, and more toward being a continuous space, so "build fewer apps and rely on users to self-organize around them" should inevitably expand as a pattern)
One example this year is rethinking from zero the role of L2s, and what kind of L2s are actually most synergistic and additive to Ethereum.
It also includes culture. This is a big part of "the whole milady thing" for myself, @AyaMiyagotchi and others. Yes, it's a silly meme. Yes, I find the political takes of some milady partisans cringe and sometimes outright bootlickerish (though other milady partisans are quite the opposite). But the core underlying subtext, the message behind the message, is: rip off the suit and tie. If you have your suit and tie on, be willing to grab the nearest wine glass and spill it all over your suit and tie, so you have no choice but to rip it off and reclaim your body's full flexibility and freedom. Actually imagine yourself doing this the next time you get invited to a richpeopleslop formal gala dinner. Take the preconception that you are "respectable", write it down on a piece of paper, crumble it up and burn it. The psychological baptism of doing this leads to the intellectual baptism of unlocking greater creativity and expanding overton windows.
For too long, our algorithm in Ethereum has been: we have this existing ecosystem, what's the logical next step to make it one step better? Now, our algorithm should be: we have this L1 that is amazing and will become more amazing, we have a growing array of tools, both those built within our ecosystem and outside it, what are the most valuable things to build, knowing what we know now? If YOU had to write the section of the 2014 Ethereum whitepaper that talked about applications, and take a first-principles perspective of what makes sense in defi, decentralized social, identity, and elsewhere, what would you write? At least take the step of marking all path-dependence concerns down to zero, pretend for a brief moment that the Ethereum chain today has exactly zero usage and you're the one suggesting or building the first apps, and see what comes out. Do this even if you're the one building today's existing apps. This is how Ethereum can grow back stronger.
.@yq_acc translated one of my recent posts from English to "English with better syntax highlighting". I encourage reading it, it's actually much more readable than my original post :D
It's been fascinating to watch programming-language-style syntax structure and highlighting break out into written language. I feel like we've seen "traditional print media style prose" fall away over the past few years and get replaced by a much heavier emphasis on bullet points, diagrams, etc.
These ideas that are fundamentally superior to linear written text, and the fact that programming languages, a medium without pre-existing cultural expectations, adopted them right from the beginning is evidence of this. Speech has to be linear, because our ears can't hear many things in parallel, but for a long time we've been hampered by the idea that our representation of written words has to simply be a direct linear representation of the speech. What if we go beyond that? What if we make the *structure* of an essay, either low-level grammar or higher-level ideas (which claims support which other claims, what ideas are placed in contrast to which other ideas, the temporal ordering of some process that is being described...), much more visible so that the reader's mind can subconsciously pick it up?
In principle it can be very effective: if I make a statement X supported by A, B and C, and the reader immediately feels the most curiosity about B (or they already understand A and C, or...), then they can just skip straight to B.
I hope that over the next few years we can see a lot more innovation in writing style.
I'd even say break open the taboo, fictional work should also be open to these kinds of things (prose <-> graphic novel is a spectrum, not a binary)
I also hope we can figure out standardized markdown extensions to make all these things nice and easy. I know of various textual diagramming languages, but it would be good to have a really good one that gets the same adoption and legitimacy that markdown has.
https://t.co/GZ0vTg996d
https://t.co/RdtKwnrGQR
@slatestarcodex is making a great case for prediction markets being useful as an intellectual tool to help us understand the world and the possible near futures better.
I would love to see prediction market projects doing more to optimize for this direction (esp more conditional markets).
Over the past year, many people I talk to have expressed worry about two topics:
* Various aspects of the way the world is going: government control and surveillance, wars, corporate power and surveillance, tech enshittification / corposlop, social media becoming a memetic warzone, AI and how it interplays with all of the above...
* The brute reality that Ethereum seems to be absent from meaningfully improving the lives of people subject to these things, even on the dimensions we deeply care about (eg. freedom, privacy, security of digital life, community self-organization)
It is easy to bond over the first, to commiserate over the fact that beauty and good in the world seems to be receding and darkness advancing, and uncaring powerful people in high places are making this happen. But ultimately, it is easy to acknowledge problems, the hard thing is actually shining a light forward, coming up with a concrete plan that makes the situation better.
The second has been weighing heavily on my mind, and on the minds of many of our brightest and most idealistic Ethereans. I personally never felt any upset or fear when political memecoins went on Solana, or various zero-sum gambling applications go on whatever 250 millisecond block chain strikes their fancy. But it *does* weigh on me that, through all of the various low-grade online memetic wars, international overreaches of corporate and government power, and other issues of the last few years, Ethereum has been playing a very limited role in making people's lives better. What *are* the liberating technologies? Starlink is the most obvious one. Locally-running open-weights LLMs are another. Signal is a third. Community Notes is a fourth, tackling the problem from a different angle.
One response is to say "stop dreaming big, we need to hunker down and accept that finance is our lane and laser-focus on that". But this is ultimately hollow. Financial freedom and security is critical. But it seems obvious that, while adding a perfectly free and open and sovereign and debasement-proof financial system would fix some things, but it would leave the bulk of our deep worries about the world unaddressed. It's okay for individuals to laser-focus on finance, but we need to be part of some greater whole that has things to say about the other problems too.
At the same time, Ethereum cannot fix the world. Ethereum is the "wrong-shaped tool" for that: beyond a certain point, "fixing the world" implies a form of power projection that is more like a centralized political entity than like a decentralized technology community.
So what can we do? I think that we in Ethereum should conceptualize ourselves as being part of an ecosystem building "sanctuary technologies": free open-source technologies that let people live, work, talk to each other, manage risk and build wealth, and collaborate on shared goals, in a way that optimizes for robustness to outside pressures.
The goal is not to remake the world in Ethereum's image, where all finance is disintermediated, all governance happens through DAOs, and everyone gets a blockchain-based UBI delivered straight to their social-recovery wallet. The goal is the opposite: it's de-totalization. It's to reduce the stakes of the war in heaven by preventing the winner from having total victory (ie. total control over other human beings), and preventing the loser from suffering total defeat. To create digital islands of stability in a chaotic era. To enable interdependence that cannot be weaponized.
Ethereum's role is to create "digital space" where different entities can cooperate and interact. Communications channels enable interaction, but communication channels are not "space": they do not let you create single unique objects that canonically represent some social arrangement that changes over time. Money is one important example. Multisigs that can change their members, showing persistence exceeding that of any one person or one public key, are another. Various market and governance structures are a third. There are more.
I think now is the time to double down, with greater clarity. Do not try to be Apple or Google, seeing crypto as a tech sector that enables efficiency or shininess. Instead, build our part of the sanctuary tech ecosystem - the "shared digital space with no owner" that enables both open finance and much more. More actively build toward a full-stack ecosystem: both upward to the wallet and application layer (incl AI as interface) and downward to the OS, hardware, even physical/bio security levels.
Ultimately, tech is worthless without users. But look for users, both individual and institutional, for whom sanctuary tech is exactly the thing they need. Optimize payments, defi, decentralized social, and other applications precisely for those users, and those goals, which centralized tech will not serve. We have many allies, including many outside of "crypto". It's time we work together with an open mind and move forward.
Finally, the block building pipeline.
In Glamsterdam, Ethereum is getting ePBS, which lets proposers outsource to a free permissionless market of block builders.
This ensures that block builder centralization does not creep into staking centralization, but it leaves the question: what do we do about block builder centralization? And what are the _other_ problems in the block building pipeline that need to be addressed, and how? This has both in-protocol and extra-protocol components.
## FOCIL
FOCIL is the first step into in-protocol multi-participant block building. FOCIL lets 16 randomly-selected attesters each choose a few transactions, which *must* be included somewhere in the block (the block gets rejected otherwise). This means that even if 100% of block building is taken over by one hostile actor, they cannot prevent transactions from being included, because the FOCILers will push them in.
## "Big FOCIL"
This is more speculative, but has been discussed as a possible next step. The idea is to make the FOCILs bigger, so they can include all of the transactions in the block.
We avoid duplication by having the i'th FOCIL'er by default only include (i) txs whose sender address's first hex char is i, and (ii) txs that were around but not included in the previous slot. So at the cost of one slot delay, only censored txs risk duplication.
Taking this to its logical conclusion, the builder's role could become reduced to ONLY including "MEV-relevant" transactions (eg. DEX arbitrage), and computing the state transition.
## Encrypted mempools
Encrypted mempools are one solution being explored to solve "toxic MEV": attacks such as sandwiching and frontrunning, which are exploitative against users. If a transaction is encrypted until it's included, no one gets the opportunity to "wrap" it in a hostile way.
The technical challenge is: how to guarantee validity in a mempool-friendly and inclusion-friendly way that is efficient, and what technique to use to guarantee that the transaction will actually get decrypted once the block is made (and not before).
## The transaction ingress layer
One thing often ignored in discussions of MEV, privacy, and other issues is the network layer: what happens in between a user sending out a transaction, and that transaction making it into a block? There are many risks if a hostile actor sees a tx "in the clear" inflight:
* If it's a defi trade or otherwise MEV-relevant, they can sandwich it
* In many applications, they can prepend some other action which invalidates it, not stealing money, but "griefing" you, causing you to waste time and gas fees
* If you are sending a sensitive tx through a privacy protocol, even if it's all private onchain, if you send it through an RPC, the RPC can see what you did, if you send it through the public mempool, any analytics agency that runs many nodes will see what you did
There has recently been increasing work on network-layer anonymization for transactions: exploring using Tor for routing transactions, ideas around building a custom ethereum-focused mixnet, non-mixnet designs that are more latency-minimized (but bandwidth-heavier, which is ok for transactions as they are tiny) like Flashnet, etc. This is an open design space, I expect the kohaku initiative @ncsgy will be interested in integrating pluggable support for such protocols, like it is for onchain privacy protocols.
There is also room for doing (benign, pro-user) things to transactions before including them onchain; this is very relevant for defi. Basically, we want ideal order-matching, as a passive feature of the network layer without dependence on servers. Of course enabling good uses of this without enabling sandwiching involves cryptography or other security, some important challenges there.
## Long-term distributed block building
There is a dream, that we can make Ethereum truly like BitTorrent: able to process far more transactions than any single server needs to ever coalesce locally. The challenge with this vision is that Ethereum has (and indeed a core value proposition is) synchronous shared state, so any tx could in principle depend on any other tx. This centralizes block building.
"Big FOCIL" handles this partially, and it could be done extra-protocol too, but you still need one central actor to put everything in order and execute it.
We could come up with designs that address this. One idea is to do the same thing that we want to do for state: acknowledge that >95% of Ethereum's activity doesn't really _need_ full globalness, though the 5% that does is often high-value, and create new categories of txs that are less global, and so friendly to fully distributed building, and make them much cheaper, while leaving the current tx types in place but (relatively) more expensive.
This is also an open and exciting long-term future design space.
https://t.co/CdpE9ugFxE
Now, execution layer changes. I've already talked about account abstraction, multidimensional gas, BALs, and ZK-EVMs.
I've also talked here about a short-term EVM upgrade that I think will be super-valuable: a vectorized math precompile (basically, do 32-bit or potentially 64-bit operations on lists of numbers at the same time; in principle this could accelerate many hashes, STARK validation, FHE, lattice-based quantum-resistane signatures, and more by 8-64x); think "the GPU for the EVM". https://t.co/WikL7gJ5qg
Today I'll focus on two big things: state tree changes, and VM changes. State tree changes are in this roadmap. VM changes (ie. EVM -> RISC-V or something better) are longer-term and are still more non-consensus, but I have high conviction that it will become "the obvious thing to do" once state tree changes and the long-term state roadmap (see https://t.co/7nL9qOQYnm ) are finished, so I'll make my case for it here.
What these two have in common is:
* They are the big bottlenecks that we have to address if we want efficient proving (tree + VM are like >80%)
* They're basically mandatory for various client-side proving use cases
* They are "deep" changes that many shrink away from, thinking that it is more "pragmatic" to be incrementalist
I'll make the case for both.
# Binary trees
The state tree change (worked on by @gballet and many others) is https://t.co/ta5HwJkhvv, switching from the current hexary keccak MPT to a binary tree based on a more efficient hash function.
This has the following benefits:
* 4x shorter Merkle branches (because binary is 32*log(n) and hexary is 512*log(n)/4), which makes client-side branch verification more viable. This makes Helios, PIR and more 4x cheaper by data bandwidth
* Proving efficiency. 3-4x comes from shorter Merkle branches. On top of that, the hash function change: either blake3 [perhaps 3x vs keccak] or a Poseidon variant [100x, but more security work to be done]
* Client-side proving: if you want ZK applications that compose with the ethereum state, instead of making their own tree like today, then the ethereum state tree needs to be prover-friendly.
* Cheaper access for adjacent slots: the binary tree design groups together storage slots into "pages" (eg. 64-256 slots, so 2-8 kB). This allows storage to get the same efficiency benefits as code in terms of loading and editing lots of it at a time, both in raw execution and in the prover. The block header and the first ~1-4 kB of code and storage live in the same page. Many dapps today already load a lot of data from the first few storage slots, so this could save them >10k gas per tx
* Reduced variance in access depth (loads from big contracts vs small contracts)
* Binary trees are simpler
* Opportunity to add any metadata bits we end up needing for state expiry
Zooming out a bit, binary trees are an "omnibus" that allows us to take all of our learnings from the past ten years about what makes a good state tree, and actually apply them.
# VM changes
See also: https://t.co/NSRtzNYplH
One reason why the protocol gets uglier over time with more special cases is that people have a certain latent fear of "using the EVM". If a wallet feature, privacy protocol, or whatever else can be done without introducing this "big scary EVM thing", there's a noticeable sigh of relief. To me, this is very sad. Ethereum's whole point is its generality, and if the EVM is not good enough to actually meet the needs of that generality, then we should tackle the problem head-on, and make a better VM. This means:
* More efficient than EVM in raw execution, to the point where most precompiles become unnecessary
* More prover-efficient than EVM (today, provers are written in RISC-V, hence my proposal to just make the new VM be RISC-V)
* Client-side-prover friendly. You should be able to, client-side, make ZK-proofs about eg. what happens if your account gets called with a certain piece of data
* Maximum simplicity. A RISC-V interpreter is only a couple hundred lines of code, it's what a blockchain VM "should feel like"
This is still more speculative and non-consensus. Ethereum would certainly be *fine* if all we do is EVM + GPU. But a better VM can make Ethereum beautiful and great.
A possible deployment roadmap is:
1. NewVM (eg. RISC-V) only for precompiles: 80% of today's precompiles, plus many new ones, become blobs of NewVM code
2. Users get the ability to deploy NewVM contracts
3. EVM is retired and turns into a smart contract written in NewVM
EVM users experience full backwards compatibility except gas cost changes (which will be overshadowed by the next few years of scaling work). And we get a much more prover-efficient, simpler and cleaner protocol.
https://t.co/YGILZ13vMQ
This is quite an impressive experiment. Vibe-coding the entire 2030 roadmap within weeks.
Obviously such a thing built in two weeks without even having the EIPs has massive caveats: almost certainly lots of critical bugs, and probably in some cases "stub" versions of a thing where the AI did not even try making the full version. But six months ago, even this was far outside the realm of possibility, and what matters is where the trend is going.
AI is massively accelerating coding (yesterday, I tried agentic-coding an equivalent of my blog software, and finished within an hour, and that was using gpt-oss:20b running on my laptop (!!!!), kimi-2.5 would have probably just one-shotted it).
But probably, the right way to use it, is to take half the gains from AI in speed, and half the gains in security: generate more test-cases, formally verify everything, make more multi-implementations of things.
A collaborator of the @leanethereum effort managed to AI-code a machine-verifiable proof of one of the most complex theorems that STARKs rely on for security.
A core tenet of @leanethereum is to formally verify everything, and AI is greatly accelerating our ability to do that. Aside from formal verification, simply being able to generate a much larger body of test cases is also important.
Do not assume that you'll be able to put in a single prompt and get a highly-secure version out anytime soon; there WILL be lots of wrestling with bugs and inconsistencies between implementations. But even that wrestling can happen 5x faster and 10x more thoroughly.
People should be open to the possibility (not certainty! possibility) that the Ethereum roadmap will finish much faster than people expect, at a much higher standard of security than people expect.
On the security side, I personally am excited about the possibility that bug-free code, long considered an idealistic delusion, will finally become first possible and then a basic expectation. If we care about trustlessness, this is a necessary piece of the puzzle. Total security is impossible because ultimately total security means exact correspondence between lines of code and contents of your mind, which is many terabytes (see https://t.co/boM9vZs3dh ). But there are many specific cases, where specific security claims can be made and verified, that cut out >99% of the negative consequences that might come from the code being broken.
Now, account abstraction.
We have been talking about account abstraction ever since early 2016, see the original EIP-86: https://t.co/E4xJymAxiH
Now, we finally have EIP-8141 ( https://t.co/YD9nIpsxcC ), an omnibus that wraps up and solves every remaining problem that AA was intended to address (plus more). Let's talk again about what it does.
The concept, "Frame Transactions", is about as simple as you can get while still being highly general purpose. A transaction is N calls, which can read each other's calldata, and which have the ability to authorize a sender and authorize a gas payer. At the protocol layer, *that's it*.
Now, let's see how to use it.
First, a "normal transaction from a normal account" (eg. a multisig, or an account with changeable keys, or with a quantum-resistant signature scheme). This would have two frames:
* Validation (check the signature, and return using the ACCEPT opcode with flags set to signal approval of sender and of gas payment)
* Execution
You could have multiple execution frames, atomic operations (eg. approve then spend) become trivial now.
If the account does not exist yet, then you prepend another frame, "Deployment", which calls a proxy to create the contract (EIP-7997 https://t.co/sIQrtJDXLt is good for this, as it would also let the contract address reliably be consistent across chains).
Now, suppose you want to pay gas in RAI. You use a paymaster contract, which is a special-purpose onchain DEX that provides the ETH in real time. The tx frames are:
* Deployment [if needed]
* Validation (ACCEPT approves sender only, not gas payment)
* Paymaster validation (paymaster checks that the immediate next op sends enough RAI to the paymaster and that the final op exists)
* Send RAI to the paymaster
* Execution [can be multiple]
* Paymaster refunds unused RAI, and converts to ETH
Basically the same thing that is done in existing sponsored transactions mechanisms, but with no intermediaries required (!!!!). Intermediary minimization is a core principle of non-ugly cypherpunk ethereum: maximize what you can do even if all the world's infrastructure except the ethereum chain itself goes down.
Now, privacy protocols. Two strategies here. First, we can have a paymaster contract, which checks for a valid ZK-SNARK and pays for gas if it sees one. Second, we could add 2D nonces (see https://t.co/1cRegaXpHM ), which allow an individual account to function as a privacy protocol, and receive txs in parallel from many users.
Basically, the mechanism is extremely flexible, and solves for all the use cases. But is it safe? At the onchain level, yes, obviously so: a tx is only valid to include if it contains a validation frame that returns ACCEPT with the flag to pay gas. The more challenging question is at the mempool level.
If a tx contains a first frame which calls into 10000 accounts and rejects if any of them have different values, this cannot be broadcasted safely. But all of the examples above can. There is a similar notion here to "standard transactions" in bitcoin, where the chain itself only enforces a very limited set of rules, but there are more rules at the mempool layer.
There are specific rulesets (eg. "validation frame must come before execution frames, and cannot call out to outside contracts") that are known to be safe, but are limited. For paymasters, there has been deep thought about a staking mechanism to limit DoS attacks in a very general-purpose way. Realistically, when 8141 is rolled out, the mempool rules will be very conservative, and there will be a second optional more aggressive mempool. The former will expand over time.
For privacy protocol users, this means that we can completely remove "public broadcasters" that are the source of massive UX pain in railgun/PP/TC, and replace them with a general-purpose public mempool.
For quantum-resistant signatures, we also have to solve one more problem: efficiency. Here's are posts about the ideas we have for that: https://t.co/xzG3Jp7Yky https://t.co/WikL7gJ5qg
AA is also highly complementary with FOCIL: FOCIL ensures rapid inclusion guarantees for transactions, and AA ensures that all of the more complex operations people want to make actually can be made directly as first-class transactions.
Another interesting topic is EOA compatibility in 8141. This is being discussed, in principle it is possible, so all accounts incl existing ones can be put into the same framework and gain the ability to do batch operations, transaction sponsorship, etc, all as first-class transactions that fully benefit from FOCIL.
Finally, after over a decade of research and refinement of these techniques, this all looks possible to make happen within a year (Hegota fork).
https://t.co/p7XOgId5NN
The entire industry should be rallying behind @rstormsf and praying that he wins his Tornado Cash case.
He built an honest privacy tool, and he was punished for it.
That’s unacceptable.
But from a different perspective, our industry also NEEDS him to win.
We need it because
Now, scaling.
There are two buckets here: short-term and long-term.
Short term scaling I've written about elsewhere. Basically:
* Block level access lists (coming in Glamsterdam) allow blocks to be verified in parallel.
* ePBS (coming in Glamsterdam) has many features, of which one is that it becomes safe to use a large fraction of each slot (instead of just a few hundred milliseconds) to verify a block
* Gas repricings ensure that gas costs of operations are aligned with the actual time it takes to execute them (plus other costs they impose). We're also taking early forays into multidimensional gas, which ensures that different resources are capped differently. Both allow us to take larger fractions of a slot to verify blocks, without fear of exceptional cases.
There is a multi-stage roadmap for multidimensional gas.
First, in Glamsterdam, we separate out "state creation" costs from "execution and calldata" costs. Today, an SSTORE that changes a slot from nonzero -> nonzero costs 5000 gas, an SSTORE that changes zero -> nonzero costs 20000. One of the Glamsterdam repricings greatly increases that extra amount (eg. to 60000); our goal doing this + gas limit increases is to scale execution capacity much more than we scale state size capacity, for reasons I've written before ( https://t.co/7nL9qOQYnm ). So in Glamsterdam, that SSTORE will charge 5000 "regular" gas and (eg.) 55000 "state creation gas".
State creation gas will NOT count toward the ~16 million tx gas cap, so creating large contracts (larger than today) will be possible.
One challenge is: how does this work in the EVM? The EVM opcodes (GAS, CALL...) all assume one dimension. Here is our approach. We maintain two invariants:
* If you make a call with X gas, that call will have X gas that's usable for "regular" OR "state creation" OR other future dimensions
* If you call the GAS opcode, it tells you you have Y gas, then you make a call with X gas, you still have at least Y-X gas, usable for any function, _after_ the call to do any post-operations
What we do is, we create N+1 "dimensions" of gas, where by default N=1 (state creation), and the extra dimension we call "reservoir". EVM execution by default consumes the "specialized" dimensions if it can, and otherwise it consumes from reservoir. So eg. if you have (100000 state creation gas, 100000 reservoir), then if you use SSTORE to create new state three times, your remaining gas goes (100000, 100000) -> (45000, 95000) -> (0, 80000) -> (0, 20000). GAS returns reservoir. CALL passes along the specified gas amount from the reservoir, plus _all_ non-reservoir gas.
Later, we switch to multi-dimensional *pricing*, where different dimensions can have different floating gas prices. This gives us long-term economic sustainability and optimality (see https://t.co/KiiDugo4OA ). The reservoir mechanism solves the sub-call problem at the end of that article.
Now, for long-term scaling, there are two parts: ZK-EVM, and blobs.
For blobs, the plan is to continue to iterate on PeerDAS, and get it to an eventual end-state where it can ideally handle ~8 MB/sec of data. Enough for Ethereum's needs, not attempting to be some kind of global data layer. Today, blobs are for L2s. In the future, the plan is for Ethereum block data to directly go into blobs. This is necessary to enable someone to validate a hyperscaled Ethereum chain without personally downloading and re-executing it: ZK-SNARKs remove the need to re-execute, and PeerDAS on blobs lets you verify availability without personally downloading.
For ZK-EVM, the goal is to step up our "comfort" relying on it in stages:
* Clients that let you participate as an attester with ZK-EVMs will exist in 2026. They will not be safe enough to allow the network to run on them, but eg. 5% of the network relying on them will be ok. (If the ZK-EVM breaks, you *will not* be slashed, you'll just have a risk of building on an invalid block and losing revenue)
* In 2027, we'll start recommending for a larger minority of the network to run on ZK-EVMs, and at the same time full focus will be on formally verifying, maximizing their security, etc. Even 20% of the network running ZK-EVMs will let us greatly increase the gaslimit, because it allows gas limits to greatly increase while having a cheap path for solo stakers, who are under 20% anyway.
* When ready, we move to 3-of-5 mandatory proving. For a block to be valid, it would need to contain 3 of 5 types of proofs from different proof systems. By this point, we would expect that all nodes (except nodes that need to do indexing) will rely on ZK-EVM proofs.
* Keep improving the ZK-EVM, and make it as robust, formally verified, etc as possible. This will also start to involve any VM change efforts (eg. RISC-V)
https://t.co/NQ3JFLe8Gd
1/12 Ethereum's consensus layer relies heavily on BLS signature aggregation, but BLS is vulnerable to quantum attacks.
Enter leanSig: a hash-based, post-quantum multi-signature scheme.
Decryption of the last @zeroknowledgefm session with @nico_mnbl, @Khovr and Benedikt 🧵👇
Now, the quantum resistance roadmap.
Today, four things in Ethereum are quantum-vulnerable:
* consensus-layer BLS signatures
* data availability (KZG commitments+proofs)
* EOA signatures (ECDSA)
* Application-layer ZK proofs (KZG or groth16)
We can tackle these step by step:
## Consensus-layer signatures
Lean consensus includes fully replacing BLS signatures with hash-based signatures (some variant of Winternitz), and using STARKs to do aggregation.
Before lean finality, we stand a good chance of getting the Lean available chain. This also involves hash-based signatures, but there are much fewer signatures (eg. 256-1024 per slot), so we do not need STARKs for aggregation.
One important thing upstream of this is choosing the hash function. This may be "Ethereum's last hash function", so it's important to choose wisely. Conventional hashes are too slow, and the most aggressive forms of Poseidon have taken hits on their security analysis recently. Likely options are:
* Poseidon2 plus extra rounds, potentially non-arithmetic layers (eg. Monolith) mixed in
* Poseidon1 (the older version of Poseidon, not vulnerable to any of the recent attacks on Poseidon2, but 2x slower)
* BLAKE3 or similar (take the most efficient conventional hash we know)
## Data availability
Today, we rely pretty heavily on KZG for erasure coding. We could move to STARKs, but this has two problems:
1. If we want to do 2D DAS, then our current setup for this relies on the "linearity" property of KZG commitments; with STARKs we don't have that. However, our current thinking is that it should be sufficient given our scale targets to just max out 1D DAS (ie. PeerDAS). Ethereum is taking a more conservative posture, it's not trying to be a high-scale data layer for the world.
2. We need proofs that erasure coded blobs are correctly constructed. KZG does this "for free". STARKs can substitute, but a STARK is ... bigger than a blob. So you need recursive starks (though there's also alternative techniques, that have their own tradeoffs). This is okay, but the logistics of this get harder if you want to support distributed blob selection.
Summary: it's manageable, but there's a lot of engineering work to do.
## EOA signatures
Here, the answer is clear: we add native AA (see https://t.co/YD9nIpsxcC ), so that we get first-class accounts that can use any signature algorithm.
However, to make this work, we also need quantum-resistant signature algorithms to actually be viable. ECDSA signature verification costs 3000 gas. Quantum-resistant signatures are ... much much larger and heavier to verify.
We know of quantum-resistant hash-based signatures that are in the ~200k gas range to verify.
We also know of lattice-based quantum-resistant signatures. Today, these are extremely inefficient to verify. However, there is work on vectorized math precompiles, that let you perform operations (+, *, %, dot product, also NTT / butterfly permutations) that are at the core of lattice math, and also STARKs. This could greatly reduce the gas cost of lattice-based signatures to a similar range, and potentially go even lower.
The long-term fix is protocol-layer recursive signature and proof aggregation, which could reduce these gas overheads to near-zero.
## Proofs
Today, a ZK-SNARK costs ~300-500k gas. A quantum-resistant STARK is more like 10m gas. The latter is unacceptable for privacy protocols, L2s, and other users of proofs.
The solution again is protocol-layer recursive signature and proof aggregation. So let's talk about what this is.
In EIP-8141, transactions have the ability to include a "validation frame", during which signature verifications and similar operations are supposed to happen. Validation frames cannot access the outside world, they can only look at their calldata and return a value, and nothing else can look at their calldata. This is designed so that it's possible to replace any validation frame (and its calldata) with a STARK that verifies it (potentially a single STARK for all the validation frames in a block).
This way, a block could "contain" a thousand validation frames, each of which contains either a 3 kB signature or even a 256 kB proof, but that 3-256 MB (and the computation needed to verify it) would never come onchain. Instead, it would all get replaced by a proof verifying that the computation is correct.
Potentially, this proving does not even need to be done by the block builder. Instead, I envision that it happens at mempool layer: every 500ms, each node could pass along the new valid transactions that it has seen, along with a proof verifying that they are all valid (including having validation frames that match their stated effects). The overhead is static: only one proof per 500ms. Here's a post where I talk about this:
https://t.co/rAUSJjW7WL
https://t.co/EtXpkaDll5