From 50e84235fafc680156b4e4bab82154b6fe5dd412 Mon Sep 17 00:00:00 2001 From: Greg Colvin Date: Sat, 22 Oct 2022 11:25:03 -0400 Subject: [PATCH 1/2] Catch up to latest Yellow Paper --- EIPS/eip-2315.md | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/EIPS/eip-2315.md b/EIPS/eip-2315.md index 3abe276052f57e..08e95238802bc7 100644 --- a/EIPS/eip-2315.md +++ b/EIPS/eip-2315.md @@ -88,14 +88,15 @@ _Notes:_ ### Validity -If the execution of an instruction would violate a condition, then the execution is in an exceptional halting state. The Yellow Paper defines five such states. +_Execution_ is defined in the [Yellow Paper](https://ethereum.github.io/yellowpaper/paper.pdf) as 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 six such states. 1. Insufficient gas 2. More than 1024 stack items -3. Insufficient stack items -4. Invalid jump destination -5. Invalid instruction +3. State modification during a static call +4. Insufficient stack items +5. Invalid jump destination +6. Invalid instruction -We would like to consider EVM code valid iff no execution of the program can lead to an exceptional halting state. In practice, we must test at runtime for conditions 1 and 2 — sufficient gas and sufficient stack. We don’t know how much gas there will be, we don’t know how deep a recursion may go, and analysis of stack depth even for non-recursive programs is nontrivial. All of the remaining conditions MUST be validated statically, in time and space quasi-linear in the size of the code. +We would like to consider EVM code valid iff no execution of the program can lead to an exceptional halting state. In practice, we must test at runtime for conditions 1, 2, and 3 — sufficient gas and sufficient stack. We don’t know how much gas there will be, we don’t know how deep a recursion may go, analysis of stack depth even for non-recursive programs is nontrivial, and we don't know whether a call will be static. All of the remaining conditions MUST be validated statically, in time and space quasi-linear in the size of the code. #### Static Constraints on Valid Code @@ -131,7 +132,7 @@ Requiring a consistently aligned `data stack` * ensures that all calls to a subroutine have the same number of inputs and the same number of outputs and * ensures that stack height is bounded in the absence of recursion. -Requiring a consistently aligned `data stack` also allows some algorithms that traverse the control-flow graph -- including code validation and compilation -- to break cycles at joins, again preventing quadratic path explosion. When a traversal gets to a `PC` it has visited before it is either at the beginning of a loop or the entry to a function -- and the stacks will align. So we know that loops will not grow stack, and that the number of arguments to a subroutine will always be the same -- there is no need to traverse that path again. +Requiring a consistently aligned `data stack` also allows some algorithms that traverse the control-flow graph -- including code validation and compilation -- to break cycles at joins, again preventing quadratic path explosion. When a traversal gets to a `PC` it has visited before it is either at the beginning of a loop or the entry to a function. Since the stack height at that `PC` is constant we know that loops will not grow stack, and that the number of arguments to a subroutine will always be the same -- there may be no need to traverse that path again. _Note: The JVM and Wasm enforce similar constraints for similar reasons._ @@ -141,7 +142,7 @@ There are a few major designs for a subroutine facility, two of which are consid *1. Keep return addresses on a dedicated return stack.* Turing's design is often used by stack machines, including those for Forth, Java, Wasm, and others. The data stack is used for computation, with a dedicated stack for return addresses. A single instruction suffices to call, and another to return from a routine. -*2. Keep return addresses on the data stack.* This design is often used by register machines, including those from CDC, IBM, DEC, Intel, and ARM. The registers are used primarily for computation, and the stack maintains call frames for return addresses, arguments, and local variables. On the EVM there are no registers for computation, so using the stack for both purposes can cause the sort of inefficiencies we saw above. Pascal p-code does use this design, but as part of a complex calling convention with dedicated registers. +*2. Keep return addresses on the data stack.* This design is often used by register machines, including those from CDC, IBM, DEC, Intel, and ARM. The registers are used primarily for computation, and the stack maintains call frames for return addresses, arguments, and local variables. On the EVM there are no registers for computation, so using the stack for both purposes can cause the sort of inefficiencies we see below. Pascal p-code does use this design, but as part of a complex calling convention with dedicated registers. #### We prefer the dedicated return stack. From 5b90e9af8badd1b660c3c748a36ef46bd9e301c3 Mon Sep 17 00:00:00 2001 From: Pandapip1 <45835846+Pandapip1@users.noreply.github.com> Date: Sun, 23 Oct 2022 10:00:17 -0400 Subject: [PATCH 2/2] Remove yellow paper ref so that PR can be merged --- EIPS/eip-2315.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-2315.md b/EIPS/eip-2315.md index 08e95238802bc7..e46789d6901bbb 100644 --- a/EIPS/eip-2315.md +++ b/EIPS/eip-2315.md @@ -88,7 +88,7 @@ _Notes:_ ### Validity -_Execution_ is defined in the [Yellow Paper](https://ethereum.github.io/yellowpaper/paper.pdf) as 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 six such states. +_Execution_ is defined in the Yellow Paper as 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 six such states. 1. Insufficient gas 2. More than 1024 stack items 3. State modification during a static call