# Smart Contracts: Code ist nicht automatisch ein Vertrag

Ein Smart Contract ist ein Programm, das auf einer Blockchain ausgeführt wird und dort Zustand verwaltet. Er kann Token übertragen, Sicherheiten sperren, Abstimmungen zählen oder einen digitalen Marktplatz steuern. „Smart“ bedeutet dabei nicht intelligent, und „Contract“ bedeutet nicht automatisch einen rechtlich wirksamen Vertrag.

Der Name stammt aus der Idee, Vertragslogik technisch auszuführen. Ob daneben rechtliche Ansprüche bestehen, hängt von Parteien, Erklärungen, Inhalt und geltendem Recht ab. Code kann eine Leistung automatisieren; er ersetzt keine pauschale juristische Prüfung.

Wie ein Smart Contract lebt

Auf Ethereum wird ein Vertrag durch eine Transaktion bereitgestellt. Sein Bytecode und Zustand erhalten eine Adresse. Nutzer oder andere Verträge rufen Funktionen auf, indem sie Transaktionen beziehungsweise interne Aufrufe senden.

Jeder vollständige Knoten führt dieselben gültigen Transaktionen nach den Regeln der Ethereum Virtual Machine aus und berechnet denselben neuen Zustand. Dadurch braucht es keinen zentralen Anwendungsserver, der allein die Datenbank kontrolliert.

Der Vertrag läuft nicht von selbst zu einer beliebigen Uhrzeit. Eine Transaktion muss die Ausführung anstoßen. Automatisierungsdienste können solche Aufrufe senden, bilden dann aber eine zusätzliche Abhängigkeit.

Deterministisch, aber nicht allwissend

Alle Knoten müssen dasselbe Ergebnis erhalten. Ein Smart Contract kann deshalb nicht einfach eine zufällige Website aufrufen oder das lokale Wetter lesen. Externe Informationen kommen über Orakel in die Blockchain.

Das Orakelproblem lautet: Der Vertrag kann sauber berechnen, was mit einem gemeldeten Preis geschehen soll, aber nicht selbst feststellen, ob der Preis aus der Außenwelt richtig ist. Ein fehlerhaftes oder manipuliertes Orakel kann korrekten Code zu falschen wirtschaftlichen Ergebnissen führen.

Robuste Anwendungen verwenden mehrere Quellen, Verzögerungen, Plausibilitätsgrenzen oder Notfallmechanismen. Trotzdem bleibt Vertrauen in Datenlieferanten und Governance.

Gas begrenzt Rechenarbeit

Jede Operation verbraucht Gas. Nutzer legen eine maximale Gasmenge und Gebührenparameter fest. Das verhindert, dass ein Programm unendlich läuft und alle Knoten blockiert.

Schlägt die Ausführung fehl, werden Zustandsänderungen üblicherweise zurückgerollt, verbrauchtes Gas bleibt aber bezahlt. Die Knoten haben die Rechenarbeit trotzdem geleistet.

Komplexer Code, große Speicheränderungen und hohe Netzwerknachfrage erhöhen Kosten. Ein Vertrag kann technisch funktionieren und wirtschaftlich unbrauchbar sein, wenn eine kleine Aktion teurer als ihr Nutzen wird.

Unveränderlich – außer wenn nicht

Ein bereitgestellter Vertragscode lässt sich an seiner Adresse normalerweise nicht direkt umschreiben. Viele Projekte verwenden jedoch Proxy-Konstruktionen: Eine feste Adresse leitet Aufrufe an eine austauschbare Implementierung weiter. Administratoren können Logik aktualisieren.

Das ermöglicht Fehlerbehebung und neue Funktionen, schafft aber Macht. Prüfe:

  • Ist der Vertrag upgradefähig?
  • Wer kontrolliert das Upgrade?
  • Nutzt die Kontrolle eine Multisignatur?
  • Gibt es Zeitverzögerungen?
  • Können Nutzer vor einer Änderung aussteigen?
  • Existiert ein Pausen- oder Sperrschalter?

„Unveränderlicher Code“ ist nur korrekt, wenn keine indirekten Änderungs- oder Administrationswege bestehen.

Typische Fehlerklassen

Smart Contracts sind Software und können Fehler haben. Bekannte Risiken umfassen:

  • Reentrancy: Externer Code ruft eine Funktion erneut auf, bevor der interne Zustand sicher aktualisiert wurde.
  • Fehlerhafte Zugriffskontrolle: Unbefugte können administrative Funktionen nutzen.
  • Oracle-Manipulation: Ein ungeeigneter Preis oder Datenfeed wird beeinflusst.
  • Rundungs- und Einheitenfehler: Dezimalstellen oder Reihenfolgen erzeugen falsche Beträge.
  • Front-Running und MEV: Andere sehen eine Transaktion vorher und ordnen eigene wirtschaftlich vorteilhaft darum.
  • Ungeprüfte externe Aufrufe: Ein fremder Vertrag verhält sich anders als erwartet.
  • Upgrade-Fehler: Neue Logik beschädigt Speicherstruktur oder Rechte.

Audits senken Risiko, garantieren aber keine Fehlerfreiheit. Umfang, Version, Prüfzeit und behobene Befunde müssen nachvollzogen werden.

„Code is law“ stößt an Grenzen

Wenn ein Fehler Vermögenswerte überträgt, kann die Blockchain die Transaktion technisch gültig behandeln. Rechtlich kann trotzdem Diebstahl, Irrtum oder unwirksame Vereinbarung vorliegen. Durchsetzung und Rückholung sind separate Fragen.

Umgekehrt kann ein Vertrag etwas verweigern, obwohl eine Partei nach staatlichem Recht Anspruch hätte. Dann braucht es Gerichte, identifizierbare Parteien oder andere Rechtsmittel außerhalb des Codes.

Viele seriöse Anwendungen kombinieren technische Regeln mit Nutzungsbedingungen, Gesellschaften und definiertem Recht. Prüfe, wer Betreiber ist, welcher Gerichtsstand gilt und ob der Smart Contract oder ein Textdokument im Widerspruch Vorrang beansprucht.

Token-Freigaben verstehen

Bei ERC-20-Token erteilt eine Wallet häufig eine `approve`-Freigabe. Der aufgerufene Vertrag darf danach bis zum genehmigten Betrag Token über `transferFrom` bewegen. Unbegrenzte Freigaben sparen wiederholte Transaktionen, vergrößern aber den möglichen Schaden.

Kontrolliere Spender-Adresse, Token und Betrag. Widerrufe nicht mehr benötigte Freigaben. Eine Freigabe an einen kompromittierten Vertrag kann riskant bleiben, auch wenn du die ursprüngliche Website nicht mehr besuchst.

Signaturanfragen können außerdem Off-Chain-Nachrichten betreffen, die später eine Aktion autorisieren. „Keine Gasgebühr“ bedeutet nicht „keine Wirkung“.

Zusammensetzbarkeit: Stärke und Kettenreaktion

Smart Contracts können andere Verträge wie Bausteine verwenden. Ein Kreditprotokoll nutzt Token, Börse und Orakel. Diese Zusammensetzbarkeit ermöglicht schnelle Innovation, verbindet aber Risiken.

Fällt ein Stablecoin aus der Preisbindung, kann er Sicherheiten entwerten. Ein fehlerhaftes Orakel löst Liquidationen aus. Eine angegriffene Brücke beeinträchtigt Token auf mehreren Anwendungen. Der eigene Vertrag kann sauber sein und trotzdem durch Abhängigkeiten verlieren.

Erstelle eine Liste externer Verträge, Orakel, Brücken, Administratoren und Frontends. „Audit bestanden“ eines einzelnen Bausteins deckt die gesamte Kette nicht ab.

Open Source und verifizierter Code

Ein Explorer kann anzeigen, dass veröffentlichter Quellcode zum bereitgestellten Bytecode passt. Das erleichtert Prüfung. Es beweist nicht, dass der Code sicher oder die Adresse offiziell ist.

Nicht verifizierter Code ist schwerer zu beurteilen. Verifizierter Code kann trotzdem komplex, absichtlich schädlich oder falsch konfiguriert sein. Prüfe Vertragsadresse aus unabhängiger Quelle und achte auf Proxy-Implementierungen.

Adminschlüssel, Parameter und tatsächliche Nutzung sind ebenso wichtig wie der Quelltext. Ein Vertrag kann heute sicher konfiguriert und morgen durch Governance geändert werden.

Was Nutzer vor einer Interaktion prüfen können

Du musst keinen Solidity-Code lesen, um grundlegende Fragen zu stellen:

  1. Welche Aktion zeigt die Wallet genau?
  2. Welcher Vertrag und welches Netzwerk sind beteiligt?
  3. Wie hoch sind Betrag, Gaslimit und Tokenfreigabe?
  4. Ist die Adresse offiziell verifiziert?
  5. Gibt es Auditberichte mit Datum und Version?
  6. Wer besitzt Admin- und Upgrade-Rechte?
  7. Welche externen Orakel oder Brücken sind kritisch?
  8. Kannst du mit einem kleinen Betrag testen?

Nutze eine getrennte Wallet für experimentelle Anwendungen. So gefährdet eine schlechte Freigabe nicht automatisch langfristig verwahrte Bestände.

Wann eine normale Datenbank besser ist

Wenn eine Organisation alle Daten ohnehin kontrolliert, Transaktionen rückgängig machen muss und Nutzer ihr vertrauen, kann ein gewöhnlicher Server einfacher, günstiger und datenschutzfreundlicher sein.

Smart Contracts sind besonders interessant, wenn mehrere Parteien gemeinsame Regeln ausführen wollen, ohne einer einzelnen operativen Stelle vollständige Kontrolle zu geben. Auch dann müssen Orakel, Governance und Recht gelöst werden.

„Auf der Blockchain“ ist kein Selbstzweck. Eine langsamere, teurere Datenbank lohnt nur, wenn überprüfbare Ausführung und Zensurresistenz einen echten Nutzen bringen.

Fazit

Smart Contracts sind deterministische Programme auf einer Blockchain. Sie können Vermögenswerte und Regeln transparent ausführen, sind aber weder intelligent noch automatisch rechtlich vollständig. Fehler, Orakel, Upgrades und Freigaben schaffen Risiken außerhalb der hübschen Benutzeroberfläche.

Prüfe Codeversion, Administratoren und Abhängigkeiten. Und behalte den wichtigsten Satz im Kopf: Technisch ausgeführt bedeutet nicht automatisch wirtschaftlich sinnvoll oder rechtlich unangreifbar.

Quellen und Prüfhinweis

Geprüft am 21. September 2026. Verträge, Adminrechte und Audits ändern sich; prüfe immer die konkrete Adresse, Version und aktuelle Konfiguration.