Bitslog

Today I read that Ethereum is abandoning a crypto-rich instruction set in favor of a reduced generic instruction set. This shocked me, because I liked Ethereum instruction set design just as it was. The main argument given by VButerin is that this change makes the instruction set  more compatible with future cryptographic algorithms, by preferring none of them. I will explain why, IMHO, this argument is false. Also I will explain how changing the whole scripting language to allow deduplication will delay the Ethereum project 3 months at least.

First, after 3 years of watching Bitcoin closely I came to understand that a cryptocurrency is not a protocol, nor a contract, nor a computer-network. A cryptocurrency is a community. With the exception of a very few set of constants, such as the money supply function and the global balance, anything can be changed in the future, as long as the change is announced in advance. Bitcoin protocol worked well until now, but we know that in the long term it will face scalability issues and it will need to change accordingly. Short term benefits, such as the simplicity of the protocol and the code base, helped the Bitcoin get worldwide acceptance and network effect. Is the reference code of Bitcoin version 0.8 as simple as the 0.3 version? not at all. Now there are caches and optimizations everywhere to achieve maximum performance and higher DoS security, but no one cares about this (and nobody should). A cryptocurrency is bootstrapped by starting with a simple value proposition that works in the short/mid term.

The most interesting ideas that I’ve heard regarding contracts require strong crypto. Having crypto opcodes will help any user with minimum programming skills to create crypto-enabled scritpts and this will give Ethereum a big initial initial kick off. This is a key part of Ethereum value proposition. So removing the crypto opcodes from the instruction will put users in a disadvantageous position, forced to pay very high fees. Since the first implementation of Ethereum will have no JIT, this cost of crypto may become prohibitively high. For example, computing SHA-256 of a single small message will cost no less than 5000 Ehtreteum 2.0 instructions. Coding that in machine level instructions becomes much harder. It forces crypto scripts writers to use a powerful compiler and linker, and trust that the compiler stack has no bugs. But there is still no such compiler and writing a compiler from scratch is a difficult project in itself, and supporting pre-existing libraries (for deduplication) which must be read from the block-chain itself will delay the compiler project 2 months, at least.

So apart from making developer’s life a whole more difficult, and adding a linker layer to the compiler, let’s see what happens with the interpreter itself. Now the interpreter must be able to look up any script ever written. But then the “duplicated” parts must be copied from previous scripts into the new scripts, or some system of reference counting must be used.  If the parts are copied, then a DoS attack can be created by building small scripts that grow into very large ones in memory and may thwart the evaluation of scripts in parallel. Reference counting prevents a contract to use parts of another contract that commits suicide from becoming orphaned. I don’t now how to handle this situation if not with reference counting. If reference counting is used, the VM becomes quite more sophisticated.The instruction set may be more easy to be used for formal checking systems, but the VM becomes much more difficult to keep safe from bugs and vulnerabilities. So I guess the VM will take at least 1 additional month of work.

QixCoin takes quite the opposite design decision: it has library functions for all kinds of hashing algorithms, ECC, number oriented and standard cryptography. Each function consumes a certain amount of base fees. And if all existing crypto functions get broken, then I’m sure there will be plenty of time to add more. Does this make the reference client bigger? Yes, of course, but bigger in a way that does not affect the simplicity of the design. Note that QixCoin instruction set is also small, and the crypto functions are accessed via a simple software interrupt instruction.

Last, the new Ethereum 2.0 idea of voting on fees is awful. If one cannot predict the cost of fees in the future, how can one trust a long-term contract, such as a smart-company?

I hope VButerin rolls back this design change, and sticks to the original 1.0 set.