Home

Block Production and Validation

5 min read

Block production in the OP Stack is a proactive process managed by the Miner and its worker, while block validation is a reactive process handled by the Consensus API to verify state transitions derived from the network. Together, they ensure that every new block moves the L2 chain from one valid state to another according to protocol rules.

1. Block Production (Payload Building)

Block production begins when the Consensus Layer (CL) triggers a request via the Engine API’s forkchoiceUpdated method with provided payload attributes.

  • Environment Preparation: The miner initializes an environment, which includes a new block header based on the current chain head (the parent), a StateDB for applying mutations, and an EVM instance. The header fields, such as the EIP-1559 Base Fee and Gas Limit, are calculated based on the parent’s performance.
  • Forced Inclusion (Deposits): Before selecting transactions from the tx-pool, the protocol force-includes deposit transactions (Type 0x7E) derived from Layer 1. These transactions are unsigned and included at the absolute beginning of the block.
  • Transaction Throttling: The miner retrieves pending transactions from the txpool, sorted by Price and Nonce. In the Jovian upgrade, the miner applies strict Data Availability (DA) filters, rejecting transactions that exceed the MaxDATxSize or would cause the block to exceed the MaxDABlockSize.
  • Execution and Assembly: Each transaction is executed via the EVM, updating the state and recording changes in a journal for revertibility. Once the gas pool is exhausted or the building timer expires, the miner calls FinalizeAndAssemble to compute the final state root and seal the block payload.

2. Block Validation (Payload Execution)

Validation occurs when a node receives a pre-constructed block via the engine_newPayload RPC call.

  • Sanity and Metadata Checks: The node converts the executable data back into a Block and performs initial checks: the timestamp must be strictly greater than the parent’s, and the ParentHash must exist in the local database.
  • Optimism-Specific Validation: The node enforces rollup-specific rules, such as ensuring withdrawals are empty post-Canyon and that the withdrawalsRoot is present starting with the Isthmus fork.
  • State Reconstruction: The node must verify the producer’s stateRoot. It fetches the parent state and re-executes every transaction in the payload in the exact same order.
  • Final Commitment: If the computed state root and receipt root match the header provided in the payload, the block is marked as VALID and inserted into the blockchain.

3. Logic in Action: Jovian DA Throttling Example

This example showcases the specific logic used during the Jovian upgrade to ensure a block does not exceed its Data Availability footprint.

Scenario: A miner is building a block with a MaxDABlockSize limit of 50,000 bytes.

  1. L1 Attribute Processing: The miner starts by processing the L1 Attributes Deposit Transaction. It extracts the daFootprintGasScalar (e.g., 400), which is used to calculate the gas-equivalent cost of the L1 data footprint.
  2. The Selection Loop:
    • The miner pulls a user transaction (Tx_A) from the pool. Tx_A has an estimated DA size of 100 bytes.
    • Logic Check: 100 bytes * 400 (Scalar) = 40,000 gas units of DA footprint.
    • The current block’s BlobGasUsed is 5,000. 5,000 + 40,000 = 45,000. This is within the block gas limit.
    • Tx_A is committed; BlobGasUsed in the header is updated to 45,000.
  3. Throttling Rejection:
    • The miner pulls the next transaction (Tx_B). Its DA size is 20 bytes.
    • Logic Check: 20 bytes * 400 = 8,000. 45,000 + 8,000 = 53,000.
    • If the block’s gas limit (or a configured DA cap) is 50,000, the miner pops Tx_B from consideration.
  4. Completion: The miner stops filling, assembly is finalized, and the block is sent to the validator with a final BlobGasUsed of 45,000.

In the OP Stack, payloadAttributes serve as a detailed work order provided by the Consensus Layer (CL) to initiate block production on the Execution Layer (EL).

Compact Form of payloadAttributes

The attributes consist of standard Ethereum fields and specialized OP Stack extensions:

  • Standard Fields:

    • Timestamp: The Unix time for the new block (must be greater than the parent’s).
    • Random (Prevrandao): A 32-byte value for randomness in the EVM.
    • SuggestedFeeRecipient: The L2 address designated to receive transaction fees.
    • Withdrawals: A list of validator withdrawals; must be empty on OP Stack chains post-Canyon.
    • BeaconRoot: The parent beacon block root for EIP-4788 (Cancun).

  • OP Stack Extensions:

    • GasLimit: A mandatory parameter defining the block’s maximum gas capacity.
    • Transactions: An array of binary-encoded transactions, typically used for forced L1-to-L2 deposits.
    • NoTxPool: A boolean that, when true, restricts the block to only the provided transactions.
    • EIP1559Params: Encoded parameters for base fee adjustments introduced in the Holocene fork.
    • MinBaseFee: A mandatory floor for the base fee introduced in the Jovian fork.

How forkchoiceUpdated Uses These Attributes

When the CL calls engine_forkchoiceUpdated with these attributes, the protocol follows this logical sequence:

  1. Chain Synchronization: The method first updates the local chain to the provided HeadBlockHash, triggering a sync if the head is unknown.
  2. Attribute Validation: The EL performs strict checks, such as ensuring the GasLimit is present and that Withdrawals are empty if required by the active fork.
  3. Payload ID Generation: The protocol generates a unique 8-byte PayloadID by hashing the attributes and the parent hash.
  4. Miner Activation: The EL triggers the Miner to start a background building job on top of the updated head.
  5. Forced Inclusions: The miner immediately commits the transactions provided in the attributes (the foundation of the block) to the state.
  6. Background Optimization: Unless NoTxPool is active, the miner spawns a routine to continuously pull transactions from the pool to maximize block value until the CL requests the final payload.
  7. Interruption: If a subsequent FCU call arrives with a different head, the protocol interrupts the current work and reverts state changes via the journal to start fresh.

Graph View

Backlinks