Ethereum Pectra: Testnets, Clients & What to Know | Quicknode

सामग्री लोड हो रही है...

Ethereum Pectra: Testnets, Clients & What to Know | Quicknode

EIP-7702: Allows Externally Owned Accounts (EOAs) to delegate execution of smart contract logic without losing their ability to sign transactions. It does this via a new transaction type (0x4) that sets a "delegation designator" (0xef0100 + target address) in the EOA's code field. When someone interacts with the EOA, the EVM automatically executes the bytecode at the target address in the EOA's context, giving it access to the EOA's storage and balance. This enables smart contract features like batching transactions (i.e., ERC-20 token approval/swap) and permission management while maintaining the EOA's original address and signing capabilities. It aims to be a short-term functionality of account abstraction without requiring new protocol-level opcodes.
EIP-7251: Bumps MAX_EFFECTIVE_BALANCE to 2,048 ETH (from 32 ETH) while keeping the 32 ETH staking minimum. Large validators benefit off this by getting to run fewer validators and beacon nodes, while small validators gain from compounding rewards and more flexible staking increments (e.g., staking 40 ETH directly instead of needing 64 ETH for two separate validators).
EIP-7742: This EIP removes the redundant blob maximum verification from the execution layer and changes how the EL receives the blob target value. Instead of fixed values hardcoded in the EL, the consensus layer now dynamically provides both the target_blobs_per_block and max_blobs_per_block values via the Engine API. This modification adds flexibility to blob parameters, making it easier to adjust them as part of Ethereum's scaling strategy.
EIP-7691: Doubles blob counts from 3 to 6 (target) and 6 to 9 (max) per block, boosting L2 data availability and cutting rollup gas costs by increasing the capacity for data-intensive transactions on Ethereum’s layer 2 solution.
EIP-6110: Adds validator deposits to execution layer (EL) block bodies, slashing onboarding delays caused by consensus layer (CL) lag. Previously, deposits were processed solely through the CL, which could take up to 16-32 hours due to finality requirements. Now, deposit transactions are included directly in EL blocks, validated immediately, and synced with the CL, reducing wait times while maintaining security via a deposit root check.
EIP-7002: Lets validators with 0x01 withdrawal credentials trigger exits and withdrawals directly from the execution layer (EL), streamlining staking workflows. This eliminates the need for CL-initiated exits, allowing staking contracts or users to submit exit.
EIP-7549: Optimizes attestation signature aggregation by moving the committee index out of the signed data and into the aggregation process, trimming consensus layer (CL) overhead. Previously, each attestation included the index in its signature, increasing data and slowing verification. This change reduces redundant computation, shrinks attestation sizes, and speeds up CL processing.
EIP-7685: Sets up a cross-layer request system to support staking-focused EIPs like 7002 and 7251, enabling execution layer (EL) to consensus layer (CL) interactions. It introduces a generic framework where EL contracts can submit requests (e.g., validator exits or balance adjustments) to the CL via a precompile or Engine API call. This reduces latency, enhances staking flexibility, and allows for future upgrades by standardizing cross-layer communication.