Skip to content
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

EIP-4750: Fix formatting #6125

Merged
merged 1 commit into from
Dec 13, 2022
Merged

EIP-4750: Fix formatting #6125

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
30 changes: 15 additions & 15 deletions EIPS/eip-4750.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -17,13 +17,13 @@ Introduce the ability to have several code sections in EOF-formatted ([EIP-3540]

## Motivation

Currently in the EVM everything is a dynamic jump. Languages like Solidity generate most jumps in a static manner (i.e. the destination is pushed to the stack right before, `PUSHn .. JUMP`). Unfortunately however this cannot be used by most EVM interpreters, because of added requirement of validation/analysis. This also restricts them from making optimisations and potentially reducing the cost of jumps.
Currently, in the EVM everything is a dynamic jump. Languages like Solidity generate most jumps in a static manner (i.e. the destination is pushed to the stack right before, `PUSHn .. JUMP`). Unfortunately however this cannot be used by most EVM interpreters, because of added requirement of validation/analysis. This also restricts them from making optimisations and potentially reducing the cost of jumps.

[EIP-4200](./eip-4200.md) introduces static jump instructions, which remove the need for *most* dynamic jump use cases, but not everything can be solved with them.

This EIP aims to remove the need and disallow dynamic jumps as it offers the most important feature those are used for: calling into and returning from functions.

Furthermore it aims to improve analysis opportunities by encoding the number of inputs and outputs for each given function, and isolating the stack of each function (i.e. a function cannot read the stack of the caller/callee).
Furthermore, it aims to improve analysis opportunities by encoding the number of inputs and outputs for each given function, and isolating the stack of each function (i.e. a function cannot read the stack of the caller/callee).

## Specification

Expand All @@ -36,7 +36,7 @@ Furthermore it aims to improve analysis opportunities by encoding the number of
5. Exactly one type section MAY be present.
6. The type section, if present, MUST directly precede all code sections.
7. The type section, if present, contains a sequence of pairs of bytes: first byte in a pair encodes number of inputs, and second byte encodes number of outputs of the code section with the same index. *Note:* This implies that there is a limit of 256 stack for the input and in the output.
8. Therefore type section size MUST be `n * 2` bytes, where `n` is the number of code sections.
8. Therefore, type section size MUST be `n * 2` bytes, where `n` is the number of code sections.
9. First code section MUST have 0 inputs and 0 outputs.
10. Type section MAY be omitted if only a single code.
section is present. In that case it implicitly defines 0 inputs and 0 outputs for this code section.
Expand Down Expand Up @@ -66,7 +66,7 @@ We introduce three new instructions:

1. `CALLF` (`0xb0`) - call a function
2. `RETF` (`0xb1`) - return from a function
2. `JUMPF` (`0xb2`) - jump to a function (without updating return stack)
3. `JUMPF` (`0xb2`) - jump to a function (without updating return stack)

If the code is legacy bytecode, any of these instructions results in an *exceptional halt*. (*Note: This means no change to behaviour.*)

Expand All @@ -88,17 +88,17 @@ If the code is valid EOF1, the following execution rules apply:
6. Pops nothing and pushes nothing to data stack.
7. Pushes to return stack an item:

```
(code_section_index = current_section_index,
offset = PC_post_instruction,
stack_height = data_stack.height - types[code_section_index].inputs)
```

Under `PC_post_instruction` we mean the PC position after the entire immediate argument of `CALLF`. Data stack height is saved as it was before function inputs were pushed.

*Note:* Code validation rules of [EIP-3670](./eip-3670.md) guarantee there is always an instruction following `CALLF` (since terminating instruction is required to be final one in the section), therefore `PC_post_instruction` always points to an instruction inside section bounds.

7. Sets `current_section_index` to `code_section_index` and `PC` to `0`, and execution continues in the called section.
```
(code_section_index = current_section_index,
offset = PC_post_instruction,
stack_height = data_stack.height - types[code_section_index].inputs)
```
Under `PC_post_instruction` we mean the PC position after the entire immediate argument of `CALLF`. Data stack height is saved as it was before function inputs were pushed.
*Note:* Code validation rules of [EIP-3670](./eip-3670.md) guarantee there is always an instruction following `CALLF` (since terminating instruction is required to be final one in the section), therefore `PC_post_instruction` always points to an instruction inside section bounds.
8. Sets `current_section_index` to `code_section_index` and `PC` to `0`, and execution continues in the called section.

#### `JUMPF`

Expand Down