Linglong Pre-Settlement Layer PRD

# LingLong Pre-Settlement Layer ## 1. Introduction This PRD outlines the technical requirements and smart contract interfaces for the LingLong Pre-Settlement Layer. This doc purports to propose the design and get initial input from various stakeholders. The document provides comprehensive information about the architecture, components, interfaces, and user flows necessary to build and deploy the Pre-Settlement Layer. ## 2. The Problem Based rollups as a Ethereum scaling solution face a critical trade-off: preserving their *based* properties (L1-driven sequencing, decentralization, and synchronous composability with Ethereum) versus optimizing user experience. Full L1-driven sequencing inherits Ethereum’s 12-second block time and per-block settlement, resulting in slow, costly transactions. To mitigate this, based rollups are emploring *preconfirmation*, where validators sequence transactions and provide user confirmations before onchain settlement. However, preconfirmation introduces two key challenges: 1. **Cold Start Problem**: Each based rollup must independently bootstrap and maintain its own validator network, creating significant overhead as the ecosystem expands. This fragmentation inefficiently duplicates effort and resources across multiple rollups. 2. **Centralization Pressure**: To simplify operations, many preconfirmation systems rely on centralized gateways, undermining the core decentralization benefits of based rollups. At worst, this transforms based rollups into effectively centralized systems with single points of failure. The ecosystem urgently needs a unified framework that can: - Efficiently connect validators to multiple rollups without duplicating efforts - Support diverse rollup designs and sequencing preferences - Preserve validator sovereignty and decentralization Our proposed solution addresses these needs by creating a universal, flexible architecture that maintains Ethereum validators' agencies. This approach allows the based rollup to scale horizontally without sacrificing decentralization, security, or forcing each rollup to reinvent preconfirmation infrastructure. ## 3. Overview The LingLong Pre-Settlement Layer is a proposer commitment and delegation framework that redefines rollup sequencing by enabling Ethereum validators to delegate sequencing rights to specialized gateways/sequencers in a trustless manner. The framework leverages restaking protocols, such as Eigenlayer and Symbiotic, to extend Ethereum proposer commitments beyond its core consensus. Through its modular design, LingLong orchestrates sequencing service delegation, data availability management, and auxiliary functions, thereby creating a streamlined process for based rollups to maximize composability with L1. ## 4. Goals ### Validator - A validator should be able to delegate sequencing duties to specialized gateways without transferring operational control - A validator should be protected from gateway failures affecting their security or stake position - A validator should be fairly rewarded for delegating sequencing duties ### Rollup - A rollup should be able to configure its sequencing model and define customized conditions for gateways who sequence its transactions - A rollup should be able to seamlessly become based and tap into all validators who accept this framework ### Gateway - A gateway should be able to join the framework permissionlessly and have access to the sequencing rights of all participating rollups - A gateway should be required to satisfy conditions set by rollups - A gateway should be held accountable for malicious activities ## 5. System Architecture The LingLong Pre-Settlement Layer consists of several interconnected smart contracts that work together to enable the delegation and commitments from validators. ```mermaid flowchart LR %% Core contracts only URC("Universal Registry Contract") Slasher("Slasher Contract") RVS("Restaked Validator Service") RGS("Restaked Gateway Service") RRC("Rollup Registry Contract") %% Simple contract relationship labels URC <-->|"Coordinates slashing"| Slasher URC -->|"Registration"| RVS RVS -->|"Delegation"| RGS RGS -->|"Sequences for"| RRC %% Improved styling for contracts classDef contractStyle fill:#f8d7fe,stroke:#333,stroke-width:1px,rx:8,ry:8,font-size:14px class URC,Slasher,RVS,RGS,RRC contractStyle ``` ### Restaked Services The Restaked Services in LingLong leverage existing restaking infrastructure like [Eigenlayer](https://docs.eigenlayer.xyz/eigenlayer/overview) and [Symbiotic](https://symbiotic.foundation/) to create a layered security model with isolated risk and rewards. This architectural approach provides economic security while maintaining clear boundaries between different layers of the system. At the foundation, restaking protocols enable Ethereum validators to extend their capital efficiency by securing multiple services simultaneously. Each layer in this architecture maintains its own slashing conditions and reward parameters, ensuring that risk never spills vertically across layers. This isolation is fundamental to the system's design—failures in one layer do not compromise the integrity of others. Multiple services can be built on top of this foundational layer, particularly RGS(See below). These services interact with the RVS through delegation mechanisms, each operating with distinct security models and use cases. Within each service layer, different classes of entities can exist—what Eigenlayer calls ["operator sets"](https://github.com/eigenfoundation/ELIPs/blob/main/ELIPs/ELIP-002.md) and Symbiotic terms ["subnetworks"](https://docs.symbiotic.fi/middleware-sdk/api-reference/extensions/Subnetworks/)—each with siloed risk and reward profiles. This modular architecture creates a flexible ecosystem where: 1. Validators can delegate to various services based on their risk preferences 2. Restaked Services can define their own security parameters without impacting others 3. Rollup enjoys different sequencing models while taping into a large validator set The clear separation between layers enables independent evolution of services while maintaining system-wide stability. If a particular service experiences issues, other services remain unaffected, preserving the overall health of the network. In the first version of LingLong, we implement two primary restaked services: #### Restaked Validator Service (RVS) The Restaked Validator Service enables Ethereum validators to make credible commitments beyond Ethereum's core consensus by restaking through platforms like Eigenlayer and Symbiotic. This service forms the foundation of the Pre-Settlement Layer, allowing validators to: 1. **Delegate Specialized Duties**: Validators can delegate sequencing and other duties to specialized restaked services without giving up operational control. 2. **Maximize Yield Opportunities**: Validators can earn additional passive income through trustless delegation to other restaked services. 3. **Maintain Security Guarantees**: The service preserves Ethereum's security model through clear risk isolation and fault attribution mechanisms that ensure Ethereum base layer validators are not subject to slashing risks from sequencing activities. Slashing penalties are confined exclusively to the sequencing layer. 4. **Participate Without Technical Overhead**: Validators can contribute to the rollup ecosystem without implementing complex technical infrastructure. The service creates a foundational layer for proposer commitment, enabling Ethereum validators to trustlessly delegate their blockspace to rollups while maintaining full security guarantees and focusing on their core responsibility of securing the network. #### Restaked Gateway Service (RGS) The Restaked Gateway Service manages a network of sequencing gateways that receive delegation from validators to sequence based rollups. This service creates a marketplace where: 1. **Permissionless Participation**: Any gateway/sequencer can join the network by meeting the rollup's sequencing requirements. 3. **Customizable Rules**: Rollups can express preferences in gateway selection while maintaining access to a unified market. The service supports various selection scenarios from fully-based (validator-controlled) to fully-centralized (rollup-appointed) and hybrid approaches, creating an efficient marketplace that preserves both validator sovereignty and rollup flexibility. ### Universal Registry Contract(URC) [URC](https://github.com/eth-fabric/urc) is a governance-free and immutable contract that serves as the foundation for proposer commitments in the LingLong ecosystem. The URC enables: - Anyone to **register** for proposer commitments, including Ethereum validators who wish to opt in to the LingLong system - Anyone to **slash** proposers that break commitments Within the LingLong Pre-Settlement Layer, the URC is used to track Ethereum validators who have opted into the system, providing a reliable and immutable registry of participants. ### Slasher The Slasher Contract enforces fraud proof submissions. The Slasher contract extends [Universal Registry Contract's Slasher interface](https://github.com/eth-fabric/urc/blob/main/src/ISlasher.sol) with additional interactive slashing capabilities to handle more complex violation scenarios. The LingLong Slasher operates as the critical link between detected protocol violations<>the execution of appropriate penalties, coordinating with the URC to manage the slashing of validators and operators. It implements the URC's `ISlasher` interface, and extends it with a more sophisticated challenge-response system that enables fair adjudication of complex protocol violations. ### Rollup Registry The Rollup Registry Contract serves as the central coordination point for rollups within the LingLong Pre-Settlement Layer. This contract manages the registration and configuration of rollups, facilitating their integration with the sequencing infrastructure while maintaining their autonomy. The registry fulfills several critical functions: 1. **Rollup Registration**: Enables rollups to register with the Pre-Settlement Layer by specifying their preferred sequencing model, gateway eligibility criteria, fee split arrangement, and other configurable parameters. This registration process establishes the rollup's identity and preferences within the ecosystem. 2. **Sequencing Model Management**: Maintains and enforces three sample sequencing models (see [Appendix: Fully-Based, Half-Based, and Fully-Centralized](https://hackmd.io/sx_w_ayVQZWTLA0YKL_NmQ?both#A1-Fully-Based-Model)) that rollups can select from, with distinct logic for each: - For Fully-Based rollups, it facilitates validator-controlled sequencer selection - For Half-Based rollups, it enforces gateway eligibility requirements before enabling validator selection - For Fully-Centralized rollups, it records and enforces appointed sequencer assignments 4. **Batch Submission Authorization**: Acts as the gatekeeper for batch submissions, verifying that only authorized sequencers (either selected through the appropriate mechanism or appointed directly) can submit batches for a specific rollup and slot. 6. **Bridge Contract Interfacing**: Maintains the connection between rollups and the Pre-Settlement Layer by recording and interfacing with each rollup's bridge contract, which serves as the entry point for batch submissions. The Rollup Registry Contract embodies the flexibility of the LingLong Pre-Settlement Layer, enabling a spectrum of sequencing arrangements from fully decentralized to fully centralized. By providing this configurable infrastructure, it allows rollups to optimize for their specific needs while maintaining integration with the broader ecosystem. ## 6. User Flows ```mermaid sequenceDiagram participant URC as Universal Registry Contract participant Slasher as Slasher Contract participant RVS as Restaked Validator Service participant RGS as Restaked Gateway Service participant RRC as Rollup Registry Contract %% Registration Flow rect rgba(191, 223, 255, 0.2) Note over URC, RRC: Registration Flow URC->>RVS: Register validator information RRC->>RRC: Store rollup configuration end %% Delegation Flow rect rgba(255, 204, 204, 0.2) Note over URC, RRC: Delegation Flow URC->>RVS: Validate validator credentials RVS->>RGS: Delegate sequencing authority RRC->>RGS: Provide eligibility criteria end %% Sequencing Flow rect rgba(204, 255, 204, 0.2) Note over URC, RRC: Sequencing Flow alt Fully-Based Model RGS->>RGS: Select gateway via auction else Half-Based Model RRC->>RGS: Send gateway filtering criteria RGS->>RGS: Apply criteria & select gateway else Fully-Centralized Model RRC->>RGS: Specify appointed gateway end RGS->>RRC: Request batch submission authorization RRC->>RRC: Verify sequencer authorization RRC->>RRC: Process batch & store commitments end %% Slashing Flow rect rgba(255, 235, 204, 0.2) Note over URC, RRC: Slashing Flow alt Gateway Violation Slasher->>Slasher: Create SlashingChallenge record alt Non-Interactive Slashing Slasher->>Slasher: Verify violation proof immediately Slasher->>RGS: Submit verified slashing evidence RGS->>RGS: Execute gateway penalty else Interactive Slashing Slasher->>Slasher: Initiate dispute period RGS->>Slasher: Submit counter-evidence (optional) Slasher->>Slasher: Resolve challenge after dispute period Slasher->>RGS: Execute penalty if challenge upheld end else Validator Violation Slasher->>Slasher: Create SlashingChallenge record alt Non-Interactive Slashing Slasher->>Slasher: Verify violation proof immediately Slasher->>URC: Submit verified slashing evidence URC->>URC: Execute validator penalty else Interactive Slashing Slasher->>Slasher: Initiate dispute period URC->>Slasher: Submit counter-evidence (optional) Slasher->>Slasher: Resolve challenge after dispute period Slasher->>URC: Execute penalty if challenge upheld end end end %% Reward Distribution Flow rect rgba(204, 204, 255, 0.2) Note over URC, RRC: Reward Distribution Flow RRC->>RGS: Forward sequencing fees RGS->>RGS: Calculate gateway portion RGS->>RVS: Send validator portion RVS->>URC: Forward validator rewards URC->>URC: Distribute to validator stakes end ``` ### Rollup Operator Flow 1. **RGS Registration** - Rollup operator indicates participation in the Pre-Settlement Layer - Registers configuration in the Rollup Registry contract 2. **Gateway Selection Rule Setting** - Configures rollup-specific gateway selection rules within the RGS ### Gateway Flow 1. **Registration & Restaking** - Registers as an operator in the RGS - Puts up required collateral via restaking 2. **Market Participation** - Satisfies rollup-specific requirements to become eligible for gateway selection - Competes with other gateways in the selection process - Sequences rollups when selected ### Validator Flow 1. **Registration & Restaking** - Registers with the RVS through URC - Puts up required collateral via restaking 2. **Delegation** - Delegates rollup sequencing rights to the RGS - Optionally delegates blockspace rights to the DPS 3. **Passive Income Generation** - Receives payouts from delegated services ### Slasher Flow 1. **Violation Monitoring** - Monitors the network for protocol violations - Receives submissions of potential violations from network participants 2. **Challenge Processing** - Creates a `SlashingChallenge` record for each submitted violation - Associates challenges with the responsible party (validator or gateway) 3. **Evidence Verification** - For non-interactive slashing: Verifies cryptographic proofs of violations immediately - For interactive slashing: Initiates a dispute period where accused parties can submit counter-evidence 4. **Slashing Execution** - Coordinates with URC to slash validators when they are at fault - Coordinates with RGS to slash gateways when they are at fault - Records slashing outcomes and distributes any rewards to challengers 5. **Challenge Resolution** - Updates challenge status throughout its lifecycle (Pending -> Verified -> Disputed/Executed/Rejected) - Provides transparency into the slashing process through challenge status tracking - Allows querying of active challenges for any address ## 7. Interfaces > **Note**: The interfaces presented in this section are works in progress and subject to change as development continues and feedback is incorporated. These interfaces are not meant to be exhaustive in terms of functions but only include core functions ### 7.1 Universal Registry Contract (URC) The URC forms the foundation of the system, managing validator registrations and commitments. The implementation is available at [https://github.com/eth-fabric/urc](https://github.com/eth-fabric/urc). ### 7.2 Slasher Contract The Slasher Contract serves as the adjudication mechanism, verifying violations and coordinating penalties. The LingLong Slasher extends the [URC's ISlasher interface](https://github.com/eth-fabric/urc/blob/main/src/ISlasher.sol) with additional interactive slashing capabilities to handle more complex violation scenarios. > **Note**: The interface below only shows the extensions beyond the base ISlasher.sol interface. The LingLong Slasher inherits all structures (Delegation, SignedDelegation, Commitment, SignedCommitment) and functions (slash, slashFromOptIn) from the URC's ISlasher interface. ```solidity /** * @title ILingLongSlasher * @notice Extended adjudication mechanism for complex protocol violations * @dev Inherits from URC's ISlasher and adds interactive slashing capabilities */ interface ILingLongSlasher is ISlasher { /** * @notice A struct containing metadata for a slashing challenge */ struct SlashingChallenge { /// Unique identifier of the challenge bytes32 id; /// Type of violation (e.g., missed preconfirmation, invalid commitment) ViolationType violationType; /// Target being challenged (validator or gateway address) address target; /// Address of the challenger address challenger; /// Timestamp when the challenge was submitted uint256 timestamp; /// Current status of the challenge (pending, verified, disputed, executed, rejected) ChallengeStatus status; /// BLS key registration root if targeting a validator bytes32 registrationRoot; /// Rollup address if related to a rollup-specific violation address rollup; /// Signed commitment for integrity verification SignedCommitment signedCommitment; /// Dispute period end timestamp (zero if non-interactive) uint256 disputePeriodEnd; } /** * @notice Creates a new slashing challenge directly from a SlashingChallenge struct * @param challenge Complete SlashingChallenge struct with all challenge details * @return challengeId Unique identifier for the submitted challenge * @dev For creating challenges with complex metadata requirements */ function createChallenge(SlashingChallenge calldata challenge) external returns (bytes32 challengeId); /** * @notice Executes immediate slashing for objectively verifiable violations * @param challengeId ID of the validated violation challenge * @return updatedChallenge The full challenge struct after execution * @dev For non-interactive slashing with clear cryptographic proof */ function executeNonInteractiveSlashing(bytes32 challengeId) external returns (SlashingChallenge memory updatedChallenge); /** * @notice Initiates interactive slashing with dispute period * @param challengeId ID of the violation challenge * @param disputePeriodDuration Duration of the dispute period in seconds * @return updatedChallenge The full challenge struct after initiation * @dev For violations requiring subjective assessment */ function initiateInteractiveSlashing( bytes32 challengeId, uint256 disputePeriodDuration ) external returns (SlashingChallenge memory updatedChallenge); /** * @notice Submits evidence against a slashing claim during dispute period * @param challengeId ID of the violation challenge being disputed * @param counterEvidence Evidence countering the violation claim * @return updatedChallenge The full challenge struct after dispute * @dev Allows accused parties to defend against slashing */ function disputeChallenge( bytes32 challengeId, bytes calldata counterEvidence ) external returns (SlashingChallenge memory updatedChallenge); /** * @notice Finalizes an interactive slashing after dispute period * @param challengeId ID of the violation challenge * @return updatedChallenge The full challenge struct after finalization * @dev Can result in execution or rejection based on dispute resolution */ function finalizeInteractiveSlashing(bytes32 challengeId) external returns (ChallengeStatus newStatus); } ``` ### 7.3 Restaked Validator Service (RVS) The RVS manages validator delegation to specialized services and coordinates the delegation flow. ```solidity /** * @title IRestatedValidatorService * @notice Manages validator delegation to specialized services * @dev Acts as middleware between validators and service contracts */ interface IRestatedValidatorService { /** * @notice Represents a validator's registration data for the URC * @dev This struct mimics the URC's Registration struct for consistency */ struct ValidatorRegistration { /// BLS public key BLS.G1Point pubkey; /// BLS signature BLS.G2Point signature; } /** * @notice Registers validators with the URC and onboards them to the RVS * @param validatorRegistrations Array of validator registrations (public key and signature pairs) * @param owner Address authorized to control these validator registrations * @return registrationRoot The merkle root of the registrations from the URC * @dev This function is payable to accept the collateral required for URC registration * @dev It acts as a wrapper around the URC's register function, adding RVS-specific functionality */ function registerValidators( ValidatorRegistration[] calldata validatorRegistrations, address owner, ) external payable returns (bytes32 registrationRoot); /** * @notice Gets the registration root for a validator public key hash * @param validatorPubKeyHash Hash of the validator's BLS public key * @return registrationRoot The URC registration root for this validator * @dev Used to map between validator identifiers and URC registration roots */ function getValidatorRegistrationRoot( bytes32 validatorPubKeyHash ) external view returns (bytes32 registrationRoot); /** * @notice Creates a delegation from a validator to a service * @param validatorPubKeyHash Hash of the validator's BLS public key * @param serviceContract Address of the service contract to delegate to * @param serviceData Additional data specific to the service * @param signature Signature proving consent to the delegation * @dev Establishes a persistent delegation until explicitly modified */ function createDelegation( bytes32 validatorPubKeyHash, address serviceContract, bytes calldata serviceData, bytes calldata signature ) external; /** * @notice Revokes a delegation from a validator to a service * @param validatorPubKeyHash Hash of the validator's BLS public key * @param serviceContract Address of the service contract * @dev Terminates an existing delegation relationship */ function revokeDelegation( bytes32 validatorPubKeyHash, address serviceContract ) external; /** * @notice Registers a service that can receive delegations * @param serviceContract Address of the service contract * @param serviceName Name of the service for identification * @param serviceMetadata Additional metadata about the service * @dev Allows new specialized services to be added to the ecosystem */ function registerService( address serviceContract, string calldata serviceName, bytes calldata serviceMetadata ) external; /** * @notice Forwards validator rewards from a service * @param validatorPubKeyHashes Array of validator public key hashes * @param amounts Array of reward amounts corresponding to each validator * @dev Routes rewards from services to validators via URC */ function forwardRewards( bytes32[] calldata validatorPubKeyHashes, uint256[] calldata amounts ) external; } ``` ### 7.4 Restaked Gateway Service (RGS) The RGS manages the network of sequencing gateways and handles gateway selection based on rollup preferences. ```solidity // SPDX-License-Identifier: MIT pragma solidity ^0.8.25; /** * @title IRestakedGatewayService * @notice Manages sequencing gateways and their selection for rollups * @dev Implements the gateway marketplace and selection logic */ interface IRestakedGatewayService { /** * @notice Registers a gateway as a sequencer operator * @param stake Amount of collateral to stake * @param gatewayEndpoint URL endpoint of the gateway service * @return gatewayId Unique identifier for the registered gateway * @dev Allows permissionless registration of new gateways */ function registerGateway( uint256 stake, string calldata gatewayEndpoint ) external returns (bytes32 gatewayId); /** * @notice Stakes additional tokens for a specific rollup * @param rollup Address of the rollup * @param token Address of the rollup's native token * @param amount Amount of tokens to stake * @dev Allows gateways to meet rollup-specific requirements */ function stakeForRollup( address rollup, address token, uint256 amount ) external; /** * @notice Selects a gateway for a rollup at a specific slot * @param rollup Address of the rollup * @param slot Slot number * @return gateway Address of the selected gateway * @dev Implements selection logic based on rollup's sequencing model */ function selectGateway(address rollup, uint64 slot) external returns (address gateway); /** * @notice Distributes rewards to gateways * @param rollup Address of the rollup * @param gateways Array of gateway addresses * @param amounts Array of reward amounts corresponding to each gateway * @dev Distributes sequencing fees to selected gateways */ function distributeGatewayRewards( address rollup, address[] calldata gateways, uint256[] calldata amounts ) external; } ``` ### 7.5 Rollup Registry Contract (RRC) The RRC manages rollup registration, configuration, and batch submissions. ```solidity // SPDX-License-Identifier: MIT pragma solidity ^0.8.25; /** * @title IRollupRegistry * @notice Manages rollup registration and configuration * @dev Central coordination point for rollups within the system */ interface IRollupRegistry { /** * @notice Enum representing sequencer selection models */ enum SequencerModel { FullyBased, // Validator-controlled selection (maximum decentralization) HalfBased, // Rollup constraints with validator selection (hybrid model) FullyCentralized // Rollup-appointed sequencers (traditional model) } /** * @notice Struct containing rollup configuration */ struct RollupConfig { SequencerModel model; // Sequencer selection model bool useDAProcurement; // Whether to use DA Procurement Service for securing future blockspace uint256 collateralRequirement; // Minimum collateral required for sequencers (in wei) uint256 feeSplit; // Percentage of sequencing fees allocated to rollup (in basis points) address tokenRequirement; // Rollup token address that sequencers must stake uint256 tokenAmount; // Amount of rollup token that sequencers must stake to be eligible address bridgeContract; // Address of the rollup's bridge contract uint64 chainId; // Chain ID of the rollup } /** * @notice Struct containing sequencing rights information */ struct SequencingRights { address sequencer; // Address of the sequencer uint64 startSlot; // Start slot for sequencing rights uint64 endSlot; // End slot for sequencing rights bytes32 commitmentRoot; // Root of commitments made by the sequencer } /** * @notice Registers a rollup with the Pre-Settlement Layer * @param config The rollup configuration * @return rollupId Unique identifier for the registered rollup * @dev Establishes rollup identity and initial configuration */ function registerRollup(RollupConfig calldata config) external returns (bytes32 rollupId); /** * @notice Updates a rollup's sequencer selection model * @param model The new sequencer selection model * @dev Changes take effect at the start of the next epoch */ function updateSequencerModel(SequencerModel model) external; /** * @notice Submits a batch from a sequencer to a rollup * @param rollup Address of the rollup * @param batchData Encoded batch data * @param slot Current slot number * @param commitmentRoot Root of commitments made by the sequencer * @param signature Signature from the sequencer * @return batchId Unique identifier for the submitted batch * @dev Verifies authorization and forwards to rollup bridge */ function submitBatch( address rollup, bytes calldata batchData, uint64 slot, bytes32 commitmentRoot, bytes calldata signature ) external returns (bytes32 batchId); /** * @notice Gets the sequencing rights for a rollup at a specific slot * @param rollup Address of the rollup * @param slot Slot number * @return The sequencing rights information * @dev Used to verify authorization for batch submissions */ function getSequencingRightsAtSlot(address rollup, uint64 slot) external view returns (SequencingRights memory); /** * @notice Performs on-chain verification of batch submitter is the current slot designated gateway * @param rollup Address of the rollup * @dev This function will revert if called by an unauthorized gateway * @dev Can be used by rollups that want to enforce on-chain verification */ function verifySubmissionSource(address rollup) external view; /** * @notice Registers a lookahead/verification adapter for a rollup * @param rollup Address of the rollup * @param adapter Address of the adapter contract * @param enforceOnChain Whether to enforce on-chain verification for the sequencer, e.g. updating lookahead on-chain * @dev Configures the gateway verification mechanism for a specific rollup * @dev The adapter is essentially a mechanism for the rollup to deduce the correct sequencer based on its architecture * @dev Each rollup implementation (Taiko, Optimism, etc.) may require a different adapter to integrate with its specific sequencer verification approach */ function registerGatewayAdapter( address rollup, address adapter, bool enforceOnChain ) external; // Todo: add adapter interface that inherits ILookahead } ``` ## 8. Appendix ### Appendix A: Sequencing Models Reference #### A.1 Fully-Based Model **Definition**: A sequencing model that maximizes decentralization by giving validators complete freedom to select sequencers based on their own criteria. **Key Characteristics**: - No rollup-imposed constraints on gateway selection - Selection mechanism fully determined by validator preferences - Typically utilizes auction mechanisms for sequencer selection - Highest degree of credible neutrality among the three models **Typical Use Cases**: - Rollups prioritizing maximal decentralization - Applications requiring strongest censorship resistance - Projects with established validator relationships #### A.2 Half-Based Model **Definition**: A hybrid sequencing model that balances rollup sovereignty with validator control by applying rollup-specific requirements to gateway selection. **Key Characteristics**: - Rollups establish minimum requirements for gateway eligibility - Validators select from the filtered set of compliant gateways - Two-stage selection process: qualification followed by selection - Balanced approach to decentralization and rollup-specific needs **Typical Use Cases**: - Rollups requiring specific security/performance guarantees - Projects with their own token ecosystem - Applications with specialized hardware/software requirements #### A.3 Fully-Centralized Model **Definition**: A sequencing model that prioritizes control and performance by allowing the rollup to directly appoint its sequencer. **Key Characteristics**: - Rollups directly appoint their preferred sequencer(s) - No validator agency in gateway selection - All sequencing requests routed to appointed sequencer - Similar architecture to traditional centralized rollup sequencing **Typical Use Cases**: - Rollups requiring maximum control over transaction ordering - Applications with specialized performance requirements - Projects in initial launch phases B. Fault Attribution ### Appendix B: Fault Attribution Model #### B.1 Introduction to Attribution Models Fault attribution is a critical aspect of any delegated system, determining which party bears responsibility when protocol violations occur. There are two fundamental approaches to fault attribution in delgated systems: **Principal-Based Attribution**: In principal-based attribution models, the delegator (principal) bears ultimate responsibility for actions taken by their delegatee (agent). This model creates vicarious liability where validators would be punished for gateway failures, even when they have no direct control over gateway operations. While this approach simplifies enforcement by always targeting the principal, it can create unfair risk allocation and discourage participation. **Agent-Based Attribution**: In agent-based attribution models, responsibility falls on the party that actually violates the protocol. The LingLong Pre-Settlement Layer implements an [agent-based attribution model](https://github.com/eth-fabric/constraints-specs/issues/19) where penalties target the entity with operational control over the specific failure. This creates a more equitable system by ensuring that the actual offender bears the consequences, rather than imposing blanket liability. #### B.2 Chain of Custody for Constraints The foundation of the LingLong fault attribution model is establishing a verifiable "chain of custody" for constraints. This mechanism creates an auditable trail showing exactly which party is responsible at each stage of the sequencing process. **Key Components**: 1. **Delegation Signatures**: Validators sign delegation messages authorizing gateways to act on their behalf 2. **Constraint Verification**: Relays verify and countersign constraints, confirming receipt of valid constraints 3. **Block Evidence**: Blocks contain cryptographic evidence (in `extra_data`) proving which Relay processed the constraints 4. **Slashing Challenges**: Any observer can submit evidence of violations to initiate the attribution process **Example Flow**: ``` 1. Validator → Gateway: SignedDelegation (authority to post constraints) 2. Gateway → Relay: Constraint(constraintType, payload=slot|relay_id) 3. Relay: Verifies slot & relay_id in payload 4. Relay → Builder: Signed constraints via GET /constraints_stream?slot={slot} 5. Builder: Places ConstraintMessage.signature in block's extra_data ``` This chain of custody allows for precise attribution when violations occur, as each stage of the process includes cryptographic evidence establishing responsibility. #### B.3 Slashing Decision Tree When a violation is detected (such as a missing preconfirmed transaction), the system follows a structured decision path to determine the responsible party: ``` Challenge Submitted ├── Was Slot Missed? │ ├── Yes → Missed Slot by Validator → Apply Liveness Penalty │ └── No → Check Block's extra_data │ ├── No valid message → Validator used non-compliant Relay → Penalize Validator │ └── Valid message → Check Transaction │ ├── Transaction Omitted → Penalize Gateway │ └── No Fault Found ``` The decision tree analysis ensures that penalties target the actual offender rather than imposing blanket liability: > **Note**: The slashing conditions described below are illustrative examples only. As a protocol, LingLong provides flexibility to developers and rollup operators to define their own specific conditions for when slashing should occur and the appropriate penalty amounts. The Pre-Settlement Layer provides the mechanisms for detection and execution of slashing, but the specific policies can be customized to suit each rollup's unique requirements and risk profiles. **Validator Slashing Conditions**: - **Missed slot** (liveness failure): Validator failed to propose a block entirely - **Bypass constraints**: Validator used a non-compliant Relay or self-built a block that ignores gateway-submitted constraints **Gateway Slashing Conditions**: - **Constraint failures**: Gateway failed to include preconfirmed transactions or included invalid transactions - **Forwarding failures**: Gateway incorrectly forwarded constraints to Relays

Syntax	Example	Reference
# Header	Header	基本排版
- Unordered List	Unordered List
1. Ordered List	Ordered List
- [ ] Todo List	Todo List
> Blockquote	Blockquote
Bold font	Bold font
Italics font	Italics font
~~Strikethrough~~	~~Strikethrough~~
19^th^	19^th
H~2~O	H₂O
++Inserted text++	Inserted text
==Marked text==	Marked text
[link text](https:// "title")	Link
![image alt](https:// "title")	Image
`Code`	`Code`	在筆記中貼入程式碼
```javascript var i = 0; ```	`var i = 0;`
:smile:		Emoji list
{%youtube youtube_id %}	Externals
$L^aT_eX$	L^aT_eX
:::info This is a alert area. :::	This is a alert area.