Demystifizierung von Smart Contracts

Smart Contracts sind weder smart noch contracts

„Smart“ heißt nach Langenscheidt Wörterbuch vorrangig: klug, aufgeweckt, intelligent, clever. Smart Contracts sind das nicht. Sie führen lediglich eine „if this then that“-Anweisung aus. Auf diese Grundfunktion reduziert, lernen sie nicht dazu, sondern führen einfach einen Befehl nach einem bestimmten Parameter aus. Das geschieht so, wie bei dem in diesem Zusammenhang oft zitierten Warenautomat, der nach dem Einwurf eines Geldbetrags, den der Automat selbst prüft („if this“), anschließend die gewünschte Ware ausgibt („then that“).

„Contract“ ist in der Wortwahl ebenfalls irreführend. Denn die Software, die den Befehl ausführt, ist kein Vertrag. Sie ist Teil der Erfüllung des Vertrags. Ein klassisches Beispiel für den Einsatz eines Smart Contracts ist der Warenautomat: Der Aufsteller des Warenautomats macht (in diesem spezifischen Fall) ein Angebot „ad incertas personas“ – also an einen unbestimmten Personenkreis. Das Angebot steht unter der Bedingung, dass die gewünschte Ware im Automaten verfügbar ist. Der Kunde nimmt das Angebot an, indem er eine Münze in den Automaten einwirft. So kommt der Kaufvertrag zustande. Durch den Münzeinwurf wird die Erfüllung automatisiert durchgeführt, der Warenautomat gibt die Ware aus („if this then that“). Die Ware wird nun an den Kunden übereignet. Der Akt der Erfüllung stellt also keinen Vertrag dar.

Smart Contracts auf der Blockchain

Smart Contracts werden oft im Zusammenhang mit der Blockchain genannt. Hintergründe zur Blockchain-Technologie werden in diesem Beitrag erläutert. Auch wenn sich Smart Contracts vielfältig einsetzen lassen, scheint eine Nutzung im Rahmen der Blockchain sehr attraktiv.

Die Blockchain steht für Transparenz und Sicherheit. Der Smart Contract liegt also offen einsehbar auf der Blockchain und dürfte stets funktionieren (kein singulärer Ausfallpunkt) und schwer manipulierbar sein (Konsensmechanismus aller Blockchain-Teilnehmer). Anders als beim Warenautomaten – hier könnte der Aufsteller natürlich den Automaten als Attrappe aufstellen und so auf kriminelle Weise Geld sammeln – kann der Kunde also dem Smart Contract auf der Blockchain vertrauen.

Das wird insbesondere für ICOs genutzt, die wir hier genauer erklären. Hier kann der Investor vorab (technisch) prüfen, ob er tatsächlich aufgrund der einprogrammierten Softwarebefehle die Anteile übertragen bekommen wird. Insoweit ist auch offen einsehbar und technisch nahezu unveränderbar, dass nur dann Kryptowährungen angenommen werden, wenn dafür genügend Tokens ausgeschüttet werden können. Bestimmte Beschränkungen (Cap) auf die Höhe der Investments oder verschiedene Investmentziele lassen also sich gleich mit einprogrammieren. Natürlich ist damit noch nicht sichergestellt, dass die erworbenen Tokens auch tatsächlich einen Wert haben oder im Wert steigen – denn dies hängt von Faktoren außerhalb der Technik ab.

„Code is law“

Im Zusammenhang mit Smart Contracts, die – wie dargestellt – keine Verträge sein dürften, ist noch auf die „Code is law“-Bewegung hinzuweisen. Die „Code is law“-Bewegung hat das (wohl idealistische) Ziel, dass der einer Software zugrunde liegende Code auch gleichzeitig das Vertragsverhältnis zwischen den Parteien abschließend regeln soll. Insoweit soll der Code nicht das „Recht“, sondern den „Vertrag“ abbilden. So ist das beispielsweise geschehen bei „The DAO“, (decentralized autonomous organization). Hier konnte man bei der ICO über einen Smart Contract Anteile an der DAO erwerben. Dazu erklärte the DAO ausdrücklich: „The DAO’s code controls and sets forth all terms of The DAO Creation”.

The DAO ist tatsächlich auch das Negativbeispiel für “Code is law”, weil im Code ein schwerwiegender Fehler vorlag, der einen großen Hack ermöglichte. Im Ergebnis wurde Ether der Kryptowährung Ethereum in großem Umfang gestohlen. Die Community entschied sich zu einem „Hard Fork“ der für den ICO genutzten Kryptowährung Ethereum, sodass die Auswirkungen des Hacks begrenzt werden konnten. Würde hier also „Code is law“ tatsächlich gelten, wäre der ausgeführte Hack kein Fehler, sondern ein Feature. Soweit wollte die Community dann aber auch nicht gehen. Insoweit dürfte nach wie vor ein Vertragswerk, das auslegungsbedürftig ist, die Interessen der Parteien besser abbilden als „Code is law“.

Ist „Code is law“ im deutschen Vertragsrecht denn möglich? Die Parteien sind im Grundsatz frei, wie sie ihren Vertrag aufsetzen, sofern nicht zwingende gesetzliche Regelungen entgegenstehen. So dürften beispielsweise die Transparenzvoraussetzungen an Verbraucher-AGB der Nutzung von „Code is law“ entgegenstehen. Bei derzeitigem Entwicklungsstand gilt außerdem: Software mag zwar feststellen, ob der Preis bezahlt wurde. Ob die Gegenleistung aber eine Schlechtleistung darstellt, ist eine komplexere Frage, die Software meist nicht abschließend bewerten kann.