The Pectra Hard Fork, set to activate on May 7, 2025, is Ethereum’s next major upgrade after Dencun. It brings powerful improvements across three main areas: Pectra Hard Fork Pectra Hard Fork May 7, 2025 Smarter Accounts (EIP-7702): Upgrades EOAs with smart contract features like transaction batching, gas fee sponsorship, spending limits, and recovery, all without needing to switch to a contract wallet. Better Staking Experience (EIP-7251, EIP-7002, EIP-6110): Enhances validator experience by increasing the maximum balance, allowing smart contract-controlled exits, and streamlining validator onboarding. More L2 Scaling (EIP-7691): Doubles blob data throughput, significantly improving scalability and reducing costs for Layer 2 solutions. Smarter Accounts (EIP-7702): Upgrades EOAs with smart contract features like transaction batching, gas fee sponsorship, spending limits, and recovery, all without needing to switch to a contract wallet. Smarter Accounts (EIP-7702): Upgrades EOAs with smart contract features like transaction batching, gas fee sponsorship, spending limits, and recovery, all without needing to switch to a contract wallet. Smarter Accounts (EIP-7702): Better Staking Experience (EIP-7251, EIP-7002, EIP-6110): Enhances validator experience by increasing the maximum balance, allowing smart contract-controlled exits, and streamlining validator onboarding. Better Staking Experience (EIP-7251, EIP-7002, EIP-6110): Enhances validator experience by increasing the maximum balance, allowing smart contract-controlled exits, and streamlining validator onboarding. Better Staking Experience (EIP-7251, EIP-7002, EIP-6110): More L2 Scaling (EIP-7691): Doubles blob data throughput, significantly improving scalability and reducing costs for Layer 2 solutions. More L2 Scaling (EIP-7691): Doubles blob data throughput, significantly improving scalability and reducing costs for Layer 2 solutions. More L2 Scaling (EIP-7691): Pectra is a combined name of Prague (execution layer) and Electra (consensus layer). It represents Ethereum’s steady push toward scalability, usability, and security. In this blog, we’ll break down the major changes in the Pectra hard fork and explain why they’re needed for Ethereum’s future. Prague Electra major changes in the Pectra hard fork why they’re needed Key Changes Introduced In Pectra Hard Fork Key Changes Introduced In Pectra Hard Fork EIP-2537: BLS12-381 Curve Operations Precompile EIP-2537: BLS12-381 Curve Operations Precompile EIP-2537 EIP-2537 addresses a significant issue with Ethereum's cryptographic security. Currently, Ethereum uses the BN254 precompile for cryptographic operations like signature verification. However, BN254 only offers 80 bits of security, which is considered weak in modern cryptography. As computational power advances, this level of security could become vulnerable to attacks. Additionally, BN254 struggles with more complex tasks, like aggregating multiple signatures or public keys, leading to higher gas costs and slower processing times. This inefficiency makes it difficult for Ethereum to support scalable applications such as rollups and decentralized apps (dApps), which rely on strong and efficient cryptographic operations. 80 bits of security higher gas costs To address these challenges, EIP-2537 proposes a new precompile for Ethereum using the BLS12-381 curve, which provides 120+ bits of security—a much stronger level of protection. The introduction of seven new precompiles (located at addresses 0x0b to 0x11) will allow for efficient operations like point addition, multi-scalar multiplication, pairing checks, and field-to-curve mappings. For example, the multi-scalar multiplication functions (G1MSM and G2MSM) use optimized algorithms to handle signature aggregation tasks more efficiently, reducing gas costs. This upgrade will enable Ethereum to perform critical tasks, such as BLS signature verification for proof-of-stake consensus, faster and more securely, supporting the needs of growing applications like rollups and staking. BLS12-381 curve 120+ bits of security seven new precompiles multi-scalar multiplication The benefits of EIP-2537 extend beyond just security improvements. It provides robust error checks, ensuring that invalid inputs are caught and preventing exploits like infinite loops or denial-of-service attacks. For developers, the new precompiles simplify the process of building secure applications by providing a more efficient way to handle complex cryptographic tasks. These improvements also reduce gas costs, making Ethereum more cost-effective for developers building rollups, staking contracts, or other dApps. EIP-2537 is backward compatible, ensuring that existing contracts continue to function as expected, though it will require a hard fork to implement. This upgrade strengthens Ethereum's cryptographic foundation, ensuring the network is safer, more scalable, and better equipped for future innovations. robust error checks EIP-2935: Efficient Block History for Stateless Execution EIP-2935: Efficient Block History for Stateless Execution EIP-2935 Ethereum’s current system only allows access to the last 256 block hashes through the BLOCKHASH opcode, which limits how smart contracts and decentralized applications (dApps) verify past block data. This is especially problematic for stateless clients, which don’t store the entire blockchain state but need to validate operations based on historical blocks. Without access to older block hashes, stateless clients must either store or retrieve this data externally, which complicates the vision of a stateless Ethereum. This limitation also affects Layer 2 solutions like rollups and cross-chain bridges, which need historical block data to prove validity across chains. 256 block hashes BLOCKHASH stateless clients Layer 2 solutions cross-chain bridges EIP-2935 addresses this issue by introducing a system contract that stores the last 8,191 block hashes directly in Ethereum’s state. This is done through a ring buffer, which is a circular array that overwrites the oldest hashes as new ones are added. The contract automatically stores the parent block's hash at the start of each block, without consuming gas or requiring manual intervention. This change allows stateless clients to query the system contract for recent block hashes, improving their ability to validate transactions without needing to store the full blockchain history. last 8,191 block hashes ring buffer The update also benefits Layer 2 solutions by giving them access to a longer history of block hashes (8,191 blocks), making it easier to prove data availability and build fraud proofs. While the BLOCKHASH opcode still only provides the most recent 256 block hashes, the system contract allows for efficient access to a much longer history. This improvement enables faster, more secure verification for decentralized applications and bridges that rely on Ethereum’s state. By providing an efficient, on-chain method for accessing block hashes, EIP-2935 makes Ethereum more scalable and adaptable, supporting the growth of stateless clients and enhancing Ethereum’s compatibility with scaling solutions, fraud proofs, and cross-chain interoperability. Layer 2 solutions BLOCKHASH EIP-6110: On-Chain Validator Deposits EIP-6110: On-Chain Validator Deposits EIP-6110 EIP-6110 addresses critical issues in Ethereum’s proof-of-stake (PoS) consensus mechanism related to validator deposit processing. Currently, deposits are handled through the "eth1data" mechanism, where proposer voting and polling the Ethereum 1.0 (Eth1) network introduce significant delays, with deposits taking up to 12 hours to be processed. This mechanism also creates security vulnerabilities, as an adversarial majority could manipulate deposit data, and it introduces operational fragility, as client sync issues and inconsistencies between different implementations of JSON-RPC APIs can lead to failures. Additionally, maintaining deposit contract snapshots to bootstrap new nodes adds unnecessary complexity, making the system harder to manage and less user-friendly. EIP-6110 resolves these issues by moving the responsibility for deposit processing from the Consensus Layer to the Execution Layer. Validator deposits will be directly appended to Execution Layer blocks from logs emitted by the deposit contract, removing the need for proposer voting and dramatically reducing deposit processing time to approximately 13 minutes, compared to the current 12-hour delay. The proposal ensures that only legitimate deposits are processed by validating them within the Execution Layer, making it impossible for adversaries to manipulate deposits without controlling the Execution Layer. Furthermore, this shift removes the reliance on external JSON-RPC APIs, reducing the risk of failure due to inconsistencies and improving client software design. approximately 13 minutes 12-hour delay external JSON-RPC APIs The solution also simplifies Ethereum's deposit system by eliminating the need for deposit contract snapshots and making the validation process more robust. With this change, the system no longer depends on polling external data sources, ensuring consistency and reliability. EIP-6110 introduces new fields in the Execution Layer’s block structure and specifies parameters like DEPOSIT_CONTRACT_ADDRESS and DEPOSIT_EVENT_SIGNATURE_HASH to streamline deposit handling. This shift not only improves security and scalability but also enhances the user experience for validators, making the process faster, safer, and less error-prone. By removing unnecessary complexities, EIP-6110 improves Ethereum’s PoS system, making it more efficient, secure, and user-friendly. DEPOSIT_CONTRACT_ADDRESS DEPOSIT_EVENT_SIGNATURE_HASH EIP-7002: Execution Layer Triggerable Withdrawals EIP-7002: Execution Layer Triggerable Withdrawals EIP-7002 EIP-7002 introduces a new mechanism that allows Ethereum validators to initiate exits and withdrawals through the execution layer, using the withdrawal credential instead of relying solely on the validator’s active key. Traditionally, Ethereum’s validator lifecycle was controlled by the consensus layer, where only the active (hot) key—used for signing duties like proposing and attesting blocks—could request an exit. However, this created a security limitation: the withdrawal credential (cold key), which truly owns the staked ETH and is typically held offline for safety, could not directly trigger exits or partial withdrawals. If the active key was lost or controlled by a third party (e.g., a staking service), the true ETH owner had no way to retrieve their funds. execution layer withdrawal credential validator’s active key consensus layer active (hot) key withdrawal credential EIP-7002 solves this by introducing a precompile contract at address 0x00000961Ef480Eb55e80D19ad83579A64c007002 in the execution layer. This contract exposes a standardized interface that allows withdrawal credential holders to submit exit or partial withdrawal requests for a specific validator index. When a valid call is made, the contract appends the request to a withdrawal queue, which is then processed by the consensus layer. Each block can process up to 16 requests (with a soft target of 2 per block) to avoid overloading the system. precompile contract 0x00000961Ef480Eb55e80D19ad83579A64c007002 exit partial withdrawal To prevent denial-of-service attacks or spam, EIP-7002 includes a dynamic fee model: the base fee to make a request increases if the queue is saturated and decreases when usage is low—similar to Ethereum’s EIP-1559 gas adjustment logic. This discourages abuse while keeping the system fair and functional. This upgrade is particularly useful for smart contract-based staking solutions or multisig-controlled validators, where the withdrawal credential is managed programmatically and should retain full authority over staked funds. For example, if a validator operator becomes unresponsive or compromised, the withdrawal credential owner (like a staking pool contract) can still exit the validator and recover ETH without needing cooperation from the validator operator. EIP-7002 enhances Ethereum’s staking architecture by empowering the true owner of funds (the withdrawal credential) with direct, on-chain control over validator exits and withdrawals. This reduces trust assumptions, mitigates lock-in risks, and strengthens the security and decentralization of Ethereum staking. true owner of funds EIP-7251: Raising Ethereum’s Staking Cap for Better Efficiency EIP-7251: Raising Ethereum’s Staking Cap for Better Efficiency EIP-7251 Ethereum currently limits each validator to a maximum effective balance of 32 ETH, which creates issues for both solo stakers and large staking operators. Big operators must manage thousands of validators to handle their ETH, leading to over 830,000 validators by October 2023. This bloats the network with peer-to-peer traffic, BLS signature processing, and memory usage—slowing things down and increasing operational costs. Solo stakers, meanwhile, can’t stake more than 32 ETH per validator and don’t benefit from compounding rewards, limiting their earning potential. maximum effective balance of 32 ETH 830,000 validators EIP-7251 proposes increasing the maximum effective balance to 2048 ETH (while keeping the 32 ETH minimum). This change would let large stakers merge multiple validators into fewer, more efficient ones—reducing network load—and give solo stakers more flexibility to stake above 32 ETH and earn better rewards. EIP-7251 maximum effective balance to 2048 ETH merge multiple validators The upgrade works through several mechanisms: On the execution layer, a new smart contract (from EIP-7685) allows validators to merge their ETH stakes into fewer validators. A queue system limits how many can merge at once, preventing spam. On the consensus layer, Ethereum adjusts how many validators can enter or exit at a time (churn limits), allows partial withdrawals (thanks to EIP-7002), enables rewards to compound automatically, and reduces penalties for merging stakes — all to make consolidation easier. To keep the system stable, there's a maximum limit of 262,144 consolidation requests. On the execution layer, a new smart contract (from EIP-7685) allows validators to merge their ETH stakes into fewer validators. A queue system limits how many can merge at once, preventing spam. On the execution layer, a new smart contract (from EIP-7685) allows validators to merge their ETH stakes into fewer validators. A queue system limits how many can merge at once, preventing spam. On the execution layer merge their ETH stakes On the consensus layer, Ethereum adjusts how many validators can enter or exit at a time (churn limits), allows partial withdrawals (thanks to EIP-7002), enables rewards to compound automatically, and reduces penalties for merging stakes — all to make consolidation easier. On the consensus layer, Ethereum adjusts how many validators can enter or exit at a time (churn limits), allows partial withdrawals (thanks to EIP-7002), enables rewards to compound automatically, and reduces penalties for merging stakes — all to make consolidation easier. On the consensus layer partial withdrawals rewards to compound automatically reduces penalties To keep the system stable, there's a maximum limit of 262,144 consolidation requests. To keep the system stable, there's a maximum limit of 262,144 consolidation requests. maximum limit of 262,144 consolidation requests By allowing in-protocol consolidation, EIP-7251 eliminates the need for slow, costly validator exits and reentries. It makes Ethereum’s staking system more scalable, flexible, and efficient, benefiting both solo and institutional stakers—without compromising decentralization or security. EIP-7251 more scalable, flexible, and efficient EIP-7549: Move Commitee Index Outside Attestation EIP-7549: Move Commitee Index Outside Attestation EIP-7549 EIP-7549 proposes moving the committee index field out of the signed Attestation message in Ethereum’s consensus layer to improve vote aggregation efficiency. Currently, each attestation includes the LMD GHOST vote, the Casper FFG vote, and the committee index. Because the committee index is inside the signed message, validators with identical votes produce different signatures, making aggregation inefficient. By relocating the committee index outside the signature and into a separate field called committee_bits, identical votes from different validators can be aggregated into a single signature. This drastically reduces the number of attestations needed to reach consensus from around 1366 to just 22 in large validator sets, a 62x improvement. It also allows blocks to include up to 8 slots' worth of votes instead of 2, significantly increasing on-chain vote capacity and efficiency. committee index Attestation LMD GHOST vote Casper FFG vote committee index committee_bits 62x improvement This proposal only affects the consensus layer—no changes are required on the execution layer. It sets the committee_index in the signed part of the attestation to zero and moves the actual indexing to an outer container using committee_bits. It also increases the size of the aggregation_bits to cover all slot committees. To prevent oversized blocks, the proposal reduces MAX_ATTESTATIONS and cuts MAX_ATTESTER_SLASHINGS from 2 to 1, since the new format increases their size. Bitvectors are used instead of Bitlists for better space efficiency. Because this change alters how attestations are verified, it is backward-incompatible and requires a hard fork. Although the first block after the fork may have zero attestations due to the format switch, the impact is minimal—only one epoch’s worth of penalties for affected validators. Security is preserved, as gossip-level mutation is mitigated by signature checks and verification rules. Malicious attempts to alter committee index data in transit are dropped by peer validation before reaching consensus. committee_index committee_bits aggregation_bits MAX_ATTESTATIONS MAX_ATTESTER_SLASHINGS Bitvectors are used instead of Bitlists for better space efficiency EIP-7623: Increase calldata cost EIP-7623: Increase calldata cost EIP-7623 Ethereum transactions can include extra data in a section called calldata. This is where rollups and many smart contracts store things like proofs, signatures, or user actions. The problem is: sending data in calldata is extremely cheap, especially if that data is made up of many zero bytes. According to current gas pricing rules, each zero byte only costs 4 gas, and even non-zero bytes only cost 16 gas. This means someone can send a huge amount of data for very little gas. For example, a transaction with mostly zero bytes can still legally exist inside a block and cause the block to balloon in size — in some cases up to 7.15 megabytes (MB). That’s far larger than the typical block size of ~100 kilobytes (KB). Even though these large blocks are technically compressed using Snappy during peer-to-peer (P2P) sharing between nodes, the network still has to download, decompress, and process that data — putting extra stress on bandwidth, memory, and CPU usage. This rising block size trend was mostly being driven by rollups and apps using Ethereum just to post raw data, with little computation involved. The issue got even more serious after Ethereum introduced EIP-4844, which created a special space (called blobs) for posting large amounts of data. That change made it even more important to keep block size variability under control, so that Ethereum nodes don’t get overwhelmed and network performance remains stable. calldata sending data in calldata is extremely cheap 4 gas 16 gas 7.15 megabytes (MB) download, decompress, and process just to post raw data EIP-4844 block size variability EIP-7623 addresses this by increasing the cost of calldata, especially when the transaction is mostly just dumping data without doing real computation. Instead of charging the same low price per byte, this proposal introduces a “floor cost” per unit of calldata. The new rule says: a transaction must pay at least 10 gas per calldata token, no matter how cheap the rest of the transaction is. A “token” here is a weighted measure: each zero byte counts as 1 token, and each non-zero byte counts as 4 tokens (because non-zero data is harder to compress). So, if a transaction includes lots of data but very little execution logic, it still has to pay this minimum base cost. This discourages oversized transactions that are just using Ethereum as a cheap data dump. Importantly, EIP-7623 doesn’t punish normal users. If you’re doing something that includes significant smart contract logic — like swapping tokens, minting NFTs, using DeFi, or bridging assets — you continue to pay the same as before. But if your transaction is mostly just dumping data into the blockchain, the cost becomes higher. This limits the total size of a block, bringing the maximum EL (execution layer) payload size down to about 0.72 MB from a theoretical 7.15 MB, significantly reducing resource load on Ethereum nodes. The proposal is backwards-incompatible because it changes gas pricing rules, so it requires a hard fork — meaning all Ethereum clients and wallets must upgrade to understand the new cost system. But for end users, the transition should be seamless once wallets and infrastructure have updated. increasing the cost of calldata “floor cost” per unit of calldata 10 gas per calldata token EIP-7623 doesn’t punish normal users maximum EL (execution layer) payload size down to about 0.72 MB backwards-incompatible EIP-7685: Standardized EL to CL Request System EIP-7685: Standardized EL to CL Request System EIP-7685 As Ethereum's ecosystem grows, many validators—the entities responsible for securing the network—are now being managed by smart contracts instead of individuals. These smart contracts often need to carry out actions that affect the Consensus Layer (CL), such as changing validator settings or initiating upgrades. However, Ethereum currently lacks a standardized, built-in way for the Execution Layer (EL), where smart contracts operate, to send such instructions or requests to the CL. As a result, these actions often require manual intervention or the use of off-chain systems, which introduces risks like human error, delays, or security vulnerabilities. This limitation becomes a serious obstacle as more parts of Ethereum’s infrastructure become automated and self-governed by code. Consensus Layer standardized, built-in way Execution Layer manual intervention EIP-7685 solves this problem by introducing a standard framework for communication from the Execution Layer to the Consensus Layer. It does this by adding a new field called requests_hash to each execution block header. During block processing, smart contracts can generate structured “requests” (such as asking for a validator update), which are collected by the execution layer. These requests are grouped, hashed, and summarized into a single requests_hash. This value is then included in the block, allowing the consensus layer to read, verify, and act on these requests in a secure and consistent way. Importantly, the system is flexible: the format and meaning of each request are defined separately, allowing new types to be added in the future without changing the core block structure. This EIP makes Ethereum more modular, automated, and secure by giving smart contracts a trusted way to suggest consensus-level actions without relying on off-chain tools or human coordination. standard framework for communication from the Execution Layer to the Consensus Layer requests_hash requests_hash read, verify, and act more modular, automated, and secure EIP-7691: Increasing Ethereum’s Blob Capacity to Support L2 Scaling EIP-7691: Increasing Ethereum’s Blob Capacity to Support L2 Scaling EIP-7691 Ethereum introduced "blobs" with the Dencun upgrade in March 2024 to help Layer 2 (L2) rollups post transaction data more cheaply and efficiently. However, the number of blobs per block was limited—3 on average and 6 at most—to avoid overloading the network while the new system was still being tested. This small limit became a problem as more L2s started using Ethereum for data availability. With many rollups competing for limited blob space, this restriction slowed down their growth and reduced the overall scalability of Ethereum. EIP-7691 solves this issue by increasing blob capacity per block. It raises the target from 3 to 6 blobs and the maximum from 6 to 9. This decision is based on real-world data showing that Ethereum’s network has handled blobs well so far, with no major issues. Improvements to the gossip network protocol, like IDONTWANT messages, have also reduced bandwidth use, making room for more data without harming performance. The proposal only changes a few constants in Ethereum’s code. It also adjusts how the blob fee is calculated to keep prices stable despite the higher capacity. Overall, this change helps L2s handle more transactions, reduces user costs, and boosts Ethereum’s scalability—while keeping things simple and safe for the network. EIP-7702: Enchanced Account Abstraction EIP-7702: Enchanced Account Abstraction EIP-7702 Ethereum's Externally Owned Accounts (EOAs) are controlled by private keys and offer basic functionality, but they lack advanced features found in smart contract wallets. EOAs cannot perform actions like batching, where multiple actions (e.g., approving and spending ERC-20 tokens) are executed in one transaction. Instead, users must perform them separately, which leads to higher gas costs and more complexity, especially for users of decentralized exchanges (DEX). EOAs also don't support sponsorship, where someone else pays the gas fees, or privilege de-escalation, where users can limit what sub-keys can do (like spending only a small percentage of funds daily). These limitations make EOAs less ideal for complex apps and lead users to use more complicated smart contract wallets, making the ecosystem fragmented. batching sponsorship privilege de-escalation Without features like batching, gas sponsorship, and privilege de-escalation, Ethereum struggles to offer a smooth user experience. These features are important for DeFi, gaming, and layer-2 apps, and their absence leads to higher costs and potential security risks. Users must either manage multiple transactions or rely on others to pay for gas, which can be error-prone. EIP-7702 aims to fix this by allowing EOAs to delegate code execution to smart contracts, so they can use advanced features without needing to switch to complex smart contract wallets. batching gas sponsorship privilege de-escalation EIP-7702 solves the problem by introducing a new type of transaction (SET_CODE_TX_TYPE 0x04) that lets EOAs permanently set their code to delegate actions to a smart contract. This is done by providing a signed list of authorizations, which specifies which contract the EOA will delegate to. This allows EOAs to use batching (doing multiple actions in one transaction), sponsorship (having someone else pay the gas fees), and privilege de-escalation (giving limited permissions to sub-keys). For example, a user could set their EOA to only allow spending 1% of their ETH per day. The delegation stays in place, and security is ensured by controlling gas costs and checking the nonce. permanently set their code batching sponsorship privilege de-escalation EIP-7702 also improves security by requiring signed approvals for delegation, preventing unauthorized code changes, and limiting the number of delegation chains to avoid problems like infinite loops. It also reduces risks like front-running and protects against replay attacks through nonce checks. For users, this means a better experience with lower gas costs, gas sponsorship, and more secure dApps. While it requires a hard fork to change the Ethereum network’s rules, EIP-7702 is backward compatible with existing contracts and fits into Ethereum's future goals, such as account abstraction (like ERC-4337). This upgrade makes EOAs more flexible, cheaper, and easier to use, helping Ethereum grow and adapt to advanced features. better experience hard fork EIP-3074 vs EIP-7702 EIP-3074 vs EIP-7702 EIP-3074 vs EIP-7702 EIP-3074 and EIP-7702 both aim to make Ethereum wallets (EOAs) smarter, but they do it in different ways. EIP-3074 lets your wallet give control to another smart contract called an invoker. This invoker can then act on your behalf, like paying gas or batching transactions. It’s simple and works with current EOAs, but the downside is that it puts a lot of trust in the invoker—if it’s buggy or malicious, your funds could be at risk. On the other hand, EIP-7702 takes a safer and more flexible approach. Instead of giving control to someone else, it allows your wallet to temporarily behave like a smart contract just for one transaction. You decide the logic, and once the transaction is done, your wallet goes back to normal. This means you get advanced features like custom login, spending limits, and recovery, all with better safety. So in short: EIP-3074 is simpler but riskier, while EIP-7702 is more powerful and secure, designed for the long-term evolution of Ethereum wallets. EIP-3074 and EIP-7702 both aim to make Ethereum wallets (EOAs) smarter, but they do it in different ways. invoker EIP-7702 takes a safer and more flexible approach you get advanced features like custom login, spending limits, and recovery, all with better safety EIP-3074 is simpler but riskier EIP-7702 is more powerful and secure EIP-7840: Add Blob Schedule to EL Config Files EIP-7840: Add Blob Schedule to EL Config Files EIP-7840 Ethereum's Dencun upgrade introduced "blobs" - special data containers that help Layer 2 solutions post data more affordably. The network needs to control how many blobs can be included in each block through parameters like target count, maximum count, and base fee update fraction. Currently, these values are hardcoded in the clients. When these values need to change (like in the upcoming Prague fork), clients must update their code. This creates unnecessary complexity and makes it harder to adjust these parameters in the future as network capacity evolves. EIP-7840 introduces a simple but effective solution: adding a dedicated blobSchedule object to client configuration files. This object lists the blob parameters for each network fork, making it easy to update values without changing the core client code. The configuration looks like this: blobSchedule "blobSchedule": { "cancun": { "target": 3, "max": 6, "baseFeeUpdateFraction": 3338477 }, "prague": { "target": 6, "max": 9, "baseFeeUpdateFraction": 5007716 } } "blobSchedule": { "cancun": { "target": 3, "max": 6, "baseFeeUpdateFraction": 3338477 }, "prague": { "target": 6, "max": 9, "baseFeeUpdateFraction": 5007716 } } This approach solves several problems at once. First, it allows dynamic adjustment of blob parameters without requiring client software updates. Second, it avoids the complexity of passing these values through the Engine API (the interface between Ethereum's execution and consensus layers) with every block. Finally, it ensures execution clients have access to these parameters for features like the eth_feeHistory RPC method, which needs to calculate blob gas usage ratios. eth_feeHistory The proposal is intentionally flexible about how clients handle missing or incomplete configuration, allowing each implementation to choose its own approach. By standardizing this configuration format across all clients, EIP-7840 creates a consistent, future-proof way to manage blob parameters as Ethereum continues to scale through its rollup-centric roadmap. This small change significantly simplifies how Ethereum handles capacity upgrades in the future. Summary: The Pectra upgrade brings key improvements to Ethereum's scalability, security, and user experience. EIPs like 2537 enhance cryptographic security, while 2935 and 6110 improve data integrity and validator deposit handling. EIP-7002 adds more flexibility for exits, and other proposals like 7251 and 7549 streamline validator balance and committee structures. EIP-7702 enables EOAs to use smart contract features, and EIP-7691 boosts data throughput. These changes collectively make Ethereum more efficient, secure, and ready for future growth. Summary
