status-im/EIPs
2
0
Fork 0
mirror of https://github.com/status-im/EIPs.git synced 2025-02-23 12:18:16 +00:00
Code Issues Projects Releases Wiki Activity

Automatically merged updates to draft EIP(s) 2315 (#3454)

Browse Source 
Hi, I'm a bot! This change was automatically merged because:

 - It only modifies existing Draft, Review, or Last Call EIP(s)
 - The PR was approved or written by at least one author of each modified EIP
 - The build is passing
This commit is contained in:
Greg Colvin 2021-03-31 23:38:21 -04:00 committed by GitHub
parent c65abe153d
commit 3979ae3771
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 4 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
EIPS/eip-2315.md
View File

@ -9,7 +9,7 @@ discussions-to: https://ethereum-magicians.org/t/eip-2315-simple-subroutines-for
created: 2019-10-17 created: 2019-10-17
--- ---
##Simple Summary ## Simple Summary
(Almost) the smallest possible change that provides native subroutines without breaking backwards compatibility. (Almost) the smallest possible change that provides native subroutines without breaking backwards compatibility.
@ -19,7 +19,7 @@ This proposal introduces three opcodes to support subroutines: `BEGINSUB`, `JUMP
## Motivation ## Motivation
The EVM does not provide subroutines as a primitive. Instead, calls can be synthesized by fetching and pushing the current program counter on the data stack and jumping to the subroutine address; returns can be synthesized by getting the return address to the top of the stack and jumping back to it. The EVM does not provide subroutines as a primitive. Instead, calls can be synthesized by fetching and pushing the current program counter on the data stack and jumping to the subroutine address; returns can be synthesized by getting the return address to the top of the stack and jumping back to it. In the EVM the return
Facilities to directly support subroutines are provided in some form by most physical and virtual machines going back at least fifty years. In whatever form, these operations provide for capturing the current context of execution, transferring control to a new context, and returning to the original context. Facilities to directly support subroutines are provided in some form by most physical and virtual machines going back at least fifty years. In whatever form, these operations provide for capturing the current context of execution, transferring control to a new context, and returning to the original context.
@ -116,7 +116,7 @@ While it is crucial going forward that it be possible to validate programs, this
### Validity ### Validity
*** Exceptional Halting States #### Exceptional Halting States
_Execution_ is as defined in the [Yellow Paper](https://ethereum.github.io/yellowpaper/paper.pdf)—a sequence of changes in the EVM state. The conditions on valid code are preserved by state changes. At runtime, if execution of an instruction would violate a condition the execution is in an exceptional halting state. The Yellow Paper defines five such states. _Execution_ is as defined in the [Yellow Paper](https://ethereum.github.io/yellowpaper/paper.pdf)—a sequence of changes in the EVM state. The conditions on valid code are preserved by state changes. At runtime, if execution of an instruction would violate a condition the execution is in an exceptional halting state. The Yellow Paper defines five such states.
1. Insufficient gas 1. Insufficient gas
@ -127,7 +127,7 @@ _Execution_ is as defined in the [Yellow Paper](https://ethereum.github.io/yello
We would like to consider EVM code valid iff no execution of the program can lead to an exceptional halting state, but we must be able to validate code in linear time to avoid denial of service attacks. So in practice, we can only partially meet these requirements. Our validation algorithm does not consider the code’s data and computations, only its control flow and stack use. This means we will reject programs with any invalid code paths, even if those paths are not reachable at runtime. Further, conditions 1 and 2 —Insufficient gas and stack overflow—must in general be checked at runtime. Conditions 3, 4, and 5 cannot occur if the code conforms to the following rules. We would like to consider EVM code valid iff no execution of the program can lead to an exceptional halting state, but we must be able to validate code in linear time to avoid denial of service attacks. So in practice, we can only partially meet these requirements. Our validation algorithm does not consider the code’s data and computations, only its control flow and stack use. This means we will reject programs with any invalid code paths, even if those paths are not reachable at runtime. Further, conditions 1 and 2 —Insufficient gas and stack overflow—must in general be checked at runtime. Conditions 3, 4, and 5 cannot occur if the code conforms to the following rules.
*** The Rules #### The Rules
1. `JUMP` and `JUMPI` address only valid `JUMPDEST` instructions. 1. `JUMP` and `JUMPI` address only valid `JUMPDEST` instructions.
2. `JUMPSUB` addresses only valid `BEGINSUB` instructions. 2. `JUMPSUB` addresses only valid `BEGINSUB` instructions.