Scaling Ethereum with Enshrined Native L2s and Stateless Block Building
Introduction
Ethereum’s scalability journey has long explored Layer 2 (L2) solutions to boost throughput while preserving decent...

<div><h1><a href="https://ethresear.ch#p-53665-scaling-ethereum-with-enshrined-native-l2s-and-stateless-block-building-1" rel="nofollow"></a>Scaling Ethereum with Enshrined Native L2s and Stateless Block Building</h1><h2><a href="https://ethresear.ch#p-53665-introduction-2" rel="nofollow"></a>Introduction</h2><p>Ethereum’s scalability journey has long explored Layer 2 (L2) solutions to boost throughput while preserving decentralization. One promising direction—building on prior work like based rollups—is the concept of <em>enshrined native L2s</em>. In this post I argue we can scale Ethereum by creating L2 systems deeply integrated into Ethereum’s protocol, sharing its validator set to process transactions in parallel. This isn’t a novel invention but a refinement of existing ideas, leveraging validators not active in Layer 1 (L1) duties through concepts like Orbit to scale throughput horizontally. By cycling validators between L1 and multiple L2s, we can unlock additional truly native blockspace, increase transaction capacity, and introduce local fee markets—all without demanding ever-heavier node hardware. Each L2 would have the same gas limits and other configurations set as the L1. I do not believe these enshrined native L2s are likely to be highly competitive with non-enshrined L2s. Those are obviously more capable of scaling throughput vertically and creating communities that can tolerate varying degrees of censorship that the enshrined native rollups would not be able to do.</p><p>I don’t believe we can safely outsource block building without having a viable enshrined fallback that would result in drastically lower throughput. Outsourcing block building to sophisticated actors will inevitably create a dependency on them. As MEV reduces over time (applications are incentivized to capture it themselves) block builders earn less and less revenue. As throughput increases, the cost to build blocks becomes more and more expensive. Profitability therefore depends on sophisticated, proprietary knowledge significantly increasing the difficulty of new entrants to block building being competitive. When auctions are winner takes all non-competitive builders cannot survive and you end up high centralization (a duopoly or monopoly wouldn’t be surprising to me). You can navigate through some threads on my perspective here: <a href="https://x.com/keyneom/status/1894523301999120501" rel="nofollow">In Defense of Local Block Building</a>.</p><p>This post will touch on the available design space, focusing on trade-offs and the critical role of stateless block building to horizontal scaling that allows us to keep local block building and keeps Ethereum forkability practical.</p><h2><a href="https://ethresear.ch#p-53665-core-concept-enshrined-native-l2s-with-shared-validators-3" rel="nofollow"></a>Core Concept: Enshrined Native L2s with Shared Validators</h2><p>Enshrined native L2s extend Ethereum’s validator set beyond L1 duties. Currently 31/32 validators are not really actively useful for Ethereum. Ideally we want a system that can ensure as much of the network is productively leveraged as possible. We can take validators not proposing or attesting on L1 (e.g., due to rotation in systems like Orbit) and shift them to L2s, forming committees to handle transaction sequencing and block production. e.g. we could have committees of 96 validators per L2, with 16 validators assigned to FOCIL/proposing duties and the rest attesting. Just like the L1, we would expect a super majority of the L2s stake to attest to the new block for it to be accepted and finalized. Every slot we can rotate 4 validators (I’m speaking as if all validators are 32 eth of stake but I’m aware this is not the case, there’s some complexity here on validator selection, etc. but I think it is something we can solve and want to keep things simple for now) from the L2 they are currently on and transition them back to L1 or another L2, ensuring continuous productivity.</p><ul><li><p><strong>Shared Security</strong>: These L2s inherit Ethereum’s security via zero-knowledge (zk) proofs, validated by the same consensus mechanism and pretty much equivalent censorship resistance guarantees (something basically no L2s currently have).</p></li><li><p><strong>Horizontal Scaling</strong>: Adding more L2s increases throughput without vertically scaling hardware, contrasting with traditional node upgrades.</p></li></ul><p>This leverages the fact that, in systems like Orbit, ~80% of validator stake might be active on L1, leaving ~20% available for L2s, amplifying native blockspace.</p><h2><a href="https://ethresear.ch#p-53665-the-necessity-of-stateless-block-building-4" rel="nofollow"></a>The Necessity of Stateless Block Building</h2><p>For this to work, <em>stateless block building</em> is desirable. Validators can’t store the full state as storage requirements continue to grow even on L1 and much less including all L2s. Instead:</p><ul><li><p><strong>How It Works</strong>: Users or state providers supply <em>witnesses</em> (state data + proofs) with transactions. Validators use Verkle trees to verify these compact proofs (~150 bytes) against the state root, building blocks without local state. You might be able to have certain optimizations that allow for zkEVM proofs of execution that don’t conflict with any other state changes to be submitted as a valid transaction as well at lower gas costs.</p></li><li><p><strong>Why It Matters</strong>: Statelessness keeps hardware requirements low, enabling fast transitions between L1 and L2 duties. It’s the backbone of horizontal scaling, ensuring validators can handle any L2 without syncing massive datasets.</p></li></ul><p>Without statelessness, the benefits of enshrined L2s—flexibility, scalability, and broad participation—collapse under impractical storage and time-to-sync demands.</p><h2><a href="https://ethresear.ch#p-53665-trade-offs-in-the-design-space-5" rel="nofollow"></a>Trade-offs in the Design Space</h2><p>Here’s where the rubber meets the road: balancing validator roles, state management, and bandwidth to make this viable.</p><h3><a href="https://ethresear.ch#p-53665-h-1-validator-committee-size-vs-throughput-6" rel="nofollow"></a>1. Validator Committee Size vs. Throughput</h3><ul><li><p><strong>Trade-off</strong>: Smaller committees (e.g., dozens of validators) simplify coordination and transitions but risk security. Larger ones (e.g., hundreds) enhance decentralization at the cost of overhead.</p></li><li><p><strong>Example Shift</strong>: With ~20% of validators free from L1, a committee of 100 might support many L2s, while 200 per L2 halves that number but bolsters resilience.</p></li><li><p><strong>Impact</strong>: More L2s mean higher throughput, but committee size dictates how many can run securely in parallel. Not only this but at a certain point L1 Gas limits limit how many L2s can actually be supported as well.</p></li></ul><h3><a href="https://ethresear.ch#p-53665-h-2-verkle-tree-or-equivalent-levels-stored-by-validators-7" rel="nofollow"></a>2. Verkle Tree (or equivalent) Levels Stored by Validators</h3><p>We can set a requirement that validators store the root and all intermediate nodes of the Verkle tree up to a certain level, rather than just the root. This allows them to verify witnesses more efficiently without needing to store the entire state but also allows us to reduce the bandwidth overhead of transmitting large witnesses for every transaction. Storing the root and a diff of the previous slot’s tree can help with avoiding invalidating otherwise valid txs that referenced the prior slots state but were too late into the slot to be included and would be invalidated by other transactions modifying their proof paths.</p><ul><li><p><strong>Trade-off</strong>: Storing upper Verkle tree levels (e.g., root to intermediates) reduces witness sizes but increases memory. Storing none keeps validators lean but bloats transaction data.</p></li><li><p><strong>Example Shift</strong>: For a branching factor of 256, storing Levels 0–3 would be I think ~1.7 GB with about 4 billion leaf nodes. At 512 branching, it’s ~13 GB but gives us ~69 billion leaf nodes (leaf nodes for L1 and each L2 with good interop I think this should be good enough for a while).</p></li><li><p><strong>Impact</strong>: More stored levels offset bandwidth increases, letting throughput scale without choking the network.</p></li></ul><h3><a href="https://ethresear.ch#p-53665-h-3-bandwidth-vs-throughput-gains-8" rel="nofollow"></a>3. Bandwidth vs. Throughput Gains</h3><ul><li><p><strong>Trade-off</strong>: Statelessness increases bandwidth per transaction (witnesses), but enshrined L2s multiply native blockspace, potentially dwarfing this cost.</p></li><li><p><strong>Key Benefit</strong>: If switching to stateless block building increases bandwidth requirements by 5x but enables us to support 500 enshrined native L2s then it might be worth the tradeoff. This also creates <em>local fee markets</em> per L2, so if we allow for app migration we might see apps that interact often settle next to each other within L2s to avoid interop overhead and large apps move to L2s with lower use to avoid being impacted by demand for other apps driving up fees for users. All of which is to say that over the long term we might see close to optimal throughput achieved.</p></li></ul><h3><a href="https://ethresear.ch#p-53665-h-4-validator-transition-speed-9" rel="nofollow"></a>4. Validator Transition Speed</h3><ul><li><p><strong>Trade-off</strong>: Minimal state (root only) stored in memory for validators enables near-instant transitions but demands larger witnesses. Storing intermediate levels slows transitions for tx bandwidth savings. We could include other things like all smart contract code is expected to be stored by the validators and would need to be synced before they are able to participate in L2 duties besides attestation. i.e. contract storage slots or eoa accounts, etc would be expected to have witnesses provided by the user (a state provider could provide the user with that data of course as well and ideally we have the eLTS–see my eth research post for more details there–as a back up). This means that the user only needs to provide a few witnesses for storage slots or account balances and all validators would be able to execute all transactions at all times. There are alternatives to this where we only keep an active set of contracts in memory and the rest would need witnesses provided for them. This recent post discusses that in greater detail (<a href="https://ethresear.ch/t/a-protocol-design-view-on-statelessness/22060" rel="nofollow">A Protocol Design View on Statelessness</a>).</p></li><li><p><strong>Example Shift</strong>: Root-only transitions take ~1 second, while ~1.7 GB syncing might take ~5 minutes, depending on network speed requirements for validators.</p></li><li><p><strong>Impact</strong>: Faster transitions maximize validator utility, but slower ones optimize transaction efficiency.</p></li></ul><h2><a href="https://ethresear.ch#p-53665-why-this-matters-throughput-and-beyond-10" rel="nofollow"></a>Why This Matters: Throughput and Beyond</h2><ul><li><p><strong>Native Blockspace</strong>: Enshrined L2s create a <em>massive</em> increase in native blockspace, allowing Ethereum to scale horizontally. This is a key differentiator from other L2s that rely on external validators.</p></li><li><p><strong>Bandwidth Offset</strong>: Yes, stateless witnesses increase bandwidth, but ideally the increase in native blockspace via L2s can far outpace this.</p></li><li><p><strong>Local Fee Markets</strong>: With enshrined L2s, we can create local fee markets, preventing demand on one app from impacting simple payments from being practical elsewhere. Enshrined L2s could receive a free allotment of blobspace or have a variety of other fee mechanisms and/or issuance mechanisms to find a reasonable balance to how this works.</p></li></ul><h2><a href="https://ethresear.ch#p-53665-conclusion-11" rel="nofollow"></a>Conclusion</h2><p>There’s obviously a ton of work that would be necessary to carry out this vision with plenty of open questions on the balance to strike between certain trade-offs. I believe enshrined native L2s, powered by stateless block building, offer the best path to scale Ethereum horizontally and maintain its long-term censorship resistance. Controlling fork choice has serious ramifications. When we limit who is capable of building the chain from a practical perspective we give up fork choice and leave ourselves susceptible to the influence of powerful actors to the harm of everyone else. Approaches to SSF like orbit that enable anyone to participate in voting on forks are our best path forwards. It also enables us to tap validators that aren’t active in L1 duties for potentially massive throughput gains. We <em>can</em> enhance capacity while keeping nodes accessible and <em>without</em> losing Ethereum’s decentralized soul.</p><div><br></div></div>

Enshrined Native L2s and Stateless Block Building

이더리움(ETH)의 고유 L2와 상태 없는 블록 구축을 통한 확장
소개
이더리움(ETH)의 확장성 여정은 오랫동안 처리량을 높이면서 적절한 수준을 유지하기 위한 레이어 2(L2) 솔루션을 탐구해 왔습니다...

<div><h1><a href="https://ethresear.ch#p-53665-scaling-ethereum-with-enshrined-native-l2s-and-stateless-block-building-1" rel="nofollow"></a>이더리움(ETH)을 고유 L2와 상태 없는 블록 빌딩으로 확장하기</h1><h2><a href="https://ethresear.ch#p-53665-introduction-2" rel="nofollow"></a>소개</h2><p>이더리움(ETH)의 확장성 여정은 오랫동안 분산성을 유지하면서 처리량을 높이기 위한 레이어 2(L2) 솔루션을 탐구해 왔습니다. 유망한 방향 중 하나는 기존 롤업 작업을 기반으로 한 고유 L2 시스템의 개념입니다. 이 글에서 저는 이더리움(ETH)의 프로토콜에 깊이 통합된 L2 시스템을 만들어 이더리움(ETH)을 확장할 수 있다고 주장합니다. 이 시스템은 동일한 검증자 세트를 공유하여 트랜잭션을 병렬로 처리합니다. 이는 새로운 발명이 아니라 기존 아이디어의 개선으로, Orbit과 같은 개념을 통해 레이어 1(L1)에서 활성화되지 않은 검증자를 활용하여 처리량을 수평적으로 확장합니다. 검증자를 L1과 여러 L2 사이에서 순환시킴으로써 추가적인 고유 블록 공간을 해제하고, 트랜잭션 용량을 늘리며, 로컬 수수료 시장을 도입할 수 있습니다. 이 모든 것이 더 무거운 노드 하드웨어를 요구하지 않고 가능합니다.</p>

[이하 생략되었습니다. 전체 번역을 원하시면 추가로 요청해 주세요.]

모셔진 네이티브 L2 및 무국적 블록 빌딩

미국 노동통계국(BLS)은 목요일 13시 30분 (스테픈(GMT) 에 매우 중요한 11월 소비자물가지수( 소비자 가격 지수(CPI) ) 데이터를 발표할 예정입니다.
물가상승률 보고서에는 소비자 가격 지수(CPI) 포함되지 않습니다.

투자자들이 연준의 1월 금리 전망을 주시하는 가운데 미국 소비자 가격 지수(CPI) 에 관심이 집중되고 있다.

2025년의 기술 뉴스만 본다면 세상이 온통 좋은 것처럼 보일 겁니다. AI 투자는 계속되고, 북미 데이터 센터 건설은 가속화되며, 암호화폐 채굴업자들은 마침내 "경기 순환에서 벗어나" 이전에 변동성이 컸던 채굴 업무 안정적인 AI 해시레이트 서비스로 성공적으로 전환할 것입니다.
기사 작성자 및 출처: Anita, MarsBit
하지만 월스트리트의 신용 부서 분위기는 완전히 달랐습니다. 신용 투자자들은 모델 성능에 대해 논의하지도 않았고, 어떤 세대의 GPU가 더 강력한지에도 관심이 없었습니다. 그들은 엑셀 스프레드시트에 적힌 핵심 가정에만 집중하고 있었습니다.

해시레이트 의 서브프라임 위기: AI 인프라 채무 급증, 채굴 기업의 레버리지, 그리고 "청산 유동성"의 소멸

비트코인의 "실현 시가총액"이 사상 최고치인 1조 1250억 달러를 기록하며, 지난 10주 동안 가격이 거의 40% 폭락했음에도 불구하고 비트코인(BTC) 여전히 불 에 있음을 시사합니다.
이 온체인...