Ethereum Consensus Assumptions You Inherit Automatically

You assume at least two-thirds of validators are honest. This is the bedrock of Ethereum's Casper FFG finality. A 1/3+ attack can halt finalization, but not revert finalized blocks.\n- Key Consequence: Your L2's safety is a direct derivative of L1's validator set health.\n- Reality Check: This is why restaking and distributed validator technology (DVT) are critical to prevent centralization risks.

Your transaction costs are dictated by Ethereum base fee auctions. Every L2 batch, proof, or state root competes for L1 block space. This creates a hard economic floor you cannot optimize below.\n- Key Consequence: Innovations like blobs (EIP-4844) and proof aggregation (e.g., zkSync, StarkNet) are just optimizations within this constraint.\n- Reality Check: A congested L1 during a memecoin frenzy will spike your user's fees, regardless of your L2's tech.

You inherit Ethereum's ~12-second block time as the latency for cross-domain messaging. This limits synchronous composability between L2s and L1. Fast bridges like Across or LayerZero introduce new trust assumptions to work around this.\n- Key Consequence: Your "instant" withdrawals are illusions backed by liquidity providers, not protocol guarantees.\n- Reality Check: This latency is why intent-based architectures (UniswapX, CowSwap) and shared sequencers are emerging as the next paradigm.

You assume at least one honest validator is always online to finalize the chain. If >33% go offline, the chain halts.\n- Key Implication: Your app's uptime is now tied to a global, decentralized network's health.\n- Action: Design for finality delays; don't assume instant settlement. Use state channels or off-chain pre-confirmations for UX.

Finality isn't binary; it's probabilistic based on the cost to reorg. A block with 32+ ETH in attestations (~$100k+ at stake) is considered final.\n- Key Implication: 'Settlement' for your bridge or oracle has a quantifiable economic security budget.\n- Action: For high-value transactions, require deeper confirmations. Model reorg costs versus your app's max extractable value (MEV).

The protocol assumes messages (blocks, attestations) propagate in ~4 seconds. Slow propagation leads to forks and reduced security.\n- Key Implication: Your sequencer or relayer's geographic distribution and latency directly impact L2 safety.\n- Action: Benchmark your infrastructure against global propagation times. Consider using distributed relay networks like Across or LayerZero for critical cross-chain messages.

While theoretically resistant, proposer-builder separation (PBS) and MEV-Boost create centralized relay points. Builders can censor.\n- Key Implication: Your users' transactions can be excluded from blocks, breaking core app logic.\n- Action: Integrate censorship mitigation like Flashbots Protect, SUAVE, or direct inclusion lists. Don't rely on vanilla eth_sendTransaction.

You assume all consensus data is available for verification. Rollups like Arbitrum, Optimism inherit this via calldata, but validiums and L3s fracture the assumption.\n- Key Implication: Choosing an alternative DA layer (Celestia, EigenDA) changes your security model from Ethereum to that system.\n- Action: Explicitly map your stack's DA source. The trade-off is ~100x cost savings vs. inheriting Ethereum's full security.

New nodes or long-offline nodes need a trusted recent block hash ('weak subjectivity checkpoint') to sync correctly.\n- Key Implication: Your infra's ability to recover from failure depends on social consensus and client diversity.\n- Action: Hardcode reputable checkpoints (e.g., from client teams) in your node orchestration. Monitor client diversity to avoid single-point failures.