# Linglong Pre-Settlement Layer PRD
## 1. Introduction
This PRD outlines the technical requirements and smart contract interfaces for the Linglong Pre-Settlement Layer. This doc purports to prpose the deisng and get initial buy-ins from partners. The document provides comprehensive information about the architecture, components, interfaces, and user flows necessary to build and deploy the Pre-Settlement Layer.
## 2. Product Overview
### Product Description
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 core consensus. Through its modular design, Linglong orchestrates sequencing service delegation, data availability management, and auxiliary functions, thereby creating a streamlined environment for based rollups.
## 3. Requirements
### Validator
- A validator should be able to delegate sequencing duties to specialized gateways without transferring operational control
- *Example: A validator delegates sequencing rights to Espresso Sequencer while retaining the ability to revoke this delegation if the sequencer underperforms or acts maliciously.*
- A validator should be able to sequence for multiple rollups simultaneously, while ensuring each rollup has exactly one designated sequencer
- *Example: A validator in slot 42 can sequence for both Puffer and Taiko, but for each of these rollups, there is only one sequencer responsible for that specific rollup's transactions during the validator's slot.*
- A validator should be protected from delegatee failures affecting their security or stake position
- *Example: If a gateway renegates on a preconfirmed user tx, the validator's ETH stake remains secure and isn't subject to slashing for the gateway's mistakes.*
- A validator should be able to maintain autonomy through self-delegation when preferred
- *Example: A validator can choose to sequence certain rollups directly rather than delegating, perhaps for rollups they operate themselves or have special interest in.*
- A validator should be required to delegate only once, with persistence until explicitly modified
- *Example: After initial delegation setup, the validator continues earning yield across multiple epochs without needing to renew delegation permissions each time a new rollup joins the network.*
- A validator should have full liberty to choose which rollups receive their sequencing capacity
- *Example: A validator might opt to sequence rollups that meet specific operational criteria, while forgoing those that, despite offering higher yields, diverge from their risk management and strategic values.*
- A validator should be shielded from regulatory exposure through clear separation of legal responsibilities
- *Example: If a gateway sequences transactions later deemed non-compliant with certain regulations, the validator isn't held legally responsible as they had no control over transaction selection or censorship decisions.*
### Rollup
- A rollup should be able to configure its sequencing model according to its specific needs for security, performance, and control
- *Example: Rise Finance can choose a half-based model to balance decentralization with performance requirements, while Taiko might opt for a fully-based model to maximize decentralization.*
- A rollup should be able to define eligibility criteria for gateways that sequence its transactions
- *Example: A rollup requires gateways to stake 100,000 of its native tokens and maintain a 99.9% uptime over the previous month to be eligible for selection.*
- A rollup should be able to seamlessly transition between sequencing models with minimal disruption
- *Example: A rollup transitions from a fully-centralized model during its initial launch phase to a half-based model as it matures, with the change taking effect at the start of the next epoch.*
- A rollup should have access to credibly committed future blockspace for data availability
- *Example: A rollup secures guaranteed blobspace allocation for the next week through the DA Procurement Service, ensuring predictable costs and availability.*
- A rollup should be able to express economic preferences through configurable fee models
- *Example: A rollup sets a 20% fee split with gateways and implements a priority fee mechanism that allocates 10% to validators, 70% to gateways, and 20% to the protocol.*
- A rollup should be able to implement custom validation rules for transactions while maintaining compatibility with the Pre-Settlement Layer
- *Example: A privacy-focused rollup implements zero-knowledge verification of transactions while still leveraging the standard batch submission process of the Pre-Settlement Layer.*
- A rollup should receive verifiable proofs of sequencer commitments that can be used for dispute resolution
- *Example: If a gateway fails to include a specific transaction, the rollup can present cryptographic proof of the commitment to initiate slashing through the Universal Registry Contract.*
### Restaked Gateways
- The RGS should establish a restaked network of sequencing gateways who receive delegation from validators
- *Example: The RGS creates a marketplace where Espresso, Radius, and independent gateways can compete to sequence transactions for multiple rollups.*
- A gateway should be able to permissionlessly join the RGS as an operator by meeting predefined criteria
- *Example: A new sequencing provider can join the network by staking the required collateral, without needing approval from a central authority.*
- The RGS should support various gateway selection scenarios based on rollup preferences
- *Example: Taiko can operate in a fully-centralized mode with appointed gateways, while Rise uses a semi-based approach requiring gateways to stake Rise's token.*
- Fault attribution within the RGS should be clearly defined across different gateway sets
- *Example: A gateway sequencing rollup A should not be penalized for faults committed by another gateway that sequences rollup B, ensuring fair and targeted accountability.*
## 4. 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<br>Contract")
Slasher("Slasher<br>Contract")
RVS("Restaked Validator<br>Service")
RGS("Restaked Gateway<br>Service")
RRC("Rollup Registry<br>Contract")
%% Simple contract relationship labels
URC <-->|"Coordinates<br>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 the Restaked Validator Service (RVS). 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" and Symbiotic terms "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 clean 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. **Specialized Gateways Compete**: Gateways like the [L2 preconf gateway](https://ethresear.ch/t/becoming-based-a-path-towards-decentralised-sequencing/21733) by Gattaca, and shared sequencers like [Espresso](https://docs.espressosys.com/network) and [Radius](https://docs.theradius.xyz/), can compete to provide sequencing services.
2. **Permissionless Participation**: Any new gateway can join the network by meeting the rollup's sequencing requirements.
3. **Flexible Selection Mechanisms**: The service implements modular gateway selection that balances validator preferences with rollup requirements.
4. **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)
The Universal Registry Contract (URC) is a governance-free and immutable contract that serves as the foundation for proposer commitments in the Linglong ecosystem. Located at [https://github.com/eth-fabric/urc](https://github.com/eth-fabric/urc), 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. This registry is crucial for the operation of the RVS, as it establishes the foundation of trust upon which delegation and other services are built.
### 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 and the execution of appropriate penalties, coordinating with the URC to manage the slashing of validators and operators. It inherits the base slashing functionality for commitment violations from the URC Slasher, and extends it with a more sophisticated challenge-response system that enables fair adjudication of complex protocol violations.
The Slasher implements a fault attribution model that ensures penalties target the responsible parties while protecting innocent participants from undue penalties. It fulfills several critical functions:
1. **Violation Detection and Verification**: Processes submission of protocol violations, including missed pre-confirmations, invalid commitments, and other rule breaches. The contract verifies these submissions through cryptographic proofs before initiating any slashing action.
2. **Responsible Party Identification**: Implements attribution logic to determine which actor in the system (validator, gateway, or other stakeholders) bears responsibility for a detected violation. This ensures that penalties are directed at the actual offender rather than other participants in the system.
3. **Dual Slashing Mechanisms**: Supports two distinct slashing types based on violation severity and complexity:
- **Non-Interactive Slashing**: For objectively verifiable violations with clear proofs, this mechanism executes immediately upon verification of the proof without requiring a dispute period. Examples include cryptographically verifiable missed preconfirmations or double-signing events.
- **Interactive Slashing**: For violations requiring subjective assessment or additional context, this mechanism implements a challenge-response protocol with a veto period. The accused party can provide counter-evidence during this period, and the community can participate in the adjudication process.
The Slasher Contract's design emphasizes attribution in identification and flexibility in enforcement, with multiple safeguards against false accusations or erroneous slashing. For interactive slashing scenarios, the contract implements a time-locked execution process that allows for community oversight and intervention if necessary.
### 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 the three sequencing models (Fully-Based, Half-Based, and Fully-Centralized) 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.
5. **Model Transition Coordination**: Manages sequencing model transitions on an epoch basis, ensuring that changes to a rollup's sequencing model are implemented in a controlled manner that preserves system stability and security.
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.
## 5. 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
RGS->>RGS: Register gateway stake
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
## 6. 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
### 6.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).
### 6.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;
/// Evidence hash for integrity verification
bytes32 evidenceHash;
/// 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);
}
```
### 6.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;
}
```
### 6.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;
}
```
### 6.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
}
```
## 7. 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
### 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:
**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
Sign in with Wallet
Connect another wallet