Ein Meinungsbeitrag von Josh Primero, Head Protocol Architect bei RDX Works.  Nachdem ich Radix Engine V2 im Babylon-Netzwerk gestartet habe, habe ich einen genaueren Blick auf die neue Welle von VMs geworfen, die in der DeFi-Szene auftaucht. Eines der überzeugendsten davon ist Suis MoveVM, eine Verbesserung gegenüber Diems ursprünglichem MoveVM.  Ich bin schon seit einiger Zeit von der Architektur von Sui begeistert, da sie einige wichtige technische Philosophien mit Radix teilt:  Verwendung der Bewegungssemantik, um eine ressourcenorientierte Programmierung zu ermöglichen.  Nutzen Sie das Wissen über Zustandsabhängigkeiten, um den Konsens durch teilweise Ordnung zu skalieren (anstatt zu stark zu abstrahieren und die Skalierbarkeit auf eine höhere Ebene zu verlagern, wie es damals der Trend war).  Technisch gesehen fand ich es sehr cool, wie sie eine Sprache und einen kompilierten Bytecode verwendet haben, der die minimalen Zustandsabhängigkeiten, die zum Ausführen einer Logik erforderlich sind, statisch erfasst.  Dies führt nicht nur zu einer schnellen Ausführung, sondern bietet auch Sicherheitsvorteile, da Zustandsabhängigkeiten und Zustandsschreibvorgänge einer Transaktion gut begrenzt sind.  Dieser Erfolg hat jedoch seinen Preis. DeFi-Programmierer müssen ein schwierigeres und manchmal nicht intuitives Modell verwalten, bei dem sogar bekannte Probleme des EVM wiederholt werden.  Schauen wir uns diese Probleme nun anhand von vier Fehlern in Suis VM an.  1. Objektprimitiv, das zu allgemein ist  Die größte Innovation von Suis MoveVM (oder MoveVM im Allgemeinen) ist die Verwendung der Move/Borrow-Semantik auf der Bytecode-Ebene. Das bedeutet, dass ihre Low-Level-Maschine den Besitz und die Bewegung von Objekten verstehen kann; ziemlich cool!  Jedes Objekt in Suis VM also  , ein typisierter Wert mit zugehöriger Logik, der besessen, verschoben und geteilt werden kann.    verhält sich wie ein NFT  Da ein Objekt in diesem Modell leider viele allgemeinere Dinge tun kann, ist der DeFi-Programmierer mit der Definition und Verwaltung einer komplexen Zustandsmaschine für die Objektlebensdauer belastet.   Insbesondere muss ein Programmierer in Sui beim Definieren einer neuen Struktur eine Kombination aus vier Fähigkeiten („Kopieren“, „Ablegen“, „Schlüssel“ und „Speichern“) angeben, die sich jeweils auf unterschiedliche Weise auf die Zustandsmaschine auswirken. Darüber hinaus muss ein Programmierer verwalten, ob ein Objekt bei der Instanziierung gemeinsam genutzt, übertragen, als Wert zurückgegeben oder eingefroren werden soll.  Eine falsche Konfiguration kann zu subtilen Fehlern führen, die zum Verlust von Geldern führen können.  Im folgenden Code verwenden wir beispielsweise Suis  um einen einfachen Blitzkredit umzusetzen. Das Problem? Wir haben der Quittung versehentlich die Drop-Funktion hinzugefügt.    Heiße Kartoffelmuster  Dieser kleine Fehler ermöglicht es einem Kreditnehmer, mit dem Kredit davonzulaufen, ohne ihn jemals zurückzuzahlen, indem er die Quittung selbst fallen lässt. (Es gibt einen weiteren Fehler in der Beziehung zwischen FlashLoan und Receipt. Versuchen Sie, ihn zu finden!)  Obwohl es konzeptionell elegant und einfach ist, eine VM um eine einzelne Objektabstraktion mit einer Reihe von Fähigkeiten herum zu organisieren, ist es aus der Sicht eines Programmierers schwierig, die Auswirkungen jedes einzelnen zu verstehen, da es so viele Zustände auf niedriger Ebene gibt verwalten.  Dies ist nicht allzu unähnlich zu den Speicherverwaltungsproblemen älterer Sprachen und erklärt, warum Garbage-Collection-VMs großen Erfolg hatten. Anwendungsprogrammierer kümmern sich nicht um die Verwaltung von Low-Level-Zuständen, etwa wann die Speicherfreigabe in Ordnung ist; Sie kümmern sich um Objekte und die Beziehungen zwischen diesen Objekten.  In ähnlicher Weise kümmern sich DeFi-Programmierer grundsätzlich um Vermögenswerte und die Logik rund um die Bewegung und den Besitz dieser Vermögenswerte. Vermögenswerte allein haben keine inhärente Logik, und die Logik, die diese Vermögenswerte verwaltet, muss weder „verschoben“ noch „im Besitz“ sein.  Suis MoveVM vereint diese beiden sehr unterschiedlichen Dinge zu einer generischen Objektabstraktion, was zu einem schwierigen mentalen Modell für die DeFi-Programmierung führt.  2. Kein dynamischer Versand  Ein entscheidendes Merkmal von MoveVM ist die Verwendung von statischem Dispatch, was bedeutet, dass es keine Indirektionsebene zwischen einem Funktionsaufruf und seiner Ausführung während der Laufzeit gibt. Funktionsaufrufe und die zugrunde liegende Logik werden zum Zeitpunkt der Veröffentlichung eines neuen Pakets statisch verknüpft. Dadurch kann die VM schnell und vorhersehbar sein, allerdings auf Kosten einer geringeren Flexibilität und einer schwieriger zu verwendenden Programmierumgebung.  Werfen wir einen Blick auf drei Auswirkungen des Mangels an dynamischem Versand.  2a) Keine Funktionszusammensetzung  Da die VM zum Zeitpunkt der Codeveröffentlichung genau wissen muss, welche Funktion aufgerufen werden soll, ist es unmöglich, verschiedene Funktionen zusammenzustellen. ein sehr häufiges Muster in der regulären Programmierung (z. B. Schnittstellen in OO-Sprachen oder Merkmale in Rust).  Werfen wir einen Blick auf einen einfachen Anreiz für einen Liquiditätspool. Wenn ich einen Anreiz schreiben würde, der Ihren Beitrag in Rust um 10 % erhöht, würde das etwa so aussehen:   Auf diese Weise würde mein LiquidityEnhancer mit jedem Pool funktionieren, der das Pool-Merkmal implementiert (Ja, für Sie Rust-Nitpicker: Dieses Merkmal ist auch statisch verknüpft. Dies ist nur ein Beispiel für die Funktionszusammensetzung).  Dies ist in Sui nicht möglich, da „contribute“ eine bereits definierte Funktion sein muss. Stattdessen müsste für jede neue Pool-Implementierung ein neues Paket veröffentlicht werden, das auf genaue Pool-Implementierungen verweist.  2b) Keine dynamischen Rückrufe oder Funktionszeiger  In diesem Zusammenhang ist die Möglichkeit, beliebige Logik über eine generische Schnittstelle auszuführen, ein sehr nützliches Konstrukt, insbesondere im DeFi-Umfeld.  Stellen Sie sich einen zukünftigen Ausführenden mit Anreizen vor, der einen Anrufer in der Zukunft dazu anregt, eine beliebige Logik aufzurufen (z. B. für die Verwendung verzögerter Zahlungen). In Rust würde das so aussehen:   Dies ist jedoch in Sui aufgrund des fehlenden dynamischen Versands nicht möglich. Stattdessen müsste für jede Methode, die ein solches Feature nutzen möchte, ein neues IncentivizedFutureExecution-Paket veröffentlicht werden.  2c) Umständliche Aufrüstbarkeit  Sui hat Unterstützung für  . Aufgrund der statischen Dispatch-Invariante ist die Verwaltung von Paket-Upgrades leider umständlicher und weniger sicher als erwartet.   Paketaktualisierung und Versionierung  Erstens sind nahtlose und transparente Code-Updates nicht möglich. Wenn ich ein Paket habe, das Aufrufe an ein anderes Paket durchführt, und das andere Paket über ein erforderliches Bugfix-Update verfügt, muss ich selbst ein neues Paket veröffentlichen, wenn ich den Fix möchte.   Bei immer mehr Paketabhängigkeiten kann dies leicht zu einer Explosion von Paket-Upgrades führen, selbst wenn nur ein einfacher Bugfix eines häufig verwendeten Pakets erfolgt.   Zweitens wird der gesamte alte Code immer vorhanden sein (notwendig, da jeder andere davon abhängige Code ihn aufrufen können muss), selbst in Fällen, in denen dieser Code möglicherweise Fehler und/oder bösartigen Code enthält. Um dem entgegenzuwirken, wird der Anwendungsschicht die Aufgabe auferlegt, ein sinnvolles Versionierungsschema für den Zustand ihrer Objekte aufrechtzuerhalten.  3. Ein unangenehmes Postfachmuster  Sui hat kürzlich eine veröffentlicht  Dies lässt sich am besten als eine Möglichkeit beschreiben, ein Objekt an ein anderes Objekt zu senden, ohne dass das andere Objekt davon weiß (zuvor war dies nur mit Adressen möglich). Um auf dieses Objekt zugreifen zu können, muss eine separate Transaktion mit Kenntnis dieser Übertragung ausgeführt werden.    Übertragungs-zu-Objekt-Muster  Ein solches Konstrukt ist nützlich, um die Abhängigkeit vom Zustand des empfangenden Objekts zu beseitigen. nicht unähnlich dem Senden von UTXOs an eine andere Adresse im UTXO-Modell (der Empfangsteil ähnelt auch dem Nachweis des Eigentums durch UTXO-Zeugenskripte). Suis Konsens ist dann in der Lage, diesen Mangel an Konflikten auszunutzen und eine solche Transaktion besser zu parallelisieren.  Ein solcher Leistungsgewinn geht jedoch nicht ohne Kompromisse in Bezug auf die Sicherheit einher. Die Tatsache, dass Objekte ohne Informationen über das empfangende Objekt empfangen werden können (einschließlich ob es existiert oder nicht!), birgt die Möglichkeit, dass der Zugriff auf diese gesendeten Objekte für immer verloren geht.  Dies ist möglich, wenn das empfangende Objekt das gesendete Objekt nicht unterstützt. Ein solcher Fehler ähnelt dem irrtümlichen Senden eines ERC-20-Tokens an einen Smart Contract, der diesen Token nicht unterstützt (eine   häufige Ursache für Geldverluste). sehr  Darüber hinaus führt die Tatsache, dass es zwei Arten von Eltern-Kind-Beziehungen gibt, eine, bei der die Eltern über ihre Kinder Bescheid wissen, und eine, bei der die Kinder über ihre Eltern Bescheid wissen, zu einem komplizierteren Modell, als es in der traditionellen Programmierung üblich ist.   Gibt es einen Ansatz, der die Leistungsvorteile beibehält, ohne diese umständliche Struktur zu programmieren? Ich glaube, das gibt es. Es erfordert die Verwendung unveränderlicher Zeiger zusammen mit anderen CRDT-Ansätzen, aber ich werde das in einem zukünftigen Artikel behandeln.  4. Umständliche Shared-State-Programmierung  Suis VM ist für die Programmierung und Ausführung in einem nicht umstrittenen Zustand optimiert. Dies hat zu einigen ziemlich umständlichen Programmiermechanismen geführt, wenn es tatsächlich um den Umgang mit gemeinsam genutzten Zuständen geht. Schauen wir uns einige davon an.  4a) Keine gespeicherten Referenzen  Suis VM kennt keine gespeicherten Referenzen. Wenn dies der Fall wäre, würde es die Fähigkeit verlieren, die Zustandsabhängigkeiten einer Funktion statisch zu analysieren, und somit die Fähigkeit zur Parallelisierung verlieren. Dies hat zur Folge, dass die Last der Verwaltung gespeicherter Referenzen nun beim Programmierer/Benutzer liegt.  Nehmen wir zum Beispiel an, ich habe ein Objekt, das in einer seiner Funktionen einen Preis von einem bestimmten Oracle erfordert. In Rust könnte das so aussehen:   Da in Sui keine Referenzen gespeichert werden können, muss diese Beziehung zwischen MyDefi und Oracle funktionaler beschrieben werden:   Aber warte! Jetzt kann jedes beliebige Orakel übergeben werden. Um sicherzustellen, dass das richtige Orakel verwendet wird, muss das  muss benutzt werden:    ID-Zeigermuster  Dieses Muster ist im Vergleich zu regulären Referenzen fragiler und es muss darauf geachtet werden, die richtige Beziehung zu implementieren. Da der Beziehungsgraph zwischen Objekten wächst und komplexer wird, kann man sich kaum vorstellen, dass dieser Programmieraufwand sehr gut skaliert (was wäre beispielsweise, wenn der Oracle-Aufruf get_price auch seine eigenen Abhängigkeiten hätte)?  Darüber hinaus wird es für den Aufrufer immer eine Belastung sein, ob es sich um einen Transaktions- oder Paketcode handelt, die korrekte Referenz einzugeben. Wenn sich diese Referenz ändern kann, stellt dies eine weitere zusätzliche Belastung für den Anrufer dar, um sicherzustellen, dass die Referenz auf den neuesten Stand gebracht wurde.  4b) Nichtdynamische Typsicherheit für verwandte Instanzen  Im Gegensatz zur herkömmlichen Programmierung ist es bei der DeFi-Programmierung sehr nützlich, typüberprüfen zu können, ob eine Instanz Teil derselben „Instanzgruppe“ wie eine andere Instanz ist.  Es wäre zum Beispiel schön zu überprüfen, ob die Verbindung zweier Münzen dieselbe Münzkennung hat:   Das Problem bei der Umsetzung mit traditioneller generischer Semantik besteht darin, dass Generika zur Darstellung von Typen und nicht „einer Gruppe verwandter Instanzen“ verwendet werden.  Sui konnte dieses Problem auf ziemlich clevere Weise umgehen  . In diesem systemgestützten Muster heißt es im Wesentlichen: Wenn Sie eine neue Gruppe verwandter Instanzen erstellen möchten, erstellen Sie diesen speziellen neuen Typ, der die Kennung dieser Gruppe darstellt.   Muster für einmalige Zeugen  Ein großer Vorteil davon besteht darin, dass die Sprachschicht überhaupt nicht geändert werden muss und man einfach bekannte generische Semantik verwenden könnte, um diese Art von Sicherheit zu erreichen.  Der größte Fehler besteht darin, dass jedes Mal ein neuer Typ (und damit ein neues Paket) bereitgestellt werden muss, wenn eine neue Gruppe verwandter Dinge erstellt werden soll. Man kann nicht einfach dynamisch eine neue Coin<T> erstellen, ohne beispielsweise ein neues Paket bereitzustellen.   Abschluss  Suis MoveVM wurde nach den Standards von Systemingenieuren entwickelt: eine VM, die auf konzeptionell einfachen Grundelementen auf niedriger Ebene basiert und statisch durchgesetzt wird.  Leider bedeutet einfach nicht gleich einfach, und ihr Beharren auf der Vermeidung normaler Shared-Object-Muster führt dazu, dass ihre Anwendungsschicht recht komplex und nicht intuitiv zu programmieren ist.  DeFi ist eine chaotische, gemeinsam genutzte Objektwelt: Pools mit großer Liquidität, auf die jeder zugreifen kann, Kreditprotokolle, bei denen jeder Geld leihen und verleihen kann, Orakel, die von jedem aufgerufen werden können, und die Zusammensetzung und Interaktion all dieser Objekte geschieht gleichzeitig.  Die Parallelisierung eines solchen Ökosystems ist der heilige Gral von DLTs, und Suis Versuch ist gut, außer dass er zu viel Chaos auf die Anwendungsebene verlagert.  Obwohl es wahr ist, dass einige der Probleme möglicherweise mit besseren Werkzeugen und Sprachunterstützung gelöst werden könnten (   ), sind einige ohne große VM-Änderungen irreparabel (   ). 1 Object Primitive, das zu generisch ist, 4 umständliche Shared-State-Programmierung 2 kein dynamischer Versand, 3 eine umständliche). Mailbox-Muster

Buy XRD with card or bank transfer via Switchere.

Dieses Audio ist in der Originalsprache der Geschichte produziert!

Suis MoveVM: Eine umfassende Rezension

About Author

KOMMENTARE

Hängeetiketten

DIESER ARTIKEL WURDE VORGESTELLT IN

Related Stories

HackerNoon Decoded 2024: Celebrating Our Data Science Community!

Welcome to HackerNoon Decoded: The Best of 2024 Tech Blogging

HackerNoon Decoded 2024: Wir feiern unsere Produktmanagement-Community!

HackerNoon Decoded 2024: Celebrating Our AI Community!

HackerNoon Decoded 2024: Celebrating Our Data Science Community!

Welcome to HackerNoon Decoded: The Best of 2024 Tech Blogging

HackerNoon Decoded 2024: Wir feiern unsere Produktmanagement-Community!

HackerNoon Decoded 2024: Celebrating Our AI Community!

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps