EIP-4200: Static relative jumps

This is the discussion topic for

This proposal started as a comment back in February and was one of the reasons which kicked off our journey with EVM Object Format (EOF). In the past few months @gumb0 has been working on experimenting and validating this in evmone (PR here), but now is the time to release an actual EIP.

Benchmarks

We compared performance of “static” JUMP instruction with new RJUMP.

The benchmark case consist of 4096 instruction groups called “jumppads”. During execution each jumppad is visited exactly once in fixed pseudo-random order.

Benchmarks were done on Intel Haswell CPU 4.4 GHz with evmone/Baseline 0.8.2.

Instruction CPU time [µs] Burn rate [Ggas/s]
JUMP 28.1 1.75
RJUMP 12.0 1.70 (cost 5), 0.99 (cost 3)

Conservative gas cost selection for RJUMP is 5 to match the current performance of JUMP in “static” context.
However, the JUMP seems to be significantly overpriced as the program heavily using it runs at 1.75 Ggas/s gas burn rate. Selecting RJUMP cost of 3 would still be acceptable because the performance of 1 Ggas/s is still excellent.

2 Likes

I very much support this proposal, having been wanting static jumps for a long time. It will also let me pull these jumps out of EIP-2315, including this EIP by reference.

My only worry is that it may be too soon to be removing JUMPDEST. The pros are clear - more speed, less space, saved gas. The cons are, as you say, that JUMPDEST serves some purposes.

EVM code can be parsed into basic blocks in one pass – because JUMPDESTs (and other control-flow instructions) delimit basic blocks. Otherwise a preliminary pass is needed to find the destinations (such as jumpdest analysis). Tools can take advantage of this, including disassemblers, compilers, and interpreters. And human writers and readers.

Whether the pros outweigh the cons in the end isn’t clear to me, but getting more experience with these operations and getting feedback from toolmakers and others seems worth the wait.