One would think that because blobs are almost free, L2s should have no problem landing blobs. But one interesting thing I learned from interviewing L2s is that they in fact have a lot of trouble landing blobs, EVEN WHEN there's no congestion. I want to explain why, as that reveals some very interesting facts about the protocol. Recall that blob pricing works similar to gas pricing (EIP-1559), where there's a "base fee" which goes up or down each block, depending on whether the previous block hit the target number of blobs (14 out of 21). The idea is that in a well-functioning market, the base fee will track the "market price" of blobs, so that you can land blobs by just paying the base fee, with perhaps a little priority fee if there's congestion. However, whereas this mechanism works well for regular gas, it turns out to be an issue for blobs, because blob demand is relatively inelastic to price. In other words, just because the blob price is low does not mean that L2 will send more blobs -- they still need to fill those blobs with L2 transactions, which may have low demand even when L1 blob fees are low. As a result, blob usage has been consistently below target, such that the blob price sat at 1 wei -- the theoretical minimum -- for a long time. A later EIP raised the floor higher, but it's still so low as to be effectively free. Why is this an issue? Normally it's not. People love free blobs! But at times of congestion, because the base price starts so low, it takes a HUGE amount of time for the base price to rise enough to discover the true market price. For example, if the base price is 1 gwei and the (hidden) market price is 40 gwei, it would take 47 consecutive full blocks (~10 minutes) for the base price to catch up. By the time it catches up, the congestion may already be over. So what do L2s do during congestion? They bid with the priority fee, but without knowing what the true market clearing price is, they have to overbid in order to be sure that their blobs will be included. This is precisely the unreliability / wastefulness that EIP-1559 was set out to fix in the first place! But price instability is not the only reason why L2s have trouble landing blobs. There's another more subtle and interesting reason -- MEV. Blobs are large chunks of data, and as such they cost bandwidth to propagate. Since bandwidth is a finite resource, everything being equal a block with blobs will take longer to propagate than a block without blobs. This is an issue because a block builder only has a limited amount of time to propagate blocks before missing the attestation deadline, which would cause their block to be reorg-ed. Therefore, block builders play a timing game where they wait as long as possible so they can pack the most valuable (high MEV) transactions into their block, but not waiting so long that they miss the attestation deadline. Therefore, blobs have a hidden cost -- because they make blocks larger, builders who include blobs must send out their blocks sooner, causing them to miss out on some MEV. As such, some builders refuse to include blobs EVEN WHEN there's no congestion in the blob market, so from the L2's perspective they just see their blob transactions being silently dropped, even though they appear to be paying adequate fees. To truly ensure blob inclusion, the L2 would have to include a high-enough priority fee to compensate for the lost MEV from the builder, but once again this value is hidden and hard to discover. In short, there are at least two forces against L2s landing blobs reliably: - The blob price being so low that it kills price discovery and causes bidding wars during congestion. - Blobs cause builders to lose MEV, so they ignore blobs unless priority fees are high enough to compensate for the MEV. So what can we do to make blobs more reliable? Good news is that things will already get better in Glamsterdam due to ePBS giving blobs more time to propagate, but more fixes are required if we want to completely fix these issues. Thankfully many researchers including @fradamt @potuz_eth @barnabemonnot are already thinking about this -- I may talk about some of their ideas in a future post!

I'm a Ethereum maxi, not a decentralization maxi. I believe the world needs only one fully decentralized / permissionless / trustless blockchain, and that is Ethereum. Every other chain -- whether they are stage 0/1/2, trusted, trustless, centralized, semi-centralized, etc. -- can and should be built on Ethereum. In fact, the beauty of Ethereum is precisely that because it's itself maximally decentralized, other systems of various degrees of centralization can be built on top, and that they can interop with each other through Ethereum. As long as these systems provide real value to real people, they will strengthen the network effects of Ethereum and bring in more users and liquidity into the overall Ethereum ecosystem, which ultimately leads to a stronger L1 and stronger ETH. Ethereum is the only credibly neutral, global settlement layer of the world. We are the hub. Let's celebrate the nodes that connect to us.

We've been interviewing L2s about how Ethereum can improve DA/blobs, and one thing that warms my heart from these interviews is how often the project expresses something along the lines of: "thank you for talking to us; we didn't know how to give feedback to L1 before, and it's really refreshing that you proactively reach out to us." That's why I'm so excited by our work here at @ethlabs_org. Besides our technical capabilities, just the fact that we can serve as a bridge between core devs and L1 users (such as L2s) provides immense value. If you ever want some improvements from the L1 and are unsure who to talk to, don't hesitate to reach out to us!

Ethereum has had 100% uptime since its inception, so it’s worth asking why @ethlabs_org and EF are redesigning its consensus protocol. I want to provide some context. Ethereum today runs what researchers call an "ebb-and-flow" consensus protocol. "Ebb-and-flow" refers to the fact that the protocol is actually two protocols in one: - There's an "availability protocol," also called a "fork-choice rule," which can produce blocks even when a majority of Ethereum's stake are offline. This is what would keep Ethereum producing blocks even if a nuclear war took out most of the internet. - There's a "finality gadget," which makes a block irreversible after some time. This is why we can all go to sleep at night knowing that our transactions won't be reverted when we wake up. However, for historical reasons, these two protocols are tightly coupled on Ethereum. Every block, a subset ("committee") of Ethereum validators send votes ("attestations") to produce blocks, and the very same votes are used to finalize blocks over a long range ("epochs"). The fact that the same votes are used for both protocols means that, if you were to reduce the votes used for the availability protocol, which would speed up block production, you would need more blocks to achieve finality, which would delay finalization. On the other hand, if you were to use more votes for the availability protocol, it would speed up finalization but slow down block production. You cannot speed up both at the same time. On the other hand, Ethereum's fork-choice rule (formally named "LMD-GHOST") has been discovered to have multiple vulnerabilities over the years. For example, it was discovered (by researchers including @casparschwa and @barnabemonnot) that you could secretly accumulate votes for a fork, then reveal it later to reorg out a new block. There have been consistent efforts to patch these vulnerabilities, but they are generally seen as bandaid fixes that introduce further complexity and bug surface into the protocol. So Ethereum's new consensus design, called "decoupled consensus", is an ambitious attempt at tackling both problems at once: - Decouple the availability protocol from the finality protocol, so both can be optimized independently. - Fix vulnerabilities with the availability protocol. The way this is done, in broad strokes, is this: - We replace LMD-GHOST with a new algorithm called Goldfish, alongside a "stabilization gadget" which is another sub-protocol that prevents Goldfish from re-orging over an arbitrarily long range. - We run the availability protocol (Goldfish+stabilization gadget) and the finality protocol in parallel, with separate votes. The result? Ethereum will provide both fast finality and fast block times, AND it will keep producing blocks during World War III. Of all blockchains, Ethereum will be the only blockchain with these properties, and that's why it will be the settlement layer of the global economy.

This was the first project I worked on after joining Ethlabs and I’m so excited to see it go live! We worked with @chainlink to roll out FCR — the Fast Confirmation Rule — to CCIP 2.0. Now, transfers and asset issuance originating from Ethereum can enjoy 30x faster confirmation, down from 14 minutes to 24 seconds. Once again we’ve cemented Ethereum special place as the best home for assets 🫡 Special shoutout to Lighthouse (@sigp_io) for being the first consensus client to ship FCR, and to @prylabs and @Teku_Consensys for working around the clock to ship FCR to meet Chainlink’s deadline. Together all three clients power the new CCIP. It’s beautiful when clients and the industry work together!

It would’ve been easy for @barnabemonnot and @binji_x to be handwavey about Quick Slots (EIP-8198) and justify it by saying things like “obviously we should make Ethereum faster,” but instead they went through the painstaking process of actually interviewing builders and identifying concrete use cases where faster slot times would improve UX. This is how responsible protocol builders push for Ethereum upgrades and the bar we set for ourselves at Ethlabs — every change we make to the protocol must have a large practical impact for users and builders TODAY.

A fun natural experiment for the value of shorter slots: Looking at the failure rate of swaps after missed blocks ("24s slots"). Prices are more likely to move out of slippage bounds over longer periods of time, increasing the failure rate. For RFQ systems, quotes may turn stale with greater delay for their execution. Conversely, with shorter slots, users can set tighter slippage bounds, and shorter latency between quote and execution ensure higher swap quality. Quick Slots is S-tier.

imo part of the reason that the L1 is going to be bigger than many people expect (including ETH bears) is that there's an emerging granular spectrum of app-chain-like architectures. It's not just "L1 app, or L2, or nothing else". Derive found the right approach for them. They call it a "zkVM program settling on mainnet". Is it an L1 app? Is it an L2? An app chain? The correct answers are "Yes" and "Who Cares" 😂 Excited for them

I'm sad to report that the AA collab between 8130 and 8141 (Frames) broke down last week, and Base and Ethereum are now going separate ways to implement different AA standards. I want to share some reflections on this collab and on the future of the EVM. For a long time, the EVM has been a unifying force between L1 and L2s. Thanks to a standard account model (EOA) and a standard transaction type (EIP-1559), users have been able to enjoy their wallets working seamlessly across EVM chains. Similarly, a AA standard shared across L1 and L2s would ensure a consistent multi-chain UX for smart accounts, including post-quantum (PQ) accounts which we will eventually all use. As the crypto industry matures, however, L1 and L2s are starting to diverge in the values they provide and the use cases they target: - For the L1, it's all about CROPS -- censorship-and-capture resistance, open source, privacy, and security. In short, Ethereum L1 wants to be the most decentralized programmable settlement layer of the world, which is what makes it a good base layer for L2s in the first place. - For L2s, it's all about scaling, customization, and compliance -- things that commercial and enterprise use cases demand, and that the L1 does not provide. These diverging needs have pushed the shared layer -- the EVM -- to its limit, and AA proved to be the breaking point. While L1 and L2s both value core AA use cases such as gasless transactions and passkey wallets, they differ sharply in what these features must comply with: - For the L1, AA transactions must be uncensorable, private, and quantum-resistant, which call for a transaction type optimized for PQ signature aggregation and privacy protocols, and an account model that can be freely programmed and extended by developers without permissions from the chain. These needs lead to AA standards such as ERC-4337, EIP-7701, and now EIP-8141 aka Frame Transactions. - For L2s, AA transactions must work at high scale, and they must be legible such that the protocol can enforce clear rules about what kinds of accounts/transactions are permitted vs not. These needs lead to AA standards such as Tempo Transactions and now EIP-8130 by Base. With the AA collab, the authors of 8130 and 8141 tried to define a shared standard that can work for both L1 and L2s. While we identified a number of technical solutions, they all required one side or the other to compromise at least a little bit on their core goals. But ultimately, Ethereum wanted to be the best version of Ethereum, and Base wanted to be the best version of Base, and while both sides acknowledged the benefits of ecosystem interoperability, it was ultimately secondary to the need for each chain to achieve their core goals. So separate ways we went, putting the burden on wallets to deal with the fragmentation that ensues. Now, just because we ended up with fragmentation doesn't necessarily mean it was a bad outcome. If reducing fragmentation comes at the cost of homogenizing chains to the point that they fail to solve problems for the users they care about, that would not be a price worth paying. While I was initially sad that the collab did not come to a successful conclusion, I took solace in the fact that both Ethereum and Base are now free to innovate on AA to the maximal extent in accordance with their own visions, unshackled from the need to accommodate the other side. If they execute well, and if the wallet community can bridge over the fragmentation, we may well end up with the best possible UX for the end users. So where does that leave us -- the broader Ethereum community including Ethlabs -- if we want to continue pushing for a consistent UX across EVM chains? I see two paths forward: - We can establish a coordination mechanism that encompasses more stakeholders than ACD itself (where only L1 client devs have voting powers), to govern shared L1<>L2 resources such as the EVM. That way, L2s can participate in shaping the EVM, as opposed to having to accept whatever the ACD decides, or being forced to fork if they don't like the decision (such as in this case with Base). - We can accept that fragmentation of the EVM and wallet UX across L1 and L2s is inevitable due to their conflicting needs, and dedicate our resources to building wallets and applications that can abstract over the differences. Indeed, the collab was an exercise in the first path -- we invited Base, Arbitrum, and other stakeholders to directly influence how native AA shapes up for the L1. While it ultimately failed in this case, I feel a better outcome could've been achieved if we had established a dialog between both sides way earlier, as opposed to well after L1 core devs had rallied around Frames. On the other hand, I also learned from this exercise that some differences are unavoidable, and indeed it would be counterproductive to overly pursue interoperability at the cost of differentiation. In other words, we sometimes just gotta let the chains cook. For that reason, I've also become more bullish about the second path -- building wallets and applications that can speak the native transaction types of each chain, and hide the complexity from users through UX abstractions. This puts a lot of onus on the wallet/application developers of course, but on the bright side, it's also an opportunity for wallets/applications to stand out and differentiate, by competing to provide great UX across chains despite the underlying fragmentation. Ethereum is the art of staying together while remaining different. We must accept that chains will succeed by innovating, and innovations will naturally result in differences. On the other hand, we must never give up on dialogue when we can achieve interoperability without compromising core product goals. As Ethereum and crypto grow to eat the world, the push and pull between innovation and collaboration will only intensify, and it's up to all of us -- builders across L1 and L2s, applications and wallets -- to determine whether diverse innovations will split Ethereum apart, or make it thrive as one.

EIP-8288 would be one of the most groundbreaking updates to Ethereum if shipped, but it may not be obvious from the technical language. Let me try to explain in plain words. Today, Ethereum scales in three dimensions: - Execution aka "gas limit" - Blobs aka "data availability" - State aka on-chain data EIP-8288 enables Ethereum to scale in a fourth dimension -- proof verification. Ethereum will need to verify a lot of proofs, because in a post-quantum world, signatures will be too expensive to verify directly, so we must aggregate them through STARKs (a type of ZK proofs) and verify the STARK proofs instead. At the same time, privacy transactions (such as those sent through Railgun / Tornado Cash) will also need to use STARKs to be quantum-safe. The problem with quantum-safe STARKs however is that they are very large (~512kb) and will therefore take millions of gas to verify. Therefore, for Ethereum to support private, post-quantum transactions at scale, it's important to lower the cost of verifying STARKs. One natural solution to this problem is to ask the block builder to create a single STARK that aggregates all the PQ signatures and STARKs in the block. That way, the cost of verifying each individual signature/proof becomes amortized over the cost of verifying a single block-level proof. This simple solution has a few issues, however: - It places a huge amount of compute burden on the block builder, who now becomes the bottleneck for how many signatures/proofs can be verified in a block. - Since many transactions are gossiped through the public mempool, if every transaction carries large PQ signatures/proofs, it can quickly overwhelm the bandwidth of mempool nodes. If the public mempool stops functioning, Ethereum loses its censorship resistance. The core insight of EIP-8288 is that we can solve these problems by aggregating signatures/proofs with a distributed network -- the mempool itself. Each mempool node would locally aggregate proofs of the signatures/proofs it has seen, and instead of gossiping the raw signatures/proofs, it would gossip the aggregated proofs instead. This new architecture solves both problems: - By the time the block builder is building a block, most of the signatures/proofs will have already been aggregated into a small number of aggregated proofs, so now the builder just has to aggregate *those* proofs. - Since mempool nodes gossip aggregated proofs rather than raw sigs/proofs, the bandwidth requirements on the mempool are vastly reduced. In short, EIP-8288 turns what's traditionally a scaling bottleneck -- the distributed mempool -- into a scaling *resource* instead. The more nodes we have in the mempool, the more PQ signatures/proofs can be aggregated, which means the more PQ/private transactions Ethereum can handle. For once, decentralization makes scaling easier, not harder. That's revolutionary! By leveraging its decentralized mempool as a compute resource, Ethereum will become the only network to support uncensorable, private, and quantum-safe transactions AT SCALE. Couldn't be more excited about this future!

We reviewed all 60+ EIPs proposed for Hegotá and updated our view on what Ethereum should prioritize. Our rankings follow four themes: 1. Stronger censorship resistance: Ethereum can only become a settlement layer for everyone if it stays neutral toward everyone. We strongly support FOCIL. 2. Faster Ethereum: Shorter slots mean faster confirmations, fresher onchain prices, and faster finality. We strongly recommend Quick Slots to make a first reduction in Hegotá and further reductions easier in subsequent forks. 3. Native account abstraction: Ethereum is long-due for native AA. Frame Transactions bring passkey wallets, sponsored transactions, gas paid in tokens, batching, and better support for privacy and post-quantum security. Adoption will take work across wallets, L2s, and the rest of the stack, and we intend to keep helping with that. 4. Performance engineering: continued L1 scaling & a faster Ethereum. Performance should remain a first-class concern in both client work and protocol design. The gains can go toward more capacity, shorter slots, lower node requirements, or all three. Thanks to everyone who put forward proposals and helped us work through them. We’ll keep updating our view as client and testing teams assess the work involved. PS: find the full view + changelog here: PPS: finally an iPhone that fits all 60+ Hegota EIPs

It’s refreshing from the L2 side to have an L1 focused org like @ethlabs_org making collaboration with L2s a core priority. EthLabs is working on UX improvements like shorter slots & native AA, finality, interop, PQ security, censorship resistance & scaling. These are areas where close coordination with L2s matters. @Offchain is fully committed to Ethereum’s cypherpunk principles, ecosystem & long-term success. We believe in settling on the most decentralized chain in the world, and want to help make L1 stronger. Across my time working on @Arbitrum and previously @ZKsync, we’ve had valuable collaboration with Ethereum Foundation. But consulting L2s on protocol design, product priorities, UX, & performance constraints often felt secondary. I’ve heard that sentiment shared across other L2s, wallet teams, & dapp devs. L2s process the vast majority of Ethereum ecosystem transactions & work directly with businesses, developers and users. We see the adoption barriers & technical bottlenecks firsthand. We’ve spent years improving scaling, UX, DevEx & proving. Several approaches now discussed in ACD have already been researched or implemented by L2 teams, bringing practical experience into L1 discussions. As the Core Protocol PM at Offchain leading our L1 coordination, I’m happy to be working closely with EthLabs on these shared priorities 💙

Toly is one of the foremost thinkers in crypto, but I think commercial interest is compelling him to willfully ignore the fact that, by launching their own L2, RH can capture revenue from all apps that launch on RH chain to colocate with tokenized stocks. The criticism of Arb/L2 gas fees is also misleading — the gas fee is determined by a combination of L1 blob market and L2 fee market, and in reality neither is technically constrained to add way more capacity. The fact that they haven’t done so is a business decision — L1 wants to capture blob revenue from L2s, and L2s want to monetize off user transactions. Should either decide to prioritize growth over revenue, they can lower the fees in an instant. In fact, we’ve been having constant debates within Ethlabs about whether it might be wise to further increase blob capacity in order to lower blob fees, to further L2 growth. There’s a saying I read on X that stuck with me: Ethereum is the art of remaining together while staying different. Robinhood cannot be more different from Ethereum in terms of philosophy and ethos, but thanks to a strong L1 supporting L2s, Ethereum and Robinhood are able to benefit from each other’s distribution and network effects, which are ultimately good for bringing the entire world on-chain.

Robinhood has created demand for $eth from hundreds of thousands of people in two months. Many of those native to other blockchain ecosystems. They’ve done plenty for Ethereum already. Please no more alignment games.

It's funny watching CT singing praises of L2s after years of bashing the rollup-centric roadmap, but to me the very framing of L2s being a result of the rollup-centric roadmap is misleading. L2s exist not because of any top-down roadmap -- they emerged naturally due to a combination of 1) Ethereum's core technical properties, and 2) market demand. In other words, short of ceasing to be itself, Ethereum could not have stopped L2s from existing even if it wanted to. Credits must go to the EF for accelerating the success of rollups by pursuing the rollup-centric roadmap, but we must not get the cause and effect wrong -- the rollup-centric roadmap was a reaction to the emergence of rollups, not the cause of it. (note that I will be using the terms "rollup" and "L2" interchangeably for readability, even though they are not technically the same thing) At its core, a rollup is an off-chain program that posts its input data and commits its state to the L1, alongside a smart contract "verifier" that can verify the state transitions. If you examine this definition, you can derive the core technical properties that a L1 must have for L2s to exist: - L1 must allow for posting data, so that input data and state commitments can be posted. - L1 must support a general programming environment, so that verifiers can be implemented. But most L1s, including alt L1s like Solana and Sui, have these technical properties, so it's worth asking why we don't see rollups flourishing in those ecosystems. This is because Ethereum also has a set of other properties that no other L1s have: - Ethereum is maximally decentralized, which makes its block space 1) credibly persistent (i.e. you can believe that Ethereum will last forever), and 2) widely accessible. This enables rollups built on Ethereum to inherit its persistence and accessibility, giving credence to the idea that rollup users can enjoy high-performance execution without giving up the benefits of decentralization. - To achieve maximal decentralization, Ethereum runs a very large validator set, which makes Ethereum blocks expensive and slow to produce. The high gas price and latency of Ethereum blocks therefore lead to market demand for cheap and fast block space, a void that rollups are perfectly positioned to fill. - As a direct result of the decentralization, Ethereum has become the best home for on-chain liquidity, simply because people want their liquidity to sit where it can 1) last forever, and 2) be maximally accessible. Therefore, L2s building on Ethereum do not have to bootstrap their liquidity from scratch, but rather can funnel Ethereum's liquidity into the rollup via trustless canonical bridges. - As another consequence of decentralization, Ethereum is capture-and-censorship-resistant. But sometimes, capture and censorship are actually desired features, in which case they are known as regulation and compliance. So market also demands L2s because they can be regulated, since Ethereum itself cannot be. In short, for as long as Ethereum keeps embracing decentralization, it will be the best home for L2s. As Ethereum builders, our job is to preserve and enforce Ethereum's core decentralization properties, while creating and improving technologies such as blobs and interop to facilitate the growth of highly scalable L2s. Ethereum and L2s will help each other win. Let's build towards it.

We can make the trenches and the ETH OGs meet, BUT we need your help. Right now it takes 13 minutes to deposit from ETH L1 to an L2 with meaningful size. But, there is tech that exists that can take that down to ~12 seconds. A 60x reduction, literally. At @ethlabs_org, we are focused on ensuring it gets adopted and have some partners commited to implementing it already. But we need your help to get more people to implement it (it’s super easy). All the info about the tech (FCR) is here: Imagine us all rallying together, it would be so fun.