Tapscript und Skriptbäume (MAST)

Neugier

1. Warum sollte das Ausgeben nach einer einzigen Klausel eines Vertrags den gesamten Vertrag offenlegen?
2. Was macht eine kooperative Ausgabe ununterscheidbar von einer einfachen Signatur?
3. Wie kann sich ein einziger Schlüssel auf eine ganze Bibliothek verborgener Ausgabebedingungen festlegen?

Erkunden

1. Merkelized Abstract Syntax Trees (MAST) wurden erstmals 2013 von Russell O’Connor beschrieben und in Vorschlägen von 2016 und 2017 weiterentwickelt. Das Konzept legte alternative Ausgabebedingungen in einen Merkle-Tree, sodass ein Ausgebender nur den Zweig offenlegen musste, den er tatsächlich nutzte. Während sich der Begriff „Abstract Syntax Tree“ auf Compiler-Strukturen bezog, in denen jede Bedingung einen neuen Knoten erzeugt, entwickelte sich die Umsetzung in Bitcoin anders. Anthony Towns prägte später das Backronym „Merklized Alternative Script Tree“, um die tatsächlich übernommene Struktur zu beschreiben: eine Menge vollständiger, unabhängiger Scripts, von denen beim Ausgeben nur eines ausgewählt wird.
2. Taproot verankerte diese Baumstruktur über BIP341 in den Konsensregeln. Jedes Blatt des Merkle-Trees enthält ein Script, und die Wurzel des Baums fließt in den endgültigen Output-Schlüssel ein. Werden Mittel über den „Script Path“ ausgegeben, legt der Ausgebende das konkrete Leaf-Script, dessen Inputs und den Merkle-Beweis offen – die Hashes der Geschwisterknoten auf jeder Ebene. Die ungenutzten Zweige bleiben on-chain verborgen, was die Privatsphäre bei komplexen Konstruktionen wie Multisig oder Timelocks wahrt, die zuvor in P2SH-Wrapper gezwungen wurden.
3. Tapscript (BIP342) ist der spezielle Dialekt für diese Leaf-Scripts und weicht in mehreren entscheidenden Punkten vom herkömmlichen Bitcoin Script ab. OP_CHECKMULTISIG ist in Tapscript deaktiviert. Sein Ersatz, OP_CHECKSIGADD, prüft eine Signatur gegen einen Schlüssel und erhöht einen laufenden Zähler um 1; eine leere Signatur erhöht nichts, während eine ungültige, nicht leere Signatur das gesamte Script scheitern lässt. Ein Script reiht pro Schlüssel einen solchen Opcode aneinander und vergleicht den Zählerstand mit dem Schwellenwert. Jede Signatur wird einem bekannten Schlüssel zugeordnet, sodass kein Zuordnen durch Ausprobieren nötig ist und Signaturen per Batch verifiziert werden können.
4. Tapscript hält außerdem mit OP_SUCCESS-Opcodes Raum für Upgrades frei: Heute ist jedes Script, das einen davon enthält, bedingungslos gültig, weshalb niemand sie verwendet – und ein künftiger Soft Fork kann ihnen restriktive Bedeutungen geben, ohne etwas ungültig zu machen, das in Gebrauch ist. Die bisherige Grenze von 10.000 Bytes für die Script-Größe entfällt in Tapscript; stattdessen ist die Script-Größe nur durch das Blockgewicht und Policy-Limits begrenzt. Zudem skaliert ein Budget für Signaturoperationen mit der Größe des Witness und verhindert so Denial-of-Service-Angriffe durch übermäßige Signaturprüfungen.
5. Betrachten wir ein praktisches Beispiel: Ein Nutzer hält Mittel in einem 2-of-2-Key-Path für alltägliche Ausgaben, bei dem beide Parteien gemeinsam signieren, sodass nichts als eine gewöhnliche Schnorr-Signatur sichtbar wird. Der Script-Baum enthält jedoch ein verborgenes Leaf, mit dem ein einzelner Schlüssel nach einem einjährigen Timelock allein ausgeben kann. Reagiert der kooperierende Partner nicht mehr, kann der Nutzer diesen Wiederherstellungszweig aktivieren. Der Merkle-Beweis legt nur dieses konkrete Timelock-Script offen, während andere mögliche Zweige – etwa Social Recovery oder Hashlocks – vollständig privat bleiben.
6. Um diese Mechanik zu überprüfen, öffnen Sie einen Block-Explorer und suchen Sie eine Taproot-Transaktion, die über den Script Path ausgegeben wurde. Untersuchen Sie den Witness: die Inputs des Scripts, das Leaf-Script selbst und einen Control Block, dessen erstes Byte die Leaf-Version (0xc0 für Tapscript) mit einem Paritätsbit kombiniert, gefolgt vom internen Schlüssel und einem 32-Byte-Hash pro Ebene des Baums. Vergleichen Sie dies mit einer Key-Path-Ausgabe desselben Adresstyps; diese zeigt nur eine 64- oder 65-Byte-Signatur und keinerlei Script-Daten – ein Beleg dafür, dass komplexe Verträge unsichtbar bleiben, solange sie nicht genutzt werden.

Kernfakten

Übung neun, sechs, drei, eins

Faktcheck

Datumsangaben, Zahlen und Behauptungen wurden mit den unten aufgeführten veröffentlichten Quellen abgeglichen.

• BIP341: Taproot: SegWit version 1 spending rules
• BIP342: Validation of Taproot Scripts
• Bitcoin Optech, 'MAST' and 'Tapscript' topics
• Anthony Towns, 'Merklized Alternative Script Trees' proposal discussions