Fusaka's Impact On Smart Contract Security

Following our prior study of Ethereum's Pectra upgradeBuilding on the foundation laid by prior hard forks, Fusaka rolls out scaling for blobs and a number of DoS-resistance measures alongside exciting new features. , the Fusaka upgrade stands for the next phase in Ethereum's continued evolution. A number of of these changes have material implications for smart contract developers and the security assumptions they rely on.

In this write-up, we look at these key changes in the Fusaka upgrade and their plausible impact on smart contract security.

EIP-7825: Transaction Gas Limit Cap

EIP-7825 brings in a cap on the maximum gas usage of a single transaction, limiting it to 2^24 (roughly 16.78 million) gas. Before that, a transaction could take up an full block, with a limit of 60 million gas.

Considerations:

• Denial of service risks: Smart contracts that assume large, involved functions can be completed in a single transaction may become unusable if those operations exceed the 16 million gas cap. Developers should keep that gas-intensive functions can be split across multiple transactions to avoid denial of service scenarios.

For example, the first getUsers() function noted below may become non-executable if it calls for more than 16M gas. In contrast, the second function does not have this problem since it can be executed across multiple transactions.

// Must be executed in a single transaction and will fail if gas usage > 16M
function getUsers() external view returns (User[] memory users) {
    for (uint256 i = 0; i < allUsers.length; i++) {
        users[i] = // ...
    }
}
 
// Can be executed across multiple transactions and does not suffer from DoS-risks
function getUsers(
    uint256 start,
    uint256 limit
) external view returns (User[] memory users) {
    for (uint256 i = start; i < limit; i++) {
        users[i] = // ...
    }
}

Note that this is a very plain example. The same concept holds for more intricate functions like liquidations or oracle marks.

EIP-7823: MODEXP Input Size Limit

EIP-7823 sets an upper bound on valid input sizes for the MODEXP precompile. The MODEXP precompile runs modular exponentiation operations and is employed in certain cryptographic operations like RSA verification. This EIP limits the size of the inputs to 8192 bits, whereas they could be of any arbitrary size before. After this EIP is activated, any call to MODEXP with inputs larger than 8192 bits will return an error and consume all gas.

Considerations:

• Input size limits: Smart contracts that rely on via MODEXP with inputs larger than 8192 bits will no longer work correctly after this upgrade. Still, as noted in EIP-7823, no contract has ever successfully called MODEXP with an input larger than 513 bytes, so the actual impact is expected to be small in practice.

EIP-7883: MODEXP Gas Cost Raise

EIP-7883 raises the gas cost for MODEXP, in some cases by a significant factor. Any smart contracts that call MODEXP will see their gas usage grow. The exact grow depends on the input parameters, so developers should check the EIP-7883 specification for the blogd pricing algorithm.

Considerations:

• Fixed gas stipends: Contracts that call MODEXP with a fixed gas stipend may find the call reverting with an out-of-gas error after the upgrade, which may cause denial of service issues. As a rule, with fixed gas stipends is strongly discouraged as gas costs are often changed in the EVM.

EIP-7939: Count Leading Zeros (CLZ) Opcode

EIP-7939 brings in a new opcode CLZ that counts the number of leading zeros in a 256-bit value. This can greatly tighten efficiency for certain mathematical operations, notably those involving bit manipulation or logarithmic reckonings.

Considerations:

• Solidity support: Right now, Solidity does not use CLZ for optimisations during code generation. Still, starting in , CLZ can be applied in inline assembly.
• Possible edge case: For an input of 0, CLZ returns 256, indicating that all bits are zero. Keep your code handles this edge case appropriately.

EIP-7951: Precompile for secp256r1 Curve Support

EIP-7951 rolls out a new precompile P256VERIFY that runs ECDSA signature verification over the secp256r1 (NIST P-256) curve. This curve is widely employed in many current systems, including WebAuthn, secure enclaves, and a range of hardware wallets, making integration with these systems by a wide margin easier and more gas-efficient.

Considerations:

• Input format: The precompile expects exactly 160 bytes of concatenated input:
  • 32 bytes: message hash h
  • 32 bytes: signature part r
  • 32 bytes: signature part s
  • 32 bytes: public key x-coordinate
  • 32 bytes: public key y-coordinate
• Return behavior: The precompile returns 0x01 if the signature is valid. Critically, if the signature is invalid or the inputs are malformed, the precompile does NOT revert but in place of that returns empty data 0x. Your contract must explicitly check for the 0x01 return value and treat empty return data as a failed verification.
• Solidity support: Solidity at present has no built-in support for this precompile, so it must be called with a low-level call to the precompile address specified in the EIP.
• L2 compatibility: Make sure the L2 network supports this precompile before deploying contracts that depend on it. Remember that a low-level call to a non-existing contract returns successfully with no return data, which could be mistaken for an invalid signature rather than an unsupported precompile.

Other Changes

A number of other EIPs were rolled out in Fusaka but have minimal direct impact on smart contract security:

• EIP-7594: PeerDAS - Peer Data Availability Sampling - raises the amount of data availability capacity for rollups.
• EIP-7917: Deterministic proposer lookahead - makes sure the beacon proposer schedule for the next epoch is fully deterministic.
• EIP-7918: Blob base fee bounded by execution cost - adjusts blob pricing to make sure blobs pay at least a fraction of the market rate for the compute they request from nodes.
• EIP-7934: RLP Execution Block Size Limit - sets a limit of 10MB on the size of an RLP-encoded block, with 2MB reserved for the beacon block.
• EIP-7935: Set default gas limit - grows the default gas limit to 60 million to enhance L1 scaling.
• EIP-7892: Blob Parameter Only Hardforks - brings in a framework for hard forks that only change blob parameters, allowing for quicker scaling with less coordination overhead.
• EIP-7910: eth_config JSON-RPC Method - adds an RPC method that returns the current, next, and last known forks for the node, useful for ensuring client readiness.

The Fusaka upgrade continues Ethereum's evolution with a focus on scaling. While most changes maintain backward compatibility, the transaction gas limit cap, MODEXP modifications, and new opcode and precompile may need attention from developers and security engineers. By grasp of these changes and testing contracts thoroughly, developers can make sure their applications continue to function correctly on Ethereum's evolving platform.