One step closer to 4-8x faster Ethereum finality! It took some time and lots of tokens, but we now have a formally verified proposal for a decoupled consensus protocol in I* (a future Ethereum upgrade)! Not yet a full spec (up next), but it includes all the key consensus-relevant details to become one. Since Ethereum aspires to be live without most of the stake online, the protocol involves many more components than a normal BFT protocol, and its correctness involves much more than standard safety and liveness. Those nuanced properties are now verified! What's more, I came away convinced that all protocol design will involve AI-assisted Formal Verification in the future, both for correctness and iteration speed. The work wasn't limited to just: Design the protocol -> Formally verify it Instead, the loop became more like: Design -> Formal Model -> Find exactly what breaks and why -> Redesign it. For a fairly complicated protocol like this one, I think having the Lean model be part of the design loop played a big role in accelerating the process. A future with agents paired with formal models is a superpower for Ethereum development, because they can then use those models to find exactly where an argument breaks down, formalize counterexamples, test proposed fixes, iterate on the protocol. Many details that would slip under the radar when asking agents (and indeed, humans) can now be specified exactly and checked by the Lean kernel. This then forces agents to be more precise and lets them make verifiable progress on their own. It's been incredible to see this play out, seeing agents find gaps and propose protocol changes to fix them. In other words, autoresearch can speed up protocol design, formal verification is here to stay, and Ethereum Finality will get faster.

Happy to report that after a month of work, EIP-8198 aka Quick Slots was merged as a feature spec in the Ethereum consensus specs! Many thanks to @jih2nn and @JustinTraglia for their tireless work as spec maintainers 🙌 What does "merging specifications" mean? Specifying a feature means writing up its behaviour, in code and in English, in a repository that has accumulated the detailed description of every feature since the launch of Ethereum’s Proof-of-Stake chain. This is the ground truth of how Ethereum consensus runs, and the model that all consensus clients follow to come to agreement with each other. Anyone can contribute to this repository, by submitting “pull requests” with more code and more text specifying a new feature. Pull requests remain open while the proposed changes and additions are reviewed, by specs maintainers and by the persons submitting their contributions. Once they have been sufficiently reviewed, with edge cases uncovered, the pull request can then be “merged”, and live inside the codebase of the specs, instead of besides it. This is usually a signal that the feature’s specs are now stable enough to evaluate in the context of other proposed changes. In particular, it also makes it easier for clients who want to start prototyping the feature, to do so on specifications that are no longer expected to change drastically. There can still be misses and unknowns, but at least the current thing has passed this first, close review. Importantly, this does not mean that faster slots have made it into Hegotá. We are still two steps away from it: Quick slots were Proposed for Inclusion on August 6th, and next week, on October 1st, we will likely be discussing raising its level to Considered for Inclusion at ACD. Should a decision then be made to include in the fork, quick slots would then become Scheduled for Inclusion, the last step. PFI -> CFI -> SFI. Easy eh? 😅 So this means the job's not done 🫡 We'll continue to advocate for a strong prototype of quick slots based on the specifications. We're continuing our outreach to ecosystem smart contracts and teams for who a slot change may impact their operations. And we're continuing to research the future of shortening slot times with post-quantum cryptography and zkEVM in view, beyond Hegotá. In the meantime, find the specs here: github.com/ethereum/consensu…

@ethlabs_org is now 3 months old since our June 22nd announcement 🥳 thought I'd share some musings as co-founder, on culture, goals and impact, also prompted by @apriori0x in the recording we made nitter.net/apriori0x/status/20983… letssgo --- establishing an org culture starts from day one, and I think we've hit it mostly, with moderate hiring since we started that has gelled well so far. I had reflected early on on culture here nitter.net/barnabemonnot/status/2… 3 months in I would say these are the main features: - goal-driven, we're not attached to specific means, we want a clear outcome and we go after it whichever way we need to - high urgency, I wake up in the morning hungry to pick up the tickets and threads that my US frens and EU night owls have left - ai native, this is a superpower and also gives a fresh spin to a lot of work that i used to enjoy doing but wasn't doing much of anymore (data collection/analysis, code/specs). i'm not the biggest consumer either, truly amazed by the strides @fradamt is making with AI-assisted formal verification - user-centric, we're still early and can always refine our approach here, but we really want to be intentional with it. building these feedback loops is imo one of our most critical needs atm. particularly as a non-profit, it's the only way to ensure impact - working in public, it's a healthy default and imo a responsibility given the nature and mission of our org, to work on behalf of the Ethereum community for the betterment of Ethereum. we push updates weekly, putting in some work to keep them engaging and high signal. see here ethlabs.org/writings/ --- the funny thing is it feels still like we are learning about ourselves, and what we can do with this new org. some observations on what's working well from my POV: - i think it is clear that we can have strong impact on core protocol direction and development still. one example, our hegotá view, led by @casparschwa @fradamt and @adietrichs, was a labour of love and rigour, and we held ourselves to a very high standard in coming up with our rankings ethlabs.org/writings/hegota-… work on account abstraction, fast finality, fast slots, all ongoing - i think we are growing well to be a "defragmenter" between L1 and L2s, sometimes a relayer helping to signal what one needs from the other, sometimes a more involved builder bridging the gap. @decentrek's work on 8130<>8141 is strong evidence, and @ox_shaman is accelerating quickly on following up its conclusion with a broad effort to maximally defragment accounts. better integration between L1 and L2s, their liquidity and their users, remains a key work stream for us. right now we're zoomed in on blobs, their demand and their supply - i think we've been good at building connections with strong teams working on the private and public buildout of the Ethereum network, and leveraging these connections. this is starting to compound for instance on going-to-market with the fast confirmation rule or the quick slots piece ethlabs.org/writings/quick-s…, and getting signal on our directions. kudos to @_julianma and @binji_x for doing so much outreach --- but! given these capabilities, are we tackling the right goals? this is a lot of our current internal chatter: - our stated mission is to make Ethereum the settlement layer for the global economy. ethereum has been unreasonably effective at attracting users and capital to its network, thanks to its unique properties. it is working, we want to make it work better, and maintain its lead + increase its footprint in the world - how can we be more principled with problem identification? we're taking it both bottom-up and top-down. some concrete work emerges organically from internal reflections and external engagement, and we also spend more time now top-down/first principles-refining our intuitions. this helps connect the dots and move up and up to bigger and bigger targets - in particular, feeling like Ethlabs can do more advocacy and work on ETH the asset, rooted in our technical work and ecosystem engagement. ETH is a big part both of the network's utility, and its reach to export the values of Ethereum. this matters. - feeling like there are big opportunities around asset issuance and tokenisation, bringing the global economy onchain, and the role of the L1 in this conversation, as critical node in the transport layer of these assets throughout the network - I like to keep moving and adjust on the fly, as action creates information. no one feels under-allocated. feeling slightly mis-allocated is probably right to keep our heads up and reflect on what is the most impactful thing we could be doing. we might not be going after the biggest fish right now, and we shouldn't be ideological about choosing our targets. it's a conversation we should keep having both internally and externally --- - last point, apart from all this, wow there is a lot of admin! we wanted to hit the ground running asap so decided to backload some of it, there's some more to get through but we're getting there. thank god for @joshrudolf --- that is all for today, back to making ethereum faster 🫡 gn

Why will ETH dominate? The same reason the US dollar dominates. "The reason why ETH will dominate is because Ethereum has the best digital infrastructure of all the blockchains." As the dollar flows seamlessly across global markets, underpinning all those financial products, ETH flows seamlessly across L2s. Look at the top trading pairs on Base, Arbitrum, Robin Hood's chain — most are denominated in ETH. FT @_julianMA @binji_x @decentrek

I like to think about privacy in terms of counterfactuals. Imagine if Ethereum transactions had been private from day one. Now imagine in 2027, an Ethereum upgrade took away the privacy, and now all transactions are public. What would've been the community reaction? It would've been ABSOLUTE OUTRAGE. How DARE you make my transactions PUBLIC???? Isn't that INSANE??? But we don't actually feel that way about our public transactions today. Why? Because humans are very good at getting used to whatever the status quo is. That's why privacy feels like a meh value prop to a lot of people right now -- because all they've ever known is transactions being public to all, they feel it's just fine the way it is, just like people before cars were fine with horses, and people before iPhone were fine with typing on tiny keyboards. It takes real visionaries to imagine what it's like to have something we don't have today, and most people are not that. Mark my words -- in 3 years, we will be marveling at Ethereum's foresight to work on privacy at scale while everyone thought it was a dead end, just like how people 3 years ago thought it was stupid that Ethereum would make something as far-fetched as quantum resistance a core part of the roadmap. That's also why I'm incredibly thankful for the EF -- while we at @ethlabs_org focus on building what builders and users need TODAY, I take constant solace in the fact that there's another incredibly talented and (thankfully) very well-funded org whose sole focus is on investing in Ethereum's long-term vision, including privacy and quantum resistance. Ethlabs and EF are the one-two punch that our ecosystem needs and what will make Ethereum commercially successful in the short term and a civilizational centerpiece in the long term.

Ethereum in 2027 is going to be almost unrecognizable. High throughput, native AA, near native privacy. Meanwhile, foundations for of a faster Ethereum and for the PQ transition are being laid. If we keep apps and users in mind as the protocol transforms, the future is bright.

Ethereum’s biggest bottleneck may no longer be demand; it’s speed. @ethlabs_org argues Ethereum is already becoming the home of tokenized finance. The next step is making it dramatically faster without sacrificing decentralization. If they pull that off, the Wall Street thesis gets much more interesting. FT @BitcoinJesusETH @_julianma @decentrek @binji_x ⏱ TIME POINTS ⏱ 00:00 - Intro 01:06 - Why Quick Slots Matter 04:21 - What Does “Faster Ethereum” Mean? 09:58 - PRO 10:32 - Can Faster Ethereum Boost ETH? 12:46 - Ethereum vs. Base on Account Abstraction 18:41 - Is Base “Divorcing” Ethereum? 21:26 - How L1 and L2s Are Changing 25:49 - Is Tokenization Ethereum’s Big Opportunity? 29:45 - Sponsor: Nexo 30:19 - Should Tokenized Assets Live on L1? 33:42 - Who Sells Ethereum L1 to Institutions? 36:45 - How Does This Drive Value to ETH? 41:34 - Does Ethereum Need L1 Privacy? 46:31 - Closing Remarks

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.

It's an increasingly common take that AI hacking means cybersecurity is doomed. I disagree. I think cybersecurity is naturally defense-favoring once people get their shit together. And anyone who continues to hold cryptocurrency (including me, ~90% of my net worth) is implicitly making that bet. Here's why I am making that bet. First, the oversimplified punchy one-line statement: If AI can prove Navier-Stokes and FLT, then AI can prove the statement "this program is secure" as a mathematical theorem. Even if the program is very complicated. Now, the nuance: (See also: vitalik.eth.limo/general/202… ) The word "secure" is hiding all kinds of skeletons in the closet in terms of what it actually means. What does it mean for Signal (the encrypted messenger) to be "secure"? The most basic definition you might think of is: no one who doesn't hold the recipient's secret key can read the contents of the message. But: * Did you remember to include _other_ critical forms of security? Can the adversary forge messages? Can the attacker prevent messages from reaching the recipient? Can they cause your client to crash by sending malformed messages? * Have you made sure that your model of the adversary includes attackers that interfere with the protocol actively and not just passively? And attackers that interfere by replaying messages to you or the recipient that either of you sent over the wire at any point earlier? * What if the adversary hacked (or _is_) the Signal server? * How did you learn which public key belongs to the recipient in the first place? What if that process was tampered with? * What if your device gets hacked at some point in the past or future - is your message still safe then? * What if your key leaks because of a bug in your operating system? Or because you got a bugged version of the Signal client? Or what if the database is corrupted? * Or the libraries, interpreter or compiler of the programming language you wrote it in? * What if your key leaks because tiny perturbations in perceptible signals generated by the hardware leak mathematical relationships that can extract the key a few hundredths of a bit at a time? * Are you hiding the *size* of the payload? Does that matter? * You're definitely not hiding the identity of the sender and the recipient, and the exact time each message was sent (think: not just time-of-day, but also time deltas between one message and the next). Is that not enough to deduce a lot of important facts about what relationships you have, and what *kinds* of conversations you are having? So ... even definitions can be over a thousand lines of code, and need deep careful thought to figure them out. Working on making definitions more human-readable is of extreme importance - it's perhaps the only "high-level language" that matters right now. But even still, even despite all of the above, for security-critical components, the definition is a much smaller attack surface than the implementation. Verifying that the definition is adequate is a much more tractable task than scanning over the code directly - and can become even more tractable with better tooling. Definitions are also _additive_: if two groups have two different definitions A and B, then, well, you can just prove that the program satisfies both A and B. Code is not additive in this way: if a program is A + B, a bug in A _or_ B can sink the whole thing. Definitions are additive. And if you can't satisfy A and B at the same time, you've isolated the most important philosophical issue for your project to spend its next few weeks grappling with. Sometimes, definitions are not much smaller than the implementation - UI components might be one example. But for many of the most critical components - message-passing protocols, sandboxes, cryptography like SNARKs and FHE - the asymmetry is real. Historically, a large class of failures with this approach have come from people only verifying a small portion of their code, that they self-declared to be the security-critical portion, and ignoring the rest - and it turns out that something in the rest of the code is security-critical too. This was reasonable back when verification was difficult and scarce. The solution today: sorry, you have to verify over literally your entire program, including database, networking, any caching layers, everything. Modern AI can do it. So it's not about "the good guys find all the vulnerabilities before the bad guys do" - that could maybe work too, after all a finite program only has a finite number of vulns, but it's riskier - it's specifically an asymmetric strategy of making code that is much more resilient in the first place. This is the kind of direction that Ethereum is going in for the next few years. There is no future for blockchains - especially blockchains with scalability and privacy - without doing this. We need to make software actually secure. And we have already made a lot of progress.

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.

I trained a fly to draw this week's cover. Next week we'll see if it can also write the whole thing.

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: ethlabs.org/writings/hegota-… 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.