Suggestions

[jamesray1]

Hi Micah,

Since the current "official" Yellow Paper is out of date, have you included the more recent EIPs from Byzantium into your specification? I see you've added the opcodes for REVERT and STATICCALL, but there is no description of these, so that needs to be done.

It also has CALL_BLACKBOX which I don't think is actually a part of the EVM. Sources:

• https://www.reddit.com/r/ethdev/comments/6i05w2/when_is_the_call_blackbox_opcode_going_to_be/
• https://www.reddit.com/r/ethereum/comments/5256ht/ethereum_20_mauve_paper/d7i9dvv/
• searching for CALL_BLACKBOX in the EIPs repo yields no results.

There is no result when I search for precompiles.

While I understand that the blanched almond paper is concise, I think it is helpful to have a full formal specification, which it isn't, e.g. compared to the Yellow Paper it doesn't formally specify the opcodes. We could also improve on my version of the Yellow Paper for people who wish to have an in-depth understanding. For example one formal specification that I didn't see is of the difficulty, which is best represented by maths (or maths in code) rather than pseudocode.

Also have you outlined the development roadmap? E.g., implement sharding which will then enable more rapid development of other projects, e.g. EWASM, parallelizability, etc.

Finally it'd obviously be good to have this info on a website, e.g. one made by https://readthedocs.org/.

I haven't read through your repo yet but these are my initial thoughts on how the yellow paper needs to be improved, in addition to your ideas.

Additionally I think it would be good to have the formal math operations, but then you can also have pseudocode or explanations in plain English. You can also refer to Wikipedia's List of Mathematical symbols and make sure the symbol is listed there (add it if it isn't).

Links for the high level languages would be good.

[chronaeon]

Thanks for this feedback! I'm going to incorporate your suggestions into the paper.

Is there anything else you wanted to add before I close this issue?

[jamesray1]

You're welcome Micah! Haha, I think I gave a lot of feedback, nothing further comes to mine at this stage.

[jamesray1]

I just want to emphasise that "the current EVM will eventually be replaced and we don’t want you to spend your labor [editing] something that will later be discarded". http://notes.eth.sg/s/rksCgM0Mz#on-verifying-compilers-to-evm

[chronaeon]

@jamesray1 That's an interesting fact that the current EVM will be replaced.

[jamesray1]

Yes, it will probably be replaced with EWASM, which will execute much more efficiently and provide more scalability for Ethereum.

https://github.com/ewasm/design

https://github.com/ewasm/design/blob/master/rationale.md

Yet more info:

https://ethereumnoobs.com/devcon/
https://ethereum.stackexchange.com/questions/25404/the-jit-evm-and-evm-1-5-are-they-different-or-the-same

[jamesray1]

See the ensuing discussion at https://gitter.im/ethereum/yellowpaper?at=5a4ad08e03838b2f2a5d350f to gain a better understanding of why the Yellow paper won't be maintained. In short, it's because of using the KEVM, "the first fully executable formal semantics of the EVM", which is reasonable.