Das intelligente Vertragsrisiko im DeFi – Nervos Network

Finanzen sind die Kunst des Risikomanagements. Risiken bestehen sowohl in Vermögenswerten als auch im operativen Geschäft. Ein Vermögenswert hat einen Preis. Der Preis spiegelt seinen inneren Wert und das synthetisierte Risiko wider. Wir können einen Vermögenswert nicht bewerten, ohne sein Risiko zu untersuchen. Die Risiken bei Operationen gehen hauptsächlich von Menschen aus, die fehleranfällig und korrumpierbar sind. Die Bewertung des Vermögens- und des Betriebsrisikos bildet den Kern der Finanzierung, unabhängig davon, ob es sich um eine traditionelle Finanzierung auf der Grundlage traditioneller Vermögenswerte oder eine glänzende neue dezentrale Finanzierung (auch bekannt als DeFi) handelt, die auf nativen Krypto-Assets basiert.

Das Risiko von Crypto-Assets setzt sich aus externen Risiken wie Änderungen von Vorschriften und internen Risiken wie Entwurfsfehlern und Implementierungsfehlern zusammen. In Ethereum ist das native Asset die ETH, und das nicht native Asset ist das, was wir ERC-Token nennen. Dies bezieht sich auf Token, die einem der ERC20-Standards und seinen Begleitern wie ERC721 und ERC777 usw. entsprechen. Das Risiko des nativen Assets ist geringer als das Risiko eines nicht-nativen Assets, da letzteres sowohl von Ethereum-Client-Fehlern als auch von Smart-Contract-Fehlern betroffen sein kann. Für ERC-Token und DeFi sind Fehler in einem intelligenten Vertrag von größter Bedeutung, da DeFi als System ein kompliziertes Netzwerk ist, das aus endlosen intelligenten Verträgen besteht, die von verschiedenen Entwicklern an verschiedenen Orten erstellt wurden. Wir nennen die Risiken, die durch intelligente Vertragsfehler verursacht werden intelligente Vertragsrisiken.

Viele Forschungsanstrengungen haben sich auf die Schwachstellen intelligenter Verträge konzentriert, und wir haben viele Verteidigungsmethoden gefunden. Wenn Sie interessiert sind, finden Sie hier eine gute Übersicht. Es ist jedoch allgemein bekannt, dass die Beseitigung von Fehlern in einem nicht trivialen Smart-Vertrag (oder nur in einem Programm) unmöglich ist. Wir leben in einer Welt voller Kommunikationsfehler und Zufälligkeiten, die in jedem Schritt zu „Verzerrungen“ führen: Wir können die Idee in unserem Kopf nicht in eine genaue Spezifikation umwandeln, und wir können eine Spezifikation auch nicht in eine fehlerfreie Implementierung umwandeln .

Wenn dies die grausame Realität ist, sollten wir bei unserer Implementierung von Krypto-Assets nicht nur proaktive und reaktive Abwehrmechanismen berücksichtigen, sondern auch Schadensbegrenzungsmethoden, die den Verlust minimieren können, wenn etwas Schlimmes passiert, um zu vermeiden, dass aus einem Schmetterling ein schwarzer Schwan wird. Es gibt viele Entwurfsmuster, die von intelligenten Verträgen zur Schadensbegrenzung übernommen werden können. Das wichtigste (glaube ich) ist die Dezentralisierung des Anwendungsstatus, da die Zentralisierung des Anwendungsstatus den durch Fehler bei intelligenten Verträgen verursachten Schaden verstärkt. Lassen Sie mich genauer erklären, was ich damit genau meine.

ERC-Token-Standards unterscheiden sich in der Schnittstelle, haben jedoch einige gemeinsame Merkmale. Das Grundmuster eines ERC-Tokens besteht darin, einen Token-Vertrag zum Verwalten des Token-Ledgers zu verwenden, und Benutzer interagieren mit dem Token-Vertrag, um Token auszustellen, zu übertragen oder zu brennen. Alle Datensätze des Token-Ledgers werden im Token-Vertrag gespeichert, und der Vertrag selbst ist einfach ein Konto bei Ethereum.

Angenommen, es gibt einen ERC-Token "Cup", Alice hat 100 Cups und Bob hat 50 Cups. Das Token-Ledger ist ein intelligenter Ethereum-Vertrag, der sich unter der Adresse / dem Konto 0x1234 befindet. Dieser Token-Vertrag 0x1234 verwaltet eine interne Datenbank, in der Aufzeichnungen wie "Alice hat 100 Tassen" und "Bob hat 50 Tassen" gespeichert sind. Wenn Alice 30 Tassen an Bob übertragen möchte, sendet sie eine signierte Nachricht an den Vertrag 0x1234 mit der Aufschrift „Bitte übertragen Sie 30 Tassen an Bob“. Der Vertrag 0x1234 überprüft dann, ob die Nachricht tatsächlich von Alice stammt, und ändert die interne Datenbank relevante Aufzeichnungen zu "Alice hat 70 Tassen" und "Bob hat 80 Tassen".

Das Problem hierbei ist, dass alle Logik und Status in dem einzelnen Vertrag 0x1234 enthalten sind. Alice und Bob haben keinen direkten Zugriff auf ihre eigenen Aufzeichnungen, da die Aufzeichnungen im Rahmen des Vertrags 0x1234 verwahrt werden. Alle Benutzer dieses Tokens interagieren mit diesem Vertrag, und die einzige Möglichkeit, ihre Token zu verwalten, besteht darin, eine Nachricht an den Vertrag 0x1234 zu senden.

Mit anderen Worten, Der Token-Vertrag ist ein zentraler Punkt. Der zentrale Punkt in jedem System ist auch der lukrativste Angriffspunkt. Jedes Problem mit dem zentralen Punkt betrifft alle Benutzer, da alle Tokens / Datensätze von ihm aufbewahrt werden und jeder damit interagieren muss. Beispielsweise kann ein Angreifer mit den Sicherheitsanfälligkeiten "transferFlaw" / "allowAnyone", die durch einen Ganzzahlüberlauf verursacht werden, oder mit der Sicherheitsanfälligkeit "ItchySwap", die durch eine vorsichtslose Autorisierung verursacht wird, andere Token stehlen, während der Eigentümer keine Interaktion mit dem Vertrag hat. Mit der Sicherheitsanfälligkeit "ownerAnyone" kann ein Angreifer die Kontrolle über den Token-Vertrag übernehmen, um alle Token zu sperren. In all diesen Beispielen sind alle in Schwierigkeiten, sobald der Token-Vertrag gebrochen ist.

Ein ERC-Token wird von einem Token-Vertrag gehalten, nicht von einzelnen Benutzern. Dies unterscheidet sich stark von nativen Token wie Ethereum's Ether. Die Aufzeichnungen der ETH-Salden werden nicht durch einen Smart-Vertrag gespeichert, sondern von den Nutzern direkt kontrolliert. Jeder ETH-Inhaber hat ein eigenes Konto und einen eigenen Kontostand. Wenn beispielsweise Alice 100 ETH und Bob 50 ETH in der Ethereum-Blockchain hat, hat Alice einen Datensatz "balance = 100" auf ihrem eigenen Konto und Bob einen Datensatz "balance = 50" auf seinem eigenen Konto. Das Guthaben von Alice kann nur mit dem Vorliegen ihrer Unterschrift verringert werden, und dasselbe gilt für Bobs Konto. Die Aufzeichnungen über den ETH-Besitz sind auf mehreren Konten dezentralisiert und nicht auf einem einzigen Konto. Solange ihre privaten Schlüssel sicher sind, kann niemand ihnen Äther stehlen. Im Gegensatz dazu ist die Angriffsschnittstelle eines ERC-Tokens größer, da ein Angreifer immer versuchen kann, den Token-Vertrag zu brechen. Dies ist viel einfacher als das Protokoll selbst zu brechen.

Die unterschiedlichen inhärenten Risiken machen ERC-Token zu zwei verschiedenen Klassen von Vermögenswerten. Ein intelligenter Vertrag, der in einem dezentralen Netzwerk ausgeführt wird, ist nicht dasselbe wie das dezentrale Netzwerk. Das Problem der Zentralisierung wird durch ERC-Token auf der Anwendungsebene erneut hervorgerufen, was den potenziellen Schaden eines Smart Contract-Fehlers verstärkt. Leider wissen wir, dass Menschen immer Fehler machen werden. Es wird immer Bugs geben. Die Dezentralisierung der Netzwerk- / Konsensschicht kann ein Zentralisierungsproblem auf der Anwendungsschicht nicht lösen.

Der Punkt der Zentralisierung tritt bei ERC-Token auf, weil ihr Staat im Programmiermodell von Ethereum kein erstklassiger Bürger ist. Ein Bundesstaat ist ein Anhang an Code, auf den jedoch nicht direkt verwiesen und verglichen werden kann. Es ist natürlich, dass Sie denselben Status mit denselben Validierungsregeln (z. B. Datensätzen mit demselben Token) in denselben Vertrag einfügen. Dieser Vertrag wird dann jedoch zu einem zentralen Punkt. Dies ist eine Folge des Programmiermodells von Ethereum.

Bei CKB ist das Muster umgekehrt, weil der Staat ein erstklassiger Bürger ist. Der Status ist das Objekt, mit dem Benutzer direkt spielen, und Code ist eine Anlage zum Status. Wir können den Status auf natürliche Weise mit denselben Validierungsregeln vergleichen und gruppieren, auch wenn diese Status direkt von verschiedenen Benutzern verwaltet werden.

Wir bezeichnen ein nicht-natives Token in CKB als "Benutzerdefiniertes Token" oder "UDT". Für eine bestimmte UDT werden die Asset-Definition (Code) und die Asset-Datensätze (Status) sowie die Datensätze verschiedener Benutzer (Adressen) getrennt. Die Asset-Definition beschreibt die Logik des Tokens, z. "Die Emissionsobergrenze beträgt 1 Million" oder "Bob kann neue Token ausgeben", und Datensätze sind Informationen wie "Alice hat 100 Token". Die Bestandsdefinition ist ein Vertrag, der von einem Token-Entwickler erstellt und in einer Zelle des Entwicklers (Bestandsdefinitionszelle) gespeichert wird, während die Datensätze in Benutzerzellen gespeichert werden und alle das gleiche "Typ" -Skript verwenden. Jeder Benutzer verwendet seine eigene Zelle, um seine eigenen Tokendatensätze zu speichern. Diese Tokendatensätze verwenden dieselben Validierungsregeln, die in der Asset-Definitionszelle definiert sind. Bei dieser Struktur werden die Datensätze dezentral gespeichert.