Mises à jour intelligentes vs contrats intelligents

Qu'est-ce qu'un contrat intelligent et pourquoi était-il nécessaire?

Il y a longtemps, après l'apparition de Bitcoin - la première machine d'état répliquée - les gens ont commencé à remarquer que la fonctionnalité incarnée dans le consensus était trop limitée. Je ne parle pas d'ajouter des cryptocodes au trading, mais des cas d'utilisation réels - DNS où chaque domaine appartient à une clé publique et non à un registraire centralisé, toutes sortes de jetons et dérivés financiers (parce que vous voulez posséder des actions de la même manière que vous possédez du bitcoin), des échanges en chaîne (pour négocier de gros montants sans avoir confiance dans l'échange), les canaux de paiement (redistribuer rapidement le séquestre général entre deux comptes sans frais généraux de message de transaction en général) ...

Il y avait trois façons d'ajouter des fonctions:

1) le plus évident est de les saisir nativement dans le code de la blockchain elle-même.

La blockchain est essentiellement un site Web répliqué , lorsque vous n'avez pas suffisamment de fonctions sur le site Web, que faites-vous? Ajoutez-le directement au code en tant que nouveau modèle ou contrôleur . Mais dans le cas d'un réseau décentralisé, il n'y a pas de processus pour un tel changement de modèles / contrôleurs - après tout, il peut être utilisé à leur avantage. Seule une option hard fork, où tout le monde s'accorde en même temps sur les chats / forums.

2) créez une autre blockchain avec cette fonctionnalité.

C'est donc arrivé avec plusieurs "blockchains d'une même idée" ala namecoin. On a rapidement remarqué que les gens ne veulent pas utiliser le nouveau réseau pour une fonction, ils ont également besoin d'interopérabilité et beaucoup de choses dépendent les unes des autres (les prêts, les identités et les actifs veulent eux-mêmes vivre dans le même espace d'adressage)

3) implémenter des fonctions à l'aide de la machine virtuelle interne et des opcodes.

Même Satoshi a posé Script dans Bitcoin précisément à cause du problème de mise à jour, ce qui a permis d'en faire beaucoup, mais ce n'était pas suffisant. Par conséquent, un script étendu a été proposé par ether (maintenant terminé), et vous pouvez prétendument faire n'importe quoi avec lui (en théorie).


C'est donc le code exécuté par la machine virtuelle à l'intérieur de la blockchain qui est appelé le contrat intelligent, et il est nécessaire pour implémenter de nouvelles fonctions. Vous pouvez l'appeler un «patch opcode», mais il ne se vend pas si bien :)

Qu'est-ce qu'une mise à jour intelligente?

En ce qui concerne les contrats intelligents au cours des deux dernières années, nous pouvons clairement dire qu'ils n'ont pas répondu aux attentes. Oui, le boom de l'ICO n'était pas possible sur le bitcoin, mais introduire un EVM avancé uniquement pour les jetons erc20 était trop.

Ecrire même un petit «patch» de solidité est extrêmement difficile. Au niveau inférieur, vous trouverez une machine virtuelle brute qui a très peu d'opcodes (par conception) et une base de données clé-valeur simple. Toutes les opérations sont extrêmement coûteuses (coût du gaz) et vous ne pouvez pas vous retourner du tout.

Les cas d'utilisateurs sophistiqués sont presque impossibles. Jetez un œil à github.com/raiden-network/raiden-contracts/tree/master/raiden_contracts/contracts - des milliers de lignes de code, en langage étranger brut (solidité), pour gérer un système financier complexe. Nous avons vu plusieurs hacks de parité et DAO avec de simples attaques, quel genre d'attaques nous attendent sur une base de code aussi monstrueuse?

Il n'y a pas de base de données SQL, NoSQL n'est pas présent, la base de données graphique n'est pas non plus prévue. Itération clé, plusieurs à plusieurs? ORM? Rien de tout cela n'existe dans le contrat. L'outillage est également très faible par rapport aux langages de programmation bien connus.

95% du travail d'un projet de solidité moderne est précisément la lutte contre la solidité et non l'architecture de code. La même idée peut être implémentée en javascript dix fois plus vite et plus fiable, tout simplement parce que nous savons et pouvons écrire javascript et que l'écosystème solidity n'est pas allé beaucoup plus loin que l'écosystème brainfuck.

Pour défendre EVM, je dirai toujours - l'image dans le monde du bitcoin est encore plus triste car leur réglage est encore plus faible et les opcodes sont encore plus petits . Les développeurs de Lightning mordent mais ont toujours un cactus - la complexité d'un canal bitcoin bidirectionnel sur Bitcoin est si folle que maintenir la base de code est encore plus difficile, et des choses pratiques comme les Sprites et la logique complexe à l'intérieur du canal d'état sont tout simplement impossibles.

Gouvernance Onchain = Smart Updates

Après en avoir marre du chagrin avec solidité, revenons à 2012 et rappelons la première option rejetée avec l'ajout de cas d'utilisateurs natifs à la blockchain.


Comme beaucoup l'ont remarqué, après la mise en œuvre d'EVM, EVM lui-même n'a pas cessé de mettre à jour comme il était censé le faire (le niveau de base ne change jamais, le nouveau code entier n'est qu'à l'intérieur d'EVM) - au contraire, il forge régulièrement avec la dictature de l'éthereum.

C'est-à-dire les mêmes œufs que de profil. Un groupe de personnes décide comment changer la couche onchain de ses propres mains, place le code sur un github et tous les utilisateurs n'ont d'autre choix que de télécharger un nouveau code. "Le hard fork est prévu pour vendredi, mise à niveau immédiate", nous disent-ils.

Sous cette forme, l'idée de contrats intelligents est absolument un échec - nous avons déjà une autorité qui dicte le fonctionnement de la couche de consensus (compte github d'Ethereum), à quoi sert une abstraction supplémentaire et inefficace si nous ne pouvions pas nous débarrasser des mises à jour de la couche principale?

Puisque nous ne pouvons pas nous débarrasser des mises à jour, essayons au moins de savoir comment mettre à jour cette couche principale pour nous de la manière la plus décentralisée possible?

Nous pouvons offrir des correctifs logiciels directement à l'intérieur de la blockchain, les validateurs peuvent voter pour eux et les correctifs gagnants sont simplement mis en œuvre de manière synchrone pour tout le monde après une certaine période. Cette idée de «gouvernance onchain» est dans l'air depuis un certain temps, mais Tezos a été la première à la décrire, si je ne me trompe pas. Ce que les tezos ont perdu de vue, c'est que la gouvernance onchain est un concurrent direct des contrats intelligents (c'est pourquoi j'appelle cela des mises à jour intelligentes).

Si vous disposez de mises à jour intelligentes, vous n'avez tout simplement pas besoin de contrats intelligents. Tout cas d'utilisateur peut être implémenté plus rapidement, mieux, avec n'importe quelle base de données de votre choix (SQL / NoSQL / quoi que ce soit), dans n'importe quel langage de programmation (vous exécutez le code déjà au niveau de la machine et ne vous limitez à rien). Liberté totale, moins les 95% de frais généraux que vous avez dépensés pour la solidité, et nous n'avons pas besoin de sculpter une nouvelle blockchain comme solution # 2.

Il y a exactement deux inconvénients pour les mises à jour intelligentes

1. Maintenant, tous les cas d'utilisateurs ne seront pas approuvés par les validateurs, car ils pensent et votent quel type de correctif sera utile pour le réseau (et coupent les portes dérobées franchement malveillantes). Des choses comme les crypto-monnaies ne seront probablement jamais approuvées par la majorité (un thrashold de 67% ou 95%, configuré à l'intérieur du réseau lui-même)

2. Les validateurs peuvent utiliser cette force pour passer à travers les correctifs qui leur sont directement bénéfiques (supprimer un utilisateur répréhensible, se permettre d'obtenir des actifs à partir de trois cases). Pour résoudre ce problème, il existe un délai. Une fois le patch approuvé, l'ensemble du réseau dispose de 2 à 6 semaines pour étudier. Si les utilisateurs ordinaires ne l'aiment pas, les gens devraient se réunir, faire un hard fork et remplacer l'ensemble de validateurs par des plus adéquats (ou jeter les pires personnages).

Cela semble effrayant, mais cela fonctionne déjà comme ça - athereum github peut offrir absolument n'importe quelle fourche dure et c'est la tâche des utilisateurs de réinitialiser la dictature s'ils n'aiment pas quelque chose. Cela ne va pas empirer. Nous formalisons simplement ce processus et donnons des steaks transparents à chaque développeur / validateur, au lieu du gouvernement «fantôme» existant avec le premier canal sous la forme d'un référentiel github.

Résumé

Ainsi, nous avons découvert que les contrats intelligents EVM sont un concept intéressant qui s'est avéré être un échec, un virage trop lourd dans la mauvaise direction, alors qu'il suffisait de mettre en œuvre un mécanisme transparent pour les mises à jour intelligentes afin de résoudre le problème des nouveaux cas d'utilisateurs.

L'avenir est aux mises à jour intelligentes, et presque toutes les chaînes de blocs qui sont actuellement en développement les incluent dès le début (tezos, dfinity, polkadot, decred, tendermint, fairlayer, etc.). Même dans les contrats intelligents eux-mêmes, ils essaient maintenant d'activer le mécanisme de mise à jour en eux-mêmes, se rendant compte que le concept de set-in-stone ne fonctionne pas, et d'une manière ou d'une autre, il faudra tôt ou tard mettre à jour .

Voici un wiki plus détaillé sur ce sujet (en anglais. Je suis étonné de voir comment Vitalik et Vlad Zamfir essaient de dénigrer les mises à jour intelligentes , leur concurrent direct rendant EVM complètement obsolète.