More Thoughts on Scripting and Future-Compatibility

I introduced it in the previous post Ethereum script 2.0 We received a lot of responses, some of them very supportive, others suggesting switching to a stack-based/assembly-based/functional paradigm that they prefer, and others that we’re keen to consider. Some offered a variety of specific criticisms.Perhaps the strongest criticism this time is Sergio Damien Lernera Bitcoin security researcher and developer of QixCoin, and we are grateful for his work. Dagger analysis. Sergio particularly criticizes his two aspects of the change. It’s the fee system that’s changed from a simple one-variable design where everything is a fixed multiple of his BASEFEE, and the loss of the crypto opcode.

Crypto opcodes are a more important part of Sergio’s discussion, so I’ll address that issue first. In Ethereum Script 1.0, an opcode set contained a collection of opcodes specialized for a particular cryptographic function. For example, I had an opcode SHA3 that took the length and starting memory index from the stack and pushed that her SHA3. A string obtained from the required number of blocks in memory starting at the starting index. SHA256 and his RIPEMD160 had similar opcodes, as well as cryptographic opcodes centered around secp256k1 elliptic curve operations. In ES2, these opcodes are gone. Instead, they are replaced with a fluid system where people have to manually write SHA256 into ES (we actually offer commissions or bounties for this), and then the smart interpreter You can seamlessly replace SHA256 ES scripts with plain scripts. An older machine code (or hardware) version of SHA256, the kind he uses when he calls SHA256 in C++. From the outside, ES SHA256 and machine code SHA256 are indistinguishable. Both compute the same function and therefore perform the same transformation on the stack. The only difference is that the latter is hundreds of times faster and gives you the same efficiency as if SHA256 were the opcode. Implementing a flexible pricing system, he could also make SHA256 cheaper as computation time decreases, ideally as cheap as current opcodes.

But Sergio prefers a different approach. This means that it comes with a large amount of crypto opcodes out of the box and will add new opcodes in the future using hard fork changes to the protocol if necessary. he writes:

First, after closely watching Bitcoin for three years, I realized the following: Cryptocurrency is not a protocol, a contract, or a computer network.Cryptocurrency is a community. All but a few constants, such as the money supply function and the world balance of payments, can be changed in the future as long as the changes are announced in advance. Although the Bitcoin protocol has worked well in the past, we know that in the long run it will face scalability issues and will need to change accordingly. Short-term benefits such as the simplicity of the protocol and codebase have helped Bitcoin gain global acceptance and network effects. Is the reference code for Bitcoin version 0.8 as simple as version 0.3? Not at all. Nowadays, there is caching and optimization everywhere for maximum performance and higher DoS security, but no one cares about this (and no one should care) ). Cryptocurrencies are bootstrapped by starting with a simple value proposition that works in the short/medium term.

This is a point often made about Bitcoin. But the more I look at what’s actually happening with Bitcoin development, with the exception of cryptographic protocols that are in their infancy and have very low commercialization, the more I stand firm. The argument is completely false. Bitcoin currently has many flaws that can be changed if we have the collective will. Here are some examples.

  1. 1 MB block size limit. Currently, there is a hard limit that a Bitcoin block cannot contain transactions larger than 1 MB, resulting in an upper limit of approximately 7 transactions per second. By setting each block to around 250 KB, we are already starting to break through this limit and are already putting pressure on transaction fees. For most of Bitcoin’s history, fees have been around $0.01, and each time the price rose, the default BTC denominated fee that miners accepted was lowered. But currently, the fee is fixed at $0.08, and the developer probably hasn’t adjusted it lower because changing the fee back to $0.01 would cause the number of transactions to exceed the 1 MB limit. It’s a simple change to remove this limit, or at least set it to a more reasonable value such as 32 MB. This is just one number in the source code, and it clearly has a huge impact on ensuring that Bitcoin continues to be used in the medium term. Nevertheless, Bitcoin developers are completely failing it.
  2. Bug in OP_CHECKMULTISIG. The OP_CHECKMULTISIG operator used to implement multisig transactions in Bitcoin has a well-known bug that requires an additional dummy zero as an argument, which is simply popped off the stack and used It will not be. This is very unintuitive and confusing. When I was personally working on a multisig implementation, pibitcoin tools, I understand whether a dummy zero should be at the beginning of a 2-of-3 multisig or in place of a missing public key, and whether there should be two dummy zeros. I was stuck for days because of this. 1/3 multisig. I figured it out eventually, but I would have figured it out sooner if the operation of the OP_CHECKMULTISIG operator had been more intuitive. And the bug is still not fixed.
  3. bitcoin client. The bitcoind client is notorious for being a very cumbersome and non-modular device. In fact, the problem is so severe that everyone trying to build a more scalable, enterprise-friendly alternative to Bitcoin is starting from scratch without using Bitcoin at all. This is not a core problem with the protocol, and in theory changes to Bitcoin clients do not require hard fork changes at all, but the necessary reforms have not yet taken place.

All these problems do not exist because Bitcoin developers are incompetent. Not; in fact, they are highly skilled programmers with deep knowledge of cryptography, databases, and networking issues specific to cryptocurrency client design. The problem is that the Bitcoin developers believe that Bitcoin is a $10 billion train hurtling along at 400 kilometers per hour, and if they try to change the engine midway through and even the smallest bolt comes loose, the whole thing is destroyed. This is because I fully understand that there is a possibility of it breaking. It crashes and stops. A simple change to replace the database in March 2011 almost done. For this reason, I think it would be irresponsible to leave a poorly designed and unpromising protocol in place and just say that it can be updated in a timely manner. On the contrary, protocols should be designed with appropriate flexibility from the beginning so that they can be changed automatically by consensus without software updates.

Now, let’s address Sergio’s second issue, his main concern about modifiable fees. If fees can go up or down, it becomes very difficult for a contract to set its own rates. Additionally, unexpected increases in fees can create vulnerabilities such as: An attacker may even be able to force a contract into bankruptcy. I have to thank Sergio for pointing this out. This is an area that I haven’t fully considered yet, so I’d like to think about it carefully when designing. But his solution, manual protocol update, is probably no better. Protocol updates that change the pricing structure could also expose new financial vulnerabilities in the contract, and there are absolutely no restrictions on the content that can be included in a manual protocol update, so it probably won’t make up for it. Even more difficult.

So what can you do? First of all, Sergio’s approach (using a limited fixed set of opcodes that can only be added with hard-forked protocol changes) and the idea I provided in his ES2 blog post of letting miners vote fluidly There are many intermediate solutions between. Change the price per script. One approach is to make the voting system more discrete, so that between scripts that have to pay 100% of the fee and scripts that are “promoted” to opcodes that only have to pay 20x his CRYPTOFEE It’s about setting clear boundaries. This can be done through a combination of usage counts, miner voting, ether holder voting, or other mechanisms. This is essentially a built-in mechanism for performing a hard fork, which technically does not require any source code updates to be applied, making it much more fluid and non-disruptive than a manual hard fork approach. Become. Second, it is important to point out again that the ability to efficiently execute strong cryptography was not lost, even from the Genesis block. When you launch Ethereum, you create SHA256 contracts, SHA3 contracts, etc. and “pre-mine” them into a pseudo-opcode state from the beginning. Therefore, Ethereum comes with a battery. The difference is that the batteries are installed in a way that allows for seamless installation of more batteries in the future.

However, it is important to note that I believe this ability to add efficient and optimized cryptographic operations will be a must in the future. It is theoretically possible to create a “zerocoin” contract within Ethereum, or a contract using cryptographic proof of computation (SCIP) and fully homomorphic encryption. This actually allows you to use Ethereum as a “distributed Amazon EC2 instance” for cloud computing. Now people mistakenly believe that. Once quantum computing arrives, we may need to move to contracts that rely on NTRU. When SHA4 or SHA5 come out, you may need to move to contracts that rely on time Obfuscation technology Once it matures, contracts will rely on it to store private data. But to make all this possible with a fee of less than $30 per transaction, the underlying cryptography would need to be implemented in C++ or machine code, and would require a pricing structure that reduces the fees for the operations. . Once the optimization is complete, make the appropriate adjustments. This is a challenge for which there are no easy answers, and comments and suggestions are welcome.

Related Article


Leave a Comment