Intelligente Aktualisierungen gegen intelligente Verträge

    Was ist ein intelligenter Vertrag und warum wurde er gebraucht?


    Vor langer Zeit, nach dem Erscheinen von Bitcoin - der ersten replizierbaren Zustandsmaschine - bemerkten die Leute, dass die dem Konsens innewohnende Funktionalität zu begrenzt ist. Ich spreche jetzt nicht über das Hinzufügen von Cryptotocats-Handel, sondern über reale Anwendungsfälle - DNS, bei dem jede Domäne zu einem öffentlichen Schlüssel und nicht zu einem zentralisierten Registrar gehört, alle Arten von Token und Finanzderivaten (weil Sie als Bitcoin eigene Aktien besitzen möchten), also Onchain-Tausch Um große Beträge ohne Vertrauen in den Austausch zu tauschen, spielen Sie Kanäle (um die Gesamtübergabe ohne Kontoverbindung über eine Transaktion im Allgemeinen auf alle Personen umzuverteilen). Es

    gab drei

    Möglichkeiten , Funktionen hinzuzufügen: 1) Das Offensichtlichste ist die Eingabe Setze sie nativ in den Code der Blockchain ein.

    Blockchain ist im Wesentlichen eine replizierbare Website.wenn Sie nicht genügend Funktionen auf der Website haben, was machen 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- / Controllerwechsel - schließlich kann er zu seinem eigenen Vorteil genutzt werden. Nur Hardforka-Option, bei der alle gleichzeitig Chatrooms / Foren vereinbaren.

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

    So geschah es mit mehreren „Blockchains der gleichen Idee“ ala namecoin. Bald stellte sich heraus, dass die Menschen das neue Netzwerk nicht für eine Funktion nutzen möchten, es ist auch Interoperabilität erforderlich, und viele Dinge hängen voneinander ab (Darlehen, Identität und Vermögenswerte selbst möchten im selben Adressraum leben)

    .

    Sogar in Bitcoin legte Satoshi das Skript genau wegen des Problems der Aktualisierungen auf, was eine Menge erlaubte, aber es war nicht genug. Daher wurde vom Äther ein erweitertes Skript vorgeschlagen (jetzt abgeschlossen), und angeblich kann man damit (theoretisch) alles machen.
    Bild

    Daher wird der von der virtuellen Maschine in der Blockchain ausgeführte Code als intelligenter Vertrag bezeichnet und zur Implementierung neuer Funktionen benötigt. Man kann es ein "Patch auf Opcodes" nennen, aber es verkauft sich nicht mehr so ​​gut :)

    Was ist ein intelligentes Update?


    Wenn man auf die letzten Jahre der intelligenten Verträge zurückblickt, kann man eindeutig sagen, dass sie nicht den Erwartungen entsprachen. Ja, der ICO-Boom war bei Bitcoin nicht möglich, aber es war auch eine brutale Kraft, fortgeschrittenes EVM nur für erc20-Token einzusetzen.

    Es ist extrem schwierig, auch nur einen kleinen "Patch" für die Solidität zu schreiben. Auf der untersten Ebene finden Sie eine unformatierte VM mit sehr wenigen Opcodes (konstruktionsbedingt) und einer einfachen Schlüsselwertdatenbank. Alle Vorgänge sind extrem teuer (Gaskosten) und Sie wenden sich nicht von der Welt um.

    Komplizierte Benutzerfälle sind nahezu unmöglich. Schauen Sie sich Ryden github.com/raiden-network/raiden-contracts/tree/master/raiden_contracts/contracts an- Tausende Codezeilen in der rohen Fremdsprache (Solidität), um ein komplexes Finanzsystem zu verwalten. Wir haben mehrere Paritäts-Hacks und DAO mit einfachen Angriffen gesehen. Welche Angriffe erwarten uns auf solch einer monströsen Codebasis?

    Es gibt keine SQL-Datenbank, NoSQL ist nicht vorhanden, die Diagrammdatenbank ist auch nicht geplant. Key-Iteration, viele zu viele? ORM? Nichts davon im Vertrag besteht. Tuling ist im Vergleich zu bekannten Programmiersprachen auch sehr schwach.

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

    Zur Verteidigung von EVM sage ich immer noch - das Bild in der Welt von Bitcoin ist noch trauriger, weil ihre Anspannung noch schwächer ist und die Opcodes noch kleiner sind . Die Entwickler von Lightning stechen, essen aber immer noch den Kaktus - die Komplexität eines Zwei-Wege-Kanalspiels auf Bitcoin ist so verrückt, dass es noch schwieriger ist, die Codebase aufrechtzuerhalten, und praktische Dinge wie Sprites und komplexe Logik im Zustandskanal sind einfach unmöglich.

    Onchain-Governance = Smart Updates


    Nachdem sich die Trauer mit der Solidität verschlungen hatte, gehen wir zurück bis 2012 und erinnern uns an die ausrangierte erste Version, wobei Benutzerfälle nativ in die Blockchain aufgenommen wurden.

    Bild
    Wie viele bemerkt haben, wurde EVM nach der Einführung von EVM nicht mehr so ​​aktualisiert, wie es sollte (die Grundstufe ändert sich nie, der gesamte neue Code ist nur in EVM enthalten) - im Gegenteil, regelmäßig wird sie durch die Diktatur von ethereum hart erzwungen.

    Ie gleiche Eier nur im Profil. Eine Gruppe von Menschen entscheidet persönlich, wie die Onchain-Ebene geändert werden soll, legt den Code auf den Github und alle Benutzer müssen nichts weiter tun, als den neuen Code herunterzuladen. "Hardfork ist für Freitag geplant und wird sofort aktualisiert", sagen sie uns.

    In dieser Form ist die Idee von intelligenten Verträgen absolut ein Misserfolg - wir bereitsWir haben eine Autorität, die bestimmt, wie die Konsensschicht (der Githab-Bericht des Etheriums) funktioniert. Was ist für uns eine zusätzliche und ineffiziente Abstraktion, wenn wir die Aktualisierungen der Hauptschicht nicht loswerden könnten?

    Da wir die Updates nicht loswerden können, wollen wir wenigstens herausfinden, wie wir diese Hauptschicht möglichst dezentral aktualisieren können?

    Wir können Patches für die Software direkt in der Blockchain anbieten, Validatoren können dafür abstimmen, und die Gewinner-Patches werden einfach für alle Benutzer nach einer bestimmten Zeit synchron implementiert. Diese Idee der „Onchain-Governance“ war lange Zeit in der Luft, wurde aber zuerst, wenn ich mich nicht irre, von Tezos beschrieben. Was Mesos übersehen haben, ist die Onchain-Kontrolle, ein direkter Konkurrent zu intelligenten Verträgen (daher nenne ich es intelligente Updates).

    Wenn Sie über intelligente Updates verfügen, benötigen Sie einfach keine intelligenten Verträge. Jeder Anwenderfall kann mit jeder beliebigen Datenbank (SQL / NoSQL / was auch immer) in jeder Programmiersprache qualitativ hochwertiger implementiert werden (Sie führen den Code bereits auf Maschinenebene aus, und es gibt keine Einschränkungen). Volle Freiheit, minus den gleichen 95% des Overhead-Projekts, das Sie für die Solidität ausgeben, und wir müssen keine neue Blockchain wie in Lösung Nr. 2 formen.

    In intelligenten Updates gibt es genau zwei Nachteile


    1. Nun wird nicht jeder Benutzerfall von Validatoren genehmigt, da sie überlegen und entscheiden, welche Art von Patch für das Netzwerk nützlich ist (und die bösartigen Hintertüren abschneidet). Dinge wie Cryptococcus werden wahrscheinlich nie von der Mehrheit genehmigt (Schwellenwert von 67% oder 95% innerhalb des Netzwerks selbst konfiguriert).

    2. Validatoren können mit dieser Kraft solche Patches durchsetzen, von denen sie direkt profitieren (entfernen Sie den unerwünschten Benutzer, lassen Sie sich aus drei Boxen Aktiva zu). . Um dieses Problem zu lösen, gibt es eine Periode. Nachdem der Patch genehmigt wurde, hat das gesamte Netzwerk 2 bis 6 Wochen Zeit, um zu studieren. Wenn gewöhnliche Benutzer es nicht mögen, sollten die Leute zusammenkommen, eine harte Gabel machen und die Menge der Validatoren durch geeignetere ersetzen (oder die schlechtesten Zeichen auswerfen).

    Es hört sich unheimlich an, aber es istEs funktioniert bereits auf diese Weise - der Gitschhab des Etereums kann absolut jede Hardfork anbieten, und es ist bereits die Aufgabe der Benutzer, die Diktatur zurückzusetzen, wenn ihnen etwas nicht gefällt. Nicht schlimmer Wir formalisieren diesen Prozess einfach und geben jedem Entwickler / Prüfer transparente Steaks anstelle der bestehenden Schattenregierung mit dem ersten Kanal in Form eines Githab-Repositorys.

    Das Ergebnis


    So haben wir herausgefunden, dass EVM-Smart-Contracts ein interessantes Konzept sind, das sich als feil erwiesen hat, ein zu schwerer „nicht da“ -Kurs, wenn lediglich ein transparenter Mechanismus für Smart-Updates zur Lösung des Problems neuer Yuzkeys erforderlich war.

    Intelligente Updates sind die Zukunft, und fast alle Blockchains, die sich derzeit in der Entwicklung befinden, umfassen sie von Anfang an (Tezos, Dfinity, Polkadot, Decred, Tendermint, Fairlayer usw.). Selbst innerhalb der intelligenten Verträge selbst versuchen sie nun, den Aktualisierungsmechanismus in sich selbst einzuschalten. Dabei wird klar, dass das Konzept des Steiners nicht funktioniert und früher oder später aktualisiert werden muss .

    Hier ist ein ausführlicheres Wiki zu diesem Thema (auf Englisch mag ich es, wie Vitalik und Vlad Zamfir versuchen, intelligente Updates zu beeinträchtigenIhr direkter Konkurrent macht EVM komplett überflüssig.

    Jetzt auch beliebt: