Glossar / Protokoll und Upgrades
Taproot-Merkle-Zweig
- Was ist ein Taproot-Merkle-Zweig?
- Ein Taproot-Merkle-Zweig ist die Liste der Schwester-Hashes, die ein Ausgeben über einen Script-Pfad veröffentlicht, um zu belegen, dass das Script in der ausgegebenen Adresse verankert ist.
Spezifiziert im BIP-341.
Jeder Hash im Zweig ist ein Geschwister aus dem Taptree, in der Reihenfolge von Ihrem Blatt aufwärts bis zur Wurzel. BIP-341 begrenzt den Zweig auf 128 Hashes, 4.096 Bytes, und sein sortierter Baum sorgt dafür, dass der Zweig überhaupt keine Richtungsbits für links oder rechts enthält. Die Länge Ihres Zweigs ist öffentlich, ein tieferes Blatt verrät also die Mindesttiefe Ihres Baums und gibt Hinweise darauf, welche Wallet die Ausgabe erstellt hat.
Wie er funktioniert
Ein Taproot-Merkle-Zweig reist im Control Block, dem letzten Element auf dem Witness-Stack einer Ausgabe über einen Script-Pfad, nachdem ein etwaiger Annex entfernt wurde.
Der Control Block hat eine feste Form. Byte null trägt die Blattversion plus die Parität der Y-Koordinate des Ausgabeschlüssels. Die Bytes 1 bis 32 enthalten den internen öffentlichen Schlüssel. Alles danach ist der Zweig: m aufeinanderfolgende Hashes von 32 Bytes, der Control Block misst also 33 + 32m Bytes, und m muss eine ganze Zahl von 0 bis 128 sein. Jede andere Länge lässt die Ausgabe fehlschlagen, bevor auch nur ein einziger Opcode ausgeführt wird.
Die Verifikation beginnt unten. Ein Node hasht das offengelegte Script unter dem Tag TapLeaf und faltet dann der Reihe nach jeden Zweig-Hash unter dem Tag TapBranch hinein, wobei er bei jedem Schritt die beiden Werte von 32 Bytes lexikografisch vergleicht und den kleineren zuerst hasht. Was herauskommt, ist die Wurzel des Taptree, die mit dem internen Schlüssel unter dem Tag TapTweak gehasht, zum internen Punkt addiert und gegen die 32 Bytes in der ausgegebenen Ausgabe geprüft wird.
Dieser Vergleich ist der ganze Trick. Weil BIP-341 die beiden Kinder vor dem Hashen sortiert, sagt ein Zweig nie, auf welcher Seite ein Geschwister stand: Der Prüfer ermittelt es selbst. Die Begründung dafür ist unverblümt: Sie sagt, das Design kümmere sich nicht um die Position bestimmter Scripts im Baum, sondern nur darum, dass sie tatsächlich verankert sind.
Die Obergrenze von 128 ist eine Sicherheitsgrenze und keine willkürliche Kappung. Die Tiefe in einem optimal gepackten Baum liegt nahe am Logarithmus zur Basis zwei von eins durch die Wahrscheinlichkeit eines Blatts, eine Tiefe von 129 würde also ein Script mit einer Nutzungswahrscheinlichkeit unter 1 in 2^128 bedeuten, das laut BIP-341 wahrscheinlich ohnehin gelöscht werden kann. Am anderen Ende hat ein Taptree mit einem einzigen Blatt ein m von 0, einen leeren Zweig und einen Tapleaf-Hash, der bereits die Wurzel ist.
Wo er auftritt
Taproot-Merkle-Zweige erscheinen in jeder Transaktion, die eine bc1p-Ausgabe ausgibt, indem sie ein Script offenlegt, statt mit dem Schlüssel zu signieren.
BIP-341 führt ein Beispiel an einem Baum aus fünf Blättern durch. A, B, C und E sind TapLeaf-Hashes, und AB ist ein TapBranch-Hash über die ersten beiden. Um mit Script D auszugeben, trägt der Control Block C, dann E, dann AB: drei Hashes, 96 Bytes Zweig, ein Control Block von 129 Bytes. E wird vor CD gehasht, wenn diese beiden kombiniert werden, weil E niedriger sortiert.
Die Kosten für die Privatsphäre sind das, worauf Sie sich einstellen sollten. Der Sicherheitsabschnitt von BIP-341 sagt, die Tiefe eines Scripts verrate die Mindesttiefe des Baums, was auf die Wallet-Software hindeute, die die Ausgabe erstellt hat, und der Chain-Analyse helfe, Adressen zu gruppieren, und er empfiehlt, vom Baum abzuweichen, den die Blattwahrscheinlichkeiten ergeben würden. Die Wiederverwendung von Blättern ist die andere Falle: Das Ausgeben einer anderen Ausgabe kann dieselben Zweig-Hashes erneut veröffentlichen, zwei Ausgaben mit einem gemeinsamen Geschwister von 32 Bytes wirken also verwandt.
Taproot-Merkle-Zweig vs. Merkle-Block
Ein Taproot-Merkle-Zweig beweist, dass ein Script zu einer Adresse gehört; ein Merkle-Block beweist, dass eine Transaktion zu einem Block gehört. Der Taptree-Zweig ist konsensrelevant, wird von jedem Full Node neu berechnet, der die Ausgabe validiert, und er ist positionsfrei, weil die Sortierung die Notwendigkeit beseitigt hat, links oder rechts zu sagen. Ein Nachweis über den Transaktionsbaum eines Blocks kann diesen Trick nicht übernehmen, da die Reihenfolge der Transaktionen unter der Merkle-Wurzel eines Blocks fest und bedeutungstragend ist, er muss also den Weg ebenso wie die Hashes mitführen.