# Blockchain Ethereum

> Use this skill when asked about Ethereum internals, EVM deep dive, Ethereum consensus layer, execution clients, staking, EIPs, layer-2 scaling, account abstraction, PBS/MEV-Boost, EVM opcodes, and Ethereum protocol development. Languages: Go, Rust, C#, C++, Solidity. Covers EVM architecture (opcodes, gas metering, memory/storage model, EOF), execution clients (geth, reth, Nethermind, Erigon), consensus layer (Casper FFG, LMD-GHOST, beacon chain, attestation), staking and validators (32 ETH, withdrawal credentials, MEV-Boost, DVT, ePBS), account abstraction (ERC-4337, EntryPoint, paymasters, UserOp mempool), critical EIPs (1559, 4844, 4337, 3529, 2718), and L2 scaling (Optimism, Arbitrum, ZKsync, StarkNet, validium, data availability). Do NOT use for: Bitcoin protocol (use blockchain-bitcoin), non-EVM blockchains (use blockchain-core), or smart contract development (use blockchain-application).

- Skill: `j4flmao/blockchain-ethereum` (Agent Skill, multi-file: 19 files)
- Install (CLI): `npx skillmds@latest add j4flmao/blockchain-ethereum`
- Raw SKILL.md: https://api.skillmd.com/api/skills/j4flmao/blockchain-ethereum/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- License: MIT
- Author: j4flmao (https://skillmd.com/u/j4flmao)
- Updated: 2026-09-21
- Page: https://skillmd.com/skills/j4flmao/blockchain-ethereum

---


# Blockchain Ethereum

## Purpose
Guide to Ethereum protocol engineering covering execution layer, consensus layer, staking, L2 scaling, and protocol evolution through EIPs. Covers both client implementation and protocol-level design.

## Agent Protocol

### Trigger
"Ethereum", "EVM", "Ethereum Virtual Machine", "opcode", "gas", "Ethereum consensus", "beacon chain", "Casper", "LMD-GHOST", "execution client", "geth", "reth", "Nethermind", "Erigon", "Ethereum staking", "validator", "MEV-Boost", "EIP", "EIP-1559", "EIP-4844", "EIP-4337", "account abstraction", "ERC-4337", "EntryPoint", "paymaster", "UserOp", "PBS", "proposer builder separation", "ePBS", "FOCIL", "Ethereum L2", "rollup", "Optimism", "Arbitrum", "ZKsync", "StarkNet", "layer 2", "data availability", "blob", "Ethereum light client"

### Input Context
- Ethereum layer (execution/consensus/L2)
- Client implementation (geth/reth/Nethermind/Erigon)
- Protocol component (EVM/staking/EE/etc.)
- EIP/research area
- Performance requirements (TPS, latency, cost budget)

### Output Artifact
Technical analysis or implementation guide covering the specified Ethereum protocol component with architecture, mechanisms, and trade-offs.

### Response Format
1. **Scope**: execution layer vs consensus layer vs L2 vs EIP
2. **Architecture**: client implementation, component breakdown, data flow
3. **Key mechanisms**: fork choice, finality, fee mechanism, staking
4. **Implementation**: relevant code patterns, configuration, optimization
5. **Trade-offs**: security vs performance, decentralization vs throughput
6. **Integration**: how the component interacts with other Ethereum layers

### Completion Criteria
- Architecture covers the specific layer with correct component references
- Mechanisms accurately reflect current Ethereum spec (as of latest hard fork)
- Implementation references real client code where applicable
- Trade-offs analyzed with specific metrics
- Future directions (upcoming EIPs, research areas) identified

### Max Response Length
5000 tokens

## Decision Trees

### Ethereum Layer Architecture
```
Ethereum interaction type:
├── Running a node?
│   ├── Full node → Any EL + any CL client
│   │   ├── Go experience → geth + lighthouse
│   │   ├── Rust experience → reth + lodestar
│   │   ├── C#/.NET → Nethermind + teku
│   │   ├── Archival focus → Erigon + any CL
│   │   └── Resource constrained → reth + nimbus (lightest)
│   ├── Validator node → EL + CL + validator client
│   │   └── 32 ETH bonded per validator
│   └── Light node → Helios or similar (trustless, minimal resources)
├── Developing dApps?
│   ├── EVM interaction → eth_call, eth_sendRawTransaction
│   ├── Account abstraction → ERC-4337 EntryPoint
│   └── L2 deployment → OP Stack, Arbitrum Nitro, ZK stack
└── Protocol research?
    ├── EVM changes → EIP process (consider EOF, account abstraction)
    ├── Consensus changes → ePBS, FOCIL, SSF, Orbit SSF
    └── L1→L2 → 4844 blobs, based rollups, preconfirmations
```

### Client Selection Decision
```
Node requirements:
├── Mainnet, most popular → geth (Go) — reference implementation
├── High performance, sync speed → reth (Rust) — 2-3x faster sync
├── Enterprise, .NET ecosystem → Nethermind (C#) — good monitoring
├── Archival node, optimized storage → Erigon (Go) — 50% less storage
└── Lightweight, embedded → reth or custom Go light client
```

### L2 Selection
```
Scaling need:
├── EVM-equivalent, mature → Optimism OP Stack
├── EVM-equivalent, fast → Arbitrum Nitro (multi-round fraud proof)
├── EVM-equivalent, ZK → Scroll, Linea (zkEVM type 2/3)
├── ZK, custom VM → ZKsync Era (zkEVM type 4)
├── ZK, STARK-based → StarkNet (Cairo VM)
└── Data availability only → EigenDA, Celestia (for sovereign rollups)
```

### Validator Infrastructure Decision
```
Validator operations:
├── Solo staking (32 ETH, self-operated)
│   ├── Pros: Maximum rewards, no counterparty risk
│   └── Cons: Requires 32 ETH, technical operation, uptime monitoring
├── Staking pools (Lido, Rocket Pool)
│   ├── Lido: stETH token, permissioned node operators, ~30% of staked ETH
│   ├── Rocket Pool: rETH token, permissionless node operators, 8-32 ETH needed
│   └── Cons: Trust in pool smart contracts, MEV revenue sharing
├── DVT (Distributed Validator Technology)
│   ├── SSV Network: DVT multi-operator validators
│   ├── Obol: Distributed validator cluster
│   └── Pros: Fault tolerance, geographic distribution
└── CEX staking (Coinbase, Binance)
    └── Convenient but centralized, regulatory risk
```

## EVM Architecture

### Opcode Categories
```solidity
// Arithmetic: ADD, SUB, MUL, DIV, MOD, EXP
// Comparison: LT, GT, EQ, ISZERO
// Bitwise: AND, OR, XOR, NOT, SHL, SHR, SAR
// Storage: SLOAD (2100 cold, 100 warm), SSTORE (20000+)
// Memory: MLOAD, MSTORE (3 gas)
// Environment: ADDRESS, BALANCE, CALLER, ORIGIN, CALLVALUE
// Block: BLOCKHASH, COINBASE, TIMESTAMP, NUMBER, PREVRANDAO (after merge)
// Control: JUMP, JUMPI, JUMPDEST, STOP, RETURN, REVERT
// Contract creation: CREATE, CREATE2
// Calls: CALL, STATICCALL, DELEGATECALL, CALLCODE
```

### Gas Cost Table (Key Operations)
| Operation | Gas Cost | Notes |
|---|---|---|
| Base tx | 21,000 | Simple ETH transfer |
| SLOAD (cold) | 2,100 | First read of storage slot in tx |
| SLOAD (warm) | 100 | Subsequent reads in same tx |
| SSTORE (new) | 22,100 | Write to zero → non-zero |
| SSTORE (update) | 5,000 | Write to non-zero → non-zero |
| SSTORE (zero) | 2,900 | Write to non-zero → zero (refund 4,800) |
| CALL | 7,000 | Plus gas stipend if value sent |
| CREATE | 32,000 | Contract deployment base |
| SHA-256 | 60 + 12/word | Precompile at 0x02 |
| BN254 pairing | 45,000 + 34,000/point | Precompile at 0x08 |
| BLAKE2f | Variable | Precompile at 0x09 |
| KZG verification | 50,000 | PINTICE precompile (EIP-4844) |

### EVM Memory Model
```
Stack: 1024-element max, 256-bit words
  - Operations consume from top of stack
  - DUP1-16, SWAP1-16 for manipulation
  - Stack overflow at 1024 elements → revert

Memory: Linear byte array, expandable
  - MLOAD/MSTORE: 3 gas (plus 3 gas per 32-byte word expansion)
  - MCOSTY (EIP-5656): 3 gas for memory copy
  - Memory expansion cost: highest accessed address dictates total cost

Storage: Persistent 256-bit key-value store
  - 2^256 slots of 32 bytes each
  - slot = keccak256(key) for mapping entries
  - Packed storage: multiple variables in one slot if < 32 bytes

Calldata: Read-only input data for transaction/call
  - CALLDATALOAD, CALLDATASIZE, CALLDATACOPY
  - 4 gas per non-zero byte, 16 gas per zero byte (EIP-2028)
  - 16 gas per non-zero byte for calldata in tx data
```

### EOF (Ethereum Object Format)
Proposed EVM upgrade (Prague hard fork): separates code from data, adds section-based structure, enables static jumps, removes CODECOPY/CODESIZE gas issues. EOF contracts have preamble, code sections, data section. Backward-incompatible — only new EOF contracts. Benefits: improved gas metering, better static analysis, simplified client implementation.

## Consensus Layer

### Beacon Chain Architecture
```go
// Attestation flow: validator observes head → signs attestation → gossiped → included in block
type Attestation struct {
    AggregationBits []byte          // Which validators attest
    Data            AttestationData
    Signature       BLSSignature    // Aggregated BLS sig
}

type AttestationData struct {
    Slot            uint64
    Index           uint64          // Committee index
    BeaconBlockRoot Hash            // LMD-GHOST vote
    Source          Checkpoint      // Casper FFG source
    Target          Checkpoint      // Casper FFG target
}
```

### Fork Choice (LMD-GHOST)
```go
func ForkChoice(block Node, store Store) Node {
    head := block
    for {
        children := store.GetChildren(head.Root)
        if len(children) == 0 {
            return head
        }
        // Weighted by attestation votes
        best := children[0]
        for _, child := range children[1:] {
            if child.Weight > best.Weight {
                best = child
            }
        }
        head = best
    }
}
```

### Finality (Casper FFG)
```go
// Justification: 2/3 supermajority on (source, target) checkpoint pair
// Finalization: consecutive justified checkpoints (source → target justified, target → target+1 justified)
// Reorg depth: finalized checkpoints cannot be reorged (economic security)
// Epoch boundary: every 32 slots (6.4 minutes)
// Finality time: typically 2 epochs (12.8 minutes) after block proposal
```

### Validator Responsibilities
```
Per epoch (6.4 minutes, 32 slots):
├── Propose block (1 validator per slot, ~32K validators)
│   ├── Must include: EL block, attestations, slashings, deposits
│   └── Rewards: base reward * (effective balance / 32) * proposer_weight
├── Attest to head (all validators in one of 64 committees per slot)
│   ├── Vote for: LMD-GHOST head (latest block), FFG source, FFG target
│   └── Rewards: base reward * (effective balance / 32) * attestation_weight
└── Slashable offenses:
    ├── Double vote: included in two different blocks for same target
    ├── Surround vote: surrounds another vote (source > target or vice versa)
    └── Proposer slashing: two different blocks proposed for same slot
```

### Reward and Penalty Calculations
```
Base reward = effective_balance * (base_reward_factor) / sqrt(total_active_balance)
base_reward_factor = 64
Total reward per epoch = base_reward * (proposer_weight + attestation_weight + ...)
Proposer weight: 8/64 of base reward per proposed block
Attestation weight: 26/64 for source vote, 14/64 for target vote, 14/64 for head vote

Inactivity leak: when chain hasn't finalized for >4 epochs
  - Penalty increases quadratically over time
  - Max penalty: up to 60%+ of stake during prolonged inactivity
```

## Critical EIPs

| EIP | Title | Impact |
|-----|-------|--------|
| 1559 | Fee market change | Base fee burned, priority fee, block target 50% full |
| 2718 | Typed transaction envelope | Transaction type prefix, extensible tx format |
| 2929 | Gas cost increases for state access | Cold SLOAD 2100, warm SLOAD 100 |
| 3529 | Reduction in refunds | Reduced SELFDESTRUCT and SSTORE refunds |
| 3651 | Warm COINBASE | COINBASE address starts warm (saves 2100 gas) |
| 4337 | Account abstraction | UserOp mempool, EntryPoint contract, paymasters |
| 4788 | Beacon block root in EVM | BEACON_ROOT opcode for L1→L2 bridges |
| 4844 | Proto-danksharding | Blob-carrying transactions for L2 data availability |
| 5656 | MCOPY opcode | Memory copy opcode (3 gas) |
| 6780 | SELFDESTRUCT cleanup | SELFDESTRUCT only sends ETH, doesn't delete code |

### Upcoming EIPs (Prague/Electra)
| EIP | Title | Purpose |
|-----|-------|---------|
| 7002 | Execution layer withdrawal | Validator exits triggered from execution layer |
| 7251 | Compound consolidation | Validator max balance increases from 32 to 2048 ETH |
| 7549 | Move committee index out of attestation | Reduces attestation size, aggregation efficiency |
| 6110 | Supply validator deposits on execution layer | Deposit flow on EL instead of CL |
| 7685 | General purpose execution layer requests | Standardized EL→CL request format |
| 7702 | Set EOA account code | Temporary delegation for smart contract wallets |
| 7691 | Blob count increase | Increase max blob count per block for L2 scaling |

## Account Abstraction (ERC-4337)

### Architecture Components
```typescript
// ERC-4337 flow:
// 1. User creates UserOp off-chain (signs with wallet)
// 2. User sends UserOp to bundler (separate mempool)
// 3. Bundler bundles multiple UserOps into a single transaction
// 4. Bundler submits to EntryPoint.handleOps()
// 5. EntryPoint calls account contract's validateUserOp()
// 6. Account contract verifies signature and pays gas (or via paymaster)

interface UserOperation {
    sender: string;           // Account contract address
    nonce: uint256;           // Anti-replay, sequential
    initCode: bytes;          // Account deployment code (if not deployed)
    callData: bytes;          // Intended execution data
    callGasLimit: uint256;    // Gas for execution
    verificationGasLimit: uint256; // Gas for verification
    preVerificationGas: uint256;  // Gas for bundler overhead
    maxFeePerGas: uint256;    // EIP-1559 max fee
    maxPriorityFeePerGas: uint256; // EIP-1559 priority fee
    paymasterAndData: bytes;  // Paymaster contract + data (if using paymaster)
    signature: bytes;         // User signature
}
```

### Paymaster Types
| Type | Mechanism | Use Case |
|------|-----------|----------|
| Verifying paymaster | Off-chain approval flow | Sponsored transactions for specific users |
| Token paymaster | Swap tokens for gas | Pay gas in ERC-20 instead of ETH |
| Deposit paymaster | Pre-deposit ETH | Enterprise accounts with gas budget |
| Hybrid | Deposit + verification | Tiered access for users |

## L2 Scaling

### Rollup Comparison
| Feature | Optimism (OP) | Arbitrum (Nitro) | ZKsync Era | StarkNet |
|---------|---------------|------------------|------------|----------|
| Type | Optimistic | Optimistic | ZK (Type 4) | ZK (Type 4) |
| VM | EVM (OVM) | EVM (WAVM) | zkEVM (Synchrony) | Cairo VM |
| Fraud proof | Multi-round (ZKP) | Multi-round (bisection) | N/A (validity proof) | N/A (validity proof) |
| Challenge period | 7 days | 7 days | N/A | N/A |
| State commitment | L1 calldata/blobs | L1 calldata/blobs | L1 calldata/blobs | L1 calldata (compress) |
| Sequencer | Centralized (planned) | Centralized (planned) | Centralized | Centralized |
| Withdrawal time | ~7 days | ~7 days | ~30 min | ~30 min |

### Data Availability Options
```
Data posting:
├── Calldata (legacy): Store all L2 tx data as calldata on L1
│   └── Cost: ~16 gas/byte, expensive for high-throughput L2s
├── Blobs (EIP-4844): Dedicated blob-carrying transactions
│   ├── Cost: ~1-3 gas/byte (temporary, ~90% reduction)
│   ├── Blob size: 128KB per blob, max 6 blobs per block (post-Electra)
│   └── Retention: ~18 days (not stored permanently on L1)
├── EigenDA: External data availability layer
│   ├── Cost: Very low (off-chain DA with attestation)
│   └── Trust: EigenDA operator set (restaked ETH)
└── Celestia: Modular DA network
    ├── Cost: Low (dedicated DA blockchain)
    └── Trust: Celestia validator set
```

### Based Rollups
Rollups that use L1 proposers as their sequencer. No separate sequencer set. L1 proposers include L2 transactions in their L1 blocks. Inherits L1 liveness and decentralization. Challenge: latency (L1 block time = L2 block time). Projects: Taiko, ethOS. Preconfirmation services can provide sub-second user experience.

## Client Implementation Patterns

### Geth (Go) Architecture
```go
// Geth's struct node → etherbase → miner workflow
// Key internal packages:
// core/state: StateDB for account storage management
// core/vm: EVM interpreter (JIT for performance)
// eth: Ethereum protocol handler
// miner: Block producer (seal/consensus) + worker
// consensus/beacon: Engine API interface for CL

// ETH call flow for eth_call:
func (api *EthAPI) Call(args TransactionArgs, blockNrOrHash *rpc.BlockNumberOrHash) (hexutil.Bytes, error) {
    state, header, err := api.getState(blockNrOrHash)
    if err != nil { return nil, err }
    msg := args.ToMessage(api.b.BaseFee)
    result, err := api.b.CallContract(msg, header, state)
    return result, nil
}
```

### Reth (Rust) Architecture
```rust
// Reth uses staged sync pipeline:
// 1. Header stage: download block headers
// 2. Body stage: download block bodies (transactions)
// 3. Sender recovery stage: recover transaction senders
// 4. Execution stage: execute blocks, update state
// 5. Pruning stage: prune old state data

// Advantages over geth:
// - Staged pipeline enables parallel execution
// - Memory-mapped database (redb) reduces IO
// - Static dispatch for EVM (no interpreter overhead)
// - 2-3x faster initial sync
```

## Security Considerations

### Ethereum-Specific Attacks
| Attack | Description | Mitigation |
|--------|-------------|------------|
| Reorg | Chain reorganization before finality | Wait for finalization (>2 epochs) |
| Long-range attack | Attacker creates alternative chain from genesis | Weak subjectivity checkpoint, social consensus |
| Balance attack | Partition network + drain validators | Proposer boost (LMD-GHOST fix) |
| Verifier's dilemma | MEV-Boost relay censorship | FOCIL forced inclusion lists |
| L1→L2 withdrawal exploit | Exploit bridge before fraud proof window | Challenge period monitoring |
| Blob withholding | Sequencer withholds blob data | Blob forwarding network, KZG commitments |

### Staking Risk Matrix
| Risk | Likelihood | Impact | Mitigation |
|------|------------|--------|------------|
| Slashing for double sign | Low (with monitoring) | 1 ETH + removal | Use DVT, separate machines |
| Inactivity leak | Medium (during long outage) | Up to 60% of stake | Failover node, alerting |
| Execution client bug | Low | Potential slashing | Run minority client |
| Consensus client bug | Low | Potential slashing | Run minority client |
| MEV-Boost relay failure | Medium | Missed MEV revenue | Multi-relay configuration |

## Rules
1. Ethereum is a modular blockchain: execution layer (EVM) + consensus layer (beacon chain)
2. Use Go for geth (most popular), Rust for reth (fastest), C# for Nethermind, Go for Erigon
3. LMD-GHOST is fork choice; Casper FFG provides finality; together as Gasper
4. EIP-1559: base fee burned, priority fee to validator, blocks target 50% full
5. Always consider L1 vs L2 tradeoffs: security guarantees, finality, cost, latency
6. Reference specific implementations for deep technical accuracy
7. Account for MEV in protocol design — PBS/MEV-Boost is currently non-consensus
8. L2 security derives from L1 data availability — verify L2 state roots on L1
9. Staking: 32 ETH per validator, withdrawal credentials point to execution address
10. Protocol upgrades via EIP process — each fork bundles multiple EIPs
11. Account abstraction (ERC-4337) separates signature verification from execution
12. EOF enables future EVM improvements by removing backward-compatibility constraints
13. Client diversity is critical — no single client should have >33% market share
14. MEV-Boost relay selection should prioritize decentralization, not just revenue
15. Blob transactions (EIP-4844) are temporary — full danksharding is the long-term goal

## References
  - references/account-abstraction-erc4337.md — Account Abstraction (ERC-4337) Deep Dive
  - references/blockchain-ethereum-advanced.md — Blockchain Ethereum Advanced Topics
  - references/blockchain-ethereum-fundamentals.md — Blockchain Ethereum Fundamentals
  - references/eips-deep-dive.md — Critical EIPs Deep Dive
  - references/eth-consensus-layer.md — Ethereum Consensus Layer (Beacon Chain)
  - references/evm-deep-dive.md — EVM Deep Dive
  - references/execution-clients.md — Execution Clients
  - references/layer2-scaling.md — Layer-2 Scaling
  - references/pbs-mev-boost.md — Proposer-Builder Separation & MEV-Boost
  - references/staking-and-validator.md — Staking and Validators
  - references/ethereum-light-clients.md — Ethereum Light Clients
  - references/blob-transactions-4844.md — Blob Transactions (EIP-4844)
  - references/optimistic-vs-zk-rollups.md — Optimistic vs ZK Rollup Comparison

## Architecture Decision Trees

```
Ethereum Development Strategy
├── Layer-2 deployment?
│   ├── Optimistic rollup → Optimism / Arbitrum (EVM equivalent, 7d challenge)
│   ├── ZK rollup → zkSync / StarkNet (fast finality, proving overhead)
│   └── L1 only → Ethereum mainnet (security at cost)
├── Account abstraction?
│   ├── Yes → ERC-4337 (smart accounts, paymasters, bundlers)
│   ├── EIP-7702 → Native account abstraction (future)
│   └── No → EOA-based (traditional)
├── Calldata optimization?
│   ├── EIP-4844 blobs → Rollups (lower L1 call data cost)
│   ├── Calldata compression → Custom compression for L2 batches
│   └── None → Standard calldata
└── MEV strategy?
    ├── Capture → PBS (MEV-Boost) for validators
    ├── Minimize → CowSwap / batch auctions for users
    └── Ignore → Standard transaction submission
```

**Decision criteria**: Evaluate L2 needs, gas optimization, target users, and MEV exposure tolerance.

## Implementation Patterns

### ERC-4337 Account Abstraction
```solidity
// blockchain-ethereum/contracts/SmartAccount.sol
pragma solidity ^0.8.20;

import "@openzeppelin/contracts/utils/cryptography/ECDSA.sol";

contract SmartAccount {
    using ECDSA for bytes32;

    address public owner;

    function validateUserOp(UserOperation calldata userOp, bytes32 userOpHash) external returns (uint256) {
        bytes32 hash = userOpHash.toEthSignedMessageHash();
        require(owner == hash.recover(userOp.signature), "Invalid signature");
        return 0; // validation gas
    }

    function execute(address dest, uint256 value, bytes calldata func) external {
        require(msg.sender == address(this), "Only self-call");
        (bool success,) = dest.call{value: value}(func);
        require(success, "Execution failed");
    }
}
```

### EIP-4844 Blob Transaction
```python
# blockchain-ethereum/blob_transaction.py
from eth_account import Account
from eth_account._utils.signing import sign_message_hash

class BlobTransaction:
    def __init__(self, w3: Web3):
        self.w3 = w3

    def send_blob(self, blob_data: bytes, to: str) -> dict:
        tx = {
            "type": 0x03,
            "chainId": self.w3.eth.chain_id,
            "to": to,
            "maxFeePerGas": self.w3.eth.gas_price * 2,
            "maxPriorityFeePerGas": self.w3.eth.max_priority_fee,
            "blobVersionedHashes": [self._kzg_commitment(blob_data)],
            "maxFeePerBlobGas": 1000000000,
        }
        return self.w3.eth.send_transaction(tx)
```

## Production Considerations

- **Gas estimation**: Use `eth_estimateGas` with state override; account for L1 data fee on L2.
- **Nonce management**: Track nonces per address; handle reverted tx with nonce caching.
- **Fee market**: Set priority fee dynamically (Flashbots API); monitor base fee trends.
- **L2 finality**: Wait for L2 output root submission to L1 for canonical finality (7d Optimism, ~1h Arbitrum).
- **Wallet compatibility**: Test with MetaMask, WalletConnect, and Coinbase Wallet.
- **Infrastructure**: Deploy RPC nodes with redundancy; use load balancer for high-availability.

## Anti-Patterns

| Anti-Pattern | Consequence | Solution |
|---|---|---|
| Setting all txs to 0 priority fee | Slow or stuck transactions | Use dynamic priority fee (1-5 gwei) |
| No L2-specific gas estimation | Failed L2 transactions | Use L2 gas oracle for estimation |
| Hardcoded chain ID | Replay on different chain | Read chain ID from contract/network |
| Ignoring EIP-1559 | Overpaying for gas | Use type-2 transactions (EIP-1559) |
| Single RPC for production | Downtime during RPC issues | Multiple RPC endpoints with fallback |

## Performance Optimization

- **Calldata compression**: Compress calldata with custom encoding for L2 transactions to reduce L1 data fees.
- **Batch transactions**: Use Multicall (MakerDAO) to batch multiple calls into single transaction.
- **Nonce pre-computation**: Pre-compute nonces for parallel transaction submission.
- **Blob gas optimization**: Pack multiple rollup transactions into single blob (EIP-4844).
- **Gas token refund**: Use EIP-3298 removed; leverage EIP-1559 base fee refund calculations.

## Security Considerations

- **Replay protection**: Include chain ID in EIP-712 signatures; verify in contract.
- **Signature malleability**: Use EIP-2 (s < secp256k1n/2) to prevent signature malleability.
- **Access control for smart accounts**: Implement social recovery; multi-owner approval for high-value operations.
- **MEV protection**: Use Flashbots Protect or CoW Swap for order-flow privacy.
- **Contract verification**: Publish source code on Etherscan; verify with Sourcify for multi-chain.

## Phase
blockchain → blockchain-ethereum