My latest post introducing Ethereum 2.0 scripting got a lot of replies, some very encouraging, others pointing to their own stack-based/assembly-based/functional paradigm and making some specific criticisms which we’re taking seriously. The most vocal criticism came from Sergio Damian Lerner, a Bitcoin Security specialist and developer of QixCoin, for which we are grateful for his dagger analysis. The author explicitly called out two aspects of the change: the fee system (which is now a complicated one-variable structure with everything being a fixed multiple on BASEFEE) and the missing cryptographic opcodes.
Cryptographic opcodes are the main point of Sergio’s argument, and it’s the one we need to address first. With Ethereum Script 1.0, the opcode collection had a number of opcodes that specialized in certain cryptographic functions. For example, a SHA3 opcode would take a length, a starting memory index and then push the SHA3 hash from the string to the specified number of blocks in the memory, starting at the initial index. There were also similar opcodes for SHA256 & RIPEMD160. There were also cryptographic opcodes designed for secp256k1 elliptic curve operations. In ES2, these opcodes are gone. Instead, they are replaced by a fluid, where users need to manually write SHA256 into ES. In practice, this can be rewarded with a fee or reward. Clever interpreters can later replace the SHA256 with a plain old (or even hardware) version of SHA256. From the outside, ES SHA256 can be distinguished from SHA256. They both calculate the same function and thus perform the same transformations on stacks. However, SHA256 is hundreds of times faster and gives us the same efficiency level as SHA256. Flexible fee systems can also be implemented to make SHA256 more affordable to account for its slower computation time. Ideally, it should be as cheap as an opcode.
Sergio, however, prefers a different approach. He writes:
After observing Bitcoin for three years, I came to the conclusion that a cryptocurrency is neither a protocol nor a contract nor a computer network. A cryptocurrency is a network.. With the exception of a few constants such as the money supply function, and the overall balance, everything is possible to change in the future, provided that the change is made in advance. The Bitcoin Protocol has been successful so far. However, we know it will have scaling issues in the long-term and will need to be modified accordingly. Long-term benefits like the simplicity of the protocol or the code base will be accepted worldwide and have a network effect. The Bitcoin Version 0.8 reference code is as simple as version 0. Not all of them. While there are many optimizations and caches that can be used to increase performance and DoS security, no one really cares. To start a cryptocurrency, you need a simple value proposition. This should work in the short and medium term.
This is an important point often raised in relation to Bitcoin. The more I see the actual development of the industry, the more I realize how true this statement is. The more I believe in the argument, the more solid it becomes. Currently, there are many flaws to this system. All of which can be changed if we have the collective will. Here are some examples:
- The 1 MB Block Limit. There is a limit to how much you can spend on a given item. A Bitcoin block cannot have more than 1MB transactions. There is a limit of seven transactions per minute. This limit is being pushed to the limit with approximately 250KB per block. It already puts pressure on transaction fees. Most of Bitcoin’s past, fees were around $0.01 and the default BTC-denominated fee accepted by miners was adjusted downward every time the price rose. Right now, the fee is $0.08. Developers are not going to adjust it. A $0.01 fee would increase transaction volume to close to 1MB. Removing this limit, or at the very least, setting it at 32MB, is trivial; it’s just one number in the source code. And it would certainly be very useful at ensuring that Bitcoin will continue to be used in the medium-term. Yet, Bitcoin developers have completely failed to do this.
- The OP_CHECKMULTISIG Bug. There is a bug in OP_CHECKMULTISIG which is commonly used to implement multisig transactions in Bitcoin, which requires an additional zero dummy argument. This argument is just popped off the stack and not used.
