I updated my 2023 roadmap diagram to overlay where the items that were there sit in the current Strawmap ( ). In general, a lot of overlap, but: * Some things got reshuffled in order (eg. quantum safety up-prioritized) * Some things deprioritized (eg. VDFs; many EVM improvements) * Some things replaced with superior constructions (eg. Verkle -> unified BT -> PBT; state expiry -> new state types) What's most striking, however, is that some completely new things are in the strawmap that are NOT in this diagram, because they were not in the 2023 roadmap at all. These reflect changing priorities. Notably: * First-class attention to strong privacy. This covers: keyed nonces and recent roots, aspects of FOCIL, lean privacy pool & wormholes * Aggressive scaling in the context of post-quantum. This covers: leanSPHINCS signatures and aggregation, zkzk frames (see ) * Lean-ification of the spec, to assist in formal verification (full FV of everything is only possible because of modern AI) * Blob and gas futures (this idea just didn't exist back in 2023) * Native rollups (SNARKs were nowhere near mature enough to even consider this back in 2023) * A more open design space for the "future of the EVM". zkzk frames already implies that the protocol will expose to users some ISA that's not the EVM - current leading candidates are leanISA and RISC-V. These ISAs are more simple, modern and efficient than the EVM. Once they're there, why not expose them to developers everywhere? (And then, why not turn the EVM into being an IR on top of that ISA, instead of an enshrined feature massively complicating the base protocol?) Though much of the deeper exploration here is too early even for the strawmap. * New state types are not just a replacement for expiry, they're a fundamentally different paradigm to how Ethereum does scaling A common theme in scaling, found in both state types and zkzk frames (both new ideas), is that instead of trying to maximally scale ALL ethereum activity, we try to create specialized mechanisms that have more restrictive properties that make them more scaling-friendly, while supporting the heaviest loads incurred by users and applications today (eg. token transfers, swaps) and tomorrow (eg. privacy protocols). The other common theme is treating STARKs and AI-accelerated FV as first-class objects, that we are okay betting the technical future of Ethereum on. There are recursive STARKs in many layers of the protocol, one particular primitive (the "aggregate to union verified dependencies" primitive) is expected to be used in *three* places in the protocol: EL, CL and DL. This can only be safe with formal verification, which is itself only feasible with modern AI tools. In general, many steps forward in maturity. And a huge amount of hard work by many dozens of Ethereum researchers and developers on all of these features. Ethereum will be quantum-safe. Ethereum will put users' privacy first. Ethereum will be secure. Ethereum will be censorship-resistant. Ethereum will be highly performant and scalable while satisfying the above. And Ethereum will be Lean.

Minimax H3 is the first *open* video model I've seen that outperforms HunyuanVideo 1.5 - which is actually an impressive accomplishment for @TencentHunyuan to have held that throne for so long. For a while now I've been sad that the image/video frontier seemed to be getting much more closed than the text LLM frontier. H3 is a very strong step back in the open direction. This was generated in ~30 min on my AMD laptop:

Very welcome recent news from Signal: they are working on letting you register an account without a phone number. That said, an important counterpoint about what this would and would not accomplish. The good #1#: reducing dependence on phone numbers. Even aside from privacy benefits, reducing dependency on a highly oligopolistic system of chokepoints is good in itself. The good #2#: phone numbers are for many people not a good "root" of identity from an access control perspective. Phone numbers get sim swapped all the time. The good #3#: allowing phone-number-free accounts will make it harder for them in the future to discriminate against people by country - and so make it harder for governments to pressure them to block their own citizens. Now, on privacy. Significantly better than status quo, so yes it is good #4#, but... In practice, in 2026, I believe that pseudonymity (a long-term persistent account that is not tied to your primary identity) is a dead concept. There are just too many channels by which we accidentally slowly leak data about who we are - timing of messages, the pattern of who we send messages to with what frequency, size, etc. And too many highly effective AI-based means (both using LLMs per-user, and LLMs helping every person and agency under the sun use math that we had all along) to uncover and piece together those hints. As a trivial example, whatever server you interact with learns your IP address, but even if you hide *that* with a VPN or Tor, there are many other identity leakage vectors. And so the only defensible form of privacy is *message-by-message unlinkability* - no one except sender and receiver knows the (sender, receiver) pair, ideally even not knowing who the sender or the receiver are. A natural taxonomy of privacy is the following 2x2: * Sitting duck: adversary knows "X did Y" * Confidentiality: adversary knows "X did ???" [E2E encryption provides this] * Anonymity: adversary knows "??? did Y" [aka message-by-message unlinkability] * Ideal: adversary knows "??? did ???" Signal has already had confidentiality for a long time. (Note: in other contexts, "confidentiality" sometimes means "someone knows X did Y, and we trust that someone to not reveal it", ie. not true privacy. Here, by confidentiality we mean hiding contents from third parties) This adds pseudonymity: in the above schema, adversary knows "0x8b512c... did Y", where they don't initially know who 0x8b512c... is, but may figure that out over time. The ideal is getting to message-by-message unlinkability. Actually accomplishing that gets into territory that is currently being explored by mixnet projects as well as newer messengers, eg. @session_app and @SimpleXChat. Once we get deeper into this territory, I suspect the primary frontier will be spam and DoS protection. Right now, much of the internet blocks all Tor exit nodes - not because they personally hate privacy, but because that's where DoS attacks come from. So we need ways for people to prove their non-spammer status while maintaining message-by-message unlinkability. See here for one direction (which complements nicely). So I hope that we appreciate the victory that is mainstreaming of end-to-end encryption, that we actually get Signal accounts without phone number dependency (it's a great thing even if it had zero privacy consequences), and then that we keep moving forward and pushing the frontier of data leakage minimization.

It's hard to believe it's already been 11 years. On July 30 2015 we launched Ethereum from a small scrappy office in Berlin's Kreuzberg. So much has changed since then. Ethereum has undergone so many transformations yet one thing stays the same. Ethereum is the world computer.

We’re pleased to welcome @pcaversaccio to the EF Board. A longtime Ethereum contributor, co-founder of SEAL 911, Silviculture Society member, and privacy and security maximalist, pc has consistently championed the values at Ethereum’s core. We look forward to working together to help steward Ethereum’s long-term future. Read more:

This is quite a good article on how the cubic formula works, and particularly how root-finding is connected to symmetries (key background for understanding the impossibility of a quintic formula)

A new type of "high-level programming language" that seems really worth trying to make, is a language that gets compiled to Lean (or HOL, or...) that is specifically about making it as friendly as possible for a human to read definitions and theorems. Not the proofs - as all that matters with proofs is that the proofs are correct - just the definitions and theorems. The intended use case is that AI outputs a blob of proofs, and you're trying to make it as easy as possible for anyone reading the output to understand what the actual precise claims are that have been proven

Thread: how I think about the growth of AI capabilities and what it means for us as they keep getting stronger. I think the right model for comparing humans and AI is not any single dimension like intelligence or aggregate performance on economic tasks. Rather, I view both humans and machines as having a whole range of capabilities. This includes both physical (eg. doing things with our hands, walking) and mental (eg. strategic thinking, mental math, emotional intelligence). For most of human history, machines have only exceeded us in very few areas, eg. a strong early example is water and windmills. So we can look at the situation in 1500 like this:

One thing I find striking in the discourse between AI 2040 and its detractors is that the two seem to be locked in to totally incompatible worldviews of how fast and how much of a big deal AI progress is: * In AI 2040, every scenario sees superintelligence of some kind emerging by 2040, unless a herculean effort is made to completely stop it * Detractors say things like "AI 2040 is naive about human coordination ability and a threat to freedom", but don't seem to see any naivety in assuming that the ASI transition will just go well by default, don't seem to see ASI itself as a massive power concentrator risk, and don't seem to feel fear of humanity's "hard power" dropping to zero if ASIs can do literally every task better than we can. This stance makes total sense in a "AI is normal technology" world, zero sense in a world where superintelligence is possible by 2030 and almost guaranteed by 2040 I think my beliefs are: - If I was confident that (present-day-style) AI is normal technology, I would be in the detractor camp - If I was confident that superintelligence is coming in 2030 by default, I would be closer to the AI 2040 camp - it's naive, but every other option is naive squared? But my problem is that I feel great uncertainty and have no idea which of the two worlds (or some other third thing) we're living in? Hence why I continue to be open-minded about slowdowns/pauses, but also I feel very uncomfortable with the "open source bad, the good outcome is the one where our guys have controlling global dominance" push coming from some major AI companies and intellectuals - in a "normal" world that's the sort of thing that triggers every political alarm bell at the same time. A big reason why I have been advocating and trying my best to support the d/acc platform (rapid up-skilling in formal verification, cryptography, secure and open hardware, pandemic resistance and other defensive biotech, food and basic resource security, public epistemics, non-power-concentrating versions of physical security) is that these things are clearly worth doing in both worlds. The 2040 plan is already much more open source friendly (even mandating it! yay). It also includes "mutually assured compute destruction" ideas which (if they work) effectively give one of 2-5 actors the ability to trigger a global compute winter - as opposed to giving 1-5 actors the ability to selectively disenfranchise people they consider baddies while exempting themselves. This is also a big improvement. So I can see the earnest attempts to improve along the dimensions detractors criticize on ("does this concentrate power in big AI labs and superpower governments?"), and I appreciate this. I think many people don't appreciate enough the differences between different "kinds" of pause buttons, and how some concentrate power far more than others. Probably we can think harder and improve even more here. But on the "slowdown/pause or not" topic, there isn't a magic "escape the tradeoff" button. The Hansonian in me says: the winning deal is a deal which, from the perspective of both sides' present-day beliefs and knowledge, both sides would accept, though for different reasons. If the crux is AI progress speed, then identify a set of pre-agreed triggers for "okay, serious shit is happening" [super-pandemics? >25% unemployment? something involving slaughterbots?], and pre-agree that we become much more open-minded to the slowdown or pause thing if enough triggers come to pass within some timeframe. 2040 detractors (who clearly implicitly think that we'll see amazing speedup of progress from AI but think that what I call the "serious shit" category is overhyped) will accept expecting that the triggers don't come to pass, and AI worriers will accept expecting that they will. Pre-agreeing on the specific triggers means that once the triggers either hit or don't hit, there is stronger legitimacy around the idea that one side's worldview turned out more correct and we should be more inclined toward their program. If I were @elonmusk (or zuck, or...) I would re-tool twitter much more heavily into being a platform for helping to identify and make these kinds of grand win-win deals, so that we can bypass big-country governments and big-company CEOs and big nonprofit intellectuals and give more people a voice in the discussion. It's possibly one of the best things that social media _could_ do for humanity if it wanted to. But again, maybe this is also naive. Actually, probably it's naive. But currently, I see zero plans for how to deal with an ASI transition that are not naive. Perhaps humanity is stuck with a choice between naive and naive squared (or maybe even naive squared and naive cubed), so I feel inclined to cut some slack to people who are trying.

And ... we have a winner! My method when writing the post in 2024 was: I wrote it in Chinese, used qwen2.5 locally to translate it to English, then manually fixed all the bugs in the translation. Notice that the stylistic hints that his AI picked up on were intellectual habits and style of math and algorithm explanation, which bypassed my obfuscation strategy (which only covered prose) completely.

Native UTXOs on Ethereum. Payments should be one-shot objects, not permanent state. Bitcoin got this right. Ethereum can bring the same idea to payments: prove existence from history, keep only a spent bit in state, and reduce permanent state by ~99.8%. Check out the blog post for details.

If we want to make the Lean Ethereum consensus chain aggressively more "lean", and add strong validator privacy (ZK-unlink deposit from staking activity from withdrawal, and re-anonymize stakers every day), here is a path:

13 days. So far no one has found it. My only hint is that I would encourage people to somewhat broaden their search; I've seen quite a few searches and AI scripts that fail to include categories of documents that really should be included.

Two weeks ago, Ethereum researchers met in Berlin to continue charting the protocol's long-term trajectory, following along discussions with client teams in Svalbard in April. The updated strawmap is at and I attached a picture of it to this post. My own high-level takeaways: * "Lean Ethereum" is not a single one-shot upgrade, it is a collection of improvements that will come online to the Ethereum network over the course of three or four years. But make no mistake, this IS the third major iteration of Ethereum in the same way that the Merge was the second. Almost every major piece of the protocol will be replaced: - Verification through recursive STARKs, rather than direct re-execution. Recursive STARKs become an enshrined first-class core component of the protocol - Replacing everything quantum-vulnerable with quantum-safe alternatives - Consensus: decoupled available chain and finality, one or two-round finality. Theoretically optimal security properties, simpler than today, and faster than today - Multidimensional gas - State: not just tree structure, but what *types* of state are available - Changes to client architecture ... At the same time, simplification, cleanup and future-proofing. And this will all be done in a way that minimizes disruption to existing application. We've done this before (the Merge), we can do it again. * H-star (aka Hegota) is probably Ethereum's last thematically "pre-Lean" fork. Starting from I-star, most of everything we do will have a very strong "Lean" feel to it in one way or another. * Privacy is no longer an afterthought, it is a first class goal. When designing Frames, the mempool, additions to the state tree, we explicitly ask the question "okay, how do quantum-safe, intermediary-free privacy protocol transactions go through this, and what is the overhead?" * Formal verification of everything for security. * FV also makes us much more comfortable with canonicalization (having pieces of the protocol that are directly defined as a piece of bytecode expressed in some language). evm-asm is being written in part to become a canonical proof system for the EVM. * Quantum safety has shifted up a LOT in priority. This adds a lot of work (eg. finalizing a quantum-safe blobs design has become urgent; this work has already been ongoing for months) * Probably the single most disruptive part of the plan is the changes to state. There is growing consensus around leaving present-day-style "dynamic state" mostly unchanged, but scaling it only a medium amount, and adding new types of state that are more scalability-friendly (eg. no need for builders to sync/store all of it) but more restrictive, and that will scale a large amount. eg. possible Ethereum in 2030: 2 TB of present-day-style (dynamic) state, and 100 TB of new-style (scalable but restrictive) state This "new-style" state would work very well for ERC20s, NFTs, many defi use cases, but not eg. highly "central" objects like Uniswap contracts, or onchain order books, or other complex things (which are crucial for Ethereum but which only take up a small percentage of state) Hence, it will not be *necessary* to rewrite any apps, but it will be *very cost-effective* to eg. rewrite an ERC20 token into a newer design that uses a new type of UTXO storage that is currently being explored, so that it will have >10x lower txfees. Design of these new state types (current ideas: keyed nonces, ring buffers, UTXOs, statically accessible state, temp state) is an area where we will need a lot of feedback from application developers (incl. privacy-friendly application developers) and probably several rounds of rethinking and iteration. * In the context of a much larger total state size, we need to figure out the incentive issues around who stores this state and what motivates them to. Even saying "each node stores 1%" is not good enough - why do they store that 1% and why are they willing to serve it? This is being elevated as a first-class research area. * Ethereum will need to have a "VM" other than EVM in one form or another - at the very least, we need something like leanISA for recursive STARKs - and the gains are large in exposing it to users so that we support programmable privacy and better scalability. Right now, the most likely contenders are leanISA and RISC-V. My own ideal is that in this world, we adjust the protocol so that the EVM becomes a high-level-language compiler-level feature, and the protocol only "sees" RISC-V / leanISA directly. But this is still far away. * Gas limit increases, blob increases and slot time decreases will happen many times over the next ~5 years. We expect a large gas limit increase with Glasterdam. Each step of increased scale or decreased slot time is a matter of getting to the point where it is safe to do it, which comes from a combination of client optimization and protocol changes. Ethereum is CROPS. Ethereum is scaling. Ethereum is reinventing itself. Onward.

"Pokemon" is short for "pocket monsters". "Digimon" is short for "digital monsters". Therefore, "salmon" is short for "saltwater monsters". (You might object: salmon spend a big part of their life in freshwater. But pokemon spend a big part of their life outside pockets too!)