Im letzten Tag mit der Hilfe der Community haben wir eine Liste aller wichtigen Fehler mit intelligenten Verträgen von Ethereum bisher, einschließlich der DAO sowie verschiedenen kleineren 100-10000 ETH-Diebstählen und -verlusten in Spielen und Token-Verträgen, aufgenommen.
Diese Liste (Originalquelle Hier) ist wie folgt:
Wir können die Liste nach Kategorien von Fehler kategorisieren:
- Variable/Funktionsnamenmischungen: Fireponzi, Rubixi
- Öffentliche Daten, die nicht öffentlich sein sollen: Das öffentliche RNG -Seed Casino, betrügerische RPS
- Wiedereintritt (A Ruf B, der A angerufen wird): The DAO, Maker’s Eth Backed Token
- Sendet aufgrund von 2300 Gasgrenze versagen: König des Äthers
- Arrays/Schleifen und Gasgrenzen: Regierung
- Viel subtilere spieltheoretische Schwächen, bei der die Menschen an der Grenze sogar diskutieren, ob sie Bugs sind oder nicht: The DAO
Es wurden viele Lösungen für die Sicherheit intelligenter Vertragssicherheit vorgeschlagen, die von besseren Entwicklungsumgebungen bis zu besseren Programmiersprachen bis hin zu formeller Überprüfung und symbolischer Ausführung reichen, und Forscher haben es Forscher begann solche Tools zu entwickeln. Meine persönliche Meinung zum Thema ist, dass eine wichtige primäre Schlussfolgerung die folgende ist: Fortschritte bei der Sicherheit intelligenter Vertragssicherheit werden notwendigerweise geschichtet, inkrementell und notwendigerweise von der Verteidigung abhängig. Dort Wille Seien Sie weitere Fehler, und wir werden weitere Lektionen lernen; Dort wird nicht Sei eine einzige magische Technologie, die alles löst.
Der Grund für diese grundlegende Schlussfolgerung ist wie folgt. Alle Fälle von intelligentem Vertragsdiebstahl oder Verlust – in der Tat,, Die Definition von intelligentem Vertragsdiebstahl oder Verlust geht grundsätzlich um Unterschiede zwischen Umsetzung und Absicht. Wenn in einem bestimmten Fall Implementierung und Absicht dasselbe sind, dann ist jeder Fall von “Diebstahl” tatsächlich eine Spende, und jede Instanz von “Verlust” ist freiwillig Geldverbrennung, die wirtschaftlich einer proportionalen Spende an die ETH-Token-Inhaber-Gemeinschaft durch Deflation entsprechen. Dies führt zur nächsten Herausforderung: Absicht ist grundlegend komplex.
Die Philosophie hinter dieser Tatsache wurde am besten von der freundlichen AI -Forschungsgemeinschaft formalisiert, wo die Namen von “die Namen von” trägt “Komplexität des Wertes” Und “Wertungsfragilität“Die These ist einfach: Wir als Menschen haben sehr viele Werte und sehr komplexe Werte – so komplex, dass wir sie selbst nicht vollständig ausdrücken können, und jeder Versuch, unweigerlich einen unbedeckten Eckfall zu enthalten. Die Nützlichkeit des Konzepts ist wichtig, weil es wichtig ist, dass ein supertelligentes Ai in jeder Ecke sucht. Superintelligent KI, um Krebs zu heilen, und es wird 99,99% des Weges durch einige mäßig komplexe Verbesserungen in der molekularen Biologie erkennen, aber es wird bald erkennen, dass es bis zu 100% stößt, indem es das Aussterben des Menschen auslöst, ohne dass das Aussterben durch einen Atomkrieg durch einen Atomkrieg ausgelöst wird, und/oder biologische Pandemie, die Krebs töten, um Krebs zu töten. Wenn es wollte – wird es einfach nicht.
In Smart Contract Land ist die Situation ähnlich. Wir glauben, dass wir Dinge wie “Fairness” schätzen, aber es ist schwer zu definieren, was Fairness überhaupt bedeutet. Möglicherweise möchten Sie Dinge wie “Es sollte nicht möglich sein, dass jemand nur 10000 ETH von einem Dao stiehlt”, aber was ist, wenn der DAO für eine bestimmte Auszahlung tatsächlich die Übertragung genehmigt hat, weil der Empfänger einen wertvollen Service zur Verfügung gestellt hat? Aber wenn die Übertragung genehmigt wurde, woher wissen wir, dass der Mechanismus zur Entscheidung, dass dies durch eine spieltheoretische Verletzlichkeit nicht täuscht wurde? Was ist eine spieltheoretische Sicherheitsanfälligkeit? Was ist mit “Spalten”? Was ist mit dem Front-Running im Falle eines Blockchain-basierten Marktes? Wenn ein bestimmter Vertrag einen “Eigentümer” angibt, der Gebühren erheben kann, was wäre, wenn jemand, der Eigentümer wird, tatsächlich Teil der Regeln wäre, um den Spaß zu ergänzen?
All dies ist kein Streik gegen Experten für formelle Überprüfung, Typtheorie, seltsame Programmiersprachen und dergleichen; Die intelligenten kennen diese Probleme bereits. Es zeigt jedoch, dass es eine grundlegende Barriere für das gibt, was erreicht werden kann, und “Fairness” ist nicht etwas, das in einem Theorem mathematisch nachgewiesen werden kann. In einigen Fällen ist die Fairness -Behauptungen so lang und komplex, dass Sie sich fragen müssen, ob sich der Satz von Ansprüchen selbst einen Fehler haben könnte.
Auf einen Minderungsweg
Es gibt jedoch viele Bereiche, in denen die Abweichung zwischen Absicht und Umsetzung stark reduziert werden kann. Eine Kategorie besteht darin, gemeinsame Muster zu nehmen und sie zu harten: Zum Beispiel hätte der Rubixi -Fehler durch das Erstellen vermieden werden können Eigentümer Ein Schlüsselwort, das nur so initialisiert werden konnte, um gleich zu sein msg.sender im Konstruktor und möglicherweise in a übertragen Transferbesitzer Funktion. Eine andere Kategorie besteht darin, zu versuchen, so viele standardisierte mittlere Komponenten wie möglich zu erstellen. Zum Beispiel möchten wir jedes Casino davon abhalten, seinen eigenen Zufallszahlengenerator zu erstellen, und stattdessen die Leute dazu leiten Randao (oder so etwas wie Mein Randao ++ Vorschlageinmal implementiert).
Eine wichtigere Kategorie von Lösungen beinhaltet jedoch die Minderung der spezifischen und unintuitiven Macken der EVM -Ausführungsumgebung. Dazu gehören: die Gasgrenze (verantwortlich für den staatlichen Verlust sowie die Verluste aufgrund von Empfängern, die beim Akzeptieren eines Sendens zu viel Gas verbrauchen), Wiedereintritt (verantwortlich für den DAO und den Hersteller-ETH-Vertrag) und die Call-Stapel-Grenze. Die Call -Stack -Grenze kann beispielsweise durch gemindert werden Dieser EIPwas es im Wesentlichen aus der Berücksichtigung durch den Ersatz seines Zwecks durch eine Änderung der Gasmechanik entfernt. Die Wiedereintritt könnte sofort verboten werden (dh nur eine Ausführungsinstanz jedes zulässigen Vertrags), aber dies würde wahrscheinlich neue Formen der Unintuberität einführen, daher ist wahrscheinlich eine bessere Lösung erforderlich.
Die Gasgrenze geht jedoch nicht weg; Daher sind die einzigen Lösungen, die sich wahrscheinlich in der Entwicklungsumgebung selbst befinden. Compiler sollten eine Warnung werfen, wenn ein Vertrag nachweislich weniger als 2300 Gas ohne Daten aufgerufen wird. Sie sollten auch eine Warnung werfen, wenn eine Funktion nachweislich nicht innerhalb einer sicheren Menge Gas endet. Variablennamen können gefärbt werden (z. B. RGB basierend auf den ersten drei Bytes des Hashs des Namens) oder möglicherweise eine heuristische Warnung, wenn zwei Variablennamen zu nahe beieinander liegen.
Darüber hinaus gibt es Codierungsmuster, die gefährlicher sind als andere, und obwohl sie nicht verboten werden sollten, sollten sie deutlich hervorgehoben werden, wobei Entwickler ihre Verwendung rechtfertigen müssen. Ein besonders involviertes Beispiel ist wie folgt. Es gibt zwei Arten von Anrufvorgängen, die eindeutig sicher sind. Der erste ist ein Send, der 2300 Gas enthält (vorausgesetzt, wir akzeptieren die Norm, dass es die Verantwortung des Empfängers ist, bei leeren Daten nicht mehr als 2300 Gas zu konsumieren). Der zweite ist ein Aufruf eines Vertrags, dem Sie vertrauen und der selbst bereits sicher ist (beachten Sie, dass diese Definition wieder einsetzt, da Sie dann nachweisen müssten, dass A sicher ist, bevor er sich sicher ist, sicher zu sein).
Wie sich herausstellt, können sehr viele Verträge durch diese Definition abgedeckt werden. Allerdings können nicht alle; Eine Ausnahme ist die Idee eines Vertrags “Allzwecke dezentral ERC20-kompatibel Token. Man könnte einen Sondervertrag nur für ein paar Vermögenswerte abschließen und dadurch unter die Befreiung von “vertrauenswürdiger Callee” fallen, aber eine generische Befreiung scheint eine sehr wertvolle Idee zu sein. Aber in diesem Fall müsste der Austausch anrufen überweisen Und transfer von von unbekannten Verträgen und, ja, geben Sie ihnen genügend Gas, um zu laufen, und machen Sie möglicherweise einen wieder eingerichteten Anruf, um zu versuchen, den Austausch auszunutzen. In diesem Fall möchte der Compiler möglicherweise eine klare Warnung werfen, es sei denn, ein “Mutex -Schloss” wird verwendet, wodurch verhindert wird, dass der Vertrag während dieser Anrufe erneut zugegriffen wird.
Eine dritte Kategorie von Lösungen ist die Verteidigung der Tiefe. Ein Beispiel, um Verluste (jedoch nicht Diebstähle) zu verhindern, besteht darin, alle Verträge zu fördern, die nicht dauerhaft sein sollen, um ein Ablaufdatum zu haben. Danach kann der Eigentümer im Namen des Vertrags willkürliche Maßnahmen ergreifen. Auf diese Weise wären Verluste nur möglich, wenn (i) der Vertrag und gleichzeitig (ii) der Eigentümer fehlt oder unehrlich ist. Vertrauenswürdige Multisig -Eigentümer können entstehen, um zu mildern (II). Diebstähle könnten durch Hinzufügen von Wartezeiten gemindert werden. Die DAO -Ausgabe wurde im Umfang sehr gemildert, gerade weil das Kind Dao 28 Tage lang eingesperrt war. Ein vorgeschlagenes Merkmal im Makerdao besteht darin, eine Verzögerung zu schaffen, bevor eine Änderung der Governance aktiviert wird, sodass die mit der Änderungszeit unzufriedenen Token -Inhaber unzufrieden sind, ihre Token zu verkaufen. Dies ist auch ein guter Ansatz.
Die formale Überprüfung kann oben geschichtet werden. Ein einfacher Anwendungsfall ist ein Weg, um die Kündigung zu beweisen, die gasbedingte Probleme stark mildern. Ein weiterer Anwendungsfall ist das Bestehen spezifischer Immobilien – zum Beispiel: “Wenn alle Teilnehmer zusammenarbeiten, können sie ihr Geld in allen Fällen herausholen” oder “Wenn Sie Ihre Token A zu diesem Vertrag senden, erhalten Sie garantiert, dass Sie entweder die Höhe des Token B erhalten, die Sie wollen oder in der Lage sind, sich vollständig zurückzuerstatten”. Oder “dieser Vertrag passt in eine eingeschränkte Teilmenge der Solidität, die Wiedereinträge, Gasprobleme und als Stapelprobleme unmöglich macht.”
Eine endgültige Notiz ist, dass bisher alle Bedenken hinsichtlich zufälliger Fehler, böswillige Fehler ein zusätzliches Problem sind. Wie sicher können wir wirklich sein, dass der dezentrale Makerdao -Austausch keine Lücke hat, mit der sie alle Mittel herausnehmen können? Einige von uns in der Community kennen das Makerdao-Team vielleicht als nette Menschen, aber der gesamte Zweck des Smart Contract Security-Modells besteht darin, Garantien zu gewährleisten, die stark genug sind, um zu überleben, auch wenn dies nicht der Fall ist, damit Entitäten, die nicht gut vernetzt sind, und feststellen, dass Menschen, die ihnen vertrauen, sie automatisch mit dem Verbrauchern, den sie mit einem Multimillion-Dollar-Dollar-Dollar-Flohing-Flohing-Flohing-Flohing-Lizenz, den Verbrauchern mit einem Multimillion-Dollar-Verbraucher, nicht mit einem Multimillion-Dollar-Vorgang mithilfe von Verbrauchern, einsetzen können. ihre Sicherheit. Daher sollten alle Überprüfungen oder Highlights nicht nur auf der Ebene der Entwicklungsumgebung vorhanden sein, sondern auch auf der Ebene der Blockforscher und anderer Tools existieren, in denen unabhängige Beobachter den Quellcode überprüfen können.
Bestimmte Maßnahmen, die von der Community unternommen werden können, sind:
- Übernehmen Sie das Projekt, eine überlegene Entwicklungsumgebung sowie einen überlegenen Block-/Quellcode -Explorer zu erstellen, der einige dieser Funktionen enthält
- Standardisierung möglicher Komponenten wie möglich
- Übernehmen Sie das Projekt des Experimentierens mit verschiedenen Smart Contract -Programmiersprachen sowie formelle Überprüfungs- und symbolische Ausführungstools
- Diskussion von Codierungsstandards, EIPs, Änderungen der Solidität usw., die das Risiko eines zufälligen oder absichtlichen Fehler
- Wenn Sie eine millionenschwere Smart Contract-Anwendung entwickeln, wenden Sie sich an Sicherheitsforscher und arbeiten Sie mit ihnen an der Verwendung Ihres Projekts als Testfall für verschiedene Überprüfungswerkzeuge zusammen
Beachten Sie, dass Devgrants und andere Zuschüsse, wie in einem früheren Blog -Beitrag angegeben, für einen Großteil der oben genannten verfügbar sind.
