Risiken bei Smart Contracts: Code, Oracles, Governance und Upgrade-Schlüssel

Ein Dashboard kann Risiken bei Smart Contracts wie ein einzelnes Ereignis erscheinen lassen. Tatsächlich sind die Festlegung von Rechten und Invarianten, die Prüfung des bereitgestellten Systems sowie das Reagieren und die Governance separate Zustandsänderungen, für die unterschiedliche Beteiligte verantwortlich sind. An diesen verborgenen Übergaben entstehen Zeitaufwand, Kosten und Risiken.

Das Risiko bei Smart Contracts ist die Möglichkeit, dass Code, Abhängigkeiten oder Governance zu einem finanziellen Ergebnis führen, das von den Erwartungen der Nutzer abweicht. Die Angriffsfläche umfasst Geschäftslogik, Zugriffskontrollen, Arithmetik und Buchführung, Oracles, Token, Komposierbarkeit, Frontends, private Schlüssel, Upgrades und die rechtlichen Zusagen rund um den Code.

Ein Audit ist ein Nachweis über eine klar abgegrenzte Prüfung, keine Garantie. Korrekt geschriebener Quellcode kann mit anderen Parametern bereitgestellt, später aktualisiert oder mit einem manipulierten Oracle verwendet werden. Unveränderlicher Code verringert das Änderungsrisiko nur dann, wenn das unveränderliche Verhalten und die Abhängigkeiten selbst sicher sind.

Um Risiken bei Smart Contracts in den größeren thematischen Rahmen von Securities.io einzuordnen, vergleichen Sie das Referenzmodell für den DeFi-Stack, Unternehmen für Smart-Contract-Audits und Sicherheit von Smart Contracts und KI. Zusammengenommen zeigen diese Leitfäden, wie sich dieselbe Frage zur Infrastruktur digitaler Vermögenswerte verändert, wenn sich Emittent, Vermögenswert, Anlegerrecht oder Betriebsinfrastruktur unterscheiden.

Von der Festlegung von Rechten und Invarianten bis zum Reagieren und zur Governance: die Risikokette bei Smart Contracts

Bei der Festlegung von Rechten und Invarianten werden Salden, Befugnisse, Grenzen und Bedingungen definiert, die jederzeit erfüllt sein müssen. Das Ergebnis wird anschließend zur Eingabe für die Implementierung und das Testen, bei denen geprüfte Komponenten sowie Unit-, Integrations-, Eigenschafts- und Angriffstests zum Einsatz kommen. An dieser Übergabe lässt sich erstmals das Risiko bei Smart Contracts prüfen: Die empfangende Partei muss eine abgeschlossene Zustandsänderung von einer Nachricht, einer Schätzung oder einem vorläufigen Datensatz unterscheiden können. Dieselbe Prüfung gilt für jeden weiteren Übergang, bis das Reagieren und die Governance zu einem Ergebnis führen, das sich unabhängig abgleichen lässt.

Lesen Sie das Diagramm rückwärts, ausgehend vom Reagieren und der Governance. Vom Endzustand aus sollte sich die Kette zurückverfolgen lassen: zur Spezifikation, zum bereitgestellten Quellcode und Bytecode, zu Tests und Audits, zu Parametern und administrativen Rollen, zur Übersicht über Oracles und Abhängigkeiten, zu überwachten Ereignissen, zur Reaktion auf Vorfälle und zur Zuordnung von Verlusten. Von dort führt sie weiter zu den Befugnissen beim Betrieb und der Überwachung, dem Risiko, das durch das Audit des bereitgestellten Systems entsteht, und den Eingaben, die bei der Festlegung von Rechten und Invarianten akzeptiert wurden. Reißt diese Kette, kann ein Fehler in der Zugriffskontrolle wie eine abgeschlossene Transaktion aussehen, obwohl ein nicht autorisierter Aufrufer die Befugnis zum Prägen, Abheben, Anhalten oder Aktualisieren erhält. Diese Rückverfolgung hält die Analyse auf die zugesagte finanzielle Invariante und alle Code-, Daten- und Governance-Abhängigkeiten konzentriert, die sie verändern können – statt auf ein Anbieterlabel oder den Status einer Benutzeroberfläche.

Wer kontrolliert die entscheidenden Datensätze bei Risiken von Smart Contracts?

Protokollentwickler und Auditor stehen an unterschiedlichen Stellen der operativen Prozesskette. Der Protokollentwickler konzipiert und implementiert die ökonomische und technische Logik, während der Auditor eine klar abgegrenzte Version prüft und seine Feststellungen berichtet. Ihre Aufzeichnungen – Spezifikation, Code, Tests, Commits, Abhängigkeiten und Bereitstellung einerseits sowie Prüfungsumfang, Methoden, Annahmen, Schweregrad, Korrekturen und Restrisiko andererseits – sollten dasselbe Ereignis abbilden, ohne Kopien derselben Anbieterdatenbank zu sein. Ein Orakel oder externes Protokoll, Governance und Schlüsselinhaber sowie Nutzer oder Integrator bringen jeweils eigene Entscheidungen oder Belege ein. Werden diese Funktionen als austauschbar behandelt, bleibt verborgen, wo Ermessensspielraum, Liquidität oder rechtliche Verantwortung ins Spiel kommen.

Ein Ausfall bei Governance und Schlüsselinhabern ist ein praktischer Test für die Rechenschaftspflicht im Zusammenhang mit Risiken von Smart Contracts. Governance und Schlüsselinhaber können Parameter ändern, den Betrieb anhalten, Upgrades durchführen oder Vermögenswerte verschieben. Entscheidend ist, ob Protokollentwickler und Auditor die Lage anhand von Rollen, Quorum, Zeitsperre, Abstimmungen, Verwahrung der Schlüssel und Ereignisverlauf weiterhin rekonstruieren können. Verträge können Aufgaben zuweisen, doch wer gegenüber Kunden ein Versprechen gibt oder für einen Vermögenswert oder eine Verpflichtung einsteht, kann Belege nicht durch eine Klausel zur Auslagerung ersetzen. Ein belastbares Design legt fest, welche Ausweichaufzeichnung gilt und wer befugt ist, Abweichungen zu klären.

Wie sich Risiken von Smart Contracts in der Praxis auswirken

1. Rechte und Invarianten festlegen: Den Ausgangszustand für Risiken von Smart Contracts definieren

Definieren Sie Kontostände, Befugnisse, Grenzen und Bedingungen, die stets erfüllt sein müssen. In diesem Teil der Risiken von Smart Contracts legt dieser Schritt die Bedingungen fest, auf die sich Implementierung und Tests stützen können. Der Protokollentwickler steht im Mittelpunkt, weil er die ökonomische und technische Logik konzipiert und implementiert. Die Arbeitsdokumentation sollte Spezifikation, Code, Tests, Commits, Abhängigkeiten und Bereitstellung enthalten.

Der hier zu untersuchende Fehler ist ein Zugriffskontrollfehler: Ein nicht vorgesehener Aufrufer erhält die Befugnis, Token zu prägen, Auszahlungen vorzunehmen, den Betrieb anzuhalten oder Upgrades durchzuführen. Um diese Phase zu testen, halten Sie das Ergebnis unter denselben Zeit-, Umfangs- und maßgeblichen Vertragsbedingungen fest und ändern Sie anschließend eine Annahme, bevor Sie implementieren und testen. Bei Risiken von Smart Contracts hält eine belastbare Übergabe fest, wer die Änderung genehmigt hat, welche Aufzeichnung geändert wurde, was sich noch rückgängig machen lässt und wer den Verlust trägt, falls der nächste Beteiligte die Belege zurückweist.

2. Implementieren und testen: Die Entscheidungsregel bei Risiken von Smart Contracts ermitteln

Verwenden Sie geprüfte Komponenten sowie Unit-, Integrations-, Eigenschafts- und Angriffstests. In diesem Teil der Risiken von Smart Contracts prüft dieser Schritt die Bedingungen, auf die sich das Audit des bereitgestellten Systems stützen kann. Der Auditor steht im Mittelpunkt, weil er eine klar abgegrenzte Version prüft und seine Feststellungen berichtet. Die Arbeitsdokumentation sollte Prüfungsumfang, Methoden, Annahmen, Schweregrad, Korrekturen und Restrisiko enthalten.

Der hier zu untersuchende Fehler ist ein Abrechnungs-Exploit: Rundungsfehler, Reentrancy, Anteilspreisbildung oder die Reihenfolge von Zustandsänderungen erzeugen Wert aus dem Nichts. Um diese Phase zu testen, berechnen Sie das Ergebnis unter denselben Zeit-, Umfangs- und maßgeblichen Vertragsbedingungen erneut und ändern Sie anschließend eine Annahme, bevor Sie das bereitgestellte System auditieren. Bei Risiken von Smart Contracts hält eine belastbare Übergabe fest, wer die Änderung genehmigt hat, welche Aufzeichnung geändert wurde, was sich noch rückgängig machen lässt und wer den Verlust trägt, falls der nächste Beteiligte die Belege zurückweist.

3. Das bereitgestellte System auditieren: Die Risikoübertragung bei Risiken von Smart Contracts messen

Überprüfen Sie Quellcode, Bytecode, Parameter, Abhängigkeiten, Schlüssel und betriebliche Kontrollen. In diesem Teil der Risiken von Smart Contracts ordnet dieser Schritt die Bedingungen neu zu, auf die sich Betrieb und Überwachung stützen können. Ein Orakel oder externes Protokoll steht im Mittelpunkt, weil es Preise, Nachrichten, Token oder Liquidität bereitstellt. Die Arbeitsdokumentation sollte Datenquellen, Aktualisierungen, Manipulationsresistenz, Administrator und Vorfälle festhalten.

Der hier zu untersuchende Fehler ist eine Orakelmanipulation: Ein vorübergehender oder illiquider Preis bestimmt Kreditaufnahme, Swaps oder Liquidationen. Um diese Phase zu testen, prüfen Sie die Belastbarkeit des Ergebnisses unter denselben Zeit-, Umfangs- und maßgeblichen Vertragsbedingungen und ändern Sie anschließend eine Annahme, bevor Sie den Betrieb aufnehmen und überwachen. Bei Risiken von Smart Contracts hält eine belastbare Übergabe fest, wer die Änderung genehmigt hat, welche Aufzeichnung geändert wurde, was sich noch rückgängig machen lässt und wer den Verlust trägt, falls der nächste Beteiligte die Belege zurückweist.

4. Betrieb aufnehmen und überwachen: Die maßgebliche Aufzeichnung für Risiken von Smart Contracts abgleichen

Überwachen Sie Werte, Anomalien, Orakel, privilegierte Aktionen und Änderungen an Abhängigkeiten. In diesem Teil der Risiken von Smart Contracts gleicht dieser Schritt die Bedingungen ab, auf die sich Reaktion und Governance stützen können. Governance und Schlüsselinhaber stehen im Mittelpunkt, weil sie Parameter ändern, den Betrieb anhalten, Upgrades durchführen oder Vermögenswerte verschieben können. Die Arbeitsdokumentation sollte Rollen, Quorum, Zeitsperre, Abstimmungen, Verwahrung der Schlüssel und Ereignisverlauf enthalten.

Der hier zu untersuchende Fehler ist der Ausfall einer Abhängigkeit: Ein Token, eine Bridge, ein Pool oder eine Blockchain verhält sich anders als angenommen. Um diese Phase zu testen, vergleichen Sie das Ergebnis unter denselben Zeit-, Umfangs- und maßgeblichen Vertragsbedingungen und ändern Sie anschließend eine Annahme, bevor Sie reagieren und Governance-Maßnahmen ergreifen. Bei Risiken von Smart Contracts hält eine belastbare Übergabe fest, wer die Änderung genehmigt hat, welche Aufzeichnung geändert wurde, was sich noch rückgängig machen lässt und wer den Verlust trägt, falls der nächste Beteiligte die Belege zurückweist.

5. Reagieren und Governance ausüben: Das Endergebnis der Risiken von Smart Contracts prüfen

Unter der offengelegten Zuständigkeit pausieren, aktualisieren, entschädigen, migrieren oder die Unveränderlichkeit akzeptieren. In diesem Teil zum Risiko von Smart Contracts legt dieser Schritt die Bedingungen fest, auf die sich das dokumentierte Ergebnis stützen kann. Der Nutzer oder Integrator steht im Mittelpunkt, weil er die Risiken des Codes und seiner Abhängigkeiten akzeptiert. Die Arbeitsdokumentation sollte Adresse, Version, Freigaben, Transaktionssimulation, Beschränkungen und Ausstiegsmöglichkeiten festhalten.

Wird dieser Punkt nicht hinterfragt, kann es zum Missbrauch des Notfallschlüssels kommen: Ein Wiederherstellungsmechanismus wird zum Angriffsweg oder ist im Krisenfall nicht verfügbar. Um diese Phase zu prüfen, muss das Ergebnis anhand desselben Zeitpunkts, desselben Umfangs und derselben maßgeblichen Bedingungen belegt werden. Anschließend ist eine Annahme zu ändern, bevor das Ergebnis dokumentiert wird. Eine belastbare Übergabe im Zusammenhang mit dem Risiko von Smart Contracts hält fest, wer die Maßnahme genehmigt hat, welcher Datensatz geändert wurde, was weiterhin rückgängig gemacht werden kann und wer den Verlust trägt, falls der nächste Beteiligte die Belege zurückweist.

Drei Zustände, die beim Risiko von Smart Contracts häufig verwechselt werden

Code-Risiko bedeutet, dass die Implementierung ihre vorgesehenen Invarianten verletzt oder einen Grenzfall fehlerhaft behandelt. Beim Orakel- und Kompositionsrisiko stützt sich der lokal korrekte Code dagegen auf einen falschen Preis, eine falsche Nachricht, ein abweichendes Tokenverhalten oder einen falschen externen Zustand. Governance- und Upgrade-Risiko kommt als dritte Bedingung hinzu: Berechtigte Akteure können nach der Prüfung das Verhalten, Parameter oder Vermögenswerte ändern. Diese Unterscheidungen sind wichtig, denn zwei Nutzer können eine ähnlich wirkende Bestätigung sehen und dennoch unterschiedliche Rechte haben, mit unterschiedlichen Zeitabläufen konfrontiert sein oder von unterschiedlichen Institutionen abhängen. Beim Risiko von Smart Contracts sollte ein aussagekräftiger Vergleich für jeden Zustand die maßgebliche Dokumentation und den Verlustträger benennen.

Vergleichen Sie Code-Risiko, Orakel- und Kompositionsrisiko sowie Governance- und Upgrade-Risiko anhand derselben Bezugsgrößen: Betrag, Zeit, gebundene Liquidität, Umkehrbarkeit, Rechtsanspruch und verbleibender Verlust. Beim Risiko von Smart Contracts bedeutet eine schnellere Einstufung nicht automatisch einen endgültigeren Zustand, und eine gleichmäßiger ausgewiesene Rendite bedeutet nicht automatisch ein geringeres wirtschaftliches Risiko. Ein einheitlicher Bewertungsrahmen verhindert, dass Unterschiede bei Zeitabläufen oder der Rechnungslegung mit einer tatsächlichen Verbesserung verwechselt werden.

Kosten, Anreize und Bilanzwirkungen des Risikos von Smart Contracts

Die Ausgaben für Sicherheit sollten sich nach dem maximalen Wert und der Unumkehrbarkeit richten, nicht nach dem Tokenpreis oder der Sichtbarkeit im Marketing. Audits, formale Methoden, Überwachung und Prämien für das Aufdecken von Schwachstellen ergänzen einander, decken aber unterschiedliche Bereiche ab.

Komponierbarkeit schafft Netzwerkwert, weil Verträge Liquidität und Dienste gemeinsam nutzen können. Sie führt jedoch auch zu miteinander verknüpften Abhängigkeiten: Der Ausfall eines Orakels oder Tokens kann sich auf zahlreiche Protokolle ausbreiten, bevor die Governance reagiert.

Die Möglichkeit, ein System zu aktualisieren, lässt Spielraum, Fehler zu beheben und sich anzupassen; Nutzer zahlen dafür jedoch einen Aufschlag für das Governance-Risiko. Zeitverzögerungen bei Änderungen, vielfältig zusammengesetzte Mehrfachsignaturen, eng gefasste Berechtigungen, Obergrenzen und transparente Ereignisprotokolle können diesen Aufschlag senken, ohne zu behaupten, dass es keine Administratoren gibt.

Wo das Risiko von Smart Contracts zum Tragen kommt – und was zuerst zu prüfen ist

• Fehler in der Zugriffskontrolle: Ein nicht vorgesehener Aufrufer erhält die Berechtigung zum Prägen, Abheben, Pausieren oder Aktualisieren. Unterbrechen, Rechte und Invarianten festlegen, während der Protokollentwickler seiner üblichen Verpflichtung nachkommt; anschließend prüfen, ob Code-Risiko weiterhin die oben beschriebene Bedeutung hat.
• Abrechnungs-Exploit: Rundung, Reentranz, die Bewertung von Anteilen oder die Reihenfolge von Zustandsänderungen erzeugt Wert aus dem Nichts. Unterbrechen, implementieren und testen, während der Auditor seiner üblichen Verpflichtung nachkommt; anschließend prüfen, ob Orakel- und Kompositionsrisiko weiterhin die oben beschriebene Bedeutung hat.
• Orakelmanipulation: Ein vorübergehender oder illiquider Preis bestimmt Kreditaufnahme, Tauschgeschäfte oder Liquidationen. Die Prüfung des bereitgestellten Systems unterbrechen, während das Orakel oder das externe Protokoll seiner üblichen Verpflichtung nachkommt; anschließend prüfen, ob Governance- und Upgrade-Risiko weiterhin die oben beschriebene Bedeutung hat.
• Ausfall einer Abhängigkeit: Ein Token, eine Bridge, ein Pool oder eine Blockchain verhält sich anders als angenommen. Unterbrich den Betrieb und die Überwachung, während Governance und Schlüsselinhaber ihren üblichen Verpflichtungen weiterhin nachkommen, und prüfe anschließend, ob das zuvor beschriebene Code-Risiko noch dieselbe Bedeutung hat.
• Missbrauch eines Notschlüssels: Ein Wiederherstellungsmechanismus wird zum Angriffspfad oder ist während einer Krise nicht verfügbar. Unterbrich die Reaktion und Steuerung, während Nutzer oder Integratoren ihren üblichen Verpflichtungen weiterhin nachkommen, und prüfe anschließend, ob das zuvor beschriebene Oracle- und Kompositionsrisiko noch dieselbe Bedeutung hat.

Ein aussagekräftiger Stresstest für Smart-Contract-Risiken kombiniert einen Fehler in der Zugriffskontrolle mit einer Manipulation des Oracles, anstatt beides isoliert zu prüfen. Unterbrich oder verzögere die Prüfung des bereitgestellten Systems, mache Governance und Schlüsselinhaber nicht verfügbar und verlange von Nutzern oder Integratoren, das Ergebnis anhand der Adresse, Version, Berechtigungen, Transaktionssimulation, Limits und Ausstiegsmöglichkeiten nachzuvollziehen. Der Entwurf besteht den Test nur, wenn die Reaktion und Steuerung zu einem einzigen nachvollziehbaren Zustand führen, die mit Oracle- und Kompositionsrisiken verbundenen Rechte gewahrt bleiben und etwaige Fehlbeträge nach Regeln zugewiesen werden, die bereits vor der Störung galten.

Durchgespieltes Beispiel: Ein Smart-Contract-Risikoereignis von Anfang bis Ende nachvollziehen

Ein Kreditvertrag wurde geprüft, doch der Preis seiner Sicherheiten stammt aus einem einzigen Pool mit geringer Liquidität. Ein Angreifer manipuliert den Preis dieses Pools vorübergehend, nimmt einen Kredit auf, der den tatsächlichen Wert der Sicherheiten übersteigt, und zieht sich zurück, bevor das Oracle den Preis korrigiert. Der Kreditcode funktionierte genau wie geschrieben; das System versagte, weil die Annahmen zum Vertrauen in das Oracle und zur Liquidität unsicher waren. Eine gründliche Prüfung würde den vollständigen Abhängigkeitsgraphen modellieren und das Risiko durch manipulierbare Sicherheiten begrenzen.

Das Beispiel lässt sich widerlegen, indem man die Annahme ändert, die bei der Implementierung und beim Testen zugrunde gelegt wurde, oder die vom Oracle oder einem externen Protokoll gelieferten Belege entfernt. Verfolge die Änderung durch die Prüfung des bereitgestellten Systems, den Betrieb und die Überwachung sowie die Reaktion und Steuerung; springe nicht direkt von der Eingabe zum Endergebnis. Lässt sich das neue Ergebnis des Smart-Contract-Risikos nicht anhand der Spezifikation, des bereitgestellten Quellcodes und Bytecodes, der Tests und Prüfungen, der Parameter und Administratorrollen, der Oracle- und Abhängigkeitsübersicht, der überwachten Ereignisse, der Reaktion auf Vorfälle und der Verlustverteilung nachvollziehen, beruht der Prozess auf einem undokumentierten Ermessen oder Datensatz.

Warum Smart-Contract-Risiken jetzt wichtig sind

Formale Verifikation, kontinuierliche Überwachung, Prämien für das Aufdecken von Sicherheitslücken, modulare Abschottung und bessere Wallet-Simulationen erhöhen die Sicherheit von Smart Contracts. Gleichzeitig vergrößern aktualisierbare Proxys und kettenübergreifende Abhängigkeiten das Governance-Risiko. Die nützlichste Offenlegung benennt den bereitgestellten Code, privilegierte Befugnisse, den Oracle-Pfad, Wertgrenzen und den Plan zur Verlustverteilung in einer Sprache, die Nutzer überprüfen können.

Die zentrale, dauerhafte Erkenntnis zu Smart-Contract-Risiken ist, dass Rechte und Invarianten festzulegen nicht dasselbe ist wie zu reagieren und zu steuern. Die dazwischenliegenden Entscheidungen bestimmen die zugesicherte finanzielle Invariante und jede Code-, Daten- und Governance-Abhängigkeit, die sie verändern kann; dabei können Protokollentwickler und Nutzer oder Integratoren unterschiedliche Teile der Dokumentation einsehen. Automatisierung ist wertvoll, wenn sie diese Entscheidungen leichter überprüfbar macht; gefährlich ist sie, wenn sie diese zu einem einzigen Status zusammenfasst und dadurch den Missbrauch eines Notschlüssels verschleiert.

Die Belege zu Smart-Contract-Risiken

Die wichtigsten Belege zu Smart-Contract-Risiken stammen aus dem NIST-Rahmenwerk für Cybersicherheit, dem BIS-Bericht zu den Risiken von DeFi für die Finanzstabilität und dem DeFi-Bericht des Technologiebeirats der CFTC. Sie sollten als einander ergänzende Ebenen gelesen werden: Regeln und Definitionen, institutionelle oder Marktstrukturen sowie die operativen Belege, die nötig sind, um eine konkrete Behauptung zu überprüfen. Keiner dieser Texte sollte als Ersatz für die oben beschriebenen Produktdokumente, Konten oder Transaktionsaufzeichnungen dienen.

Fragen, die vor dem Vertrauen auf Angaben zu Smart-Contract-Risiken zu stellen sind

• Kann der Protokollentwickler die Spezifikation, den Code, die Tests, Commits, Abhängigkeiten und Bereitstellung belegen, bevor implementiert und getestet wird?
• Welcher Datensatz ist maßgeblich, wenn Prüfer, Governance und Schlüsselinhaber unterschiedlicher Meinung sind?
• Wer finanziert oder trägt das Risiko, das bei der Prüfung des bereitgestellten Systems entsteht?
• Worin unterscheiden sich Oracle- und Kompositionsrisiken rechtlich und wirtschaftlich von Code-Risiken?
• Wie würde das System einen Buchführungs-Exploit erkennen, bevor Maßnahmen ergriffen und die Steuerung übernommen wird?
• Was geschieht, wenn das Oracle oder ein externes Protokoll nicht verfügbar ist oder seine Belege veraltet sind?
• Kann ein unabhängiger Prüfer das Ergebnis anhand der Spezifikation, des bereitgestellten Quellcodes und Bytecodes, der Tests und Prüfungen, der Parameter und Administratorrollen, der Oracle- und Abhängigkeitsübersicht, der überwachten Ereignisse, der Reaktion auf Vorfälle und der Verlustverteilung nachvollziehen?

Bei Smart-Contract-Risiken sollten Formulierungen wie „Die Plattform kümmert sich darum“ durch konkrete Konten, Verträge, Zeitstempel, Genehmigungsregeln und verantwortliche Stellen ersetzt werden. Eine vollständige Antwort sollte es Prüfern ermöglichen, von der Reaktion und Steuerung zu den festgelegten Rechten und Invarianten zurückzugehen, den Verantwortlichen für jeden Datensatz zu ermitteln und vor Eintritt eines Ausnahmefalls zu berechnen, wer den Verlust trägt.

Der zentrale Grundsatz zu Smart-Contract-Risiken

Das Risiko von Smart Contracts lässt sich am klarsten beurteilen, wenn die Analyse der zugesicherten finanziellen Invariante und sämtlichen Abhängigkeiten von Code, Daten und Governance folgt, die diese im Verlauf der fünf Betriebsphasen verändern können. Anschließend wird das Ergebnis anhand der Spezifikation, des bereitgestellten Quellcodes und Bytecodes, der Tests und Audits, der Parameter und Admin-Rollen, der Orakel- und Abhängigkeitsübersicht, der überwachten Ereignisse, der Reaktion auf Vorfälle und der Verlustverteilung überprüft. Der Ablauf erläutert, was sich ändert; die Teilnehmertabelle zeigt, wer diese Änderung genehmigen kann; der Vergleich der drei Zustände verhindert, dass unterschiedliche Aussagen miteinander vermengt werden; und die Fehlerübersicht zeigt, an welchen Stellen das Vertrauen sinken sollte. Diese Kombination macht den Unterschied zwischen einer tatsächlichen Verbesserung und zusätzlichem Aufwand oder einem Risiko aus, das in eine weniger sichtbare Ebene verlagert wurde, deutlich.

Primärquellen zum Risiko von Smart Contracts

• NIST-Rahmenwerk für Cybersicherheit
• BIS: Risiken von DeFi für die Finanzstabilität
• DeFi-Bericht des Technologiebeirats der CFTC