Alert Source Discuss
⚠️ Draft Standards Track: Core

EIP-7877: Enhanced RETURN opcodes

Deprecate RETURN opcode in favor of new opcodes that allow returning data from various locations without first having to write to memory.

Authors Josh Weintraub (@jhweintraub)
Created 2025-01-31
Discussion Link https://ethereum-magicians.org/t/eip-7877-new-m-s-t-rreturn-opcodes/22731
Requires EIP-6, EIP-1153, EIP-3855

Abstract

This EIP specifies a series of new RETURN opcodes which allow the user to specify which data location to return from instead of defaulting to returning from memory.

Motivation

With the introduction of transient storage, many smart contracts have begun to store data using the new transient opcodes to optimize for gas usage, whereby a callback involves returning the data previously stored transiently. However, the current RETURN opcode only allows for returning sequential bytes in memory. This requires developers to incur additional gas overhead by manually writing data from transient storage to memory before returning, incuring both an additional memory expansion and opcode cost from complicated for-loops. Similar inefficiencies already occur when attempting to return data already placed in storage. This EIP attempts to rectify this by allowing developers to optimize their code by deciding where to return data from directly, instead of requiring the intermediate step of first copying the data to memory.

Specification

This EIP introduces 3 new opcodes as well as renaming/aliasing an existing one.

SRETURN (0xf6)
TRETURN (0xf7)
RRETURN (0xf8)

RETURN -> MRETURN (0xf3)

The MRETURN opcode is a rename of RETURN, whereby sequential bytes in memory are returned. It will operate exactly as it currenty does as of the Cancun hard-fork, and its gas cost will remain the same.

RRETURN operates similar to MRETURN. It pops two items off the stack, an offset to begin reading bytes from in the existing RETURNDATA buffer, and a number of bytes to return. Those bytes are used to overwrite the existing RETURNDATA buffer and then a return to the previous function is performed.

SRETURN and TRETURN operate similarly, except on storage and transient respectively. It pops two items off the stack, a slot number to begin reading from, and a number of sequential slots to return from. Ex: SRETURN(0x0, 0x40) returns the 64 bytes of data in slots [0, 1], and TRETURN(0x0, 0x40) returns the data in transient storage slots [0, 1]. Since the existing S/TLOAD opcodes already return 32-bytes, having the opcode return data in chunks of 32-bytes should make implementation by assembly/compiler much simpler. If the length parameter is a zero, then only the initial slot value should be returned, so SRETURN(0x00, 0x00) returns the value at storage slot 0.

The cost for these opcodes should be similar to the cost of accessing data now.

SRETURN = (number_of_cold_slots) * 2100 + (numer_of_warm_slots * 100)
TRETURN = number_of_slots * 100

RRETURN = cost of RETURNDATACOPY without memory_expansion cost

minimum_word_size = (size + 31) / 32

static_gas = 3
dynamic_gas = 3 * minimum_word_size

overall = static_gas + dynamic_gas

Rationale

Allowing for more targeted return opcodes allows for saving gas at all levels of smart contract optimization by eliminating the intermediate steps of first writing any data to memory before returning. In events where this data may be large, this can result in significant gas savings. These opcodes can be built into the Solidity compiler directly so that all contracts can take advantage of them. Similarly, by making return more explicit it allows for better static analysis by avoiding messy memory allocations.

There is precedent for these changes.

EIP-3855: Introducing PUSH0 opcode to optimize away alternative methods of pushing 0 onto the stack.

EIP-6: Renaming SUICIDE to SELFDESTRUCT without changing functionality.

Backwards Compatibility

There are no backwards compatibility concerns, as MRETURN will utilize the same gas cost and opcode as RETURN does now. Due to EOF, it is suggested that these changes be activated in future EVM version once EOF has been fully implemented.

Security Considerations

There are no security considerations as it is fully backwards compatible, and reduces potential attack space through simplified bytecode.

Copyright and related rights waived via CC0.

Citation

Please cite this document as:

Josh Weintraub (@jhweintraub), "EIP-7877: Enhanced RETURN opcodes [DRAFT]," Ethereum Improvement Proposals, no. 7877, January 2025. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-7877.