EIP-3779: Safer Control Flow for the EVM

EIPs Core EIPs
#1

Abstract

This EIP specifies validation rules for some important safety properties, including

  • valid jump destinations,
  • valid instructions,
  • no stack underflows, and
  • no stack overflows without recursion.

Valid contracts will not halt with an exception unless they either run out of gas or overflow stack during a recursive subroutine call.

Code is validated at contract creation time – not runtime – by the provided algorithm. This is a one-pass algorithm, linear in the size of the bytecode, so as not to be a DoS surface.

2 Likes
EIP-3690: EOF - JUMPDEST Table
EIP-2315 Simple Subroutines for the EVM
#2

Am I correct that is is intended to be a possible improvement under EOF (EIP3540) but that the exact mechanism through which this would be integrated with EOF is not currently specified?

#3

In the end this just specifies a few more rules, in the same way that EIP-3690 “extends contact creation validation rules (as defined in EIP-3540).” I should be more clear about that.

The validation algorithm (or its equivalent) would presumably be run at code-validation time, as defined in EIP-3540. I should be more clear about that. Logically, it could be run after the code given there is run. For performance reasons an implementation would probably integrate the code into a single pass.

#4

3690 extends the rules defined in 3670. The basic validation rules are defined by 3670 and not 3540.

For clarity I suggest to provide a reference implementation in Python which extends the validation of 3670 the same way 3690 does.

#5

Aha. I’ve been using Go for example implementations because I don’t know Python, and when I write the reference implementation it will almost surely be a draft PR against Geth.

Anyway, this PR would render 3670 unnecessary - all jump destinations are validated, and no jumpdest table is needed. However, EIPs generally should not reference other EIPs that are still Drafts. We are making an exception for 3540 because it is almost sure to go in. 3670 is more controversial.

#6

3670 does not introduce a jumpdest table (3690 does), so not sure what do you mean.

3540/3670/3690 are all in Review and not Draft.

Why is 3670 controversial?

#7

3540/3670/3690 are all in Review and not Draft.

Good, I and I think @MicahZoltu I missed that, or it changed since his review.

Why is 3670 controversial?

Sorry - I meant 3690. 3670 is good. 3690 I don’t like at all.

#8

I’ve added an EOF container section with a jumptable which gives valid jump destinations for every dynamic jump. This extends the range of valid programs without sacrificing tractable validation.