1.  

  2. While the author has some good points, it’s trashing an MVP inspired off Bitcoin. A lot of projects claim to be technically better than Ethereum, which may be true. But Ethereum established blockchain-market fit first. It’s MUCH easier to identify faults of an existing system and then improve it rather than building a perfect one first time round.

    1. Author here. I would encourage everyone to not take technical criticisms as “trashing” the EVM, as much as it is a retrospective of the things we must improve upon in order to progress the EVM. While EWASM makes some strides towards fixing some of these, there are others that the working group had not thought of, and this post has provided valuable feedback to the group so that they can continue to improve the machine. Just because it was not done correctly on first pass, does not mean it is not subject to technical criticism on the basis of its merits.

      It is true that the EVM was inspired by Bitcoin, but inspiration only insofar as the notion of a VM and a bytecode language. In fact, the EVM crew took the Bitcoin design and seemingly said “lets not do what they did” in many aspects of their original design principles, which echo through the architectural concerns we now face while scaling.

      1. Thanks for this article and for your elaboration on it, I found it super valuable and interesting.

      2. Perfect first-pass is never possible, but I’m of the opinion that small and safe first, then bigger and badder as it’s shown possible/tractable is best.

        I was actually chatting with Emily about the broader topic – iterative migration of an existing live system to a later version, and the perils from a security POV that entails – and she pointed me to a programming language theory problem I was unaware of: https://en.wikipedia.org/wiki/Expression_problem

        The goal is to define a datatype by cases, where one can add new cases to the datatype and new functions over the datatype, without recompiling existing code, and while retaining static type safety (e.g., no casts).

        It lays out the known solutions to iterative updates to a language without impacting the security of the existing code (e.g. when Parity multi-sig happened, there was some discussion of remove the suicide opcode from the EVM which ended with a discussion of we’re not sure what that would do to existing programs).

        Overall, I’m unsure if it’s even possible to iterate on the fundamental EVM design because:

        • we can’t migrate the bytecode to a new machine (unprovable/knowable security implications)

        • we can’t re-compile existing contracts to a new machine (source code isn’t public for all contracts)

        • we can’t slowly update the VM in non-trivial ways (e.g. more than precompiled contracts) because it would change the security in unknowable ways

        • we can put a new VM next to the old one (e.g. eWASM) but either it is a new machine and people need to migrate manually from one to the other (e.g. python 2 vs 3 problem, but now python 2 represents a multi-billion market cap so migration is harder to make happen) -or- have the new VM be a reimplementation of the old so its a little safer but not big leap forward (e.g. what eWASM is doing now)

        Anyway, just my 2c.

      3. An in-depth examination of the Ethereum Virtual Machine vs. Kadena’s Pact smart contract language.