Was ist ein Smart Contract, und was kann schiefgehen?

Smart Contract ist einer der irreführenderen Begriffe in Krypto, weil er ein juristisches Wort für etwas entlehnt, das streng genommen kein Vertrag ist. Es ist ein auf einer Blockchain gespeichertes Programm, das automatisch läuft, wenn bestimmte Bedingungen erfüllt sind, ohne Bank, Broker oder Gericht dazwischen. Diese Automatisierung ist der Reiz, und sie ist auch die Quelle des meisten Risikos. Dieser Leitfaden erklärt, was ein Smart Contract tatsächlich tut, wo die Idee in der Praxis eingesetzt wird, und die Hauptkategorien dessen, was schiefgeht, wenn sich der Code nicht so verhält, wie seine Autoren es beabsichtigt hatten.

Was ein Smart Contract tatsächlich ist

Entfernt man den Namen, ist ein Smart Contract ein Stück Software, das auf einer Blockchain bereitgestellt wird, meist Ethereum oder einem ähnlichen programmierbaren Netzwerk. Einmal bereitgestellt, liegt sein Code an einer festen Adresse und kann in der Regel nicht mehr geändert werden, sofern die Entwickler nicht im Voraus einen bestimmten Upgrade-Mechanismus eingebaut haben. Jeder kann ihm eine Transaktion senden, und das Netzwerk der Validatoren führt den Code exakt wie geschrieben aus und aktualisiert dadurch den gemeinsamen Zustand der Blockchain. Es gibt keine Kundendienst-Hotline und, in den meisten Fällen, keine Möglichkeit, ein Ergebnis rückgängig zu machen, sobald es bestätigt wurde.

Das unterscheidet sich grundlegend von einer traditionellen Vereinbarung. Ein Papiervertrag beschreibt Absicht in natürlicher Sprache, und ein Gericht oder Schiedsrichter interpretiert diese Absicht, falls ein Streit entsteht. Ein Smart Contract hat keinen Interpreten. Er tut exakt das, was sein Code sagt, selbst wenn das stark von dem abweicht, was die Parteien für selbstverständlich hielten. Der in den frühen Tagen Ethereums populäre Satz „the code is law“ fasst das wörtlich zusammen: Das Ergebnis ist, was das Programm berechnet, nicht was irgendjemand für fair hält. In der Praxis hat diese Idee reale Grenzen, die die späteren Abschnitte dieses Leitfadens behandeln.

Wo Smart Contracts tatsächlich eingesetzt werden

Das Konzept klingt abstrakt, bis es an konkrete Beispiele gebunden wird. Drei Anwendungsfälle machen den Großteil der Aktivität auf programmierbaren Blockchains heute aus.

• Swaps auf dezentralen Exchanges. Auf Automated-Market-Maker-Designs aufgebaute Protokolle lassen Nutzer einen Token direkt gegen einen gepoolten Bestand gegen einen anderen tauschen, wobei der Wechselkurs durch eine Formel statt ein Orderbuch festgelegt wird. Der Smart Contract hält die Gelder und führt den Swap in einer einzigen Transaktion aus.
• Lending und Borrowing. DeFi-Lending-Protokolle nutzen Smart Contracts, um Sicherheiten zu akzeptieren, Kredite auszugeben, Zinsen nachzuverfolgen und, falls der Sicherheitenwert zu stark fällt, eine automatisierte Liquidation auszulösen, alles ohne einen Kreditsachbearbeiter, der die Anfrage prüft.
• Token-Ausgabe. Die meisten Token jenseits des nativen Assets einer Blockchain, einschließlich der Mehrheit der auf Ethereum gebauten Assets, sind selbst Smart Contracts, die Angebot, Übertragungsregeln und Eigentumseinträge definieren.

In jedem Fall ist der Reiz derselbe: Transaktionen wickeln sich automatisch ab, gemäß öffentlicher Regeln, die jeder im Voraus prüfen kann, ohne dass Teilnehmer einer bestimmten Institution vertrauen müssen.

Die praktischen Grenzen von „the code is law“

Code als letztes Wort zu behandeln klingt theoretisch sauber, gerät aber in Schwierigkeiten, sobald der Code von dem abweicht, was Menschen beabsichtigt hatten. Ein häufig zitiertes Beispiel ist der Zusammenbruch eines Projekts namens The DAO im Jahr 2016, bei dem ein Angreifer eine Schwachstelle in der Logik des Contracts ausnutzte, um einen großen Anteil der gepoolten Gelder abzuziehen, wobei er Funktionen nutzte, die technisch exakt wie geschrieben funktionierten. Die Reaktion der Ethereum-Community, ein umstrittener Netzwerk-Split, der Ethereum und Ethereum Classic hervorbrachte, bleibt eine lebendige Illustration dafür, dass „the code is law“ eine Designphilosophie ist, kein Naturgesetz. Ist das Ergebnis disruptiv genug, können Teilnehmer sich dennoch entscheiden, auf Ebene des zugrunde liegenden Netzwerks einzugreifen.

Außerhalb solch extremer Fälle ist die häufigere Spannung leiser. Ein Contract kann fehlerfrei ausführen und trotzdem ein Ergebnis produzieren, das niemand wollte, weil der Code eine bestimmte Abfolge von Transaktionen, eine bestimmte Marktbedingung oder eine bestimmte Kombination von Eingaben nicht antizipiert hat. Dafür gibt es im Allgemeinen keinen eingebauten Einspruchsprozess.

Was schiefgehen kann: die Hauptkategorien

Berichte über Smart-Contract-Ausfälle fallen tendenziell in eine Handvoll wiederkehrender Kategorien, und zwischen ihnen zu unterscheiden ist wichtig, weil sie unterschiedliche Sorgfalt erfordern, bevor man sich auf ein Protokoll verlässt.

• Fehler und Exploits. Fehler im Code selbst, etwa fehlerhafte Zugriffskontrollen, Integer-Überläufe oder Logik, die es erlaubt, eine Funktion in einer unbeabsichtigten Reihenfolge aufzurufen (ein Muster hinter vielen Reentrancy-Exploits), können einem Angreifer erlauben, Gelder abzuziehen oder Token unautorisiert zu minten. Das sind Programmierfehler, und sobald ein Contract live und unveränderlich ist, sind sie oft schwer oder unmöglich zu patchen.
• Oracle-Manipulation. Smart Contracts können nicht außerhalb ihrer eigenen Blockchain sehen. Braucht ein Contract externe Daten, etwa den Preis eines Assets, verlässt er sich auf einen „Oracle“-Dienst, der diese Information einspeist. Kann ein Angreifer den von einem Oracle gemeldeten Preis verzerren, und sei es nur kurz, kann er einen Lending- oder Trading-Contract dazu bringen, auf Basis falscher Informationen zu handeln — eine Technik hinter mehreren aufsehenerregenden DeFi-Verlusten.
• Admin-Key- und Upgrade-Risiko. Viele Contracts enthalten designbedingt eine Hintertür: einen Administrator-Schlüssel oder eine Multisig-Wallet, die den Contract pausieren, Parameter ändern oder den Code aktualisieren kann. Diese Flexibilität hilft Teams, Fehler schnell zu beheben, bedeutet aber auch, dass das System nicht vollständig autonom ist. Wird dieser Schlüssel kompromittiert, oder handelt das ihn haltende Team böswillig, erleiden Nutzer Verluste, die nichts mit einem Fehler in der Kernlogik zu tun haben.
• Ökonomische Designfehler. Nicht jeder Ausfall ist ein Programmierfehler. Ein Contract kann exakt wie beabsichtigt umgesetzt sein und trotzdem scheitern, weil seine ökonomischen Annahmen falsch waren, etwa eine Anreizstruktur, die unter normalen Bedingungen funktioniert, aber während extremer Volatilität oder einer Liquiditätsklemme zusammenbricht. Diese Kategorie ist schwerer zu auditieren, weil der Code technisch nicht „fehlerhaft“ ist; das zugrunde liegende Modell davon, wie sich Teilnehmer verhalten würden, war schlicht unvollständig.

Audits, Bug Bounties, und ihre Grenzen

Angesichts dieser Risiken beauftragen die meisten seriösen Projekte vor dem Start ein Sicherheitsaudit durch Dritte, und viele betreiben laufende Bug-Bounty-Programme, die unabhängige Forscher für das Melden von Schwachstellen bezahlen. Beide Praktiken reduzieren das Risiko spürbar. Ein von einer erfahrenen Firma durchgeführtes Audit findet typischerweise gängige Fehlermuster, und eine gut finanzierte Bug Bounty gibt White-Hat-Forschern einen finanziellen Anreiz, Schwachstellen vor Angreifern zu finden.

Keines von beiden ist eine Garantie. Ein Audit ist eine Überprüfung des Codes, wie er zu einem bestimmten Zeitpunkt existierte, durchgeführt unter Zeit- und Budgetbeschränkungen, und es kann nicht das Fehlen jedes möglichen Fehlers beweisen, sondern nur das Fehlen der Fehler, an die die Prüfer gedacht haben. Contracts, die mehrere Audits bestanden haben, wurden dennoch ausgenutzt, manchmal durch eine Schwachstelle außerhalb des geprüften Umfangs, manchmal durch einen ökonomischen Angriff statt einen Fehler auf Code-Ebene. Ein Audit-Abzeichen als Sicherheitszertifikat zu behandeln, statt als einen Eingabewert unter mehreren, ist ein häufiger und kostspieliger Fehler.

Für jeden, der ein auf Smart Contracts aufgebautes Protokoll nutzt, gehört zu einer vernünftigen Grundlage zu prüfen, ob der Contract auditiert wurde, von wem, wie lange her, ob ein Admin-Key existiert und wer ihn kontrolliert, und wie das Protokoll in der Vergangenheit mit Stress umgegangen ist. Nichts davon beseitigt Risiko, aber es ersetzt blindes Vertrauen durch ein informiertes Urteil, was der realistischere Standard ist, den Smart Contracts je bieten konnten. Leser, die diese Gewohnheit über ein Portfolio hinweg aufbauen, finden möglicherweise einen breiteren Risikorahmen nützlich, etwa den in roo2yas Methodik skizzierten, neben allgemeinen Recherchepraktiken wie DYOR.

Dieser Artikel dient ausschließlich Informationszwecken und stellt keine Finanzberatung dar.