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), onchain exchange (so that to trade large sums without trust in the exchange), play channels (to quickly redistribute the total escrow between two accounts without an overhead report about a transaction in general to everyone) ... There
ways to add functions: 1) the most obvious is to enter Put them in the code of the blockchain itself, natively.
Blockchain is essentially a replicable website.when you do not have enough features 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 the same idea” ala namecoin. Soon it was noticed that people do not want to use the 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 by means of an 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 by the ether (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 enter 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 github.com/raiden-network/raiden-contracts/tree/master/raiden_contracts/contracts- thousands of lines of code, in the raw alien language (solidity), to manage a complex financial system. We have seen several parity hacks 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. Key iteration, many-to-many? ORM? None of this inside the contract exists. Tuling is also very weak relative to known programming languages.
In defense of EVM, I’ll still say - the picture in the world of Bitcoin is even sadder because 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 a two-way channel play on bitcoin is so crazy that it is even more difficult to maintain 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 to 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 hardforced 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 a failure - we alreadywe have an authority that dictates how the consensus layer (the githab account of the etherium) 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 (67% or 95% treshold configured inside the network itself)
2. Validators can use this force to push through such patches that directly benefit them (remove the unwanted user, allow themselves assets from three boxes) . To solve this problem, there is a period. After the patch is approved, 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 itit is already working this way - the gitkhab of the etereum can offer absolutely any hardfork and it is already the task of users to reset 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.
Thus, we found out that EVM smart contracts are 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.