Laut der offiziellen Website werden Smart-Verträge von Ethereum „genau wie programmiert ausgeführt, ohne dass Ausfallzeiten, Zensur, Betrug oder Eingriffe Dritter möglich sind“. Heute werde ich versuchen herauszufinden, ob tatsächlich alles so rosig ist, nachdem ich einige der Probleme untersucht habe, mit denen Benutzer intelligenter Verträge in der Praxis konfrontiert sind.
Am Ende des Artikels fasse ich meine Gedanken mit einer kurzen Anleitung zum Schreiben sicherer intelligenter Verträge zusammen.
- Dieser Artikel konzentriert sich nur auf intelligente Verträge von Ethereum. Die Community hat stillschweigend intelligente Verträge mit intelligenten Verträgen von Ethereum identifiziert. In der Zwischenzeit ist das erste eher ein Konzept, und das zweite ist die Implementierung, und die Frage, wie diese Implementierung dem Konzept entspricht, kann diskutiert werden (ebenso wie im Prinzip das Konzept intelligenter Verträge und anderer möglicher Implementierungen). Dieses Thema ist komplex, unterschätzt und interessant, aber dies ist nicht das Thema dieses Artikels, daher werde ich diejenigen verweisen, die sich für die Werke von Nick Szabo interessieren. Dementsprechend meine ich überall, wo ich „intelligente Verträge“ sage, tatsächlich „intelligente Verträge von Ethereum“.
- Der Artikel konzentriert sich nur auf die Sprache der intelligenten Verträge. Solidity ist die beliebteste und für den Ethereum-Benutzer derzeit die einzige.
Probleme mit der Sicherheit intelligenter Verträge
Es geht um die Probleme, mit denen Entwickler intelligenter Verträge am Ende konfrontiert sind, und nicht um die Sicherheit der Plattform selbst (wenn auch ein wenig darüber). Wir unterteilen diese Probleme herkömmlicherweise in die folgenden Typen:
- Probleme im Smart Contract Code;
- Probleme im Entwicklungsprozess;
- Probleme in der Sprache;
- Probleme im Konzept.
1. Probleme im Smart Contract Code
Mit Problemen im Code eines intelligenten Vertrags meine ich hier Probleme, die durch Bearbeiten der .sol-Datei gelöst werden. Dies ist insbesondere:
- Bekannte anfällige Konstrukte (z. B. Wiedereintritt ).
Lebensbeispiel : Wiedereintritt oder allgemeiner Verstoß gegen das Muster "Checks-Effects-Interactions" - selbst weithin bekannte (und zuvor ausgenutzte ) Sicherheitslücken finden sich weiterhin in neuen Verträgen. - Anfällige Konstrukte des Autors (insbesondere Fehler in der Logik des Codes).
Lebensbeispiel : Eine MultiSig-Brieftasche, die eigentlich keine MultiSig ist. Um eine Transaktion zu unterzeichnen und Geld zu überweisen, benötigen Sie die erforderliche Anzahl von Unterschriften der Brieftaschenbesitzer. Gleichzeitig reicht nur die Unterschrift eines der Eigentümer aus, um die required Änderungen vorzunehmen (z. B. um eins, um die Transaktionen selbst weiter zu unterzeichnen):
- Schlechte Architektur.
Lebensbeispiel : Ein Versuch, ein Token, eine Brieftasche und einen Schlüsselspeicher in einem einzigen Vertrag zu implementieren. Der Vertrag erweist sich als zu kompliziert, der Code ist schwer zu pflegen, zu prüfen und zu ändern. Infolgedessen leidet auch die Sicherheit. - Code von geringer Qualität.
Lebensbeispiel : Verträge mit unterschiedlichen Einzügen, willkürlichen Zeilenumbrüchen und Leerzeichen. Der Code ist schwer zu lesen, was bedeutet, dass die Sicherheit erneut leidet. Trotz der Tatsache, dass es bereits Linters für Solidity gibt ( Solium , Solhit ).
Probleme im Code führen direkt zu Angriffen und Geldverlust. Die gute Nachricht ist, dass Codeprobleme während des Prüfprozesses identifiziert und behoben werden können. Es ist wichtig zu verstehen, woher sie kommen, um sie in Zukunft zu vermeiden. Daher fahren wir mit dem nächsten Absatz fort.
2. Probleme im Entwicklungsprozess
Probleme im Code werden hauptsächlich durch einen falsch erstellten Entwicklungsprozess verursacht. Es scheint, dass die Softwareentwicklung ein langjähriges Unternehmen mit etablierten Best Practices ist. Trotzdem führen die Jugendlichen im Bereich der intelligenten Verträge, unverhältnismäßig viel Geld und Hype dazu, dass die Menschen aus dem einen oder anderen Grund die Standardverfahren vernachlässigen, was häufig zu ernsthaften Problemen führt. Von den typischsten ist es erwähnenswert:
- TK: Die meisten intelligenten Verträge von Ethereum werden ohne technische Aufgabe abgeschlossen. Zu was dies führen kann, unnötig zu erklären.
- Timing: Im Durchschnitt wird nur sehr wenig Zeit für die Entwicklung zur Verfügung gestellt, etwa ein Monat. Ein extremes Beispiel aus meiner Praxis: Der Kunde bat den Entwickler, 3 Tage vor dem ICO einen intelligenten Vertrag zu schreiben.
- Entwicklerebene: Viele Leute kommen auf das Gebiet, auch ohne Programmierhintergrund.
- Das Ökosystem verstehen: Auch wenn die Entwickler einen Hintergrund haben, sind sie häufig nicht tief in das Thema vertieft und verstehen die Besonderheiten intelligenter Verträge nicht.
- Entwicklungskosten: und doch gibt es nur wenige, die intelligente Verträge schreiben. noch weniger, die sie gut schreiben. Daher die unangemessen hohen Entwicklungskosten.
3. Probleme in der Sprache
Fügt der Sprache der Solidität selbst Teer hinzu. Ursprünglich wurde es eher so konzipiert, dass es von einer großen Anzahl von Personen schnell beherrscht werden kann, als dass es bequem ist, sichere intelligente Verträge darauf zu schreiben. Hier sind nur einige seiner Funktionen, die die Sicherheit beeinträchtigen:
- Mehrfachvererbung
using for , call / delegate call - all dies startet den Code nicht von der aktuellen Quelle, was bedeutet, dass die Lesbarkeit und damit die Codesicherheit verringert werden. - Checks-Effects-Interactions-Muster - Wenn Konstruktionen, die gegen CEI verstoßen, unsicher sind, warum sollten Sie sie (und viele andere) nicht einfach auf Sprachebene verbieten?
- Wenn Sie einen anderen Vertrag anrufen, können Sie plötzlich in seine Fallback-Funktion mit unerwarteten Konsequenzen fallen.
Es ist klar, dass sich das Ethereum-Projekt entwickelt, und es ist unmöglich, alles im Voraus zu berücksichtigen. Am Ende sind Entwickler jedoch gezwungen, sich an viele Funktionen zu erinnern und Krücken zu verwenden, um ihren intelligenten Vertrag sicherer zu machen.
4. Probleme im Konzept
Das schwerwiegendste Problem ist jedoch noch tiefer: Viele verstehen nicht gut genug, warum intelligente Verträge benötigt werden, was sie können, was sie nicht können und wie sie funktionieren. Im schlimmsten Fall führt dies dazu, dass der Smart-Vertrag:
Nicht schlau:
- Schlecht geschrieben - tut, was geschrieben steht, aber nicht, was beabsichtigt ist.
- Es ist stark an das Backend und / oder Frontend gebunden - und dieser Code ist kein intelligenter Vertrag mehr, er wird auf die übliche Weise ausgeführt und seine Implementierung wird vollständig vom Serveradministrator gesteuert.
Kein Vertrag:
- Die Verpflichtungen der Parteien werden nicht erfasst - zum Beispiel verkauft ICO seine Token für die ETH, aber Token sind im Wesentlichen Bonbonverpackungen, weil Legen Sie demjenigen, der sie freigegeben hat, keine Einschränkungen oder Verpflichtungen auf.
- Ermöglicht einseitige Änderungen - und es stellt sich heraus, dass eine der Parteien den Vertrag nach seiner Unterzeichnung ändern kann.
Lebensbeispiel : Der Vertragseigentümer kann die Kapitalisierung, die Rate und die Dauer des Token-Verkaufs willkürlich ändern:
Nicht benötigt:
- Der Smart-Vertrag wurde nicht hinzugefügt, weil er technisch notwendig war, sondern um herauszufinden, was mit Smart-Verträgen zu tun ist, und um eine Welle des Hype zu bewältigen.
- Wir haben versucht herauszufinden, wie intelligente Verträge an ein vorhandenes Produkt gebunden werden können.
Intelligenter Vertrag als Sicherheitsbedrohung für den Blockchain-Start
Was ist das Ergebnis? Sie wollten, dass es modisch, sicher und blockchain ist, aber wir bekommen teuren, nicht unterstützten Code, der die Sicherheit gefährdet und überhaupt nicht benötigt wird. Wir wollten, dass unsere intelligenten Verträge „genau so programmiert werden, wie sie programmiert sind, ohne die Möglichkeit von Ausfallzeiten, Zensur, Betrug oder Eingriffen Dritter“, und am Ende werden sie wirklich so ausgeführt, wie sie geschrieben wurden - sie werden nur mit Verwundbarkeit geschrieben. Und alles, was uns bleibt, ist, mit unseren Mitteln mit einem Stift zu winken. Nun, oder um eine harte Gabel zu machen (wodurch die ursprüngliche Idee selbst tatsächlich diskreditiert wird), wenn die Schöpfer von Ethereum aufgrund der Verwundbarkeit Geld verloren haben.
So schreiben Sie sichere Smart-Verträge
In der Tat ist natürlich nicht alles so schlecht. Ich übertreibe nur, um auf einige meiner Meinung nach wichtige Punkte aufmerksam zu machen. Im Allgemeinen entwickelt sich das Gebiet, die Menschen lernen, einschließlich der Sicherheit.
Wenn der Leser beschließt, einen intelligenten Vertrag zu schreiben, würde ich raten:
- verstehen, warum ein intelligenter Vertrag benötigt wird (und ob er benötigt wird);
- vom Kunden erhalten oder TK schreiben;
- Zeit berechnen;
- Verwenden Sie Entwicklungs- und Testtools ( Truffle , Remix , SmartCheck , Solhint oder Solium Linter ).
- Tests schreiben;
- Führen Sie mehrere unabhängige Audits und Bug Bounty durch.
- Überwachen Sie die Sicherheit der verbleibenden Komponenten des Projekts (Website, Twitter usw.).
Wenn Sie diese einfachen Empfehlungen befolgen, können Sie die meisten der oben beschriebenen Probleme vermeiden (von einer harten Gabel aus wird dies jedoch immer noch nicht gespeichert).
Der Artikel wurde in Zusammenarbeit mit Eugene Marchenko ( eMarchenko ) erstellt.