EIP-615: Subroutines and Static Jumps for the EVM



Maybe I have an answer to my own question. If you treat JUMPV as an optimized version of a tree of JUMPIF, having all 1’s as conditions would jump to the last leaf in the tree. But that is not really an explanation of JUMPSUBV because it cannot be an optimization of JUMPSUBI (because it is not in the proposal).


What is the wording you want @Arachnid? Is there existing wording in the YP that fits? MSB-first, unsigned, highest bit set to 0.

I’m following Wasm’s semantics here. I should probably say so.


Sidney Amani extended Yoichi’s work to handle this EIP in Lem. We worked on it off-and-on from Nov '17 through Jan '18. https://github.com/seed/eth-isabelle/tree/evm15


They are integers, not arbitrary bit patterns, whether they are described as @chfast does or as @Arachnid does. And the same bit patterns. So “MSB-first, twos-complement, signed, two-byte positive integers”, or “MSB-first, unsigned, two-byte integers less than 2^63.” I don’t have an opinion, @expede.


I am really enthusiastic about the use of static calls and subroutines. At Trail of Bits, we spent a lot of effort building static analyzer and reverse engineering tools for EVM, and we always struggle because of the lack of clear stack-frame definition.

These changes will clearly make EVM more suitable for code analysis and help anyone doing program analysis.

Is there any blocker for pushing this EIP? What are the next steps/deadlines?


In a discussion on AllCoreDevs Martin Swende noticed problems in the Backwards Compatibility section that are probably going to require some a versioning scheme.

Greg Colvin @gcolvin 01:42
@holiman I think you are right. A proposal for versioning code upfront is probably needed. eWasm will need one too, if it hasn’t proposed one already.

Noel Maersk @veox 02:44
@gcolvin I vaguely remember @Arachnid proposing a contract versioning scheme (with a VERSION operation IIRC); not sure if this was just chat or a forum topic.
Here: EM thread 2440 (but see ensuing discussion, next few comments at least).
Also with keyword “versioning”: EM thread 2286 (which I haven’t seen before).

Noel Maersk @veox 02:49
There’s also ethereum/EIPs#1712 (draft, “Disallow Deployment of Unused Opcodes”; discussion: sorpaas/EIPs#4) which may be tangentially related.

Noel Maersk @veox 02:59
And issue ethereum/EIPs#154 from 2016; and pull ethereum/EIPs#1707, linked therein…
In short: there’s 3-5 proposals on versioning, in various states of “stuck draft”.


The links in above copy-paste (in order of appearance):

EVM instruction set versioning

Thanks, Noel @veox.

(Post must be at least 20 characters.)


And https://github.com/ethereum/EIPs/issues/178.

So yes, a number of proposals for EVM versioning have been made. None of them reached a proper EIP draft.

I also believe this is prerequisite for static jumps.

EVM instruction set versioning

Main blocker has been lack of Foundation funding. (Edit: not so much blocker as slower-downer.)
Next step will be Last Call once issues are resolved here.
Deadlines are tracked at https://en.ethereum.wiki/roadmap/istanbul

  • 2019-05-17 (Fri) hard deadline to accept proposals for “Istanbul”
  • 2019-07-19 (Fri) soft deadline for major client implementations


@chfast @veox @holiman

Most of the existing versioning proposals involve starting the contract with a currently invalid bytecode and interpreting what follows as some sort of version name or number. If we don’t want to sort through them all, reopen their discussions, and get consensus on a general scheme, then we can solve the problem just for this proposal.

We can insist in EIP-615 that the implicit main routine that begins each contract must instead start with an explicit, BEGINSUB 0,0. That marks post-615 code and makes it invalid to pre-615 VMs.

In Phase One only post-615 code must be valid. In an optional Phase Two we stop allowing pre-615 contracts at all, except as created by pre-615 contracts.

EVM instruction set versioning