# LingLong: Pre-Settle Ethereum By [Luban](https://paragraph.com/@luban-2) · 2025-05-01 --- Ethereum Scaling Challenges and the Based Rollup Solution --------------------------------------------------------- Ethereum's rollup-centric approach has built a $30B L2 ecosystem, yet concerns over fragmentation and a diminished L1 value proposition grow. Scaling the L1 is a much needed short term solution. However, in the long term, expecting a single virtual machine on every node to support global-scale finance and applications is unrealistic without compromising decentralization. **We still need rollups**. ### The Core Problem How to scale Ethereum via rollups, while preserving decentralization, sustaining L1 value capture, and maintaining a composable ecosystem. ### The Solution **Based rollups** solve the challenge by adding shard-like execution extensions to Ethereum while leveraging the L1 for sequencing. This approach aligns with three key scaling trends: #### 1\. Decoupling Execution from Consensus Emerging solutions decouple execution from consensus: * Solana proposes [Asynchronous Program Execution](https://www.helius.dev/blog/asynchronous-program-execution) to build blocks before verification. * Monad [achieves consensus](https://docs.monad.xyz/monad-arch/consensus/asynchronous-execution) before executing transactions. * Ethereum is progressing with EIP‑7732 (ePBS) to boost throughput and accelerate finality—capabilities critical for based rollups. #### 2\. Parallel Execution and Local Fee Markets Parallelization enables higher throughput by processing mutiple transactions concurrently: * High performance chains like [Solana](https://github.com/solana-foundation/solana-improvement-documents/pull/110), [Sui](https://blog.sui.io/shared-object-congestion-control/), and [Monad](https://docs.monad.xyz/monad-arch/execution/parallel-execution) process transactions in parallel, creating isolated "local" fee markets that keep hotspots from throttling the chain. * Similarly, Ethereum rollups serve as parallel execution zones with independent fee dynamics. For more on local fee markets, see Luban's [previous](https://www.luban.wtf/Building-Local-Fee-Markets-on-Ethereum-Part-I-12dfd86cb60f80a7a632c1b3993bc01f) [writings](https://www.luban.wtf/Building-Local-Fee-Markets-on-Ethereum-Part-II-136fd86cb60f80d383f4fefbd31fa2be). #### 3\. Maintaining Synchronous Composability Parallel VMs stay composable only if they coordinate state conflicts: * deterministic read/write lists before execution (Solana, Sui) * or optimistic "run-then-replay" parallelization (Aptos, Monad). Absent either, calls between threads can only be **asynchronous**, consider separate Cosmos zones communicating over IBC, or separate rollups on Ethereum today connected via bridges. Based rollups restore Ethereum's missing **synchronous composability** by moving each rollup's sequencing back to the L1. Since the same Ethereum validators order both L1 and L2 transactions within a single block, state transitions on based rollups and L1 share a unified, canonical order, enabling real-time interaction across layers. What's Missing for Based Rollups Today -------------------------------------- Based rollups face a critical trade-off: preserving their _based_ properties (inheriting liveness and censorship-resistance from L1, synchronous composability) versus optimizing user experience. Fully L1-driven sequencing inherits Ethereum's 12-second block time and per-block settlement, resulting in slow, costly transactions. To address this, **preconfirmation** are used, where Ethereum validators sequence and confirm transactions before they're settled on L1. However, preconfirmation introduces two key challenges: 1. **Cold Start**: Each based rollup must independently bootstrap and maintain its own validator network, leading to duplicated effort and resource inefficiency as the ecosystem grows. 2. **Scalability**: It's impractical to expect every single Ethereum validator to run 1000 sidecars and sequence for 1000 based rollups. These gaps highlight the need for a unified framework that efficiently connects validators to based rollups, enabling superior UX while preserving the core benefits of based sequencing. LingLong: The Pre-Settlement Layer for Ethereum ----------------------------------------------- Luban introduces [LingLong](https://github.com/lu-bann/linglong), a proposer commitment and delegation framework that enables **pre-settlement** of rollups on Ethereum. LingLong allows * **Based Rollups** to choose where they want to be on the _basedness_ spectrum, offering flexible sequencing models and ways to capture value. * **Validators** to earn passive yields from rollup activity, strengthening both Ethereum L1's value proposition and ETH as an asset. ### Pre-settlement Pre-settlement is a proposer commitment primitive that enables Ethereum validators to delegate their based rollup sequencing rights to third parties. LingLong embodies this primitive, thereby effectively facilitating PBS (Proposer-Builder Separation) for based rollups. Currently, most validators delegate block building rights to the highest-bidding block builder via MEV-Boost relays, maximizing passive returns through auctions. Similarly, validators by definition possess sequencing rights for based rollups and can delegate these rights to earn passive yield. The delegatee—known as a **gateway**—becomes the actual rollup sequencer. Unlike MEV-Boost auctions where builders are chosen just-in-time, the gateway must be chosen ahead of time since rollup users require instant transaction confirmation. Linglong makes this possible through restaking-secured credible commitments, allowing rollups to settle state update before actual L1 settlement. > `Pre-settlement vs. Preconfirmation` > > In preconfirmation, the 'preconfirmer' must be the proposer of the next Ethereum block to guarantee absolute settlement certainty for the preconfirmed transactions—since the proposer controls the block. A preconfirmer who is not the proposer cannot offer the same level of assurance. > > Pre-settlement decouples the roles of preconfirmer and proposer, allowing anyone to act as a preconfirmer (gateway) while still achieving absolute settlement certainty through delegation from proposers. Rather than relying on centralized solutions with individual gateways, validators delegate to a gateway network that supports customizable selection mechanisms to optimize for both validator and rollup. ### Restaked Services Pre-settlement operates through LingLong's restaked services, which use restaking protocols to extend validator commitments across a permissionless range of activities—such as rollup sequencing—while shielding validators from operational, legal, and financial risks. **Restaked Validator Service (RVS)** is foundational to all other restaked services. Validators join RVS and provide the required stake through restaking—using either their own staked ETH or external capital from restakers—to delegate rights and duties to other restaked services. ![Restaked Validator Service (RVS)](https://storage.googleapis.com/papyrus_images/2c625816a77977d922322fdfc4da971e88f9c5ae0e11c6a359dcec89c4af5277.jpg) Restaked Validator Service (RVS) **Restaked Gateway Service (RGS)** is a network of sequencing gateways that receives delegation from validators to sequence based rollups. RGS creates a marketplace where gateways can join by meeting rollup sequencing requirements and compete for sequencing opportunities. When RVS delegates rollup sequencing rights to RGS * rollups dictate their own sequencing models, * validator receives passive yield from rollup activities, * rollup users receive instant transaction confirmation from gateways, * restakers receive yield from restaked services they are securing. ![Restaked Gateway Service (RGS)](https://storage.googleapis.com/papyrus_images/60efbe0ea8ba7346919af96784b8f8aebec1939e4585a749aa696a84117fd54f.jpg) Restaked Gateway Service (RGS) **Note**: More restaked services can be built on top of RVS permissionlessly. For example, validators can delegate future blockspace and blobs to an underwriter network, enabling users to secure faster confirmations and deterministic L1 costs with blockspace futures. As a validator, the downside of opting into RVS is limited yet the upside is unlimited. ### Sequencing Models LingLong, or specifically RGS supports three configurable sequencing models compatible with all rollups—not just based ones. This flexibility allows rollups to balance decentralization, performance, and control throughout their platform's development stages. #### 1\. **Fully-Based Model** * **Based Sequencing**: Validators freely choose rollup gateways through RGS auction mechanisms. * **No Rollup Restrictions**: Rollups place no constraints on gateway selection. * **Use Cases**: Ideal for rollups prioritizing maximum decentralization and censorship resistance. #### 2\. **Half-Based Model** * **Hybrid Approach**: Rollups establish gateway requirements (like native token staking or hardware specifications), while validators select from qualified candidates. * **Two-Stage Process**: Gateways must first satisfy rollup criteria, then compete for validator selection. * **Use Cases**: Suitable for rollups requiring specific infrastructure or focusing on native token value capture. #### 3\. **Fully-Centralized Model** * **Direct Appointment**: Rollups directly assign their gateways without validator involvement. * **Maximum Control**: Mirrors the structure of traditional centralized sequencer rollups. * **Use Cases**: Best for early-stage rollups or those prioritizing MEV control. What the Future Looks Like -------------------------- Existing rollups can use LingLong to gradually transition to being based. A centralized sequencer rollup can initially adopt the fully-centralized sequencing model—which preserves complete control for the rollup operator—while benefiting from guaranteed settlement certainty through proposer commitments. Their sequencer, as part of RGS, can then compete to sequence other rollups (including L1) to enhance cross-chain composability for their users. Most rollups are expected to adopt the half-based model. Rollup operators can accrue value by setting gateway selection criteria while opening sequencing to a unified market of professional gateways. These gateways aim to sequence multiple rollups and L1 to maximize returns, naturally creating a synchronously composable ecosystem. The fully-based model creates pure extensions to Ethereum L1's execution environment. It's analogous to sharding, but in a bottom-up way. Based rollups can be built permissionlessly without requiring changes to Ethereum consensus. At Luban, we envision a horizontally scalable Ethereum as a unified ecosystem that eliminates the boundary between dapps and rollups. Any application or group of applications can seamlessly become part of Ethereum, accessing the strongest cryptoeconomic security and largest onchain financial ecosystem while maintaining sovereignty and user experience. Assets and operations flow freely across all applications, whether they're L1 smart contracts or rollups. --- *Originally published on [Luban](https://paragraph.com/@luban-2/linglong-pre-settle-ethereum)*