Smart updates against smart contracts

What is a smart contract and why was it needed?

Long ago, after the appearance of Bitcoin - the first replicable state machine - people began to notice that the functionality inherent in the consensus is too limited. I’m not talking now about adding cryptotocats trade, but about real real use cases - DNS where each domain belongs to a public key and not a centralized registrar, all sorts of tokens and financial derivatives (because you want to own shares as you own Bitcoin), you need to exchange (to trade large sums without trust in the exchange), play channels (quickly redistribute the total escrow between two accounts without an overhead of the transaction message to everyone) ...

There were three outputs for adding functions:

1) the most obvious is to enter them in the code of the blockchain itself, natively.
')
Blockchain is essentially a replicable website , when you do not have enough functions on the website, what are you doing? Just add it, directly to the code as a new model or controller . But in the case of a decentralized network, there is no process for such a change of models / controllers - after all, it can be used to its own advantage. Only hardforka option, where all at the same time agree on chat rooms / forums.

2) create another blockchain with this functionality.

So it happened with several “blockchains of one idea” ala namecoin. It was soon noticed that people do not want to use a new network for the sake of one function, interoperability is also needed, and many things depend on each other (loans, identity and assets themselves want to live in the same address space)

3) implement the functions of the internal virtual machine and opcodes.

Even in Bitcoin Satoshi laid Script precisely because of the problem of updates, which allowed to do a lot, but it was not enough. Therefore, an extended script was proposed (now turing complete) and supposedly you can do anything with it (in theory).


So, the code executed by the virtual machine inside the blockchain is called a smart contract, and it is needed to implement new functions. You can call it a “patch on opcodes”, but it’s not selling so well anymore :)

What is a smart update?

Looking back over the past couple of years of smart contracts, one can clearly say that they did not meet the expectations. Yes, the ICO boom was not possible on Bitcoin, but it was also a brute force to introduce advanced EVM just for the sake of erc20 tokens.

It is extremely difficult to write even a small “patch” on solidity. At the bottom level, you will find a raw VM which has very few opcodes (by design) and a simple key-value database. All operations are extremely expensive (gas cost) and you do not turn around from the word at all.

Complicated user cases are almost impossible. Look at Ryden at github.com/raiden-network/raiden-contracts/tree/master/raiden_contracts/contracts - thousands of lines of code, in a raw alien language (solidity), to manage a complex financial system. We have seen several attacks of parity and DAO using simple attacks, what attacks are waiting for us on such a monstrous code base?

There is no SQL database, NoSQL is not present, the graph database is also not planned. Iteration over keys, many-to-many? ORM? None of this inside the contract exists. Tuling is also very weak relative to known programming languages.

95% of the work of the modern solidity project is exactly the fight against solidity and not the architecture of the code. The same idea can be implemented in javascript ten times faster and more reliably, simply because we know and can write javascript, and the solidity ecosystem is not much further than the brainfuck language ecosystem.

In defense of EVM, I’ll still say - the picture in the world of Bitcoin is even sadder since their tuling is even weaker and the opcodes are even smaller . The developers of Lightning are pricking but continue to eat the cactus - the complexity of the two-way paymen channel on Bitcoin is so crazy that it is even harder to maintain the codebase, and convenient things like Sprites and complex logic inside the state channel are simply impossible.

Onchain governance = Smart Updates

Having gorged on grief with solidity, let's go back to 2012 and recall the discarded first version with the addition of user cases natively in the blockchain.


As many have noticed, after the implementation of EVM, EVM itself did not cease to be updated as it was supposed to (the basic level never changes, the whole new code is only inside EVM) - on the contrary, it is regularly hard forked by the dictatorship of ethereum.

Those. same eggs only in profile. A group of people personally decides how to change the onchain layer, puts the code on the github, and all users have nothing left to do but download the new code. “Hardfork is scheduled for Friday, update immediately,” they tell us.

In this form, the idea of ​​smart contracts is absolutely disastrous - we already have a authority that dictates how the consensus layer (the githab account of the ethereum) works, what for us is an extra and inefficient abstraction if we could not get rid of the updates of the main layer?

Since we can’t get rid of the updates, let's at least figure out how to update this main layer for us in the most decentralized way?

We can offer patches to the software right inside the blockchain, validators can vote for them, and the winning patches are simply implemented for everyone synchronously after a certain period. This idea of ​​“onchain governance” was in the air for quite some time, but it was first described, if I am not mistaken, by Tezos. What mesos were overlooked is onchain control, a direct competitor to smart contracts (so I call it smart updates).

If you have smart updates, you simply do not need smart contracts. Any user case can be implemented faster, more qualitatively, with any database to your taste (SQL / NoSQL / whatever), in any programming language (you execute the code already at the machine level, and nothing is limited). Full freedom, minus those same 95% of the overhead project that you spend on solidity, and we do not need to sculpt a new blockchain as in solution # 2.

There are exactly two minuses in smart updates

1. Now, not every user case will be approved by validators, since they think and vote what kind of patch will be useful for the network (and cut off the malicious backdoors). Things like cryptococcus are unlikely to ever be approved by the majority (treshold in 67% or 95%, configurable within the network itself)

2. Validators can use this force to push through such patches that are directly beneficial to them (remove the unwanted user, pick up assets from three boxes). To solve this problem, there is a period. After approval of the patch, the entire network has 2-6 weeks to study. If ordinary users do not like it, people should get together, make a hard fork and replace the set of validators with more adequate ones (or throw out the worst characters).

It sounds scary, but it already works that way right now - a gitkhab of an etereum can offer absolutely any hard forks, and this is the task of users to throw off the dictatorship if they don’t like something. No worse. We simply formalize this process and give transparent steaks to each developer / validator, instead of the existing “shadow” government with the first channel in the form of a githab repository.

Total

Thus, we found out that EVM smart contracts is an interesting concept that turned out to be a feil, a too heavy “not there” turn, when all that was needed was to implement a transparent mechanism for smart updates to solve the problem of new yuzkeys.

Smart updates are the future, and almost all the blockchains now in development include them from the very beginning (tezos, dfinity, polkadot, decred, tendermint, fairlayer, etc). Even within the smart contracts themselves, they are now trying to turn on the update mechanism inside themselves, realizing that the concept of set-in-stone does not work, and it will have to be updated sooner or later .

Here is a more detailed wiki on this topic (in English I am fond of how Vitalik and Vlad Zamfir are trying to tarnish smart updates , their direct competitor making EVM completely obsolete.