Intelligente Updates im Vergleich zu intelligenten Verträgen

Was ist ein intelligenter Vertrag und warum wurde er benötigt?

Vor langer Zeit, nach dem Erscheinen von Bitcoin - der ersten replizierten Zustandsmaschine - bemerkten die Leute, dass die im Konsens verkörperte Funktionalität zu begrenzt ist. Ich spreche nicht über das Hinzufügen von Kryptocots zum Handel, sondern über ganz reale Benutzerfälle - DNS, bei dem jede Domain zu einem öffentlichen Schlüssel und nicht zu einem zentralen Registrar gehört, alle Arten von Token und Finanzderivaten (weil Sie Aktien genauso besitzen möchten, wie Sie Bitcoin besitzen), Onchain-Börsen (zu Handel in großen Mengen ohne Vertrauen in die Börse), Zahlungskanäle (schnelles Umverteilen der allgemeinen Übertragungsurkunde zwischen zwei Konten ohne Overhead einer Transaktionsnachricht im Allgemeinen) ...

Es gab drei Möglichkeiten, Funktionen hinzuzufügen:

1) Am naheliegendsten ist es, sie nativ in den Code der Blockchain selbst einzugeben.

Blockchain ist im Wesentlichen eine replizierte Website . Wenn Sie nicht genügend Funktionen auf der Website haben, was tun Sie dann? Fügen Sie es einfach als neues Modell oder Controller direkt zum Code hinzu . Bei einem dezentralen Netzwerk gibt es jedoch keinen Prozess für einen solchen Modell- / Steuerungswechsel - schließlich kann er zu ihrem Vorteil genutzt werden. Nur eine Hard-Fork-Option, bei der sich alle gleichzeitig auf Chats / Foren einigen.

2) Erstellen Sie eine weitere Blockchain mit dieser Funktionalität.

So geschah es mit mehreren „Blockchains einer Idee“, ala Namecoin. Es wurde schnell bemerkt, dass Menschen das neue Netzwerk nicht für eine Funktion nutzen möchten, sondern auch Interoperabilität benötigen und viele Dinge voneinander abhängen (Kredite, Identitäten und Vermögenswerte selbst möchten im selben Adressraum leben).

3) Implementieren von Funktionen unter Verwendung der internen virtuellen Maschine und der Opcodes.

Sogar Satoshi legte Script in Bitcoin genau wegen des Update-Problems, das viel erlaubte, aber es war nicht genug. Daher wurde von ether ein erweitertes Skript vorgeschlagen (das jetzt vollständig ist), und Sie können angeblich alles damit machen (theoretisch).


Es ist also der Code, der von der virtuellen Maschine in der Blockchain ausgeführt wird und als Smart Contract bezeichnet wird. Er wird benötigt, um neue Funktionen zu implementieren. Sie können es als "Opcode-Patch" bezeichnen, aber es verkauft sich nicht so gut :)

Was ist ein intelligentes Update?

Wenn wir uns in den letzten Jahren intelligenten Verträgen zuwenden, können wir klar sagen, dass sie nicht den Erwartungen entsprachen. Ja, der ICO-Boom war mit Bitcoin nicht möglich, aber die Einführung eines fortschrittlichen EVM nur für erc20-Token war zu viel.

Es ist äußerst schwierig, auch nur einen kleinen „Patch“ in Solidität zu schreiben. Auf der unteren Ebene finden Sie eine unformatierte VM mit sehr wenigen Opcodes (von Entwurf) und einer einfachen Schlüsselwertdatenbank. Alle Operationen sind extrem teuer (Gaskosten) und Sie können sich überhaupt nicht umdrehen.

Anspruchsvolle Anwenderfälle sind nahezu unmöglich. Werfen Sie einen Blick auf github.com/raiden-network/raiden-contracts/tree/master/raiden_contracts/contracts - Tausende von Codezeilen in der fremden Sprache (Solidität), um ein komplexes Finanzsystem zu verwalten. Wir haben mehrere Hacks von Parität und DAO mit einfachen Angriffen gesehen. Welche Art von Angriffen erwarten uns auf solch einer monströsen Codebasis?

Es gibt keine SQL-Datenbank, NoSQL ist nicht vorhanden, die Diagrammdatenbank ist ebenfalls nicht geplant. Schlüsseliteration, viele zu viele? ORM? Nichts davon ist vertraglich geregelt. Das Werkzeug ist auch im Vergleich zu bekannten Programmiersprachen sehr schwach.

95% der Arbeit eines modernen Soliditätsprojekts ist genau der Kampf gegen die Solidität und nicht die Architektur des Codes. Dieselbe Idee kann zehnmal schneller und zuverlässiger in Javascript implementiert werden, einfach weil wir Javascript kennen und schreiben können und das Soliditäts-Ökosystem nicht viel weiter gegangen ist als das Brainfuck-Ökosystem.

Zur Verteidigung von EVM sage ich immer noch: Das Bild in der Welt von Bitcoin ist noch trauriger, weil ihre Abstimmung noch schwächer und die Opcodes noch kleiner sind . Blitzentwickler beißen, haben aber immer noch einen Kaktus - die Komplexität eines Zwei-Wege-Bitcoin-Kanals auf Bitcoin ist so verrückt, dass die Pflege der Codebasis noch schwieriger ist und praktische Dinge wie Sprites und komplexe Logik innerhalb des Statuskanals einfach unmöglich sind.

Onchain Governance = Intelligente Updates

Nachdem wir die Trauer mit der Solidität satt haben, gehen wir zurück zu 2012 und erinnern uns an die verworfene erste Option, bei der Benutzerfälle nativ zur Blockchain hinzugefügt wurden.


Wie viele bemerkt haben, hat EVM nach der Implementierung von EVM selbst nicht aufgehört zu aktualisieren, wie es sollte (die Basisebene ändert sich nie, der gesamte neue Code befindet sich nur innerhalb von EVM) - im Gegenteil, es gibt regelmäßig die Diktatur des Ätherums.

Das heißt, die gleichen Eier nur im Profil. Eine Gruppe von Personen entscheidet, wie die Onchain-Ebene mit ihren eigenen Händen geändert werden soll, legt den Code auf einen Github und alle Benutzer haben keine andere Wahl, als einen neuen Code herunterzuladen. "Hard Fork ist für Freitag geplant, Upgrade sofort", sagen sie uns.

In dieser Form ist die Idee von intelligenten Verträgen absolut ein Misserfolg - wir haben bereits Autorität, die vorschreibt, wie die Konsensschicht (Github-Konto von Ethereum) funktioniert. Wofür ist eine zusätzliche und ineffektive Abstraktion, wenn wir Aktualisierungen der Hauptschicht nicht loswerden könnten?

Da wir Updates nicht loswerden können, wollen wir zumindest herausfinden, wie wir diese Hauptebene so dezentral wie möglich für uns aktualisieren können.

Wir können Software-Patches direkt in der Blockchain anbieten, Validatoren können für sie stimmen und Gewinner-Patches werden nach einiger Zeit einfach für alle synchron implementiert. Diese Idee der „Onchain Governance“ ist schon seit einiger Zeit in der Luft, aber Tezos hat sie als erster beschrieben, wenn ich mich nicht irre. Was die Tezos aus den Augen verloren haben, ist, dass Onchain Governance ein direkter Konkurrent zu intelligenten Verträgen ist (deshalb nenne ich es intelligente Updates).

Wenn Sie über intelligente Updates verfügen, benötigen Sie einfach keine intelligenten Verträge. Jeder Benutzerfall kann schneller und besser mit jeder Datenbank Ihrer Wahl (SQL / NoSQL / was auch immer) in jeder Programmiersprache implementiert werden (Sie führen den Code bereits auf Maschinenebene aus und sind auf nichts beschränkt). Völlige Freiheit, abzüglich des 95% igen Overheads, den Sie für Solidität aufgewendet haben, und wir müssen keine neue Blockchain als Lösung Nr. 2 formen.

Es gibt genau zwei Minuspunkte für intelligente Updates

1. Jetzt wird nicht jeder Benutzerfall von Validatoren genehmigt, da sie überlegen und abstimmen, welche Art von Patch für das Netzwerk nützlich ist (und offen gesagt böswillige Hintertüren abschneiden). Es ist unwahrscheinlich, dass Dinge wie Kryptowährungen jemals von der Mehrheit genehmigt werden (ein Thrashold von 67% oder 95%, der im Netzwerk selbst konfiguriert ist).

2. Validatoren können diese Kraft verwenden, um solche Patches durchzusetzen, die für sie direkt von Vorteil sind (entfernen Sie einen anstößigen Benutzer, lassen Sie sich Assets aus drei Feldern holen). Um dieses Problem zu lösen, gibt es eine Verzögerungszeit. Nach der Genehmigung des Patches hat das gesamte Netzwerk 2-6 Wochen Zeit zum Studieren. Wenn gewöhnliche Benutzer es nicht mögen, sollten sich die Leute zusammensetzen, eine harte Gabel machen und den Satz von Validatoren durch adäquatere ersetzen (oder die schlechtesten Zeichen wegwerfen).

Es klingt beängstigend, funktioniert aber bereits jetzt - der Ethereum-Github kann absolut jede harte Gabel bieten, und dies ist die Aufgabe der Benutzer, die Diktatur zurückzusetzen, wenn sie etwas nicht mögen. Schlimmer wird es nicht. Wir formalisieren diesen Prozess einfach und geben jedem Entwickler / Validator transparente Steaks anstelle der bestehenden „Schatten“ -Regierung mit dem ersten Kanal in Form eines Github-Repositorys.

Zusammenfassung

So fanden wir heraus, dass EVM-Smart-Verträge ein interessantes Konzept sind, das sich als Fehlschlag herausstellte, eine zu schwere Wendung in die falsche Richtung, als lediglich ein transparenter Mechanismus für Smart-Updates implementiert werden musste, um das Problem neuer Benutzerfälle zu lösen.

Die Zukunft liegt in intelligenten Updates, und fast alle Blockchains, die derzeit entwickelt werden, enthalten sie von Anfang an (Tezos, Dfinity, Polkadot, Decred, Tendermint, Fairlayer usw.). Selbst in den intelligenten Verträgen selbst versuchen sie nun, den Aktualisierungsmechanismus in sich selbst einzuschalten, und stellen fest, dass das Konzept des Einbaus nicht funktioniert und dass früher oder später eine Aktualisierung erforderlich sein wird .

Hier ist ein detaillierteres Wiki zu diesem Thema (auf Englisch. Ich bin erstaunt, wie Vitalik und Vlad Zamfir versuchen, intelligente Updates zu verunglimpfen , da ihr direkter Konkurrent EVM völlig überflüssig macht.