EIP-615: Subroutines and Static Jumps for the EVM -- Last Call

@chriseth has expressed very belated but very strong and reasoned objections to EIP-615. Being as he is a core developer and coauthor of the proposal I must take it that there is not consensus to move forward. I am withdrawing the proposal from further consideration.

1 Like

Given the open and egalitarian nature of the community, I don’t see a problem with people explaining that lack of payment results in lack of implementation. No one is mocking anyone.

1 Like

I’de spend more time on this but I am involved in putting a bow on what is finally in the Istanbul so my priorities lie elsewhere. I think that the ideas in this EIP are worth working on and if things go as planned I may come back to this by the end of the year, possibly in several smaller EIPs.

To that end two things are worth pointing out. First: my advocacy for getting EIP-1702 was preparatory for EVM upgrades like in this EIP. The radical changes would not leak into older versions of contracts. There is also some recommended methods to allow for multiple versions on the chain at the same time.

Second the argument that multi-byte instructions don’t already exist is not entirely accurate. All of the push instructions keep immediate mode values in the code. While they do not directly impact EVM execution they often do in the next instruction, when a jump is called. We can split hairs over the semantics but push <x> jump isn’t much different from jumpto <x>, whereas with the latter we can deprecate dynamic jumps (and then get linear time native compilation, and then eliminate the need for random precompiles for performance reasons).

@chriseth proposed that “additional output” and “a formal system” can be used to to gain the same benefits. Saying there are better ways to do without a concrete implementation is letting perfect be the enemy of better. If there are better solutions they should be proposed so they can be implemented. Until then this is the best solution that I’ve seen proposed to get the EVM to adopt modern VM technologies and thus reap the benefits (such as linear time native compilation).

1 Like

My snark was out of line by my own standards, @AFDudley, and I’m glad that @shemnon called me out on it.

I’ll be happy to help with this, but it unlikely I can be a champion again. I will likely be editing the EIP soon to lay out a better backwards compatibility plan to implement this in stages–amounting perhaps to a few EIPs, but better maintaining conceptual integrity and a clear path forward. So we should stay in touch on this, @shemnon. I think a successful reintroduction of this proposal would take a more up-to-date reference implementation, test vectors, support by at least one high level language, and an explicit push from the formalists, auditors, and tool makers who have expressed private support. @expede, @boris, and myself attempted to get EF funding for that work, but were denied for reasons unknown.

I was trying to get the EVM architecture up to the standards of 1950’s era stack machines, so not all that modern.

1 Like

@boris, I should add that like you and Brooke I would be loathe to work with the Ethereum Foundation on any future project. Their grants process is dysfunctional, unprofessional, and unfair to proposers. They also offer about 1/2 to 1/4 of the going rate for senior American engineers, or less. Volunteering what time I can I will do.

1 Like

I don’t have much issue with their rates. It’s a “break even” level of compensation that won’t build sustainable teams but does compensate engineers that want to do some public service.

Wasting 7 months of our time without clear feedback and then having the EVM Working Group being the only funding not approved with the personal attack of “someone at the EF doesn’t like Boris” is the issue.

The EVM evolution roadmap is there if people care about making a better VM today that leads to a better / easier transition to a future WASM EE is there if people want to follow it.

2 Likes

The rate issue depends a lot on where you live and what you could otherwise earn. Ethereum is not a charity, though I’ve treated it like one. Ethereum is a community, but not yet a self-sustaining one. So now I need to earn what I’m worth as as senior VM architect, and get my R&D back on the cutting edge.

And yes, “dysfunctional, unprofessional, and unfair to proposers.” You were treated shabbily.

I think things will be picked up again, but the need will have to be more apparent. The test will be whether we can write an EVM compiler that can’t go quadratic in the face of adversarial code.

1 Like

The lead author here has confirmed to withdraw the proposal from further consideration in this round. So now wanted to add non-technical notes.

On the human side. I consider this review/discussion to be a success. Having just some of the attention of the great people in this room is value enough for me to get involved in these reviews and bring my a-game.

Private support is a real thing. Many of the use cases (people that want to use the new things that get invented here) will reach out privately. If you spend a lot of time on GitHub and have never put your phone number/email directly in an issue then you might not know really how many not-GitHub people are reading along. These are great relationships, they lead to good, profitable client relationships.

Now is a good time to regroup and follow up on any new contacts we made along the way in this journey. Wishing all the best.

2 Likes

Thank you @fulldecent. We sometimes disagree technically, but always in a civilized manner. My Magicians, Github, and Twitter profiles include my email address, so I’m easy to find, and have done good work with people who have found me. It is unfortunate that many of the people supporting this proposal did not make their needs more clear in our public forums. It’s also unfortunate that I withdrew the proposal not for technical reasons, but because @chriseth–a major coauthor–objected. I have asked him to remove his name from the proposal so that any future attempt to introduce this proposal by @shemnon or others can be judged mainly on technical grounds.

Actually, the proposal points at nearly complete C++ code for an earlier version of the proposal, in the aleth repo. Not that much has changed, so it still serves as useful example.

Per EIP-1 normative information should be in the public domain, typically via a CC0 designation. Aleth is GPL. As a reference implementation it is fine, but it can only be considered informative and not normative.

1 Like

I’m only pointing at the Aleth code as “an aid in understanding how the opcodes work.” Given a normative spec I don’t know that we need a public-domain normative implementation. If we do, Geth is LGPL and Parity is GPL.