# Base Chain Specification

> Base Chain protocol specification, upgrades, and reference documentation.

## Docs

- [V1: Execution Engine](/upgrades/v1/exec-engine): [EIP-7825](https://eips.ethereum.org/EIPS/eip-7825) introduces a protocol-level maximum gas limit
of 16,777,216 (2^24) per transaction. Transactions exceeding this cap are rejected during validation.
- [V1](/upgrades/v1/overview): Add Fusaka Support
- [Pectra Blob Schedule Derivation](/upgrades/pectra-blob-schedule/derivation): If this hardfork is enabled (i.e. if there is a non nil hardfork activation timestamp set), the following rules apply:
- [Pectra Blob Schedule (Sepolia)](/upgrades/pectra-blob-schedule/overview): The Pectra Blob Schedule hardfork is an optional hardfork which delays the adoption of the
Prague blob base fee update fraction until the specified time. Until that time, the Cancun
update fraction from the previous fork is retained.
- [Derivation](/upgrades/jovian/derivation): The first block with a timestamp at or after the Jovian activation time is considered the *Jovian activation block*.
- [Jovian: Execution Engine](/upgrades/jovian/exec-engine): Jovian introduces a
[configurable minimum base fee](https://github.com/ethereum-optimism/design-docs/blob/main/protocol/minimum-base-fee.md)
to reduce the duration of priority-fee auctions on Base.
- [L1 Block Attributes](/upgrades/jovian/l1-attributes): The L1 block attributes transaction is updated to include the DA footprint gas scalar.
- [Jovian](/upgrades/jovian/overview): [Minimum Base Fee](/upgrades/jovian/exec-engine#minimum-base-fee)
- [Jovian: System Config](/upgrades/jovian/system-config): Jovian adds a configuration value to `SystemConfig` to control the minimum base fee used by the EIP-1559 fee market
on Base. The value is a minimum base fee in wei.
- [Isthmus L2 Chain Derivation Changes](/upgrades/isthmus/derivation): The Isthmus hardfork activation block contains the following transactions, in this order:
- [Network upgrade automation transactions](/upgrades/isthmus/derivation): The Isthmus hardfork activation block contains the following transactions, in this order:
- [Span Batch Updates](/upgrades/isthmus/derivation): L1 Attributes Transaction
- [L2 Execution Engine](/upgrades/isthmus/exec-engine): The storage root of the `L2ToL1MessagePasser` is included in the block header's
`withdrawalRoot` field.
- [L1 Block Attributes](/upgrades/isthmus/l1-attributes): The L1 block attributes transaction is updated to include the operator fee parameters.
- [Isthmus](/upgrades/isthmus/overview): [Pectra](https://eips.ethereum.org/EIPS/eip-7600) (Execution Layer):
- [Predeploys](/upgrades/isthmus/predeploys): This function is meant to be called once on the activation block of the Isthmus network upgrade.
It MUST only be callable by the `DEPOSITOR_ACCOUNT` once. When it is called, it MUST call
call each getter for the network specific config and set the returndata into storage.
- [Isthmus: System Config](/upgrades/isthmus/system-config): Isthmus adds configuration variables `operatorFeeScalar` (`uint32`)
and `operatorFeeConstant` (`uint64`) to `SystemConfig` to control the operator fee parameters.
- [Holocene L2 Chain Derivation Changes](/upgrades/holocene/derivation): The Holocene hardfork introduces several changes to block derivation rules that render the
derivation pipeline mostly stricter and simpler, improve worst-case scenarios for Fault Proofs and
Interop. The changes are:
- [Holocene Derivation](/upgrades/holocene/derivation): The Holocene hardfork introduces several changes to block derivation rules that render the
derivation pipeline mostly stricter and simpler, improve worst-case scenarios for Fault Proofs and
Interop. The changes are:
- [Rationale](/upgrades/holocene/derivation): *Strict Batch Ordering* required batches within and across channels to be strictly ordered.
- [Security and Implementation Considerations](/upgrades/holocene/derivation): *Strict Batch Ordering* required batches within and across channels to be strictly ordered.
- [L2 Execution Engine](/upgrades/holocene/exec-engine): The EIP-1559 parameters are encoded in the block header's `extraData` field and can be configured dynamically through
the `SystemConfig`.
- [Holocene](/upgrades/holocene/overview): [Dynamic EIP-1559 Parameters](/upgrades/holocene/exec-engine#dynamic-eip-1559-parameters)
- [System Config](/upgrades/holocene/system-config): The `SystemConfig` is updated to allow for dynamic EIP-1559 parameters.
- [Granite L2 Chain Derivation Changes](/upgrades/granite/derivation): The following table gives an overview of the changes in parameters.
- [L2 Execution Engine](/upgrades/granite/exec-engine): The `bn256Pairing` precompile execution has additional validation on its input.
The precompile reverts if its input is larger than `112687` bytes.
This is the input size that consumes approximately 20 M gas given the latest `bn256Pairing` gas schedule on L2.
- [Granite](/upgrades/granite/overview): [Limit `bn256Pairing` precompile input size](/upgrades/granite/exec-engine#bn256pairing-precompile-input-restriction)
- [Fjord L2 Chain Derivation Changes](/upgrades/fjord/derivation): The following table gives an overview of the changes in parameters.
- [Protocol Parameter Changes](/upgrades/fjord/derivation): The following table gives an overview of the changes in parameters.
- [Brotli Channel Compression](/upgrades/fjord/derivation): Fjord introduces a new versioned channel encoding format to support alternate compression
algorithms, with the [legacy channel format][legacy-channel-format] remaining supported. The
versioned format is as follows:
- [Network upgrade automation transactions](/upgrades/fjord/derivation): The Fjord hardfork activation block contains the following transactions, in this order:
- [L2 Execution Engine](/upgrades/fjord/exec-engine): Fjord updates the L1 cost calculation function to use a FastLZ-based compression estimator.
The L1 cost is computed as:
- [Fjord](/upgrades/fjord/overview): [RIP-7212: Precompile for secp256r1 Curve Support](/protocol/execution/evm/precompiles#P256VERIFY)
- [Predeploys](/upgrades/fjord/predeploys): Following the Fjord upgrade, three additional values used for L1 fee computation are:
- [Derivation](/upgrades/ecotone/derivation): With the Ecotone upgrade the retrieval stage is extended to support an additional DA source:
[EIP-4844] blobs. After the Ecotone upgrade we modify the iteration over batcher transactions to
treat transactions of transaction-type == `0x03` (`BLOB_TX_TYPE`) differently. If the batcher
transaction is a blob transaction, then its calldata MUST be ignored should it be present. Instead:
- [Ecotone L1 Attributes](/upgrades/ecotone/l1-attributes): On the Ecotone activation block, and if Ecotone is not activated at Genesis,
the L1 Attributes Transaction includes a call to `setL1BlockValues()`
because the L1 Attributes transaction precedes the [Ecotone Upgrade Transactions][ecotone-upgrade-txs],
meaning that `setL1BlockValuesEcotone` is not guaranteed to exist yet.
- [Ecotone](/upgrades/ecotone/overview): The Ecotone upgrade contains the Dencun upgrade from L1, and adopts EIP-4844 blobs for data-availability.
- [Delta](/upgrades/delta/overview): The Delta upgrade uses a *L2 block-timestamp* activation-rule, and is specified only in the rollup-node (`delta_time`).
- [Span-batches](/upgrades/delta/span-batches): Span-batch is a new batching spec that reduces overhead,
introduced in the [Delta](overview.md) network upgrade.
- [Canyon](/upgrades/canyon/overview): The Canyon upgrade contains the Shapella upgrade from L1 and some minor protocol fixes.
The Canyon upgrade uses a *L2 block-timestamp* activation-rule, and is specified in both the
rollup-node (`canyon_time`) and execution engine (`config.canyonTime`). Shanghai time in the
execution engine should be set to the same time as the Canyon time.
- [Configuration](/reference/configurability): There are four categories of Base configuration:
- [Glossary](/reference/glossary): Refers the Ethereum blockchain, used in contrast to [layer 2][L2], which refers to Base.
- [Batcher](/protocol/batcher): The batcher, also referred to as the batch submitter, is the entity responsible for posting L2 sequencer data to L1, making it available to the derivation pipeline operated by verifiers. The format of batcher transactions — channels, frames, and batches within them — is defined in the [derivation spec]: the data is constructed from L2 blocks in the reverse order from which it is derived back into L2 blocks. Only data that conforms to those rules will be accepted as valid from the verifier's perspective.
- [Overview](/protocol/overview): Base is a rollup built on Ethereum. L2 transaction data is posted to Ethereum for data availability,
and proofs allow anyone to challenge invalid state transitions. This page gives a high-level tour of the
protocol components and the core user flows.
- [Multithreaded Cannon Fault Proof Virtual Machine](/protocol/fault-proof/cannon-fault-proof-vm): This is a description of the second iteration of the Cannon Fault Proof Virtual Machine (FPVM).
When necessary to distinguish this version from the initial implementation,
it can be referred to as Multithreaded Cannon (MTCannon). Similarly,
the original Cannon implementation can be referred to as Singlethreaded Cannon (STCannon) where necessary for clarity.
- [Fault Proof](/protocol/fault-proof): A fault proof, also known as fraud proof or interactive game, consists of 3 components:
- [Proposer](/protocol/fault-proof/proposer): After processing one or more blocks the outputs will need to be synchronized with the settlement layer (L1)
for trustless execution of L2-to-L1 messaging, such as withdrawals.
These output proposals act as the bridge's view into the L2 state.
Actors called "Proposers" submit the output roots to the settlement layer (L1) and can be contested with a proof,
with a bond at stake if the proof is wrong. The [op-proposer][op-proposer] in one such implementation of a proposer.
- [AnchorStateRegistry](/protocol/fault-proof/stage-one/anchor-state-registry): The `AnchorStateRegistry` was designed as a registry where `DisputeGame` contracts could store and
register their results so that these results could be used as the starting states for new
`DisputeGame` instances. These starting states, called "anchor states", allow new `DisputeGame`
contracts to use a newer starting state to bound the size of the execution trace for any given
game.
- [Bond Incentives](/protocol/fault-proof/stage-one/bond-incentives): Bonds is an add-on to the core [Fault Dispute Game](fault-dispute-game.md). The core game mechanics are
designed to ensure honesty as the best response to winning subgames. By introducing financial incentives,
Bonds makes it worthwhile for honest challengers to participate.
Without the bond reward incentive, the FDG will be too costly for honest players to participate in given the
cost of verifying and making claims.
- [Bridge Integration](/protocol/fault-proof/stage-one/bridge-integration): With fault proofs, the withdrawal path changes such that withdrawals submitted to the `OptimismPortal` are proven
against [output proposals][g-l2-proposal] submitted as a [`FaultDisputeGame`][fdg] prior to being finalized. Output
proposals are now finalized whenever a dispute game resolves in their favor.
- [Dispute Game Interface](/protocol/fault-proof/stage-one/dispute-game-interface): A dispute game is played between multiple parties when contesting the truthiness
of a claim. In the context of an optimistic rollup, claims are made about the
state of the layer two network to enable withdrawals to the layer one. A proposer
makes a claim about the layer two state such that they can withdraw and a
challenger can dispute the validity of the claim. The security of the layer two
comes from the ability of fraudulent withdrawals being able to be disputed.
- [Fault Dispute Game](/protocol/fault-proof/stage-one/fault-dispute-game): The Fault Dispute Game (FDG) is a specific type of [dispute game](dispute-game-interface.md) that verifies the
validity of a root claim by iteratively bisecting over [output roots][g-output-root] and execution traces of single
block state transitions down to a single instruction step. It relies on a Virtual Machine (VM) to falsify invalid
claims made at a single instruction step.
- [Honest Challenger (Fault Dispute Game)](/protocol/fault-proof/stage-one/honest-challenger-fdg): The honest challenger is an agent interacting in the [Fault Dispute Game](fault-dispute-game.md)
that supports honest claims and disputes false claims.
An honest challenger strives to ensure a correct, truthful, game resolution.
The honest challenger is also *rational* as any deviation from its behavior will result in
negative outcomes.
This document specifies the expected behavior of an honest challenger.
- [Stage One Decentralization](/protocol/fault-proof/stage-one): This section of the specification contains the system design for stage one decentralization, with a fault-proof system
for [output proposals][g-l2-proposal] and the integration with the `OptimismPortal` contract, which is the arbiter of
withdrawals on L1.
- [OptimismPortal](/protocol/fault-proof/stage-one/optimism-portal): The `OptimismPortal` contract is the primary interface for deposits and withdrawals between the L1
and L2 chains within Base. The `OptimismPortal` contract allows users to create
"deposit transactions" on the L1 chain that are automatically executed on the L2 chain within a
bounded amount of time. Additionally, the `OptimismPortal` contract allows users to execute
withdrawal transactions by proving that such a withdrawal was initiated on the L2 chain. The
`OptimismPortal` verifies the correctness of these withdrawal transactions against Output Roots
that have been declared valid by the L1 Fault Proof system.
- [L2 Execution Engine](/protocol/execution): This document outlines the modifications, configuration and usage of a L1 execution engine for L2.
- [Precompiles](/protocol/execution/evm/precompiles): [Precompiled contracts](../../../reference/glossary.md#precompiled-contract-precompile) exist on Base at
predefined addresses. They are similar to predeploys but are implemented as native code in the EVM as opposed to
bytecode. Precompiles are used for computationally expensive operations, that would be cost prohibitive to implement
in Solidity. Where possible predeploys are preferred, as precompiles must be implemented in every execution client.
- [Predeploys](/protocol/execution/evm/predeploys): [Predeployed smart contracts](../../../reference/glossary.md#predeployed-contract-predeploy) exist on Optimism
at predetermined addresses in the genesis state. They are similar to precompiles but instead run
directly in the EVM instead of running native code outside of the EVM.
- [Preinstalls](/protocol/execution/evm/preinstalls): [Preinstalled smart contracts](../../../reference/glossary.md#preinstalled-contract-preinstall) exist on Optimism
at predetermined addresses in the genesis state. They are similar to precompiles but instead run
directly in the EVM instead of running native code outside of the EVM and are developed by third
parties unaffiliated with the Optimism Collective.
- [RPC](/protocol/execution/evm/rpc): This document specifies the JSON-RPC methods implemented by the Flashblocks RPC provider.
- [Derivation](/protocol/consensus/derivation): **Note** the following assumes a single sequencer and batcher. In the future, the design will be adapted to
accommodate multiple such entities.
- [Batch Submission](/protocol/consensus/derivation): **Note** the following assumes a single sequencer and batcher. In the future, the design will be adapted to
accommodate multiple such entities.
- [Architecture](/protocol/consensus/derivation): **Note** the following assumes a single sequencer and batcher. In the future, the design will be adapted to
accommodate multiple such entities.
- [Deriving Payload Attributes](/protocol/consensus/derivation): **Note** the following assumes a single sequencer and batcher. In the future, the design will be adapted to
accommodate multiple such entities.
- [Specification](/protocol/consensus): The [rollup node][g-rollup-node] is the component responsible for [deriving the L2 chain][g-derivation] from L1 blocks
(and their associated [receipts][g-receipts]).
- [P2P](/protocol/consensus/p2p): The [rollup node](index.md) has an optional peer-to-peer (P2P) network service to improve the latency between
the view of sequencers and the rest of the network by bypassing the L1 in the happy case,
without relying on a single centralized endpoint.
- [RPC](/protocol/consensus/rpc): The Rollup node has its own RPC method, `optimism_outputAtBlock` which returns a 32
byte hash corresponding to the [L2 output root](../fault-proof/proposer.md#l2-output-commitment-construction).
- [Standard Bridges](/protocol/bridging/bridges): The standard bridges are responsible for allowing cross domain
ETH and ERC20 token transfers. They are built on top of the cross domain
messenger contracts and give a standard interface for depositing tokens.
- [Deposits](/protocol/bridging/deposits): [Deposited transactions][g-deposited], also known as [deposits][g-deposits] are transactions which
are initiated on L1, and executed on L2. This document outlines a new [transaction
type][g-transaction-type] for deposits. It also describes how deposits are initiated on L1, along
with the authorization and validation conditions on L2.
- [Cross Domain Messengers](/protocol/bridging/messengers): The cross domain messengers are responsible for providing a higher level API for
developers who are interested in sending cross domain messages. They allow for
the ability to replay cross domain messages and sit directly on top of the lower
level system contracts responsible for cross domain messaging on L1 and L2.
- [Withdrawals](/protocol/bridging/withdrawals): [Withdrawals][g-withdrawal] are cross domain transactions which are initiated on L2, and finalized by a transaction
executed on L1. Notably, withdrawals may be used by an L2 account to call an L1 contract, or to transfer ETH from
an L2 account to an L1 account.