Changes in Ethereum scripting language

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.

It would be great if this crypto library would come pre-built with the client at launch of the coin. But this will delay the launch, and currently the cryptocoin ecosystem is very competitive: time is money. I hope they can launch it during 2014.

I have added a script instruction to my experimental build – it loads the block height onto the top of the stack, and that’s useful for many protocols. It’s the first of several additions. I cannot imagine any utility in removing crypto-oriented instructions. In fact I’ve been considering adding more. The decision you cite shows pretty clearly that the Ethereum devs are not getting it about scripts. But then, with its very narrow view of what is allowed in a standard transaction, Bitcoin has certainly not been reminding them about how useful scripts can be.

I’ve been considering, even, making script instructions 16 rather than 8 bits wide. Then you could take the thousand or so most useful scripts, package them in a GUI as transaction types, and assign them to one instruction each (plus data). It would be overkill, but it would be a net win in terms of tx size.