Tapscript

BIP-342 definiert es, und das Leaf-Version-Byte 0xc0 kennzeichnet einen Zweig eines Taptree als Tapscript und nicht als etwas, das später erfunden wurde. Gegenüber der Skriptsprache, die überall sonst verwendet wird, entfallen die Grenze von 201 Nicht-Push-Operationen und die Obergrenze für die Skriptgröße von 10.000 Bytes, und OP_CHECKMULTISIG wird deaktiviert. Wenn Sie einen Taproot-Coin ausgeben, indem Sie ein Skript offenlegen, ist dies die Sprache, in der dieses Skript geschrieben ist.

Wie es funktioniert

Eine Tapscript-Ausgabe übergibt dem Netzwerk drei Dinge auf dem Witness-Stack: die Argumente, die das Skript verlangt, das Skript selbst und einen Kontrollblock, der beweist, dass das Skript zur Adresse gehört.

Zuerst änderte sich die Signaturprüfung. OP_CHECKSIG und OP_CHECKSIGVERIFY erwarten jetzt einen x-only öffentlichen Schlüssel von 32 Bytes und eine Schnorr-Signatur von 64 Bytes, oder 65 Bytes, wenn ein vom Standard abweichender Sighash-Typ angehängt wird. OP_CHECKMULTISIG und OP_CHECKMULTISIGVERIFY schlagen immer fehl, und OP_CHECKSIGADD tritt an ihre Stelle.

Zweitens änderte sich die Ressourcenabrechnung, und das ist der Teil mit echten Folgen. Die alten Zähler, 201 Operationen pro Skript und eine globale Sigop-Zählung, sind verschwunden. Stattdessen erhält jeder Input ein Validierungsbudget, das bei 50 Gewichtseinheiten plus der Größe seines eigenen Witness beginnt, und jede erfolgreiche Signaturprüfung zieht 50 davon ab. Verifizierungsarbeit wird mit Bytes bezahlt, was eine sauberere Regel als eine feste Anzahl ist und bedeutet, dass ein Skript so viele Schlüssel enthalten kann, wie man zu zahlen bereit ist.

Zwei Türen blieben für künftige Upgrades offen. Die Opcodes 80, 98, 126 bis 129, 131 bis 134, 137, 138, 141, 142, 149 bis 153 und 187 bis 254 wurden zu OP_SUCCESS: Wenn einer von ihnen irgendwo im Skript vorkommt, selbst in einem Zweig, der nie ausgeführt wird, gelingt das Skript sofort. Öffentliche Schlüssel jeder Länge außer 32 Bytes werden als unbekannter Schlüsseltyp behandelt und akzeptiert. Beide Regeln erlauben es einer späteren Soft Fork, echtes Verhalten ohne eine Hard Fork zuzuweisen. Unverändert geblieben sind die Obergrenze von 520 Bytes für ein einzelnes Stack-Element und das Limit von 1.000 Elementen auf dem Stack.

Wo Sie es sehen

Tapscript tritt immer dann auf, wenn eine Taproot-Ausgabe auf dem schwierigen Weg ausgegeben wird, indem ein Zweig offengelegt wird, statt mit dem aggregierten Schlüssel zu signieren.

Der gewichtigste reale Nutzer ist die Datenspeicherung. Eine Ordinals-Inschrift ist ein Tapscript-Umschlag, ein Stück Inhalt, das in Abschnitten von 520 Bytes zwischen OP_FALSE OP_IF und OP_ENDIF eingefügt wird, und sie existiert genau in dieser Form, weil Tapscript die Skriptgrenze von 10.000 Bytes entfernt und den Witness-Rabatt dahinter gestellt hat. Was Sie von dieser Praxis auch halten mögen, sie ist der Grund, warum die meisten Menschen eine Tapscript-Ausgabe gesehen haben, ohne es zu wissen.

Die Verwendungen, die einem Sparer näher liegen, sind stiller. Zeitlich gesperrte Wiederherstellungszweige, Treuhand-Rückfalloptionen und die neueren Kanalskripte von Lightning liegen alle als Tapscript-Leaves vor, und Bitcoin Core kann sie über Miniscript innerhalb eines tr()-Deskriptors erstellen und signieren.

Tapscript vs. Bitcoin Script

Bitcoin Script ist die Familie; Tapscript ist eines ihrer Mitglieder. Drei Skriptversionen sind gleichzeitig im Netzwerk aktiv: die alte Sprache, die Sprache der SegWit-Version 0 und Tapscript, und ein Node wählt zwischen ihnen anhand der Ausgabe, die ausgegeben wird, nicht anhand von etwas im Skript selbst.

Das ist wichtig, wenn Sie ein Skript aus einer Anleitung kopieren. Ein Zwei-von-drei, das mit OP_CHECKMULTISIG geschrieben ist, ist in einer P2WSH-Ausgabe gültig und in einem Taptree-Leaf ungültig. Ein Skript, das 4.000 Bytes einfügt, überschreitet die Konsensgrenze in einem P2WSH-Witness-Skript und ist in Tapscript unproblematisch. Dieselben Opcodes auf der Seite, ein anderes Regelwerk darunter.