Cube erklärt: Smart Contracts auf Bitcoin, ohne Bitcoin zu verändern?

Bitcoin ist bewusst einfach gehalten. Die Skriptsprache ist begrenzt und der Base-Layer langsam und teuer, wenn man ihn mit klassischen Smart-Contract-Plattformen vergleicht. Genau das ist aber kein Versehen oder Fehler, sondern genau genommen Teil des Sicherheitsmodells.

Bitcoin soll als alternatives Geldsystem schließlich möglichst robust, überprüfbar und widerstandsfähig bleiben.

Das Problem ist, dass viele Anwendungen, die man von Ethereum oder anderen Smart-Contract-Systemen kennt, sich nicht direkt auf Bitcoin abbilden lassen. Dazu zählen etwa komplexe Finanzanwendungen, automatisierte Märkte, Stablecoins, Kreditprotokolle oder andere programmierbare Vertragslogiken.

Klar kann man geteilter Meinung sein, ob es so etwas auf Bitcoin überhaupt braucht, dennoch will Cube diese Lücke schließen, ohne Bitcoin selbst zu verändern. Laut dem veröffentlichten Konzept soll Cube eine virtuelle Maschine sein, die „trustless smart contract execution natively on Bitcoin“ ermöglicht und dabei auf BitVM, sogenannte Timeout Trees und Bitcoin als Settlement-Layer setzt.

Cube versucht, Bitcoin um eine Art programmierbare zweite Ebene zu erweitern. Nutzer sollen dort Smart Contracts verwenden können, ohne ihre Bitcoin an eine klassische Bridge, eine Federation oder einen zentralen Betreiber abgeben zu müssen.

Der (entscheidende) Anspruch von Burak ist eben nicht „Gib deine BTC an ein anderes System und vertraue darauf, dass du sie später zurückbekommst“, sondern eher: „Deine BTC bleiben durch Bitcoin-Regeln und vorbereitete Exit-Pfade abgesichert, während darüber eine programmierbare Umgebung läuft.“

Der Betreiber dieser Umgebung heißt bei Cube „Engine“. Diese Engine koordiniert Transaktionen, sortiert sie in Batches und schlägt neue Zustände vor. Sie soll aber nicht die Coins der Nutzer verwahren können. Im Normalfall arbeitet sie sozusagen kooperativ. Im Streitfall sollen Nutzer über Bitcoin selbst aussteigen oder falsche Zustände anfechten können.

Die Lösung besteht nicht darin, Bitcoin zu verändern. Sie besteht darin, darauf aufzubauen. Eine effektive Layer-2-Lösung muss die Fähigkeiten von Bitcoin erweitern, ohne seine grundlegenden Eigenschaften zu beeinträchtigen. Sie muss programmierbare Smart Contracts ermöglichen und gleichzeitig die Garantie der Selbstverwahrung bewahren, sodass kein Vermittler die Gelder eines Nutzers beschlagnahmen oder einfrieren kann. Und sie muss dies erreichen, ohne Änderungen am Bitcoin-Protokoll zu erfordern, ohne vertrauenswürdige Zwischeninstanzen einzuführen, die stehlen können, und ohne die Nutzer dazu zu zwingen, Verfahren, Komitees oder Bridge-Betreibern zu vertrauen, die sie nie kennengelernt haben.
^{Burak, Zitat aus dem Whitepaper}

Um das Konzept besser zu verstehen, hilft eventuell ein grober Vergleich mit Lightning.

Im Lightning-Netzwerk sperren bekanntlich zwei Parteien Bitcoin in einen sogenannten „Channel“, der im Grunde nichts anderes als ein 2-aus-2-Vertrag ist. Danach können die beiden Teilnehmer quasi unbegrenzt Zahlungen off-chain, sprich außerhalb des Bitcoin-Netzwerks, durchführen. Sollte eine Partei nicht mehr kooperieren, kann die andere den Kanal „on-chain“ schließen.

Cube denkt dieses Prinzip nun noch weiter. Es geht nicht mehr nur um Zahlungen, sondern um programmierbare Zustände. Also nicht nur „Alice zahlt Bob 10.000 Sats“, sondern auch „Alice hinterlegt BTC in einem Vertrag, dessen Logik bestimmt, wie die Ansprüche letztlich verteilt werden.“

Ein zentrales Element sind sogenannte Timeout Trees. Stark vereinfacht gesagt sind das vorab vorbereitete Transaktionsbäume, mit denen viele virtuelle Besitzansprüche zusammengefasst werden können.

Timeout Trees sind wahrscheinlich der wichtigste Baustein von Cube, weil sie das grundlegende Problem lösen, wie viele Nutzer gleichzeitig Smart Contracts nutzen können, ohne dass jede einzelne Aktion direkt auf der Bitcoin-Blockchain gespeichert werden muss. Man kann sich einen Timeout Tree wie einen bereits im Voraus geplanten Entscheidungsbaum vorstellen. Am Anfang steht ein gemeinsamer Bitcoin-Output, von dem aus viele mögliche zukünftige Auszahlungswege vorbereitet werden. Diese Wege müssen normalerweise nie genutzt werden und existieren zunächst nur als „Notfallplan“. Solange alle Beteiligten kooperieren, werden Zustandsänderungen, Transaktionen und Smart-Contract-Aktionen lediglich virtuell beziehungsweise off-chain aktualisiert. Dadurch können tausende Nutzer miteinander interagieren, ohne ständig „teuren“ Bitcoin-Blockspace zu verbrauchen.

Der entscheidende Punkt ist jedoch, dass jeder dieser virtuellen Ansprüche einen eigenen sogenannten Exit-Pfad besitzt. Sollte die Engine ausfallen, offline gehen oder sich sogar böswillig verhalten, muss der Nutzer nicht darauf hoffen, dass ihm jemand seine Coins freiwillig auszahlt. Stattdessen kann er auf einen bereits vorbereiteten Bitcoin-Pfad zurückgreifen. Hier kommen dann auch die namensgebenden „Timeouts“ ins Spiel. Jeder Ast im Baum besitzt eine festgelegte Wartezeit. Nach Ablauf dieser Frist darf der Nutzer seinen Anspruch direkt auf Bitcoin geltend machen. Bitcoin selbst überprüft dabei lediglich die Signaturen und die Zeitbedingungen. Die Bitcoin-Software muss weder verstehen, was der Smart Contract gemacht hat, noch die gesamte Historie der Anwendung nachvollziehen.

Ein praktischer Vergleich wären bei einem Notar hinterlegte, viele versiegelte Notfallumschläge. Im Alltag nutzt niemand diese Umschläge, weil alle Beteiligten normal zusammenarbeiten. Sollte aber jemand verschwinden oder sich nicht mehr an die Regeln halten, darf nach einer bestimmten Wartezeit der passende Umschlag geöffnet werden, der genau beschreibt, wem welcher Anteil zusteht. Die Auszahlung kann dann direkt durch Bitcoin erfolgen. 

Dadurch entsteht eine wichtige Sicherheitseigenschaft. Nutzer müssen der Engine zwar für den normalen Betrieb vertrauen, aber nicht für die endgültige Kontrolle über ihre Bitcoin. Selbst wenn Cube als System ausfällt, bleibt der Rückweg auf die Bitcoin-Blockchain immer erhalten.

Der eigentliche Vorteil liegt entsprechend in der Skalierung. Anstatt für jeden Nutzer und jede Smart-Contract-Aktion eine eigene On-Chain-Transaktion zu benötigen, teilen sich viele Teilnehmer denselben Bitcoin-Anker. Die Blockchain dient nur als Absicherung im Hintergrund. Dadurch kann Cube deutlich mehr Aktivität ermöglichen, während die Sicherheit letztlich weiterhin von Bitcoin und nicht von einem zentralen Betreiber abhängt.

Noch nicht vollständig geklärt ist allerdings, wie flexibel neue Nutzer in bereits bestehende Timeout Trees integriert werden können, da die zugrunde liegenden Transaktionsbäume schließlich vorab vorbereitet und signiert werden. Es könnte also sein, dass die Teilnehmer eines einzelnen Timeout Trees jeweils feststehen und fix sind. Selbst wenn das zutrifft, würde das aber wohl nicht zwangsläufig die Skalierbarkeit des Gesamtsystems einschränken, da jederzeit neue Timeout Trees erzeugt werden können. Wie genau Cube diesen Prozess in der Praxis organisiert, geht aus dem bisherigen Whitepaper jedoch noch nicht eindeutig hervor, und um ehrlich zu sein, ist Burak vermutlich auch der einzige Mensch aktuell, der das komplexe System wirklich in seiner Gänze versteht.

Der zweite große Baustein hinter Cube ist BitVM. Über dieses Konzept haben wir bereits vor einiger Zeit bei Blocktrainer.de berichtet und auch einen Podcast dazu mit dem Erfinder, Robin Linus, aufgenommen. 

Die Idee hinter BitVM ist, dass Bitcoin komplexe Berechnungen nicht direkt ausführen muss. Stattdessen kann eine Partei behaupten: „Dieser neue Zustand ist korrekt.“ Eine andere Partei kann diese Behauptung im Streitfall anfechten. Wenn sich nachweisen lässt, dass die Berechnung falsch war, greifen vorher festgelegte Straf- oder Abwicklungspfade. Bitcoin wird so zwar nicht zur vollwertigen Smart-Contract-Chain, aber dient Smart-Contract-ähnlichen Berechnungen immerhin als Schlichtungs- oder Durchsetzungsschicht.

Cube verbindet Timeout Trees und BitVM in einem eigenen Konstrukt namens „Zero-Knowledge Time-Locked Contract (ZKTLC)“.

Vereinfacht gesagt ist ein ZKTLC ein virtueller Bitcoin-Anspruch, der zusätzlich eine überprüfbare Behauptung über eine Berechnung enthält. Der Nutzer hat also nicht nur einen Anspruch auf Coins, sondern auch ein Recht, falsche Zustandsübergänge anzufechten.

Der Kern des Modells ist, dass Cube nicht einfach nur virtuelle BTC bewegen will, sondern eben virtuelle BTC mit programmierbarer Logik verknüpfen möchte.

Damit Smart Contracts überhaupt möglich werden, führt Cube zusätzlich eine eigene virtuelle Maschine ein, die sogenannte CubeVM.

Diese wird als erweiterte Variante von Bitcoin Script beschrieben. Sie soll zusätzliche Funktionen ermöglichen, etwa globale Zustände, fortschrittliche Speicherverwaltung, 256-Bit-Arithmetik, elliptische Kurvenoperationen, Contract Calls und spezielle sogenannte Shadowing-Befehle (dazu gleich mehr).

Anstatt die Ausführungsphilosophie von Bitcoin zu ersetzen, erweitert CubeVM das stapelbasierte Ausführungsmodell von Bitcoin Script zu einer programmierbaren Umgebung mit globalem Zustand, die für einseitige Ausstiege und widerlegbare Berechnungen optimiert ist. CubeVM ergänzt Bitcoin Script um zusätzliche Opcodes, die für allgemeine Smart-Contract-Berechnungen erforderlich sind. Die virtuelle Maschine [wurde] speziell dafür entwickelt, direkt mit Bitcoin als zugrunde liegendem Asset zu arbeiten.
^{Burak, Zitat aus dem Whitepaper}

CubeVM ist damit also nicht einfach eine Kopie der Ethereum Virtual Machine, sondern von Grund auf auf Bitcoin-Eigenschaften wie unter anderem das UTXO-Modell ausgerichtet.

Cube verspricht im Kern drei Dinge:

Erstens: Bitcoin soll programmierbarer werden, ohne Bitcoin selbst zu verändern.
Zweitens: Nutzer sollen ihre BTC nicht an Bridges, Federations oder fremde Validatoren abgeben müssen.
Drittens: Falsche Zustände sollen über Bitcoin-nahe Mechanismen angefochten werden können.

Wenn das funktioniert, wäre Cube definitiv ein sehr interessanter Ansatz für die Skalierung von BTC und Bitcoin-native Smart Contracts mit stärkerem Selbstverwahrungsanspruch als viele bestehende Sidechain- oder Bridge-Modelle.

Trotzdem sollte man Cube ehrlicherweise nicht vorschnell als fertiges Produkt oder finale Lösung betrachten. Das Konzept ist technisch sehr ambitioniert. Viele Bestandteile sind extrem komplex, teils theoretisch und hängen davon ab, dass die beschriebenen Mechanismen auch in realen Umgebungen zuverlässig funktionieren.

Es gibt noch zahlreiche offene Fragen, die unter anderem die praktische Umsetzung, die Nutzerfreundlichkeit, oder die Liquiditätsanforderungen betreffen.

Gerade für Bitcoin ist nicht nur entscheidend, ob etwas theoretisch trustless ist und funktioniert, sondern auch, ob normale Nutzer in der Praxis damit zurechtkommen und im Ernstfall tatsächlich ihre Rechte und Besitzansprüche durchsetzen können.

Ob Cube diesen Anspruch praktisch einlösen kann, muss sich erst zeigen. Als Konzept ist es jedoch ein spannender Beitrag zur Frage, wie weit Bitcoin erweitert werden kann, ohne den Base-Layer und dessen Grundstruktur zu verändern.