Skip to content

Update EIP-7877: Clarify SRETURN/TRETURN data format and RRETURN bounds #10797

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
+2 −6
Open

Update EIP-7877: Clarify SRETURN/TRETURN data format and RRETURN bounds #10797

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 2 additions & 6 deletions EIPS/eip-7877.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -40,13 +40,9 @@ 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.
`RRETURN` operates similar to `MRETURN`. It pops two items off the stack: `offset` (starting byte index into the current call’s `RETURNDATA` buffer) and `length` (number of bytes to return). It returns the slice `RETURNDATA[offset : offset + length)`. Bounds and error semantics are identical to `RETURNDATACOPY` per [EIP-211](./eip-211.md): if `offset + length > RETURNDATASIZE`, execution fails; zero-length reads at bounds are allowed.

`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.
`SRETURN` and `TRETURN` operate similarly, except on storage and transient storage respectively. Each pops two items off the stack: `slot` (starting storage slot index) and `length` (byte length to return). Bytes are produced by serializing consecutive slots starting at `slot` in ascending order (`slot`, `slot + 1`, …). Each slot is serialized as its 32 raw bytes exactly as if the 256-bit word were written to memory via `MSTORE` (i.e., big-endian 32-byte representation). The returned byte stream is the first `length` bytes of this concatenation. If `length` is not a multiple of 32, the final slot contributes only the first `length % 32` bytes of its 32-byte image. If `length == 0`, zero bytes are returned. Reads of uninitialized storage/transient slots yield 32 zero bytes each.

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

Expand Down
Loading