Menu
Article Security

Pectra's Impact On Smart Contract Security

Toon Van Hove

Toon Van Hove

Category Security

Following our previous analysis of Ethereum's upgrades from The Merge through Dencun, the Pectra upgrade represents Ethereum's next significant hard fork in the continuing tradition of network improvements. While many of these changes focus on the consensus layer, several have direct implications for smart contract security and functionality. As developers build immutable smart contracts, understanding these changes becomes crucial for maintaining security assumptions and preventing unexpected behavior.

In this post we will explore the key components of the Pectra upgrade and their potential impact on smart contract development and security.

EIP-7702: Account Abstraction for EOAs

EIP-7702 is perhaps the most significant change for smart contract developers, as it allows Externally Owned Accounts (EOAs) to execute smart contract code during transactions.

Considerations:

  • Only EOA check: The tx.origin == msg.sender check is no longer reliable for distinguishing between EOA and contract callers. With EIP-7702, an EOA can execute code, making it trivial to bypass this check. As such, any functionality that relies on only being called by EOAs and is gated by this check is vulnerable. By updating the check to msg.sender.code.length == 0 && tx.origin == msg.sender it is still possible to identify EOA accounts and reject contracts and 7702-enabled accounts. This is because 7702 accounts have their code set to 0xef0100 || address and thus have a non-zero codesize.

EIP-7251: Increase the MAX_EFFECTIVE_BALANCE

EIP-7251 increases the maximum effective balance for validators to 2048 ETH, allowing them to stake more than the traditional 32 ETH limit.

Considerations:

  • Validator balance assumptions: Smart contracts that process validator balances onchain should account for the fact that effective balances can now be significantly larger than 32 ETH.
  • New system contract: The upgrade introduces a new system contract that allows you to consolidate two validators into one. This contract does not have a typical ABI interface that you might expect from a smart contract. As such, special care is required when interacting with it:
    • By calling the contract with no calldata, the fee getter function is activated and the current consolidation fee is returned.
    • By calling the contract with exactly 96 bytes of calldata a consolidation request is created. The first 48 bytes of calldata represent the public key of the source validator and the remaining 48 bytes represent the public key of the target validator. This call must also have a value attached to it larger than the current consolidation fee. Note that any attached value larger than the current fee is not refunded, as such, it is recommended to call the fee getter before creating a request.

EIP-2537: BLS12-381 Curve Operations

EIP-2537 adds precompiles for BLS12-381 curve operations, enabling more efficient cryptographic operations.

Considerations:

  • L2 compatibility: As always, when new opcodes or precompiles are added, most layer 2 networks do not immediately support them. So if you want to use these precompiles on an L2, ensure the L2 supports it. Calling an unsupported precompile results in a call to an empty contract, which can cause unexpected behavior, like a silent failure.
  • Solidity support: Solidity currently has no built-in support for the BLS precompiles. This means a low level call to the precompile address is required. The precompile addresses, inputs and outputs can be found in the EIP.

EIP-2935: Historical Block Hashes in State

EIP-2935 makes historical block hashes more accessible by storing the latest 8191 hashes in state.

Considerations:

  • New system contract: The current BLOCKHASH opcode and corresponding Solidity block.hash built-in remain unchanged, ensuring backward compatibility. Smart contracts can access a larger range of historical block hashes by calling the new system contract with exactly 32 bytes of calldata, representing the number of the requested block. If the requested number is not in range of the latest 8191 blocks, the system contract will revert.
  • L2 considerations: Layer 2 networks may implement this system contract differently or not at all, so cross-chain applications should verify support.

EIP-7002: Execution Layer Triggerable Withdrawals

EIP-7002 allows withdrawal requests to be triggered from the execution layer, providing more flexibility for validator operations.

Considerations:

  • New system contract: Similar to EIP-7251 and EIP-2935, a new system contract is introduced.
    • By calling the contract with no calldata, the current withdrawal request fee is returned
    • By calling the contract with exactly 56 bytes of calldata, a withdrawal request is created. The first 48 bytes represent the public key of the validator, the remaining 8 bytes are a uint64 representing the amount to withdraw. This call must also have a value attached to it larger or equal to the current withdrawal request fee. Similar to EIP-7251, any attached value larger than the current fee is not refunded, as such, it is recommended to call the fee getter before creating a request.

EIP-7623: Increase Calldata Pricing

EIP-7623 increases the gas pricing of calldata to reduce the maximum block size.

Considerations:

  • Pricing changes: The price of calldata is increased, particularly for transactions that post lots of data and do little execution. Note that this only impacts the top level call. As such, this is mostly relevant for projects that run infrastructure, like relays and wallets that must account for gas costs. For non-top level calls, such as those initiated by a CALL opcode, gas pricing remains unchanged, so the impact on smart contract systems is limited.

Other Changes

Several other EIPs were introduced in Pectra but have minimal direct impact on smart contract security:

The Pectra upgrade continues Ethereum's evolution toward a more flexible and capable platform. While most changes maintain backward compatibility, some changes break previous assumptions and require careful consideration from smart contract developers. By understanding these changes and adapting security assumptions accordingly, developers can continue to build robust and secure applications on Ethereum's evolving foundation.

Share