„Das, was auf der Chain ankommt, ist eine einzelne Signatur. Das ist Taproot.“

Eines der Upgrades von Bitcoin, über das schon lange geredet wird, aber das kaum jemand versteht, ist Taproot. Mit dem Vorschlag sollen Smart Contracts auf Bitcoin privater und platzsparender werden. Ob und wann er umgesetzt wird, ist zwar noch nicht bekannt. Wir erklären die Idee aber anhand eines Vortrags von Blockstreams Chefwissenschaftler Andrew Poelstra.

Andrew Poelstra, Chefwissenschaftler von Blockstream, beschreibt in einem Talk auf der virtuellen Konferenz MIT Bitcoin Expo das Konzept von Taproot. Wer noch nie etwas über Taproot gehört hat: Das ist eine von Blockstream und Gregory Maxwell entwickelte Technologie, um Smart Contracts auf Bitcoin in einer Weise zu signieren, die besonders privat und platzsparend ist.

Taproot selbst ist herrlich oder fürchterlich komplex, je nach Perspektive, und um es zu verstehen, sollte man das eine oder andere über die innere Mechanik von Bitcoin wissen. Daher erklärt Poelstra es auch nicht in der vollen Tiefe, sondern streift eher an der Oberfläche. Das macht seinen Vortrag recht gut geeignet, um ihn hier zusammenzufassen.

Scripte in Bitcoin

Taproot, erklärt Poelstra, „ist ein Vorschlag für Bitcoin, der von Pieter Wuille, Gregory Maxwell und mir selbst entwickelt wurde. Im Lauf der letzten ein oder zwei Jahre haben aber etwa 10 Leute mitgearbeitet und verschiedene Dinge über IRC oder die Mailing-List beigetragen.“ Taproot sei „eine neue Version eines Transaktions-Outputs“, was bedeute, „dass es eine neue Bedingung meint, Bitcoins auszugeben.“

Um das zu verstehen, muss man ein wenig tiefer in Bitcoin eintauchen. Bitcoin hat nämlich ein „Scripting System“. Das ist „die Möglichkeit, eine Bedingung zu spezifizieren, wann Coins ausgegeben werden können.“ Die typische Bedingung ist diese: Es gibt eine Adresse, die einen öffentlichen Schlüssel repräsentiert, und wer eine Transaktion mit dem dazu passenden privaten Schlüssel signiert, kann die Coins ausgeben. Dies ist aber, meint Poelstra, „in Wahrheit ein Sonderfall von dem, was Bitcoin tun kann.“ Denn man kann „beliebige Bedingungen beschreiben, wann man Coins ausgeben kann.“ So kann man etwa Hashes prüfen, „was bedeutet, man legt eine Hash von bestimmten Daten auf der Blockchain ab, und die Bedingung ist dann, dass nur der, der das Preimage der Hash“ – also die zugrundeliegenden Daten – „enthüllt, die Coins ausgeben kann.“ Man kann ferner „Timelocks“ bilden, „die es nicht erlauben, die Coins zu bewegen, bevor eine bestimmte Zeit vergangen ist.“ Und so weiter. Man kann mit Script viele Bedingungen definieren.

Allerdings sind die meisten Dinge, die man mit Script machen kann, „nicht besonders aufregend.“ Es gibt vieles, das man nicht machen kann. Beispielsweise ein „Velocity Limit“, also ein Umlauflimit, was meint, dass man an einem einzelnen Tag nur eine bestimmte Menge an Coins bewegen kann. „Das ist eine Sache, die man nicht mit Bitcoin Script machen kann“, und es ist eine der Funktionen, die immer wieder gewünscht werden [soweit ich es sehe dürfte dies mit dem von sCrypt für Bitcoin SV entwickelten Pseudo-opcode OP_PUSH_TX möglich sein, seitdem das Genesis-Upgrade die vollständigen Scriptbefehle von Bitcoin wieder hergestellt hat. Aber das nur am Rande].

Eine weitere Sache, die Poelstra an Script stört, ist die hohe Transparenz und der verschwenderische Umgang mit Platz auf der Blockchain. Er erklärt das durch das Beispiel eines Multisig-Vertrags, den zwei von drei Schlüsseln zeichnen, und bei dem es, für den Fall des Verlusts dieser Schlüssel, einen Backupschlüssel gibt, der aber erst nach Ablauf einer bestimmten Zeit signieren kann: „Man kann das machen, aber das, was auf der Blockchain eintrifft, wenn man Coins ausgibt, ist nur eine einzige Bedingung. Man hat das Script, das eine Menge an verschiedenen Sachen beschreibt, aber am Ende kommt es nur auf eine davon an. Nur eine einzige zählt, wenn die Coins ausgegeben sind.“ Allerdings müssen alle Bedingungen auf der Blockchain abgespeichert, enthüllt und validiert werden. Es wäre, meint Poelstra, „ideal, wenn man nicht alle diese Bedingungen enthüllen müsste. Wenn gewöhnlich nur eine zählt, warum veröffentlichen wir dann alle? Warum zwingen wir jeden, sie herunterzuladen? Warum zwingen wir jeden, sie zu parsen? Warum zwingen wir jeden, zu prüfen, ob sie sinnvoll sind, und so weiter?“

Von MAST zu Taproot

Aus diesem Grund wurde schon 2011 oder 2012 eine Idee entwickelt. Die Idee heißt „MAST“, was die Abkürzung von „Merklized Abstract Syntax Tree“ ist. Bei ihr geht es darum, „dass man alle diese verschiedenen Bedingungen nimmt und in einen Hashbaum (Merkle-Tree) packt. Man nimmt diese Bedingungen, hasht sie, und dann nimmt man alle diese Hashes, bündelt sie zusammen und hasht das ganze wieder. Damit bekommt man ein kryptographisches Objekt, das es erlaubt, eine der Bedingungen oder ein Subset der Bedingungen zu enthüllen, ohne alle enthüllen zu müssen.“

Ein Hashbaum bündelt viele Hashes in der „Wurzel“. Dadurch würde die Transaktion kleiner werden: Am Ende schlägt lediglich eine 32 Byte große Hash auf der Blockchain auf, die sämtliche möglichen Bedingungen enthält.

Diese Idee ist schon eine Weile da, wurde aber niemals implementiert. „Ein Grund dafür ist, dass etwas wie MAST eine weite und tiefe Änderung von Bitcoin ist,“ und sich keiner traue, eine solche Änderung einzuführen, bevor klar ist, dass der beste mögliche Vorschlag vorliegt. „Wir hatten in den letzten Jahren viele Variationen von etwas wie MAST, verschiedene Methoden, um den Inhalt der Scripte zu verbergen.“ Keine hat sich durchgesetzt. Doch Taproot soll es werden – die beste mögliche Methode, um Skripte in einem Hashbaum zu verbergen.

Ein solcher Hashbaum ist ein Teil von Taproot. „Man packte alle Bedingungen, um Coins auszugeben, in einen Hashbaum. Enthüllen muss man nur eine. Niemand kann sehen, wie viele es gibt. Niemand kann sehen, welches die anderen sind. Alles ist großartig.“

Der zweite Teil von Taproot sind, was Poelstra „Schlüssel-Tricks“ nennt. Üblicherweise gibt es bei Bitcoin Adressen, die an einen einzelnen privaten Schlüssel gebunden sind, und wenn man die Coins auf dieser Adresse ausgibt, signiert man die Transaktion mit diesem Schlüssel. Der Schlüssel gehört üblicherweise einem Individuum und identifiziert die Person, die in der Lage ist, Bitcoins auszugeben. Allerdings „kann man noch viel mehr mit Schlüssel machen.“ Eine Menge davon ist einfacher, wenn man Transaktionen mit Schnorr anstatt ECDSA signiert. Daher soll das Taproot-Upgrade auch Schnorr-Signaturen zu Bitcoin bringen.

Ein Beispiel sind Multisig-Signaturen, also Transaktionen, die von mehreren Sendern signiert werden. Dabei allerdings schlagen nicht mehrere Signaturen auf der Blockchain auf, sondern mehrere Sender arbeiten zusammen, um eine gültige Signatur zu produzieren. Mit ECDSA muss man hierfür mehr oder weniger einen Umweg gehen, und keine echte Signatur bereitstellen, sondern eine Hash der verbundenen Signaturen. Mit Schnorr ist eine Art „natives“ Multisig möglich, so dass eine Multisig-Transaktion genauso aussieht wie eine normale Transaktion. Dadurch werden selbst sehr große Multisig-Transaktionen – bei denen etwa 58 von 115 Teilnehmern signieren müssen – genauso klein wie eine gewöhnliche Transaktion.

Ein anderes Beispiel ist es, einen Schlüssel an eine Hash von Daten zu binden. „Wofür ist das gut? Es ist gut für einige Dinge wie Timestamps und so. Wenn ich Daten habe, und ich wil beweisen, dass ich diese Daten schon zu einem bestimmten Zeitpunkt hatte, dann kann ich sie in einem meiner öffentlichen Schlüssel verstecken, die ich sowieso auf die Blockchain bringen wollte.“ Taproot erlaubt es, solche Schlüsseltricks mit einer hohen Privatsphäre und nur geringem Platz auf der Blockchain auszuführen.

„Das ist Taproot“

Mit Taproot werden all diese Arten von Smart Contracts also in eine normale Transaktion eingestampft: Man nimmt eine Hash und validiert diese gegen den Hashbaum, der in einem öffentlichen Schlüssel einer Bitcoin-Adresse steckt. Wenn die Hash gültig ist, dann kann man eine Transaktion mit einer einfachen Signatur zeichnen, unabhängig davon, welche Bedingung sie erfüllt und welche es sonst noch gibt. „Niemand sieht, dass weitere Bedingungen auch nur existieren. Wenn man zeichnet, sehen sie nur eine Bedingung.“ Egal was man macht – eine einfache Transaktion, einen Lightning-Channel, eine Treuhand-Transaktion – „das, was auf der Chain ankommt, ist eine einzelne Signatur.“

Der Vorteil davon liegt für Poelstra auf der Hand: Es ist günstiger für alle, als wenn man sämtliche Bedingungen explizit auf der Blockchain ablädt. „Es ist auch besser für die Privatsphäre, da man nicht enthüllt, welche Bedingungen es gibt, wodurch man auch nicht enthüllt, dass es besondere Bedingungen gibt. Man enthüllt auch nicht, wie viele Teilnehmer involviert sind, wie viele Parteien beteiligt sind, und wie die Beteiligung gestaltet ist. Das ist Taproot.“