- \n
- Pectra combines the Prague and Electra upgrades, designed to expand wallet capabilities and make Ethereum more efficient.<\/li>\n
- The major upgrade is pencilled in for the first quarter of 2025. <\/li>\n
- Pectra will, among other things, bring smart-contract functionality to familiar wallets and let validators stake more than today\u2019s 32 ETH limit\u2014up to 2048 ETH.<\/li>\n<\/ul>\n<\/div>\n
What is Pectra?<\/h2>\n
Pectra fuses two previously planned upgrades: Prague (for the execution layer<\/span>) and Electra (for the consensus layer<\/span>).<\/p>\n
![\"Ethereum](\"https:\/\/u1f987.com\/wp-content\/uploads\/apgrejdy-Ethereum-1024x576.png\")
Data: DataWallet<\/a>.<\/figcaption><\/figure>\n \n\u201cThe Pectra upgrade plays a key role in Ethereum\u2019s evolution, and the developer community\u2019s engagement raises the network\u2019s capabilities to a higher level,\u201d \u2014 noted<\/a> CoinGecko analysts.<\/cite><\/p><\/blockquote>\n
The scale of the effort is hinted at by a long list of EIPs<\/span> slated for inclusion in the hard fork:<\/p>\n
![\"EIPs\"](\"https:\/\/u1f987.com\/wp-content\/uploads\/EIPs.webp\")
Data: Ethereum.org<\/a>.<\/figcaption><\/figure>\n These EIPs include advances in account abstraction, significant changes to validator operations, and network-wide performance improvements.<\/p>\n
Among the most notable proposals:<\/p>\n
- \n
- EIP-2537<\/strong><\/a> \u2014 introduces a precompile for operations on the BLS12-381<\/a> elliptic curve. This speeds up and cheapens BLS-signature<\/a> operations, improving validator accessibility and performance and lowering gas costs;<\/li>\n
- EIP-2935<\/strong><\/a> \u2014 persists previous block hashes in dedicated storage slots to improve the efficiency and reliability of Ethereum data verification as the protocol moves toward statelessness;<\/li>\n
- EIP-7002<\/strong><\/a> \u2014 enables faster, more convenient withdrawal management for validators, widening the design space for staking and restaking;<\/li>\n
- EIP-7251<\/strong><\/a> <\/strong>\u2014 allows validators to stake more than the current 32 ETH cap\u2014up to 2048 ETH. This lets node operators reduce the number of validators they run;<\/li>\n
- EIP-7594<\/strong><\/a> \u2014 introduces the PeerDAS (Peer Data Availability Sampling) protocol to optimise L2s, transaction processing and network scalability;<\/li>\n
- EIP-7702<\/strong><\/a> \u2014 adds a new transaction type that lets Ethereum account addresses act as smart-contract wallets for the duration of an operation, then revert to their original state; <\/li>\n
- EIP-7692<\/strong><\/a> \u2014 a bundle of 11 EIPs aimed at improving smart-contract deployment and execution, including gas-cost optimisations for specific operations.<\/li>\n<\/ul>\n
\n\u201cAfter the upgrade, Ethereum will be applied across a broader spectrum of use cases, meeting diverse user needs. Regular user accounts will become more programmable, L2s more accessible, smart contracts more efficient, and validators more flexible in management,\u201d \u2014 said<\/a> William M. Peaster of Bankless.<\/cite><\/p><\/blockquote>\n
EIP-3074 vs EIP-7702<\/h2>\n
The benefits and pitfalls of EIP-3074<\/h3>\n
One of the central components of the forthcoming upgrade was initially expected to be EIP-3074<\/a>, which would bring smart-contract functionality to standard crypto-wallets. In particular, it was envisaged that users could bundle transactions and sign them in a single step.<\/p>\n
EIP-3074 presents the idea of \u201cdelegating control of EOAs<\/span> to a smart contract\u201d. Its main goals include: <\/p>\n
- \n
- advancing the concept of sponsored transactions<\/em>;<\/li>\n
- improving user experience (UX)<\/em> when using a regular Ethereum account (an address derived from a public\/private key pair).<\/li>\n<\/ul>\n
Sponsored transactions let the account that pays gas differ from the account that actually performs ERC-20 operations. For example, a DEX could fold the gas cost into its trading fee by paying on a user\u2019s behalf. That would allow users to avoid holding ETH if they do not need it.<\/p>\n
Put simply, the proposal would enable batching transfers to save time and money, and paying fees for other users. <\/p>\n
EIP-3074 defines two new Ethereum opcodes:<\/p>\n
- \n
- AUTH \u2014 specifies the address authorised to send a transaction on a user\u2019s behalf;<\/li>\n
- AUTHCALL \u2014 calls smart contracts at the specified address on a user\u2019s behalf.<\/li>\n<\/ul>\n
AUTH verifies the user\u2019s signature and intended action, while AUTHCALL invokes the target contract with \u201cthe sender address as the caller\u201d. <\/p>\n
Ordinarily, users must manually sign a message each time they interact with a dapp<\/span> (swapping or staking tokens). With EIP-3074, a single signature would suffice\u2014AUTH and AUTHCALL would automatically handle subsequent steps.<\/p>\n
Another innovation is recovery of lost keys<\/em>. To use it, users grant ownership of their assets to an initiator contract via a digital signature; the contract then performs transactions and function calls on their behalf.<\/p>\n
Despite advantages such as \u201csocial\u201d recovery, advanced transactions and better UX, some community members criticised EIP-3074. For example, DeFi Llama developer 0xngmi called out the chief drawback: \u201cnow it\u2019ll be possible to fully drain an address, all tokens, all NFTs, all DeFi positions with only one bad signature\u201d.<\/p>\n
\n
downside of EIP 3074 is that now it’ll be possible to fully drain an address (all tokens, all nfts, all defi positions\u2026) with only one bad signature<\/p>\n
\u2014 0xngmi (@0xngmi) April 11, 2024<\/a><\/p><\/blockquote>\n
- improving user experience (UX)<\/em> when using a regular Ethereum account (an address derived from a public\/private key pair).<\/li>\n<\/ul>\n
- EIP-2935<\/strong><\/a> \u2014 persists previous block hashes in dedicated storage slots to improve the efficiency and reliability of Ethereum data verification as the protocol moves toward statelessness;<\/li>\n
- EIP-2537<\/strong><\/a> \u2014 introduces a precompile for operations on the BLS12-381<\/a> elliptic curve. This speeds up and cheapens BLS-signature<\/a> operations, improving validator accessibility and performance and lowering gas costs;<\/li>\n