Smart updates vs. smart contracts

What is a smart contract and why was it needed?

Long ago, after the emergence of bitcoin — the first replicated state machine — people began to notice that the functionality inherent in the consensus was too limited. I’m not talking about adding crypto cat trading, but about quite real use cases, i.e. DNS where each domain belongs to a public key and not to a centralized registrar, as well as all kinds of tokens and financial derivatives (after all, you want to own stocks just as you own bitcoin), on-chain exchangers (to trade large amounts without trusting the exchanger), payment channels (to quickly redistribute a common escrow between two accounts without overhead messaging about the transaction to everyone)…

There were three ways of adding functions:

1. The most obvious one was to write them into the code of the blockchain itself, natively. A blockchain is essentially a replicated website. What do you do when your website lacks functions? You just add them, right to the code, in the form of a new model or controller. But in the case of a decentralized web, there is no process for such a model/controller change since it can be used to your advantage. Only a hard fork, where everyone simultaneously agrees on chats/forums, is possible.
2. Create another blockchain with this functionality. This is what happened to several “blockchains of one idea” ala namecoin. It was soon noticed that people did not want to use a new network for the sake of one function, interoperability was also needed, and a lot of things depended on each other (credits, identities and assets want to exist in the same address space).
3. Implement functions using an internal virtual machine and opcodes. Satoshi added his Script to Bitcoin precisely because of the problem of updates. The script made it possible to do a lot, but it was not enough. Therefore, an extended script (now turing complete) was proposed by Ethereum. Allegedly, this script can help you do whatever you want (in theory).

So, a code executed by a virtual machine inside a blockchain is a smart contract, and it is needed to implement new functions. You can call it an “opcode patch”, but in this case, it wouldn’t be selling so well :)

What is a smart update?

Looking back over the last couple of years, we can clearly say that smart contracts did not meet expectations. Yes, the ICO boom was impossible with bitcoin, but introducing an advanced EVM just to get erc20 tokens was too much.

It is extremely difficult to write even a small “patch” in solidity. At the bottom level, you will find a raw VM that has very few opcodes (by design) and a simple key-value database. All operations are extremely expensive (gas cost), and you don’t get much chance here.

Complex use cases are almost impossible. Have a look at Raiden — thousands of code lines, in a raw alien language (solidity), to manage a complex financial system. We have seen several hacks of parity and DAO using simple attacks. What attacks are going to be used for such a monstrous codebase?

There is no SQL database, no NoSQL database, no graph database is planned either. What about key iteration, many-to-many? ORM? None of this exists within the contract. The tooling is also very weak relative to well-known programming languages.

95% of the work of a modern solidity project is a fight against solidity instead of the code architecture. The same idea can be implemented in javascript ten times faster and more reliable just because we know how to write a javascript and can do it, while the solidity ecosystem has gone no further than the brainfuck ecosystem.

In defense of EVM, the picture in the world of bitcoin is even sadder since their tooling is even weaker and there are even fewer opcodes. The Lightning developers are not going to give up — the complexity of a two-way payment channel of bitcoin is extremely high, and it is even more difficult to maintain a code base. What’s more, conveniences like Sprites and complex logic within a state channel are simply impossible.

On-chain governance = Smart Updates

After so much grief with solidity, let’s go back to 2012 and remember the rejected first option which involved adding use cases natively to blockchain.

As many have noticed, after the implementation of EVM, the EVM itself did not stop updating as expected (the base level never changes, all the new code is inside the EVM) — on the contrary, it is regularly hardforked by the dictatorship of Ethereum.

This means nothing has changed. A group of people decides how to change the on-chain layer, uploads a code to GitHub, and all users have no choice but to download the new code. “The hard fork is scheduled for Friday. Please update immediately,” they say to us.

In this form, the idea of ​​smart contracts is doomed to fail — we already have authority that dictates how the consensus layer (Ethereum GitHub account) works. Why do we need an extra and ineffective abstraction if we couldn’t get rid of updating the main layer?

Since we can’t get rid of updates, let’s at least figure out how to update this main layer in the most decentralised manner?

We can offer patches to software right inside a blockchain, validators will vote for them, and winning patches will simply be implemented synchronously for everyone after some period. This idea of on-chain governance has been in the air for quite a long time, but Tezos was the first to describe it if I’m not mistaken. What Tezos missed is that on-chain governance is a direct competitor to smart contracts (that’s why I call it smart updates).

If you have smart updates, you don’t need smart contracts. Any use case can be implemented faster, with better quality, with any database you choose (SQL/NoSQL/whatever), and in any programming language (you execute the code at the machine level and are not limited by anything). Complete freedom, minus the 95% overhead that you used to spend on solidity, and you do not need to build a new blockchain as in solution #2.

Smart updates have only two drawbacks

1. Not every use case will be approved by validators, since they think and decide what kind of patch will be useful for the network (and reject obviously malicious backdoors). Things like crypto kitties are unlikely to ever be approved by the majority (67% or 95% threshold, configurable within the network).
2. Validators may use their power to promote the patches from which they can directly benefit (remove an unwanted user, or release a number of assets for themselves). There is a delay period to solve this problem. Once a patch is approved, the entire network has 2–6 weeks for exploration. If ordinary users don’t like it, people should get together, make a hard fork, and replace the validators with more adequate ones (or remove “villains”).

It sounds scary, but it already works like that — the GitHub of Ethereum can offer almost any hard fork, and it is the task of users to reset the dictatorship if they don’t like something. It won’t get any worse. We just formalize this process and provide clear stakes for each developer/validator, instead of the existing shadow government with the first channel in the form of a GitHub repository.

Conclusion

Thus, we have found out that EVM smart contracts are an interesting concept that turned out to be a fail, a too heavy “wrong turn” when all that was required was to implement a transparent mechanism for smart updates to solve the problem of new use cases.

Smart updates are the future, and almost all blockchains that are currently being developed include them from the very beginning (tezos, dfinity, polkadot, decred, tendermint, fairlayer, etc). Even smart contracts are now trying to include an update mechanism, having realized that the set-in-stone concept does not work, and sooner or later they will have to somehow update.