Ethereum Improvement Proposals (EIPs)

EIP-4844 introduces a new transaction format called "blob-carrying transactions." These transactions allow for the inclusion of large amounts of data that are not directly accessible by the Ethereum Virtual Machine (EVM) during execution, but whose cryptographic commitments are accessible.

This serves as a stop-gap solution for data sharding by implementing the transaction format intended for full sharding without actually sharding the data. Instead, the blob data is part of the beacon chain and is downloaded by all consensus nodes, though it can be deleted after a relatively short delay.

Key constraints:

• Target data per block: ~0.375 MB
• Maximum data per block: ~0.75 MB

EIP-8052 introduces precompiled contracts to support the Falcon-512 signature scheme, providing post-quantum security for EVM-based chains. To balance NIST compliance with EVM efficiency, the signature verification process is split into two distinct stages: a Hash-to-Point stage and a Core Algorithm stage.

By separating these, developers can choose between:

1. NIST Compliance: Using the standard SHAKE256 hash function.
2. EVM Efficiency: Using a Keccak-based PRNG, which is significantly cheaper to compute within the EVM.
3. ZK Compatibility: The split architecture allows for more efficient Falcon signature ZK proofs by reducing circuit size and proving time.

EIP-2711 introduces a new transaction type (Type 2 under EIP-2718) designed to support three specific use cases:

1. Sponsored Transactions: Allows a separate account (GAS_PAYER) to pay for gas, while a different account acts as the msg.sender.
2. Batch Transactions: Enables executing multiple transactions from the same sender in sequence, providing cross-transaction atomicity.
3. Expiring Transactions: Uses a validUntil field to ensure transactions become invalid after a specific timestamp, useful for preventing stale transactions in queues or providing temporal replay protection.

Note: This EIP is currently marked as Withdrawn.

EIP-2982 specifies Phase 0 of Serenity (eth2), which is the initial bootstrapping phase of Ethereum's transition to a scalable, proof-of-stake (PoS) consensus mechanism.

In Phase 0, the existing Proof-of-Work (PoW) chain remains entirely unaffected. Instead, a beacon chain is built in parallel to serve as the core of the upgraded consensus. The beacon chain uses the Casper the Friendly Finality Gadget (FFG) for proof-of-stake consensus and the Latest Message Driven Greedy Heaviest Observed Sub-Tree (LMD-GHOST) fork-choice rule.

Key objectives of Phase 0 include:

• Bootstrapping the PoS consensus mechanism.
• Establishing the validator registry via a deposit contract on the Ethereum mainnet.
• Providing a foundation for future sharding and full PoS integration.

LUCID is a mechanism designed to provide a public, encrypted mempool for Ethereum. It allows MEV-sensitive transactions to be carried through the public inclusion pipeline while keeping their contents hidden until after the scheduling decision (block production) has been fixed.

Key features include:

• Commit-before-reveal: Transactions are committed to the inclusion pipeline before their contents are decrypted, protecting against front-running and sandwich attacks.
• Scheme Agnostic: The EIP does not enshrine a specific cryptographic construction. It allows for various off-protocol decryption schemes, such as trustless self-decryption or designs following a key publisher's instructions.
• Censorship Resistance: By allowing encrypted propagation, it enables users to access blockspace without relying on private, opaque relays, thereby complementing EIP-7805 (FOCIL).

yul7979 is a compiler for a subset of Yul designed for EIP-7979. It translates Yul function definitions and calls into the three specific instructions introduced by EIP-7979: CALLDEST, CALLSUB, and RETURNSUB.

The compiler features two backends:

1. 7979 Backend: Emits instructions nearly one-to-one (function definitions to CALLDEST...RETURNSUB, and calls to PUSH CALLSUB). This output is designed to pass the reference validator of the companion validation EIP.
2. Legacy Backend: Emits programs using traditional methods (synthesizing calls and returns from dynamic jumps) to allow for like-for-like performance and size comparisons.

EIP-8178 specifies a binary SSZ (Simple Serialize) transport layer for communication between Consensus Layer (CL) and Execution Layer (EL) clients. This serves as a high-performance alternative to the existing JSON-RPC Engine API.

Key improvements over JSON-RPC include:

• Reduced Wire Size: Eliminates hex-encoding of binary data (hashes, addresses, transactions, blobs), reducing payload sizes by approximately 50%.
• Lower CPU Overhead: Removes the need for JSON parsing and generation.
• Native SSZ Support: Since CL clients use SSZ natively, this transport allows the EL to deserialize raw SSZ bytes directly, removing the SSZ $\rightarrow$ JSON $\rightarrow$ Internal Type conversion bottleneck.

EIP-8075 introduces a mechanism to cap Ethereum state growth by dynamically adjusting the gas cost of state creation. It targets a state growth rate of 250 MiB per day using a fee market mechanism similar to EIP-4844.

Key features include:

• Dynamic Pricing: The state_gas_per_byte adjusts based on excess_state_bytes (the running total of state bytes created in excess of a target).
• Scaling via Gas Separation: To prevent state costs from crowding out compute, regular_gas and state_gas are tracked and limited separately, though they are aggregated for base fee calculations.
• Smooth Adjustments: The cost per state byte varies moderately (at most 0.1% per block) to ensure users can set reasonable gas limits without frequent transaction failures.