{"id":963,"date":"2025-04-27T13:30:05","date_gmt":"2025-04-27T11:30:05","guid":{"rendered":"https:\/\/ackee.xyz\/blog\/?p=963"},"modified":"2025-04-29T17:57:24","modified_gmt":"2025-04-29T15:57:24","slug":"ethereums-pectra-upgrade-from-the-security-perspective","status":"publish","type":"post","link":"https:\/\/ackee.xyz\/blog\/ethereums-pectra-upgrade-from-the-security-perspective\/","title":{"rendered":"Ethereum\u2019s Pectra Upgrade: Security Implications and Insights"},"content":{"rendered":"<p><span style=\"font-weight: 400;\">Ethereum\u2019s long-awaited upgrade, named Pectra, has finally been precisely scheduled to go live. Pectra will activate on May 7, 2025, at epoch 364032, approximately 10:05:11 UTC. <\/span><span style=\"font-weight: 400;\">It has been over a year (March 2024) since a significant upgrade for scalability with the name Dencun was delivered. Its most famous change for improving L2 scalability is Proto-Danksharding using Blobs (<\/span><a href=\"https:\/\/eips.ethereum.org\/EIPS\/eip-4844\"><span style=\"font-weight: 400;\">EIP-4844<\/span><\/a><span style=\"font-weight: 400;\">).<\/span><\/p>\n<p>&nbsp;<\/p>\n<p><span style=\"font-weight: 400;\">What are the goals of the Pectra hardfork?<\/span><\/p>\n<p><span style=\"font-weight: 400;\">And what is the view from a security perspective?<\/span><\/p>\n<p><span style=\"font-weight: 400;\">What are the details of the improvements that it will bring?<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Let\u2019s find out.<\/span><\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter wp-image-1041 size-gutentype-thumb-masonry-big\" src=\"https:\/\/abchprod.wpengine.com\/wp-content\/uploads\/2024\/11\/EthPectrameme-760x500.png\" alt=\"\" width=\"760\" height=\"500\" srcset=\"https:\/\/ackee.xyz\/blog\/wp-content\/uploads\/2024\/11\/EthPectrameme-760x500.png 760w, https:\/\/ackee.xyz\/blog\/wp-content\/uploads\/2024\/11\/EthPectrameme-300x197.png 300w, https:\/\/ackee.xyz\/blog\/wp-content\/uploads\/2024\/11\/EthPectrameme-1024x674.png 1024w, https:\/\/ackee.xyz\/blog\/wp-content\/uploads\/2024\/11\/EthPectrameme-768x505.png 768w, https:\/\/ackee.xyz\/blog\/wp-content\/uploads\/2024\/11\/EthPectrameme-1536x1011.png 1536w, https:\/\/ackee.xyz\/blog\/wp-content\/uploads\/2024\/11\/EthPectrameme-370x243.png 370w, https:\/\/ackee.xyz\/blog\/wp-content\/uploads\/2024\/11\/EthPectrameme.png 1760w\" sizes=\"auto, (max-width: 760px) 100vw, 760px\" \/><\/p>\n<h2><span style=\"font-weight: 400;\">Evolution of Pectra<\/span><\/h2>\n<p><span style=\"font-weight: 400;\">Since the Merge in 2022, Ethereum\u2019s upgrades to the consensus layer (CL, ensures consensus using PoS) and execution layer (EL, holds state and process transactions) are being delivered simultaneously. That is also reflected in <\/span><a href=\"https:\/\/ethereum.org\/en\/history\/\"><span style=\"font-weight: 400;\">the upgrade naming.<\/span><\/a><span style=\"font-weight: 400;\"> Pectra is a combination of words:<\/span><\/p>\n<ul>\n<li><i><span style=\"font-weight: 400;\">Prague<\/span><\/i><span style=\"font-weight: 400;\"> \u2013 the name of the EL upgrade (named after Devcon cities);<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><i><span style=\"font-weight: 400;\">Electra<\/span><\/i><span style=\"font-weight: 400;\"> \u2013 the name of the CL upgrade (named after celestial stars).<\/span><\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">In the greatest version of Pectra, 24 Ethereum Improvement Proposals (EIPs) were <\/span><a href=\"https:\/\/github.com\/ethereum\/EIPs\/blob\/b530fb418ee58043323afa898c2f0466da7b7515\/EIPS\/eip-7600.md\"><span style=\"font-weight: 400;\">proposed<\/span><\/a><span style=\"font-weight: 400;\"> to be included, but the scope was more than halved to 11 EIPs. The remaining EIPs, including two resonating proposals, PeerDAS (Peer Data Availability Sampling) and EOF (new EVM Object Format), are postponed at least to the next upgrade called Fusaka or even later, but that is yet to be re-evaluated.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">What remained in Pectra, and what will the upgrade bring?<\/span><\/p>\n<h2><span style=\"font-weight: 400;\">Summary of Pectra\u00a0<\/span><\/h2>\n<p><span style=\"font-weight: 400;\">The Ethereum Pectra upgrade makes the network faster, more efficient, and easier to use with improvements for wallets, validators, and smart contracts.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">With the reduced scope, the Pectra upgrade can be summarized in the following five bullet points:<\/span><\/p>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Establish a cross-layer system (EIP-7685) to communicate requests from smart contracts to the CL client, such as staking (EIP-6110) and deposits (EIP-7002).<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Staking with more flexible increments and compounded rewards (EIP-7251) with more secure on-chain deposits (EIP-6110) and withdrawals (EIP-7002).<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Enable smart accounts for EOAs (EIP-7702) that are compatible with ERC-4337.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Increase Ethereum\u2019s scalability by reducing validators\u2019 count (EIP-7251), improving signature aggregation and checking (EIP-7549), and prioritizing blobs by increasing their targets values (EIP-7691) and increasing calldata cost (EIP-7623).\u00a0<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Add new precompiles for more secure on-chain BLS signature verification (EIP-2537) and for retrieving recent block hashes to reduce CL state (EIP-2935).<\/span><\/li>\n<\/ul>\n<h2><span style=\"font-weight: 400;\">Security perspective on Pectra EIPs<\/span><\/h2>\n<p><span style=\"font-weight: 400;\">This section will examine improvements affecting the EL layer with SC auditing expertise.<\/span><\/p>\n<h3><a href=\"https:\/\/eips.ethereum.org\/EIPS\/eip-2935\" target=\"_blank\" rel=\"noopener\"><span style=\"font-weight: 400;\">EIP-2935<\/span><\/a><span style=\"font-weight: 400;\"> Precompile for historical block hashes<\/span><\/h3>\n<p><span style=\"font-weight: 400;\">While this improvement adds a new system contract to the SC layer that anyone can utilize, its primary use case will become viable after the successful transition to stateless clients. What has not yet been mentioned is that L2 rollups can benefit from the longer history window by directly querying this contract.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">The new precompile can also be helpful for protocols or applications utilizing the <\/span><b>BLOCKHASH<\/b><span style=\"font-weight: 400;\"> opcode, for example, for some time-dependent verification. The opcode can access only the last 256 block hashes, so if some application requires something older, it can utilize the new precompile for up to 8192 historical block hashes.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">The change in this proposal is simple and doesn\u2019t introduce new direct attack vectors.<\/span><\/p>\n<h3><a href=\"https:\/\/eips.ethereum.org\/EIPS\/eip-2537\" target=\"_blank\" rel=\"noopener\"><span style=\"font-weight: 400;\">EIP-2537<\/span><\/a><span style=\"font-weight: 400;\"> Precompile for <\/span><span style=\"font-weight: 400;\">BLS12-381<\/span><span style=\"font-weight: 400;\"> curve<\/span><\/h3>\n<p><span style=\"font-weight: 400;\">The second precompile, which adds operations that can be performed over the elliptical curve, is helpful for Ethereum dApps that utilize zero-knowledge proofs (for example, <\/span><a href=\"https:\/\/ackee.xyz\/blog\/zkemail-email-recovery-audit-summary\/\" target=\"_blank\" rel=\"noopener\"><span style=\"font-weight: 400;\">zkEmail<\/span><\/a><span style=\"font-weight: 400;\">). Zero-knowledge can be beneficial for increased security, privacy, or improved scaling (as we can see in ZK rollups).<\/span><\/p>\n<p><span style=\"font-weight: 400;\">As mentioned, operations in this precompile will provide 120+ bits of security, meaning the input and output are variable. This variability is adequately mitigated in the gas calculations. Because this EIP also contains detailed information on how to implement the curve operations effectively and handle edge cases, the possibility of a potential Denial of Service (DoS) or other attack vectors is minimal.<\/span><\/p>\n<h3><a href=\"https:\/\/eips.ethereum.org\/EIPS\/eip-7702\" target=\"_blank\" rel=\"noopener\"><span style=\"font-weight: 400;\">EIP-7702<\/span><\/a><span style=\"font-weight: 400;\"> New transaction type for loading SC code into EOA<\/span><\/h3>\n<p><span style=\"font-weight: 400;\">This EIP brings the most impactful UX improvement in years. The initial vision of Ethereum was to create a SC platform where all accounts function as SC with programmable logic. However, for ease of implementation, EOAs were introduced early as the only way to start transactions, which created the most significant usage difficulties (like seeds or gas payments) for new users adopting the technology.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">This change brings many fascinating benefits:<\/span><\/p>\n<ul>\n<li><b>Existing EOA as SA<\/b><span style=\"font-weight: 400;\"> \u2013 Not only can new wallets use SA (as with <\/span><a href=\"https:\/\/eips.ethereum.org\/EIPS\/eip-4337\" target=\"_blank\" rel=\"noopener\"><span style=\"font-weight: 400;\">ERC-4337<\/span><\/a><span style=\"font-weight: 400;\">), but existing EOAs can also be transformed into SAs through the new delegation transaction. This transformation possibility is exciting because the main factor slowing down SA adoption is the requirement to create a new wallet.<\/span><\/li>\n<li aria-level=\"1\"><b>Infrastructure reuse <\/b><span style=\"font-weight: 400;\">\u2013<\/span> <span style=\"font-weight: 400;\">EOA can delegate code to an ERC-4337 smart wallet to utilize the existing architecture built around it.<\/span><\/li>\n<\/ul>\n<ul>\n<li aria-level=\"1\"><b>Deployment efficiency <\/b><span style=\"font-weight: 400;\">\u2013 Multiple EOAs can be delegated to the exact (audited) implementation, reducing the already steep state growth and simplifying deployment.<\/span><\/li>\n<\/ul>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Metamorphosis <\/b><span style=\"font-weight: 400;\">\u2013 The transaction is designed so that EOA can change its implementation anytime or delegate to zero addresses to remove the configured delegation.<\/span><\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">On the other hand, this change brings some undeniable security risks:<\/span><\/p>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Secure Delegation<\/b><span style=\"font-weight: 400;\"><br \/>\n<\/span><span style=\"font-weight: 400;\">Delegate contracts must implement robust security measures and should ideally be verified by an independent <\/span><a href=\"https:\/\/ackee.xyz\/blog\/glossary\/audit\/\" target=\"_blank\" rel=\"noopener\"><span style=\"font-weight: 400;\">audit<\/span><\/a><span style=\"font-weight: 400;\">. These measures include replay protection and requiring signatures from the account&#8217;s authority for critical operations involving value, gas, target, and calldata. Failure to do so could grant malicious actors access to all user funds or even near-complete control over a user&#8217;s EOA. That\u2019s why users must pay especially focused attention to which contract they are delegating when signing this type of transaction.<\/span><\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">A possible attack scenario for malicious protocols, utilizing phishing or disguise techniques, could work like this:<\/span><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">The delegation transaction to SC (controlled by the malicious protocol) is proposed to a user for signing during a typical interaction (e.g., token swap).<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">The Transaction is trying to look like a regular transaction.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">The user doesn\u2019t recognize that the transaction is not safe and signs it.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">The protocol gets control over the user\u2019s EOA and all assets using the delegated SC.<\/span><\/li>\n<\/ol>\n<p><span style=\"font-weight: 400;\">Wallet providers must mitigate this attack scenario.<\/span><span style=\"font-weight: 400;\"> They should implement this new feature carefully, highlighting the potential risks when signing the delegation transaction. It would also be nice to see some info about the latest audit of the target SC, which could even utilize on-chain audit representation (<\/span><a href=\"https:\/\/eips.ethereum.org\/EIPS\/eip-7512\" target=\"_blank\" rel=\"noopener\"><span style=\"font-weight: 400;\">EIP-7512<\/span><\/a><span style=\"font-weight: 400;\">).<\/span><\/p>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Breaking <\/b><b>tx.origin<\/b><b> invariant<\/b><span style=\"font-weight: 400;\"><br \/>\n<\/span><span style=\"font-weight: 400;\">EOA can delegate to SC and then call a method on itself, effectively calling SC\u2019s method. The <\/span><b>tx.origin<\/b><span style=\"font-weight: 400;\"> and <\/span><b>tx.sender<\/b><span style=\"font-weight: 400;\"> are the same inside this call, which will also propagate to nested calls. On the one hand, this makes batching transactions possible. On the other hand, it makes reentrancy checks and atomic sandwich protections, relying on <\/span><b>require(tx.origin == msg.sender)<\/b><span style=\"font-weight: 400;\">, exploitable by this exact technique. Although protections utilizing <\/span><b>tx.origin<\/b><span style=\"font-weight: 400;\"> are not used often, this exploit may be used on already deployed protocols. There is no workaround except to migrate these protocols to a new version, where the protection is not needed or archived differently.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Front-Running Initialization<\/b><b><br \/>\n<\/b><span style=\"font-weight: 400;\">Compared to traditional contract deployment, delegation to SC does not initialize the storage because the constructor is not invoked. That makes the delegation prone to front-running initialization, which could be achieved as follows:<\/span><\/li>\n<\/ul>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">The user sends a delegation transaction to an SA that does not correctly guard initialization or contains a vulnerable method that does not check if initialization has already been done.\u00a0<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Because the constructor is not invoked, the user\u2019s EOA is left uninitialized.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">A malicious actor can call the initialization method or the vulnerable method on the user\u2019s EOA, gaining an advantage over the user\u2019s account.\u00a0<\/span><\/li>\n<\/ol>\n<p><span style=\"font-weight: 400;\">SA developers must mitigate this attack scenario by performing initialization checks in every (possibly prone) method and ensuring that initialization can only be performed by the EOA owner.<\/span><\/p>\n<h3><a href=\"https:\/\/eips.ethereum.org\/EIPS\/eip-7685\" target=\"_blank\" rel=\"noopener\"><b>EIP-7685<\/b><\/a><b> SC requests to CL (<\/b><a href=\"https:\/\/eips.ethereum.org\/EIPS\/eip-7002\" target=\"_blank\" rel=\"noopener\"><b>EIP-7002<\/b><\/a><b> withdrawals, <\/b><a href=\"https:\/\/eips.ethereum.org\/EIPS\/eip-6110\" target=\"_blank\" rel=\"noopener\"><b>EIP-6110<\/b><\/a><b> deposits)<\/b><\/h3>\n<p><span style=\"font-weight: 400;\">At first glance, the new communication channel for requests from SCs to CL may seem like a new field for exploits. But thanks to the requirement of CL and EL to be able to run independently, these requests are not processed immediately. However, they are processed sometime in the future within an unspecified timeframe (depending on the request). That means the result of the request (withdrawal\/deposit) is not available synchronously but in some next call, making it uncomposable and hard to use in any exploit scenario.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Thanks to these EIPs introducing new features to the SC layer, there is no need to worry about existing protocols handling deposits\/withdrawals off-chain being exploited by this particular protocol change. Instead, they could migrate their logic on-chain to provide users with more transparency, security, and decentralization.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Because this EIP also contains detailed gas calculations of how the withdrawal and deposit requests will be priced, the possibility of a potential DoS there is also minimal.<\/span><\/p>\n<h2><span style=\"font-weight: 400;\">Closer look to EIPs<\/span><\/h2>\n<p><span style=\"font-weight: 400;\">The Pectra upgrade (<\/span><a href=\"https:\/\/eips.ethereum.org\/EIPS\/eip-7600\" target=\"_blank\" rel=\"noopener\"><span style=\"font-weight: 400;\">EIP-7600<\/span><\/a><span style=\"font-weight: 400;\">) will include the following eleven EIPs:<\/span><\/p>\n<h2><span style=\"font-weight: 400;\">Scheduled for inclusion<\/span><\/h2>\n<h3><a href=\"https:\/\/eips.ethereum.org\/EIPS\/eip-2935\" target=\"_blank\" rel=\"noopener\"><span style=\"font-weight: 400;\">EIP-2935<\/span><\/a><span style=\"font-weight: 400;\"> Precompile for historical block hashes<\/span><\/h3>\n<p><span style=\"font-weight: 400;\">Adds a new precompile for returning the latest 8192 block hashes. This change towards stateless clients will allow the CL client to load block hashes from the EL client. In the current implementation, EVM assumes the CL client has the recent blocks available, which is not future-proof for Ethereum\u2019s stateless scaling vision.<\/span><\/p>\n<h3><a href=\"https:\/\/eips.ethereum.org\/EIPS\/eip-2537\" target=\"_blank\" rel=\"noopener\"><span style=\"font-weight: 400;\">EIP-2537<\/span><\/a><span style=\"font-weight: 400;\"> Precompile for BLS12-381 curve<\/span><\/h3>\n<p><span style=\"font-weight: 400;\">Adds a new precompile with 120+ bits of security for verifying BLS signatures on-chain. The existing BLS precompile is kept but provides only 80 bits of security.<\/span><\/p>\n<h3><a href=\"https:\/\/eips.ethereum.org\/EIPS\/eip-7685\" target=\"_blank\" rel=\"noopener\"><span style=\"font-weight: 400;\">EIP-7685<\/span><\/a><span style=\"font-weight: 400;\"> General-purpose execution layer requests<\/span><\/h3>\n<p><span style=\"font-weight: 400;\">Adds a new communication channel that allows sending requests from the SC directly to CL. This channel enables SCs to control validator deposits (EIP-6110), withdrawals (EIP-7002), and anything else in the future since the communication format is very open. Sending requests from SCs to CL to control stakes can currently be performed only via an off-chain service (or human) that collects and forwards the on-chain requests to the CL. This change will enable fully SC-controlled validators \u2013 simplification in the processes of exchanges and protocols (for example, Lido), which interact with deposits while making them more secure through decentralization.<\/span><\/p>\n<h3><a href=\"https:\/\/eips.ethereum.org\/EIPS\/eip-6110\" target=\"_blank\" rel=\"noopener\"><span style=\"font-weight: 400;\">EIP-6110<\/span><\/a><span style=\"font-weight: 400;\"> Validator deposits on-chain<\/span><\/h3>\n<p><span style=\"font-weight: 400;\">Transfers responsibility for stake deposits from CL to EL. This change makes deposit processing more secure and speeds it up from the current 13 hours to 12 minutes. It also deprecates deposit voting (other validators in CL voting to accept the new one) and the associated <\/span><b>Eth1Data<\/b><span style=\"font-weight: 400;\"> poll for storing this data, simplifying the CL implementation.<\/span><\/p>\n<h3><a href=\"https:\/\/eips.ethereum.org\/EIPS\/eip-7002\" target=\"_blank\" rel=\"noopener\"><span style=\"font-weight: 400;\">EIP-7002<\/span><\/a><span style=\"font-weight: 400;\"> Validator withdrawals on-Chain<\/span><\/h3>\n<p><span style=\"font-weight: 400;\">Transfers responsibility for withdrawing deposits from CL to EL. Similar to the previous one, this change makes the process more secure. It moves the right to withdraw the deposited Ether from the validator to the Ether owner, which can be different entities (and often are) in the real world. That makes depositing trustless because the owner of funds can withdraw them anytime without the validator&#8217;s approval.<\/span><\/p>\n<h3><a href=\"https:\/\/eips.ethereum.org\/EIPS\/eip-7251\" target=\"_blank\" rel=\"noopener\"><span style=\"font-weight: 400;\">EIP-7251<\/span><\/a><span style=\"font-weight: 400;\"> Increase <\/span><span style=\"font-weight: 400;\">MAX_EFFECTIVE_BALANCE<\/span><\/h3>\n<p><span style=\"font-weight: 400;\">Increases the effective balance (base value used for rewards calculation) from 32 to 2048 Ether. The primary motivation for this change is to reduce the number of validators up to 64 times (corresponding to the 64-time increase in the effective balance). This improvement is motivated by the change in Ethereum\u2019s scaling vision from 64 separate shard chains to rollup scaling utilizing Danksharding with Data availability sampling through stateless clients. It benefits the whole network by reducing the voting overhead and enabling compounding rewards. It also allows large validators to consolidate stakes into fewer validators, reducing the infrastructure requirements and allowing small players to stake in more flexible increments.\u00a0<\/span><\/p>\n<h3><a href=\"https:\/\/eips.ethereum.org\/EIPS\/eip-7549\" target=\"_blank\" rel=\"noopener\"><span style=\"font-weight: 400;\">EIP-7549<\/span><\/a><span style=\"font-weight: 400;\"> Move Committee Index outside Attestation<\/span><\/h3>\n<p><span style=\"font-weight: 400;\">Moves the committee index (identifier of validator group) outside the signed attestation (message attesting block validity). This change allows attestations to be aggregated more effectively, meaning fewer signatures must be verified to reach consensus.<\/span><\/p>\n<h3><a href=\"https:\/\/eips.ethereum.org\/EIPS\/eip-7702\" target=\"_blank\" rel=\"noopener\"><span style=\"font-weight: 400;\">EIP-7702<\/span><\/a><span style=\"font-weight: 400;\"> New transaction type for loading SC code into EOA<\/span><\/h3>\n<p><span style=\"font-weight: 400;\">Adds a new type of transaction that adds code to the sending EOA. The code that can be loaded to EOA is restricted to a pointer to an address. After successful transaction verification, the EOA will act as if the SC code on the pointed address was natively present in the EOA. This behavior will last until changed by the new transaction from the EOA to a different address or zero address for code removal. This change brings the long-awaited account abstraction to Ethereum, enabling the transition of EOA to smart account (SA) and making features like custom security rules, gas payment delegation, or transaction batching possible. A significant advantage of this approach is that it remains compatible with <\/span><a href=\"https:\/\/eips.ethereum.org\/EIPS\/eip-4337\" target=\"_blank\" rel=\"noopener\"><span style=\"font-weight: 400;\">ERC-4337<\/span><\/a><span style=\"font-weight: 400;\">, the currently used standard for SAs, for which infrastructure and wallets have already been developed in the last few years.<\/span><\/p>\n<h3><a href=\"https:\/\/eips.ethereum.org\/EIPS\/eip-7623\" target=\"_blank\" rel=\"noopener\"><span style=\"font-weight: 400;\">EIP-7623<\/span><\/a><span style=\"font-weight: 400;\">: Increase Calldata Cost<\/span><\/h3>\n<p><span style=\"font-weight: 400;\">Increase the gas cost of calldata for transactions that do not exceed a certain threshold of gas spent on EVM operations. The main goal is to make transactions more expensive for L2s using calldata for their data availability (DA) to incentivize them to use blobs (the preferred way) and decrease space growth.<\/span><\/p>\n<h3><a href=\"https:\/\/eips.ethereum.org\/EIPS\/eip-7691\"><span style=\"font-weight: 400;\">EIP-7691<\/span><\/a><span style=\"font-weight: 400;\">:<\/span> <span style=\"font-weight: 400;\">Blob Throughput Increase<\/span><\/h3>\n<p><span style=\"font-weight: 400;\">Doubles target blobs (3 \u2192 6) and increases max blobs (6 \u2192 9), expanding Layer 2 capacity on Ethereum. Changes target-to-max ratio from 1\/2 to 2\/3 for more responsive fees: base fee increases 8.2% (previously 12.5%) when blocks are full and decreases 14.5% (previously 11.1%) when empty, optimizing data availability pricing.<\/span><\/p>\n<h3><a href=\"https:\/\/eips.ethereum.org\/EIPS\/eip-7840\"><span style=\"font-weight: 400;\">EIP-7840<\/span><\/a><span style=\"font-weight: 400;\">: Add blob schedule to EL config files<\/span><\/h3>\n<p><span style=\"font-weight: 400;\">Introduces &#8220;blobSchedule&#8221; configuration object storing blob parameters (target, max, base fee fraction) for different network forks in JSON format. Replaces hardcoded constants in execution clients with external configuration, enabling automatic parameter application based on active fork version.<\/span><\/p>\n","protected":false},"excerpt":{"rendered":"<p>Ethereum\u2019s long-awaited upgrade, named Pectra, has finally been precisely scheduled to go live. Pectra will activate on May 7, 2025, at epoch 364032, approximately 10:05:11 UTC. It has been over a year (March 2024) since a significant upgrade for scalability with the name Dencun was delivered. Its most famous change for improving L2 scalability is Proto-Danksharding using Blobs (EIP-4844). &nbsp; What are&hellip;<\/p>\n","protected":false},"author":26,"featured_media":966,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[61,10],"tags":[24,149],"class_list":["post-963","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-education","category-ethereum","tag-ethereum","tag-pectra"],"aioseo_notices":[],"featured_image_src":"https:\/\/ackee.xyz\/blog\/wp-content\/uploads\/2024\/11\/Manual-Guided-Fuzzing-Ackee-1-600x400.png","featured_image_src_square":"https:\/\/ackee.xyz\/blog\/wp-content\/uploads\/2024\/11\/Manual-Guided-Fuzzing-Ackee-1-600x600.png","author_info":{"display_name":"Jan Prevratil","author_link":"https:\/\/ackee.xyz\/blog\/author\/jan-prevratil\/"},"_links":{"self":[{"href":"https:\/\/ackee.xyz\/blog\/wp-json\/wp\/v2\/posts\/963","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/ackee.xyz\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/ackee.xyz\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/ackee.xyz\/blog\/wp-json\/wp\/v2\/users\/26"}],"replies":[{"embeddable":true,"href":"https:\/\/ackee.xyz\/blog\/wp-json\/wp\/v2\/comments?post=963"}],"version-history":[{"count":0,"href":"https:\/\/ackee.xyz\/blog\/wp-json\/wp\/v2\/posts\/963\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/ackee.xyz\/blog\/wp-json\/wp\/v2\/media\/966"}],"wp:attachment":[{"href":"https:\/\/ackee.xyz\/blog\/wp-json\/wp\/v2\/media?parent=963"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/ackee.xyz\/blog\/wp-json\/wp\/v2\/categories?post=963"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/ackee.xyz\/blog\/wp-json\/wp\/v2\/tags?post=963"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}