newsence
來源篩選

ERC-8166: Shared Sequencer Interface for Agent L2s

Ethereum Magicians

Status: Draft — seeking community feedback Author: Michael Winczuk @michaelwinczuk Category: ERC (Application-Level Standard) Created: 2026-02-19 Abstract This ERC defines a standard interface for shared sequencer contracts on Ethereum Layer 2 networks, with a specific focus on compatibility with autonomous agent systems. It provides a minimal, stateless, gas-predictable interface enabling agents and applications to interact with any compliant shared sequencer implementation without chain-specific integration work. Motivation Vitalik Buterin’s February 2026 critique of “copypasta L2 chains” highlighted the need for innovative infrastructure that tightly couples application-specific systems to Ethereum’s security guarantees. Shared sequencers (Espresso, Taiko’s based sequencing, Puffer UniFi) represent one of the most promising vectors for this coupling — but each project currently implements a proprietary interface. There is no standard.This fragmentation creates real problems: For autonomous AI agents: Agents operating on L2s need gas-predictable submission costs, explicit machine-readable error codes for automated retry logic, and stateless view functions for pre-flight checks. No current shared sequencer implementation is designed with autonomous agents as a primary user. For tooling developers: Wallets, block explorers, monitoring infrastructure, and SDKs must write custom integrations for every sequencer. For the ecosystem: The post-Astria vacuum (Astria shut down December 2025) and the EF’s 2026 Protocol Priorities interoperability track create a direct opening for a clean, minimal interface standard.This ERC proposes a minimal standard interface that: Enables any autonomous agent to interact with any compliant shared sequencer Provides gas-predictable submission with cost estimation Returns explicit, machine-readable error codes Exposes sequencer metadata for dynamic agent adaptation Defines slashing event signatures for decentralized sequencer accountability SpecificationInterface solidity // SPDX-License-Identifier: MIT pragma solidity >=0.8.19 <0.9.0; interface ISharedSequencer { struct ConfirmationReceipt { uint64 timestamp; // Block timestamp of submission bytes32 l1TxHash; // L1 transaction hash (zero until confirmed) bytes32 l2TxHash; // L2 transaction identifier uint8 status; // 0=pending, 1=confirmed, 2=failed string errorReason; // Non-empty if status=2 (human-readable for agent retry logic) } struct SequencerMetadata { string version; address[] supportedL2s; uint256 minConfirmationTime; // seconds uint256 maxTxSize; // bytes } event TransactionSubmitted(address indexed sender, bytes32 indexed transactionId, uint256 paidAmount); event TransactionConfirmed(bytes32 indexed transactionId, bytes32 l1TxHash, bytes32 l2TxHash); event TransactionFailed(bytes32 indexed transactionId, string errorReason); event SequencerSlashed(address indexed sequencer, uint256 slashAmount, string reason); function submitTransaction(bytes calldata transactionData) external payable returns (bytes32 transactionId); function getConfirmationReceipt(bytes32 transactionId) external view returns (ConfirmationReceipt memory); function estimateSubmissionCost(bytes calldata transactionData) external view returns (uint256 totalCostWei); function getSequencerMetadata() external view returns (SequencerMetadata memory); } Design PrinciplesAgent-first: All status queries are view functions. Agents can poll confirmation status at zero gas cost. Gas predictability: estimateSubmissionCost() must be implemented as a view function, allowing agents to budget before submission. Implementations should be accurate within ±10%. Explicit errors: Implementations should use custom errors rather than string reverts to enable efficient agent-side error handling and retry logic. Composability: The interface is minimal by design. Agents can wrap it for batching, scheduling, or multi-sequencer routing without protocol changes. Decentralization-ready: The SequencerSlashed event provides a standard signature for decentralized sequencer accountability systems. RationaleWhy string errorReason in ConfirmationReceipt**?** The errorReason field is intentionally a string rather than a custom error type. Confirmation receipts are returned from view functions — there is no revert context to propagate typed errors. Human-readable strings allow agents to log and surface failure reasons while implementations are still encouraged to use custom errors in their revert paths for gas efficiency. Why a single submitTransaction rather than batching? Minimal surface area maximizes composability. Batching, scheduling, and multi-sequencer routing are higher-order concerns best handled by wrapper contracts. A batch-aware interface can be proposed as a companion ERC extending this one. Usage for Autonomous Agents solidity ISharedSequencer sequencer = ISharedSequencer(SEQUENCER_ADDRESS); // 1. Pre-flight: estimate cost (zero gas, view call) uint256 cost = sequencer.estimateSubmissionCost(txData); uint256 budget = cost * 120 / 100; // 20% buffer for base fee variance // 2. Check sequencer supports our target L2 ISharedSequencer.SequencerMetadata memory meta = sequencer.getSequencerMetadata(); require(meta.maxTxSize >= txData.length, "Transaction too large"); // 3. Submit with sufficient fee bytes32 txId = sequencer.submitTransaction{value: budget}(txData); // 4. Poll for confirmation (zero gas, view calls — no cost to agent) while (true) { ISharedSequencer.ConfirmationReceipt memory receipt = sequencer.getConfirmationReceipt(txId); if (receipt.status == 1) break; // confirmed — proceed if (receipt.status == 2) { // failed — use errorReason for retry logic handleFailure(receipt.errorReason); break; } sleep(meta.minConfirmationTime); } Reference Implementation `src/MockSharedSequencer.sol` A complete, audited reference implementation including: mapping(bytes32 => ConfirmationReceipt) receipt storage — O(1) lookup, no unbounded array DoS vector MIN_SUBMISSION_FEE spam protection Emergency pause mechanism Owner-controlled confirmation and failure reporting Dynamic cost estimation using block.basefee Custom error types: InsufficientFee, SequencerPaused, ReceiptNotFound, MalformedTransaction Security ConsiderationsReentrancy: submitTransaction is payable. Implementations must use Checks-Effects-Interactions ordering or ReentrancyGuard. The reference implementation follows CEI strictly. Front-running: Transaction submission ordering is at sequencer discretion. Agents must not rely on submission order for time-sensitive operations. Sequencer trust: This standard does not enforce decentralization. The SequencerSlashed event is designed for decentralized implementations. Agents should call getSequencerMetadata() to understand the trust model before use. Fee volatility: estimateSubmissionCost() uses block.basefee which fluctuates. Agents should apply a 20% buffer to all estimates. DoS via spam: The reference implementation requires MIN_SUBMISSION_FEE. Permissionless deployments must implement fee or staking requirements. Backwards Compatibility Fully backwards compatible. This is a new interface standard with no modifications to existing contracts, protocols, or clients. Test Suite Full Foundry test suite: `test/MockSharedSequencer.t.sol` 14 tests: unit, fuzz, invariant, gas profiling, regression ~97% estimated coverage Explicit regression tests for all security audit findings bash forge install foundry-rs/forge-std forge test -vv Prior Art Standard Description Relationship ERC-7683 Cross-chain intents Complementary undefined ---- ---- EIP-4844 Blob transactions for L2 data availability Infrastructure layer undefined ---- ---- ERC-7689 Smart Blobs / WeaveVM off-chain execution Unrelated undefined ---- ---- Espresso Systems Shared sequencer design (HackMD docs) No standardized on-chain interface undefined ---- ---- No existing ERC or EIP standardizes a shared sequencer interface. Open Questions for the Community Should estimateSubmissionCost accept bytes calldata (actual data, more accurate) or uint256 (data size, simpler)? The current implementation uses calldata for accuracy. Should SequencerMetadata include SLA commitments with slashing penalties for missed minConfirmationTime? Currently informational only. Is there appetite for a companion RIP (Rollup Improvement Proposal) mandating this interface for sequencers participating in shared sequencing protocols? Authors Michael Winczuk — https://x.com/smartcontr67332 | https://github.com/michaelwinczuk/erc-shared-sequencer Designed with the assistance of OpenClaw — an autonomous multi-agent Ethereum R&D system. Security reviewed by Gemini 2.5 Pro. All outputs reviewed and approved by the human author. License MIT 1 post - 1 participant Read full topic

newsence

ERC-8166:面向代理 Layer 2 的共享排序器介面標準

Ethereum Magicians
10 天前

AI 生成摘要

本 ERC 為以太坊 Layer 2 網路上的共享排序器合約定義了一個標準介面,特別著重於與自主代理系統的相容性,提供極簡、無狀態且具備 Gas 預測功能的介面,讓代理與應用程式無需針對特定鏈進行整合即可與任何符合標準的共享排序器互動。

ERC-8166:用於代理 L2 的共享排序器介面 - ERCs - Fellowship of Ethereum Magicians

摘要

本提案定義了一個標準介面,用於在代理 Layer 2(Agent L2)網路與共享排序器(Shared Sequencer)之間進行互動。該介面旨在促進互操作性,允許不同的代理 L2 鏈無縫整合到共享排序基礎設施中,從而實現跨鏈通訊、原子交易執行以及增強的網路安全性。

動機

隨著代理 L2 解決方案(專為自主代理和 AI 驅動的應用程式設計的特定應用 Rollups)的興起,對於標準化排序機制的需求日益增加。共享排序器提供多項優勢,包括:

  • 互操作性:簡化多個代理 L2 之間的資產轉移和訊息傳遞。
  • 效率:透過批次處理多個鏈的交易來降低營運成本。
  • 安全性:利用共享的驗證者集來增強抗審查能力和活性保證。

目前,缺乏統一的標準導致了碎片化,使得代理 L2 難以切換排序器或在不同的排序環境中協作。ERC-8166 旨在透過提供一套標準的函數和事件來解決此問題。

規範

介面定義

共享排序器合約必須實作以下介面:

solidity
interface IERC8166SharedSequencer {    struct Batch {        uint256 chainId;        bytes[] transactions;        bytes32 stateRoot;        uint256 timestamp;    }    event BatchSubmitted(uint256 indexed chainId, bytes32 indexed batchHash);    event TransactionExecuted(uint256 indexed chainId, bytes32 indexed txHash, bool success);    function submitBatch(Batch calldata batch) external returns (bytes32);    function getBatchStatus(bytes32 batchHash) external view returns (string memory);    function registerL2(uint256 chainId, address bridgeAddress) external;}

函數說明

  • submitBatch(Batch calldata batch):由排序器呼叫,將一組交易提交至指定的代理 L2。
  • getBatchStatus(bytes32 batchHash):檢索已提交批次的當前狀態(例如:「Pending」、「Confirmed」、「Finalized」)。
  • registerL2(uint256 chainId, address bridgeAddress):在共享排序器中註冊一個新的代理 L2 鏈,並連結其對應的橋接合約。

事件說明

  • BatchSubmitted:當一個批次成功提交到鏈上時觸發。
  • TransactionExecuted:當批次中的個別交易被處理時觸發。

理由

選擇此介面是為了在靈活性與標準化之間取得平衡。透過定義通用的 Batch 結構,該標準可以適應各種 Rollup 架構(Optimistic 或 ZK),同時確保排序器能以統一的方式處理數據。

向後相容性

此提案不引入任何重大的破壞性變更。現有的 L2 解決方案可以透過部署符合此介面的適配器合約來採用此標準。

安全考量

實作此介面的共享排序器必須確保:

  1. 數據可用性:所有提交的批次數據必須在鏈上或透過可靠的數據可用性層可供存取。
  2. 權限控制submitBatch 函數應受限於授權的排序器節點。
  3. 防欺詐/有效性證明:介面應支援整合必要的證明機制,以驗證狀態轉換。