Detailed Instructions

Users submit a signed transaction to the sequencer's designated RPC endpoint, such as https://sequencer.chainscore.xyz. The sequencer performs initial validation on the transaction's signature, nonce, and gas parameters to ensure it's well-formed and originates from an account with sufficient funds for the gas fee. This step prevents obviously invalid transactions from entering the mempool and consuming resources.

• Sub-step 1: Construct the transaction payload with the correct chainId (e.g., 42161 for Arbitrum One) and target contract address.
• Sub-step 2: Sign the transaction using a private key with a tool like ethers.js (wallet.signTransaction(tx)).
• Sub-step 3: Send the raw transaction via HTTP POST to the sequencer's RPC using eth_sendRawTransaction.

javascriptCopy
// Example using ethers.js v6
const tx = {
  to: '0x...',
  data: '0x...',
  gasLimit: 1000000
};
const signedTx = await wallet.signTransaction(tx);
const txHash = await provider.send('eth_sendRawTransaction', [signedTx]);

Tip: The sequencer's validation is local and does not guarantee inclusion; it only checks for basic correctness against its current view of the state.

Detailed Instructions

After validation, the sequencer places the transaction into its local mempool. It then applies a deterministic ordering rule, typically First-Come-First-Served (FCFS) based on its receipt time, to establish the canonical sequence. This order is critical as it defines the final state transition. Periodically, or when a size/time threshold is met, the sequencer creates a batch—a compressed, serialized list of transactions.

• Sub-step 1: Apply ordering logic to all pending transactions in the mempool, respecting nonce order for each sender.
• Sub-step 2: Compress transaction data using algorithms like brotli or zstd to reduce calldata costs.
• Sub-step 3: Construct the batch data structure, which includes a header with metadata like the previous batch hash and a Merkle root of the transactions.

solidityCopy
// Conceptual struct for a batch header
struct BatchHeader {
  bytes32 prevBatchHash;
  bytes32 transactionsRoot;
  uint64 timestamp;
  uint64 batchNumber;
}

Tip: The sequencer's power to order transactions is a centralization vector; some networks use decentralized sequencing or fair ordering protocols to mitigate this.

Detailed Instructions

The sequencer acts as the sole entity permitted to submit batches to the L1 inbox contract (e.g., Inbox.sol on Ethereum). It calls a function like appendSequencerBatch() , posting the raw batch data as calldata. This action anchors the sequence of L2 transactions to the security of Ethereum. The cost of this transaction, paid in L1 gas (ETH), is a major operational expense for the sequencer, often subsidized by L2 transaction fees.

• Sub-step 1: Calculate the L1 gas estimate for the batch submission transaction, which scales with batch size.
• Sub-step 2: Send the L1 transaction from the sequencer's funded Ethereum account to the canonical inbox address.
• Sub-step 3: Monitor for inclusion and confirmations on the L1 chain (typically 1-2 blocks for soft confirmation).

solidityCopy
// Interface for a typical L1 Inbox contract
interface IInbox {
  function appendSequencerBatch(bytes calldata _data) external;
}

Tip: The time between batch submissions is a key trade-off: more frequent submissions reduce latency but increase L1 gas costs due to fixed overhead per transaction.

Detailed Instructions

After the batch is accepted on L1, a state root—a cryptographic commitment to the entire L2 state—is computed. In an Optimistic Rollup, this root is posted optimistically by the sequencer (or a separate proposer) and enters a challenge period (e.g., 7 days). During this time, any watcher can submit a fraud proof to dispute an invalid state transition. In a ZK-Rollup, a validity proof (ZK-SNARK/STARK) is generated and verified on-chain instantly, proving the state transition's correctness without a challenge period.

• Sub-step 1: Execute the batch locally to compute the post-state root.
• Sub-step 2 (Optimistic): Post the state root to the L1 contract, initiating the challenge window.
• Sub-step 2 (ZK): Generate a succinct proof off-chain and submit it with the new state root for on-chain verification.
• Sub-step 3: Finalize the state after the challenge period expires or the validity proof is verified.

Tip: For users, the difference between soft confirmation (from the sequencer) and hard finality (after L1 dispute resolution) is crucial for high-value transactions.

Detailed Instructions

Withdrawing assets from L2 to L1 is a two-step process that relies on the finalized state. First, a user initiates a withdrawal transaction on L2, which burns the tokens or locks them in a bridge contract. This action is recorded in a finalized state root. After the challenge period (for optimistic rollups) or immediately after proof verification (for ZK-rollups), the user must prove the inclusion of their withdrawal in the finalized state on L1 to claim their funds.

• Sub-step 1: Initiate withdrawal on L2 by calling the bridge contract's initiateWithdrawal function.
• Sub-step 2: Wait for state finality on L1, which can take from minutes (ZK) to over a week (Optimistic).
• Sub-step 3: Prove inclusion on L1 by providing a Merkle proof against the finalized state root to the L1 bridge contract's finalizeWithdrawal function.

solidityCopy
// Simplified L1 withdrawal finalization interface
interface IL1Bridge {
  function finalizeWithdrawal(
    uint256 batchNumber,
    bytes32 stateRoot,
    bytes32 withdrawalLeaf,
    bytes32[] calldata proof
  ) external;
}

Tip: Many L2s offer canonical "fast withdrawal" services via liquidity providers, which front the user funds for a fee, abstracting away the finalization delay.