Anders Elowsson 🌻

Very closely aligned with Consentrifuge that I pitched internally in the beginning of 2025. Seems like the right way to go @anderselowsson/Consentrifuge" target="_blank" rel="nofollow noopener">notes.ethereum.org/@anderselowsso…

We thank the EF cryptography team, including Benedikt Wagner and Gottfried Herold; the @ShutterNetwork team, including @AnotherJannik, @bezzenberger, @LoringHarkness and @acaravello; and @potuz_eth.

We further outline how LUCID naturally extends to a one-slot design, how frame transactions can be integrated both for STs and for the bundles that carry the STs, the prospect of integrating a trust graph, and alternative bundling options.

The full LUCID encrypted mempool EIP-8184 is now up! LUCID is a public encrypted mempool for commit-before-reveal inclusion of MEV-sensitive transactions, without enshrining a specific encryption scheme. With coauthors @_julianma and @robocopsgonemad ethereum-magicians.org/t/eip-8184-luc…

And more generally: the oracle becomes the target.

Goodhart's Law: When a measure becomes a target, it ceases to be a good measure. Badheart's Law: When reality is financialized, it ceases to be merely observed, and the journalist becomes the target.

FOCIL 🤝 Native Account Abstraction Given the recent discussions on what EL headliner could be shipped with FOCIL for Hegota, here is a post explaining how FOCIL and FrameTxs interact. tldr: FOCIL enforces censorship resistance by using cheap post-state checks to detect when builders wrongly exclude transactions from their blocks. This works well for EOAs and EIP-7702 accounts. But for native account abstraction, validity depends on running arbitrary code that can touch state outside of the account. 👇🧵

Ethereum needs an Encrypted Mempool and it needs it fast. It's not just about stopping sandwiching. Encrypted mempools are how Ethereum matures its onchain markets. I just published a post on why Ethereum needs encrypted mempools. Here are the core arguments:

New post introducing Snap v2 for Ethereum sync. TL;DR: replace trie healing entirely by applying Block-Level Access Lists (BALs). Instead of iteratively discovering what changed one trie node at a time, nodes can just download the state diffs from BALs and apply them. Simpler protocol, way fewer round trips, and a sync design that's ready for higher gas limits and continued state growth. 🔗 ethresear.ch/t/snap-v2-repl…

Why do so many people choose to lend out ETH on Aave for 2% instead of stake via Lido for 3% yield? In a new paper with Joel Hasbrouck, @cryptoeconprof, and @casparschwa we build a structural econometric model and estimate it with data from Aave and Lido. The result? There is a huge market inefficiency that cannot be explained by smart contract risk, depeg risk, or any other risk.

First draft PR for the LUCID encrypted mempool available here: github.com/ethereum/EIPs/…

Who is that someone though? The builder of block N does not have any influence. He cannot change anything once committed in the bid for Block N. The eventual builder of block N+1 has not yet won the auction. The proposer of block N+1 could indeed make decisions on which interpretation of the PTC vote it favors under some designs, but the impact of having the absolute ability to influence top of block N+1 is essentially possible today as well. The proposer will be open to various bids for various states under the 50/50 blocks that he may be exposed to, where builders try to gain orderflow for the most profitable state they can create.

@weboftrees @markus_ @DistributedMarz I think the complain here is about owning information: someone knows way earlier than the rest, which tx will actually be executed top of N+1, even before N+1 having been built, and this gives them a lot of advantage to perpetuate winning the auction.

People keep talking about this artificial delay which is inconsequential. It is a common misconception, from the point of view of the tx sender, that tx is executed at the bottom of the *current* slot.

@potuz_eth @DistributedMarz There is no direct PTC vote on the keys in this version. The decryptors publish the keys, and they are observed by the next-slot attesters or PTC, who freeze their view before the slot commences. The builder can include keys coming in after the freeze-deadline to merge views.

@weboftrees @DistributedMarz Now I'm lost. Same slot reveal seems impossible to me. It sounds that in case of a split vote, a delay until the CL block of N+1 is inevitable. And bribing PTC becomes very profitable cause he who holds the clear text has an advantage to win the next blog

@potuz_eth @markus_ @DistributedMarz I mean, if you are not the first transaction in the next block, the number of possible states you face is already infinite..? It seems to me that this is ultimately a question of the relationship between the builder and the transactor?

No this is very different, as soon as the Payload appears, everyone can start building on top of the previous and/or the current Payload, with encrypted txs the number of possible post states explodes and no one really knows what the next builder will include unless PTC vote was clear

@potuz_eth @DistributedMarz Maybe I was unclear. I meant view-merge on the keys, as in the original LUCID post, and not on the PTC votes. There are a few options, e.g., the builder includes the keys in the block, or just flags key-adherence.

@weboftrees @DistributedMarz Yes merge view is an option to try to converge on the PTC vote but that will probably force the votes to be included on chain to force the N+1 proposers' view and anyway delays the post state until at least the CL block of N+1 if the PTC vote is split

@potuz_eth @DistributedMarz We can as an option do view merge on the keys instead of holding a PTC vote. This has different potential downsides (e.g., associated with keys only being shared privately), but reduces the risk of bribery. Related: in the latest LUCID design, there is a penalty for non-reveal.

@DistributedMarz @weboftrees I think you have a very good point that the design does make it profitable to play with timelines and edges on the PTC, in ways that makes them possible colluders (forked clients to sell PTC votes?) and perhaps more dangerous than the free option problem.

Introducing strawmap, a strawman roadmap by EF Protocol. Believe in something. Believe in an Ethereum strawmap. Who is this for? The document, available at strawmap[.]org, is intended for advanced readers. It is a dense and technical resource primarily for researchers, developers, and participants in Ethereum governance. Visit ethereum[.]org/roadmap for more introductory material. Accessible explainers unpacking the strawmap will follow soon™. What is the strawmap? The strawmap is an invitation to view L1 protocol upgrades through a holistic lens. By placing proposals on a single visual it provides a unified perspective on Ethereum L1 ambitions. The time horizon spans years, extending beyond the immediate focus of All Core Devs (ACD) and forkcast[.]org which typically cover only the next couple of forks. What are some of the highlights? The strawmap features five simple north stars, presented as black boxes on the right: → fast L1: fast UX, via short slots and finality in seconds → gigagas L1: 1 gigagas/sec (10K TPS), via zkEVMs and real-time proving → teragas L2: 1 gigabyte/sec (10M TPS), via data availability sampling → post quantum L1: durable cryptography, via hash-based schemes → private L1: first-class privacy, via shielded ETH transfers What is the origin story? The strawman roadmap originated as a discussion starter at an EF workshop in Jan 2026, partly motivated by a desire to integrate lean Ethereum with shorter-term initiatives. Upgrade dependencies and fork constraints became particularly effective at surfacing valuable discussion topics. The strawman is now shared publicly in a spirit of proactive transparency and accelerationism. Why the "strawmap" name? "Strawmap" is a portmanteau of "strawman" and "roadmap". The strawman qualifier is deliberate for two reasons: 1. It acknowledges the limits of drafting a roadmap in a highly decentralized ecosystem. An "official" roadmap reflecting all Ethereum stakeholders is effectively impossible. Rough consensus is fundamentally an emergent, continuous, and inherent uncertain process. 2. It underscores the document's status as a work-in-progress. Although it originated within the EF Protocol cluster, there are competing views held among its 100 members, not to mention a rich diversity of non-EFer views. The strawmap is not a prediction. It is an accelerationist coordination tool, sketching one reasonably coherent path among millions of possible outcomes. What is the strawmap time frame? The strawmap focuses on forks extending through the end of the decade. It outlines seven forks by 2029 based on a rough cadence of one fork every six months. While grounded in current expectations, these timelines should be treated with healthy skepticism. The current draft assumes human-first development. AI-driven development and formal verification could significantly compress schedules. What do the letters on top represent? The strawmap is organized as a timeline, with forks progressing from left to right. Consensus layer forks follow a star-based naming scheme with incrementing first letters: Altair, Bellatrix, Capella, Deneb, Electra, Fulu, etc. Upcoming forks such as Glamsterdam and Hegotá have finalized names. Other forks, like I* and J*, have placeholder names (with I* pronounced "I star"). What do the colors and arrows represent? Upgrades are grouped into three color-coded horizontal layers: consensus (CL), data (DL), execution (EL). Dark boxes denote headliners (see below), grey boxes indicate offchain upgrades, and black boxes represent north stars. An explanatory legend appears at the bottom. Within each layer, upgrades are further organized by theme and sub-theme. Arrows signal hard technical dependencies or natural upgrade progressions. Underlined text in boxes links to relevant EIPs and write-ups. What are headliners? Headliners are particularly prominent and ambitious upgrades. To maintain a fast fork cadence, the modern ACD process limits itself to one consensus and one execution headliner per fork. For example, in Glamsterdam, these headliners are ePBS and BALs, respectively. (L* is an exceptional fork, displaying two headliners tied to the bigger lean consensus fork. Lean consensus landing in L* would be a fateful coincidence.) Will the strawmap evolve? Yes, the strawmap is a living and malleable document. It will evolve alongside community feedback, R&D advancements, and governance. Expect at least quarterly updates, with the latest revision date noted on the document. Can I share feedback? Yes, feedback is actively encouraged. The EF Protocol strawmap is maintained by the EF Architecture team: @adietrichs, @barnabemonnot, @fradamt, @drakefjustin. Each has open DMs and can be reached at first.name@ethereum[.]org. General inquiries can be sent to strawmap@ethereum[.]org.

There is a PTC vote on the payload timeliness and a PTC vote on the keys. Upon observing the PTC votes, the state is implied. The PTC vote on the keys can realistically be positioned slightly earlier than the PTC vote on the payload, given the small size of the keys. Such an earlier deadline could help if the payload often arrives well within the PTC deadline.

unless I do not fully understand the proposal (which is a high likelihood!), then it does not matter whether it is optional or alternative. By adding an encrypted transaction, you are making it such that no one can understand the state of the chain until the transaction is decrypted and executed. If you are given a block with 99% unecrypted txns and the last one is encrypted but it arbs every pool onchain, then no one can know what the actual price all of these pools are offering until that transaction is decrypted! This means front ends will need to give wider quotes, which means users will get worse prices and therefore go somewhere else! The funny thing is that I actually don't think we should be doing DeFi on the L1 as it puts too much pressure on Ethereum to centralize, and from that lens I do want "encrypted mempools" if all we're doing are transfers and posting state roots. But the ecosystem has already tried to rally behind this path and we have recently reversed course. So I'd like to keep Ethereum as a good venue for trading in the mean time :)