Ethereum is about to fundamentally change how blocks are executed. With the upcoming Glamsterdam hardfork, it's shipping EIP-7928: Block-level Access Lists, a proposal that brings parallelization to the EVM. Here's a short explainer of what it is, how it works, and why it's a big deal for scaling. Let's start from the top. Alongside EIP-7732 (ePBS), EIP-7928 is the execution-layer (EL) headliner for Glamsterdam. Like ePBS, the main focus has been scaling Ethereum, though both proposals come with a bunch of other, equally important properties on the side e.g. removing trust requirements from the PBS pipeline or improving sync. EIP-7928 adds a Block Access List (BAL) to every Ethereum block. A BAL is a list of accounts and storage slots that the block touches, but that's not all: it also contains post-transaction state diffs (this part is critical!). Post-transaction state diffs tell you what the state looks like after each transaction. Quick example: user A swaps 1 ETH for DAI on DEX B. The BAL tells you that user A's ETH balance decreased by 1 ETH + tx fees and their nonce went up by 1; that DEX B's ETH balance went up by 1 ETH; and that inside the DAI contract, user A's DAI balance increased while DEX B's decreased. In other words, all of that info becomes statically available, something that previously required tracing the transaction. Client software (Geth, Nethermind, Besu, Erigon, Reth, Ethrex, Nimbus) can use this to do a few very powerful things: 1. Parallelize transaction execution. Knowing the post-state of each tx resolves the dependencies between them. No transaction has to wait on the previous one anymore, so execution can be perfectly parallelized. Instead of large parts of block validation sitting idle waiting on sequential execution, clients can finally make much better use of modern hardware. 2. Batch prefetch. One of the most cumbersome jobs for a node has been fetching the state needed for execution from disk. Because state locations (e.g. the exact storage slot in the DAI contract where user A's balance lives) are only discovered along the way, while executing, state-fetching has been a real drag on scaling: it blocks execution, takes time, and eventually slows everything down. With BALs, everything a node needs for execution is known upfront and can be loaded into cache in one go, in parallel. This speeds things up even further. 3. Parallelize post-state root calculation. Another expensive task is walking the updated state tree to compute the post-state root, which is needed so that everyone agrees on what's on disk after executing the block. With the post-tx state already in the BAL, nodes can do this in parallel while executing. A heavy task that used to wait until all transactions had finished can now run alongside prefetching and execution. 4. Snap sync (v2). An often overlooked, less sexy aspect of blockchains is syncing. Nodes need to catch up with the chain, and they need to catch up faster than the chain progresses. Today, most nodes do snap sync: downloading blocks, headers, and state in parallel while chasing the tip, and then "healing" the database once they're close to the head. Healing means asking peers for trie nodes, receiving them, validating them, and updating the local DB. It's iterative, networking-heavy, can take a while, and especially higher throughput pushes that phase to its limits. BALs help here too: with snap v2, nodes can catch up to the tip and skip the healing phase entirely. Syncing at higher throughput becomes more robust and reliable. So, to summarize, a BAL contains two things: -> The state locations the block accesses -> The state changes after each tx (incl. the new values) We're already seeing big performance gains today: on 6-core machines, EL clients validate blocks up to 5x faster, making block gas limits of 300M a very realistic outcome. ePBS will add to that by decoupling the block from the payload, giving validators 2-4x more time for execution. To not overshoot (security stays priority #1), the fork will likely ship with a 200M gas limit, but we shouldn't be stuck there for long before pushing to 300M and beyond. That's a 10x in scaling since we started taking the topic seriously, without touching hardware requirements. None of this would have happened without people going all-in, heads down, shipping: so many hours spent in calls debating the right design, so many iterations refining the specs, and tons of test cases written (and still being worked on). The road from whiteboard to production-ready code has been a journey, and we're not at the finish line yet, but from what I can tell, things look super bullish for Ethereum. Glamsterdam will be a fork that shows what's possible when a distributed, decentralized community works on a shared goal, laser-focused on providing enough block space to onboard the next wave of users.

Ethereum's execution layer scaling roadmap is on track: - Continuous Gas Limit Increases (EIP-7935) - History Expiry (EIP-4444) - Delayed Execution (EIP-7886) - Block Access Lists (EIP-7928) - Block-Level Warming (EIP-7863) Here's a short thread with additional context👇

For the first time in Ethereum PoS, validators have voted to increase the gas limit and it's happening now. 🎉 We saw the last gas limit increase with the London hardfork in August 2021, still PoW.

MEV can be so beautiful.

I don't get this vibe lately. EthGlobal organizes hackathons with thousands of participants worldwide every year, and there’s also a protocol fellowship program for aspiring core developers and researchers. As far as I know, Ethereum is the only ecosystem with sustainable developer funding (Protocol Guild). Plus, organizations like EF, Optimism, Gitcoin, and others provide grants to support academics and professionals. You can’t even learn about zk-SNARKs these days without also learning about Ethereum. Developers can contribute to core clients in at least six programming languages, and both the consensus and execution layer specs are available in readable Python. There are forums like ethresearch and EthMagicians, plus an open discord where ideas are discussed in detail with full transparency—this also applies to the governance process in general. No other blockchain ecosystem has the tooling that Ethereum has. This one is a no-brainer, truely. I’m not sure which new developers you’ve spoken to, but I see plenty entering Ethereum. Many didn't even start directly with Ethereum. Some enter through another ecosystem, first trying out something cheaper/easier/faster/<your tradeoff for decentralization here>, and take their time to discover the beauties of Ethereum. Ultimately, our goal must be to onboard developers to web3. The level of decentralization someone chooses is a personal, ideological decision based on their own trade-offs. This all works without heavy marketing or flashy influencers on twitter, mostly relying on intrinsic motivation. Ask yourself why you're here, if it wasn't some crazy marketing campaign that tricked you?

The seamless journey of blocks, from creation to validation, through the mev-boost ecosystem: nerolation.github.io/mevflow…

With EIP-1559, zero gas transactions are no longer possible. Together with @lightclients and @gballet, we reintroduced them by implementing a PoC for a gas ticketing service. It uses blind signatures to fund unfunded accounts in a privacy-preserving way. hackmd.io/@Nerolation/rkp8Ly…

Missed slots and reorgs trending down.

New dashboard online - censorship.pics 🙌 May it shed light onto the extent of censorship and guide us towards implementing practical solutions for enshrining a strong form of censorship resistance. More info 👇

I'm excited to share our latest research on adjusting the block gas limit. Together with @VitalikButerin, we're exploring paths to reduce the maximum block size, balance calldata pricing, and ultimately raise the block gas limit. ethresear.ch/t/on-increasing…

Should we increase Ethereum's block gas limit? To guide this decision, I've just published an analysis focusing on block sizes, gas limits, and scalability: ethresear.ch/t/on-block-size…

Data shows that the Flashbots MEV-Boost Relay (same for the Flashbots builders) is censoring @TornadoCash transactions. Since the Merge, not a single transaction interacting with the Tornado Cash contracts has been included in their MEV-boosted blocks. /1

Excited to share our latest research on blockchain privacy, specifically focusing on stealth addresses! Special thanks to @msolomon44, @BenDiFrancesco and @VitalikButerin for the great collaboration. Available at: arxiv.org/abs/2306.14272 Looking for a TL;DR? There you go👇

Community efforts to increase Ethereum’s block gas limit are underway. Before proceeding, consider these technical factors and next steps: ethresear.ch/t/on-increasing… Further analysis and updates will guide a measured path forward.

Let's talk Delayed Execution. Together with @fradamt, we've published a post exploring a potential implementation and its impact on scaling Ethereum's Layer 1. 🔗 Read the full post here: ethresear.ch/t/delayed-execu… If you want a quick summary, here's the TL;DR 🧵👇

Why I Believe Validators Should Raise the Gas Limit to 36 Million - a thread 🧵 TL;DR: Let's raise the gas limit to 36 million! more👇

Recently, I've been looking into the data Ethereum is producing post-merge, and it's great to see all the new opportunities for data science research. I've summarized my experience with analyzing MEV in a blog post in hopes of helping others get started /1 medium.com/@toni_w/practical…

P2P org announces that it will call getHeader later in the slot, trading off chain stability against more MEV profits. This is exactly the centralizing behavior that we shouldn't tolerate, as long as we, as users, have the choice about where to stake our assets. 1/2

Block-level Access Lists (EIP-7928) could unlock major scaling gains for Ethereum L1 by enabling faster, parallel block validation. In my latest post, I break down the design space, variants, and trade-offs behind this proposal: 🔗 ethresear.ch/t/block-level-a… TL;DR 👇

Excited to launch timing.pics!🎉 Recently, there's been a growing discussion within the community about timing games. These games can lead to a centralized playing field, and being unaware of them can be equally restrictive. I hope the site guides us well!

New post on Delayed Execution. Together with @fradamt, we explore EIP-7886—a proposal that could unlock 10x L1 scaling by decoupling block validity from execution. ethresear.ch/t/delayed-execu… Let’s break it down 👇

Ethereum’s daily gas usage over time, with major upgrades marked. From Frontier to Pectra and beyond. Continuous scaling.

In my new post, I explore execution dependencies in Ethereum blocks: ethresear.ch/t/execution-dep… TL;DR: Most blocks are highly parallelizable, though a few contain complex dependency chains. Summary below 👇

Quick Fact. Although commonly called flowcharts, their actual name is Sankey diagrams. Introduced in 1869 to show the movements of the Napoleonic army during the French invasion of Russia (1812). Now we can use them to "illuminate" the MEV-Boost Builder -> Relay block flow.

In the last 30 days, Arbitrum, Optimism and Scroll together posted over 10 GB of data to Ethereum L1. That's more calldata than all non-rollup users together. Dencun is coming: March 13, 2024 at 13:55 UTC.

No kid should have to go to sleep without knowing what validators signal as a gas limit! 👉 gaslimit.pics

It was a pleasure to present ERC-5564, a Stealth Address standard, to the wider community at @EDCON2023. What began as a discussion about various stealth address protocols turned into an effort to create a unified base that works for many different stealth address protocols. Together with @msolomon44, @BenDiFrancesco and @VitalikButerin we've been working on this standard for almost a year now and it feels great to finally receive valuable feedback from the community. There's a simple PoC deployed to Sepolia that you can play around with at stealth-wallet.xyz. Furthermore, if you're eager to get started on mainnet, @UmbraCash (built by ScopeLift) is live since 2020 and works perfectly fine!

Updated and beautified the charts to MEV-Boost! Note: The MEV Boost Relay API was used for the data; No data of manifold yet.

90% of attestations arrive within 2 seconds. 6-second slots are comfortably achievable! The chart shows when attestations were first seen during the last 100 missed slots. (Missed slots provide clearer timing data, as all clients attest at the same time)

New analysis on the impact of timing games on Ethereum's consensus online! ethresear.ch/t/on-attestatio… The TL;DR is: -> timing games cause missed attestations -> the proposers of Kiln cause the biggest problems -> attestation timing varies across Lido, Coinbase, and Kiln

Today, 4 relays hold 18-30% market share each. Rsync builders' share climbed from ~10% in early March to stable 15% now.🌟 No builder has more than 25% market share; 4 (out of ~35) are at 15-25%. Find chart at: nerolation.github.io/mevflow…

Next stop → 60 M? 📈

Excited to publish a new dashboard: mempool.pics/. The aim is to add more transparency to Ethereum's mempool. The site shows you all kinds of stats around private order flows and the actors involved. Private order flow has grown more and more into a highly important topic, eventually determining the competitiveness of builders. The site can assist in getting a more comprehensive picture of the MEV/PBS landscape. I hope it's helpful to many.

70% of the total calldata comes from rollups publishing data. Damn ready for blobs.

Happy to share that our paper on Stealth Addresses got published!🎉 We introduce a standardized Stealth Address protocol for Ethereum (ERC-5564), enhancing privacy with unlinkable transactions. ieeexplore.ieee.org/document…

With ongoing discussions about increasing the blob count while lowering the EL payload size in Pectra, I've summarized four potentially interesting changes to the blob fee market. My stance is clear: We should scale up the blob count in Pectra while reducing the maximum payload size. This way, we lower the worst-case limits while giving users what they demand—more space. ethresear.ch/t/on-blob-marke…

Blind signing is risky. I’ve been using a simple script for years to safely preview transactions before sending them. With some AI-assistance, I turned it into a CLI tool so you can easily simulate your transaction before broadcasting. 👉 github.com/nerolation/eth-tr…

Over the past two weeks, two block builders, Beaverbuild and Titan Builder, have produced 88.7% of all blocks. This trend is primarily driven by the rise of private order flow (XOF), sold exclusively by certain apps. XOF reduces genuine competition among builders in the block auction, leading to a smaller pool of shared transactions. This centralization would be less concerning if strong censorship-resistance (CR) guarantees were in place. While Ethereum is making progress on CR, with substantial research underway, new challenges related to centralization through XOF could still emerge. I believe that restricted public access to order flow might encourage colluding builders to take greater risks, potentially resulting in issues with multi-slot MEV.

New post on local builders, private orderflow and the mempool. TL;DR: We may have been overindexing on local builders for censorship resistance (CR). 🔗 ethresear.ch/t/expanding-mem… Here’s a summary thread 👇

Delayed Execution (EIP-7886) is one of the widely discussed proposals aimed at Ethereum L1 scaling, enabling significantly higher gas limits or shorter slot times. I put up this commented spec to give more insight into how it works and where it’s headed: nerolation.github.io/delayed…

Track which node operator signals a higher block gas limit: gaslimit.pics/entities/

Happy to launch calldata.pics🎉 The site provides live data on calldata and blob usage. Furthermore, it comes with visualizations on rollup data, block sizes, blob inclusion, and more. This is still v1 and I plan to add more graphs in the near future.

Core devs be like...

For those interested in Ethereum data analysis, I've open-sourced a data set with validator pubkeys mapped to labels (Lido, Kraken, Rocketpool, etc. including the individual Lido Node Operators). You can access it at mevboost.pics/data.html (updated on a daily basis). The deposit addresses and the necessary heuristics for specific validators were primarily gathered by the great @hildobby_ 👏.

Just published an analysis on big blocks, blobs, and reorgs on ethresearch. I hope it helps guide us in deciding whether to increase the blob count, raise the gas limit, or implement peerDAS. ethresear.ch/t/big-blocks-bl…

Quick analysis to contribute to the "is MEV-Boost even worth it?!" topic: TL;DR: MEV-boost increases APY from 2.93% to 3.24%. ethresear.ch/t/is-it-worth-u…

The Flashbots relay dropped to <80% market share while @bloXrouteLabs max-profit is slowly catching up. In the meantime, we saw two new relayers (of @GnosisDAO and @ultrasoundmoney) launching. Relay diversity improving, check.

Solo stakers miss relatively more slots than professional NOs. But it's not performance that a blockchain such as Ethereum demands from solo stakers. It's decentralization, censorship resistance, and credible neutrality. Instead of relying on pools, we must find ways to support solo stakers better.

Latency is an important factor in the MEV game. In order to unlock a latency edge for builders, the @ultrasoundmoney relay introduced optimistic relaying. Instead of simulating the blocks received from builders, to verify that they adhere to the rules, optimistic relaying skips the simulation step and directly forwards respective blocks to proposers, allowing them to benefit from decreased latency. Builders who submit blocks in the last milliseconds before a block starts can be sure that their block still has a chance of being shown and selected by the proposer. To provide proposers with the assurance that they will receive a block reward even if they get an invalid block from a builder (optimistically submitted through a relay), builders must post collateral at the relay that is used for compensating proposers in the event something fails. Optimistic relaying went live in mid-march and we have had enough time to observe the impact it has had on the PBS ecosystem. Thus, mevboost.pics now also features 3 diagrams on optimistic relaying and bid submissions in general: - Share of optimistically submitted blocks per builder over relays (relay tab). - Timing of bid submissions for both, all bids and winning bids only (builder tab). - Win Ratio for optimistically submitted bids vs. standard submission (builder tab). Currently, the Ultra Sound relay is the only one that offers this (experimental) feature, but from what we can see in the data, it has been going well and has increased the win ratio of builders using it. For more details, refer to @mikeneuder's post about it: github.com/ultrasoundmoney/m…

The Glamsterdam headliner-proposal Block-level Access Lists (EIP‑7928) received much love from core devs recently. But what is it, how does it work, and why do we need it now? Some quick FAQs👇 What’s EIP-7928: Block-Level Access List? -> The EIP introduces Block‑Level Access Lists (BALs) to unlock reliable parallelism on Ethereum. BALs are enforced, block‑wide access list recording every account touched and state diffs (storage keys, balances, nonces, code) during execution. No more guesswork. Clients know up front what to load and how to best parallelize. Primary Benefit: Perfect Parallelism -> With explicit mappings, disk I/O + EVM execution + post state root calculations become fully parallelizable. This cuts worst‑case block validation latency. Faster block validation = higher throughput for all Ethereum users. Secondary Wins: • Execution‑less state transition/updates (e.g., zk‑clients) • Pre‑execution analysis (inclusion lists, warmups) • Sync optimizations and improvements for partial stateless nodes. Low Overhead & Ready: -> ~35 KiB avg. per block at 36 M gas, worst-cases sizes below calldata worst-case sizes. Specs are ready; multiple client teams prototyping. No consensus‑layer changes required. Why Now? -> Ethereum needs predictable scaling. BALs are critical for 2026 targets, enabling robust scaling, faster sync, and next‑gen optimizations. Read more: ethereum-magicians.org/t/eip… Also check out @uttam_singhk explainer: nitter.app/uttam_singhk/status/19… And find more info about the EIP and other proposals for Glamsterdam: forkcast.org/upgrade/glamste…

Excited to release PyXatu, a Python package for easy Ethereum data access! 🔗 github.com/nerolation/pyxatu Features: -> EL + CL data (with timestamps) -> MEV-Boost Data API interface -> Validator label mapping 1/2

With the latest hard fork, beacon chain block roots became accessible in the EVM, enabling proofs against consensus layer data. I hacked on this proof of concept for verifying a validator got slashed. More details and the code in this post: ethresear.ch/t/slashing-proo…

Blob Flow.

New post: Max-Blobs Flag - An Economic Perspective Should local builders limit the number of blobs per block? What revenue is left on the table when doing so? Some data and charts👇 ethresear.ch/t/max-blobs-fla…

Quick update for those that haven't put this on their third screen yet. We're at 17%.

As of today, 28.8% of Ethereum validators are signaling for a higher block gas limit. When proposing blocks, validators can slightly raise or lower the gas limit. As soon as >50% signal for an increase, the gas limit will gradually move toward the level that most agree on.

That's what Lido's 26% block market share entails: A healthy ecosystem within the ecosystem itself.

A decentralized validator set is crucial for several reasons. EIP-7716: Anti-Correlation Penalties brings Ethereum closer to realizing diseconomies of scale. I have summarized the key points in this ethresearch post: ethresear.ch/t/diseconomies-…

You're good, I'll store the blobs.

The data behind mevboost.pics is now Open Source and available almost in realtime.🎉 The first published table contains info on every slot since the merge, MEV-Boost and the mapped block builders, validators, and relays. More tables to come.

Based on a feature request by a loyal .pics user, you can now see who's already signaling for the gas limit increase: gaslimit.pics/entities/index…

New post "Blobs, Reorgs, and the Role of MEV-Boost" is live on EthResearch. One observation is that MEV-Boost users are less often reorged and can handle 6-blob-blocks way better than vanilla builders. Not surprising, but still good to confirm. ethresear.ch/t/blobs-reorgs-…

We are excited to share the recent publication of our research paper, "Time to Bribe: Measuring Block Construction Market", a comprehensive analysis of the block builder and proposer landscape on Ethereum. Working collaboratively with @HatforceSec, @lzhou1110, and @KaihuaQIN, we delved into the intricacies of the PBS ecosystem, and explored its implications on the foundational blockchain structure. Our investigation casts light on topics of vertical integration, essential trust assumptions, and the ongoing struggle against the centralizing tendencies of MEV. We hope, this endeavor helps provide insight into how the dynamics of the PBS ecosystem shape and influence the blockchain space. Find the preprint here: arxiv.org/abs/2305.16468

Happy to publish this analysis on attestations. I delve into: - Node operators' performance - Impact of big blocks - Best and worst validators - Attester/proposer timing strategies ethresear.ch/t/deep-diving-a…

Block building is becoming increasingly competitive: @builder0x69 has overtaken all Flashbots builders in the number of blocks built in the last 14 days. It also overtook Flashbots' "0x..beef" builder in total number of blocks built, moving into the top 3 block builders. /1

Private Order Flow Sankey. Private OF txs bypass the public mempool, going directly from the searcher/user to the builder. JaredFromSubway produces the highest number of private OF, sending to every major builder. Except from that, we see a lot of vertical integration.

I just got unbanked because of crypto—thanks to Austria's Raiffeisen Bank. This system is cooked.

Ethereum is scaling. Next stop -> 45M.

Blobs now constitute a significant portion of the data that validators are handling. As the usage of blobs began to increase, the trend in calldata usage started to decline.

2024 saw the highest nr. of EIPs proposed, with >20 more than 2023. The avg. EIP length has stayed consistent since 2021, with a slight rise. While EIP count doesn’t directly reflect dev effort, 2024 was notably productive for Ethereum. 2025 will be an important year (again).

In the last 14 days, ~48% of all blocks were built by beaverbuild. Titan, the second largest builder, built ~41% of all blocks. Only 8% of blocks were built locally by the respective proposers.

A censoring builder at 40% market share🚨 Right now, we're essentially relying on a single builder with 26% market share (Titan builder) to include OFAC sanctioned content. Inclusion Lists may help: let's face this problem and ship them in Electra.

Ethereum improved on the censorship front. However, without a built-in mechanism to guarantee credible neutrality, the protocol remains vulnerable, depending largely on the discretion and goodwill of block builders. source: censorship.pics

@gakonst providing a glimpse into the future. Account Abstraction + UTXO-like wallets + Stealth Adresses will provide end user privacy without requiring any sort of mixing.

Most rollups post regularly over the slots of an epoch. Arbitrum prefers to post around slots shortly after the 2/3 threshold. This is advantageous because blocks will get finalized in less time.

Stackin' layers on top.

Reorged blocks present some challenges. To provide a clearer overview of reorgs and the entities involved – such as CL Clients, Validators, Relays, and Builders – I've created a quick dashboard. You can check it out at reorg.pics/. Reorgs not only cause the total volume of the chain to shrink (a reorged block results in no transactions for 12 seconds) but also create potential issues with unbundling, missed head votes, and increased MEV in the subsequent block. Notably, due to the complex computations required when handling epoch boundaries, the first and second slots in an epoch are significantly more likely to be missed or reorged than others. Being the proposer for the first or second slot in an epoch carries a burden, and many proposers struggle to meet these demanding requirements. In summary, besides processing the previous slot, the proposer of the first slot must ensure that: - The inactive/active validator set is up-to-date. - Rewards and penalties are processed. - Validators that are not yet active move through the activation queue. - Bad validators are slashed. - Effective balances are updated. - A new RANDAO value is generated. Now, let's consider a situation where the first proposer is late due to the necessary computations at the boundary. They may not receive enough attestations for their block. Then, the second proposer might face a dilemma, depending on whether or not they noticed the late first-slot block. They must decide whether to build on top of the late first-slot block or on top of the preceding block, leaving the previous slot without a block. Finally, the third proposer might disagree with the second proposer's decision to reorg the first-slot block. Instead, they may opt to reorg the block in the second slot of the epoch. You can observe this on the website, showing that blocks in the second slot of an epoch are reorged most frequently, followed by those in the first slot.

This is a diagram I use to track the gas limit for myself. I put it online as it might help others keep an eye on block gas limit changes: gaslimit.pics/

Mevboost.pics now displaying the avg. MEV-Boost payment per relay/builder/validator over different time frames in boxplots:

What do Ethereum users do? * ~20k transactions sending ETH every hour * ~10k token transfers * execute is the second most executed Solidity method, after transfer and before approve.

The RANDAO plays an integral role in Ethereum, providing the necessary randomness for the selection of proposers and committees. I looked into the possibility of RANDAO manipulation and carried out a variety of simulations using historical data. Full post: ethresear.ch/t/selfish-mixin…

New ethresearch post online.🔍 I summarize some findings from analyzing a simulated post MEV-Burn world. ethresear.ch/t/in-a-post-mev…

Tornado-warning.info now featuring block builders 🎉 Some insights 👇

Relay diversity improving: Flashbots' relay share reduced to 50%. Ultrasound & Agnostic relays saw big gains. Major builders such as builder0x69, beaverbuild and Flashbots have contributed to the improved diversity by submitting blocks to those new relays.

It's not the validators. Many validators using mev-boost would propose an uncensored block as long as it outbids the censored block. This is important to not mix up.

Why don't we have finality within a few seconds already? Reading through @benjaminion_xyz's Eth2Book, you'd find out. If you'd like to have a quick TL;DR, let me try: Ethereum is a monolithic blockchain, meaning that all validators process all information. This means, every participant must have enough time to process and verify. Next, we want to have 3 properties: * a high participation (so low barriers to get started with staking). * low overhead (no excessive amount of network traffic that would exclude low-bandwidth regions). * and finally, fast finality (not waiting long until I can be sure that my transaction can't be re-orged away). This is a trilemma. According to @beaconcha_in, there are around 600k validators. With a finality time of 768 seconds (64 slots à 12 seconds), and assuming a single message is required by a validator to agree on a certain to-be-finalized state, this results in 600k/768=781 messages per second. All requiring computing power and bandwidth to be processed. If we now want to reduce finality time, we'd simultaneously increase the required overhead. E.g. finality in 384 (1 epoch) results in 1562 messages. If we increase the required minimum stake, we'd at the same time reduce the number of validators while also reducing the overhead. A reduced overhead would then allow for faster finality. That's the trilemma. I've built this interactive dashboard that allows you to play with the individual properties and see their impact on finality time: github.com/nerolation/stake-… Note that it's purpose is only to showcase the trilemma without being a very accurate source that can reliably be compared to Ethereum. Finally, revisit Ben's post for a more detailed explanation: eth2book.info/capella/part2/…

1/ Should Ethereum ship ePBS (EIP‑7732) in Glamsterdam, or is a leaner alternative better? Let’s unpack. Full Post 👇 ethresear.ch/t/slot-restruct…

Don't let anyone tell you that "proposer timing games aren't bad because blocks stay on the canonical chain and aren't reorged." Late blocks significantly increase the number of missed and incorrect head votes, thus rugging attesters. More here: ethresear.ch/t/deep-diving-a…

The very top of a block (ToB) is the most competitive place for transaction inclusion. Searchers compete to get their bundles in as early as possible. The chart below shows a distribution of indices for private order flow transactions. It's easy to spot the searchers.

Improving Ethereum's decentralization through anti-correlation penalties. In this post, I analyse correlated attestation penalties and their impact on today's staking landscape. ethresear.ch/t/analysis-on-c…

In light of the ongoing concern about censorship, I've summarized some findings about censorship of builders in a blog post: blog.toniwahrstaetter.com/bu…

EIP-7623: Increase calldata cost: eips.ethereum.org/EIPS/eip-7… * reduce max. possible block size & variance without impacting regular users * reduce inefficiencies between average & max block sizes * make room for block gas limit & blob count scaling

Probably the best diagram of the inner mechanics of PBS that I've created so far.

Wacky Races 2.0: Successful payloads delivered since November; Builders are aggregated based on block extra data.

Just deployed a bunch of new stuff to mevboost.pics. You'll now find... * a general metrics tab, * separate tabs for relays and builders (validators to come), * sankey diagram with builders, relays and validators * and many new charts (incl. racing bar charts)

Random fact of the day: 5.6% of all Ethereum validators made their staking deposit with an initial test transaction of 1 ETH, followed by a second transaction of 31 ETH.

Blobs are posted evenly across the slots of an epoch.

A user lost 32 ETH by making a deposit to the ETH2 Deposit Contract with an invalid signature. Stick to the official staking deposit cli to prevent such issues. beaconcha.in/validator/0xac4…

Gas refunds for clearing storage slots help with state bloat but also distort block gas accounting, making blocks look less resource-intensive than they really are. Here’s why that’s a problem, and how EIP-7778 fixes it: ethresear.ch/t/overclocking-… The tldr in this thread👇

A subset of the largest validators, their relative size, their block building preferences and the relative number of OFAC incompliant blocks proposed.

Chart shows slot share of builders within MEV-Boost payment intervals (in ETH). While builders such as eth-builder land many blocks with small MEV-Boost payments, , beaverbuild seems to leverage a competitive edge as MEV opportunities increase.