Taproot kommt zu Bitcoin: Wie es funktioniert, seine Geschichte und seine Auswirkungen

Taproot- und Schnorr-Signaturen werden auf Bitcoin im Block 709,632 live geschaltet. Dies wird eine enorme grundlegende Errungenschaft sein, auf der wir auch in Zukunft aufbauen können. Es ist vier Jahre her, dass Segregated Witness im Netzwerk live ging, unser letztes großes Protokoll-Upgrade. Das ist so lang wie ein Halbierungszyklus!

Denk darüber nach. Vier Jahre von der Live-Schaltung von SegWit bis zur Live-Schaltung von Taproot. Langsame, methodische Geduld, wie es sein sollte. Aber die Geschichte von Taproot/Schnorr reicht noch viel weiter zurück.

Die Geschichte von Pfahlwurzel

Einige, die schon eine Weile hier sind, finden das vielleicht ironisch, aber die erste Erwähnung von Schnorr-Signaturen, die mir bekannt ist, stammt tatsächlich vom ehemaligen Bitcoin Core-Entwickler und späteren Unternehmens-Blockchain-Entwickler Mike Hearn. Im Jahr 2012 hat er erzogen die Idee einer neuen kryptografischen Kurve in Bezug auf die Batch-Verifizierung von Signaturen, um die Knotenvalidierung weniger rechenintensiv zu machen. Letztendlich hing der von ihm vorgeschlagene Plan von Schnorrs Unterschriften ab.

Adam Back sprach von „naiv“. Regelungen im Jahr 2014 unter Verwendung von Schnorr-Signaturen Multisig-Adressen zu erstellen, die wie Singlesig-Adressen aussahen. Sogar Gavin Andresen eingeschlossen Schnorr statt ECDSA auf seiner Wunschliste mit Änderungen, die er an Bitcoin vornehmen würde, wenn er einen Zauberstab schwenken könnte.

Seit den Anfängen von Bitcoin wollten die meisten Entwickler, die aktiv an Bitcoin Core beteiligt waren, Schnorr-Signaturen, und es herrschte immer ein ziemlich solider Konsens über deren Überlegenheit gegenüber ECDSA-Signaturen. Man könnte tatsächlich argumentieren, dass ECDSA speziell deshalb geschaffen wurde, weil das Schnorr-Signaturschema patentiert war und ein massiver Bedarf an einem kryptografischen Open-Source-Signaturschema bestand, das nicht durch Patente belastet war.

Schnorr ist viel effizienter und einfacher zu manipulieren (Dinge können zu Signaturen hinzugefügt, entfernt usw. werden, und wenn es richtig gemacht wird, können Benutzer immer noch gültige Signaturen hinterlassen, wenn sie diese haben sollten) als ECDSA. Die Verwendung von ECDSA war im Laufe der Jahre in den meisten kryptografischen Anwendungen eher eine Notwendigkeit als ein Wunsch.

Merkelized Abstract Syntax Trees (MAST), die Taproot-Hälfte dieses bevorstehenden Taproot-Upgrades, hat eine ähnlich lange Geschichte. Ich kann das Zitat nicht finden, aber ich erinnere mich noch gut daran, diesen Satz etwa 2013 oder 2014 von Leuten wie Peter Todd auf Bitcointalk.org gesehen zu haben.

Das Original BIP für MAST wurde 2016 von Johnson Lau vorgeschlagen. Dieser Vorschlag erlebte auch einige Aktivitäten um 2017, als Mark Friedenbach, BTCDrak und Kalle Alm ihn in zwei separate BIPs aufteilten (116 und 117) und erweiterte Laus ursprünglichen Vorschlag.

MAST saß das nächste Jahr lang in der Schwebe, bis Greg Maxwell die ursprüngliche Taproot-Idee hatte und veröffentlicht Senden Sie es an die Bitcoin-Dev-Mailingliste. Seine wichtigste Erkenntnis war, dass es in jedem Vertragsfall zwischen mehreren Beteiligten, der ihm einfiel, ein „optimales Ergebnis“ gab, bei dem der Vertrag dadurch abgewickelt werden konnte, dass jeder einfach das entsprechende Ergebnis unterzeichnete, anstatt das Ergebnis mit fortschrittlicheren Skripten und Transaktionen durchzusetzen. Dies ist die grundlegende Behauptung, auf der Taproot basiert, d. h. die Anpassung des MAST-Baums an einen regulären Schlüssel der obersten Ebene, der ausgegeben werden kann, ohne offenzulegen, ob überhaupt ein Merkle-Baum mit anderen Ausgabebedingungen existiert.

Der letzte Abschnitt dieser Geschichtsstunde beginnt mit der Ankündigung von Pieter Wiulle Entwürfe von BIPs für Schnorr und Taproot zusammen mit der Mailingliste am 6. Mai 2019. Im Januar 2020 wurde dies offiziell abgeschlossen BIPs 340, 341 und 342. Von diesem Zeitpunkt an waren es nur noch viele kleine Details, die auf der Implementierungsebene verfeinert wurden, ein gewisser Überprüfungszeitraum und dann das Langwierige Streit um Aktivierungsmechanismen. Das führt uns zu jetzt, knapp vor der Aktivierung.

Die Bedeutung von Schnorr-Signaturen

Was ist also das große Problem mit den Schnorr-Unterschriften? Zunächst einmal verkleinern sie die Transaktionen. Eine ECDSA-Signatur ist normalerweise etwa 72 Byte groß für eine einzelne Signatur in einer Transaktion. Schnorr-Signaturen umfassen maximal 64 Byte pro Signatur. Das entspricht einer Größeneinsparung von etwa 12 % im Vergleich zu ECDSA für jede Schnorr-Signatur. Dies ist sowohl ein direkter Vorteil für die Person, die Schnorr verwendet, die weniger Gebühren zahlt als ein ECDSA-Benutzer, als auch ein direkter Vorteil für Personen, die Schnorr nicht verwenden, da etwas weniger Daten in der Blockchain gespeichert werden müssen, um Schnorr einer anderen Person zu verarbeiten und zu validieren Unterschriften.

Weniger Daten zu speichern ist immer gut, aber was noch besser ist, ist die effizientere Validierung der zu speichernden Daten. Eine der netten Eigenschaften von Schnorr, die Linearität der Mathematik dahinter, ermöglicht auch eine nette Eigenschaft, die Sie in Bitcoin-Daten wünschen: Batch-Validierung. Wenn Ihr Knoten einen Block vom Netzwerk empfängt, analysiert er jede einzelne Transaktion und validiert jede Signatur einzeln.

Dies ist ein wesentlicher Grund dafür, dass die Validierung von Blöcken viel CPU-Leistung verbraucht. Schnorr-Signaturen können alle gestapelt und gleichzeitig mathematisch validiert werden, so als würde man sie zusammenschlagen und eine einzige mathematische Operation anstelle einer Reihe einzelner Operationen ausführen. Je mehr Schnorr-Signaturen vorhanden sind, desto größer ist die Recheneinsparung. Dies ist ein enormer Skalierungsgewinn für das Netzwerk.

Eine weitere massive Verbesserung, die Schnorr mit sich bringt, betrifft Multisignatur-Skripte. Jede Multisig-Adresse muss bei der Ausgabe explizit alle einzelnen öffentlichen Schlüssel offenlegen, die an einem Multisig-Skript beteiligt sind, und für jeden am Ausgabevorgang beteiligten Schlüssel muss eine Signatur bereitgestellt werden. Mit den mathematischen Eigenschaften von Schnorr öffnet sich die Tür für MuSig, einen Multisignaturstandard. Sie können Schlüssel einfach zusammenfügen und am Ende einen einzigen öffentlichen Schlüssel erhalten, den alle privaten Schlüsselanteile mithilfe neuer Signaturprotokolle signieren können. Jonas Nick von Blockstream Benchmarking MuSig2 hat zwei Minuten gebraucht eine Million Teilnehmer einer Multisig-Adresse zum Signieren. Die Skalierungsverbesserung bei Multisignatur-Skripten kann nicht unterschätzt werden.

Dieser enorme Fortschritt bei Multisignatur-Skripten hat auch enorme Auswirkungen auf das Datenschutzprofil und die Kosten zahlreicher auf Bitcoin basierender Anwendungen. MuSig-basierte Lightning-Kanäle können sich jetzt in den gesamten Anonymitätssatz von Schnorr/Taproot UTXOs in der Kette einfügen, da niemand mehr in der Lage sein wird, die Tatsache zu erkennen, dass es sich um eine Zwei-von-Zwei-Multisig-Ausgabe handelt.

Sie fügen sich nahtlos ein und sehen aus wie ein einzelnes Signaturskript. Das Gleiche gilt für jedes Multisig-UTXO im Allgemeinen. Dies wird viele Auswirkungen für Personen haben, die Multisignaturskripte verwenden, um ihren Cold Storage mit einem robusteren Sicherheits- und Wiederherstellungsmodell besser zu schützen als ein einzelnes Signaturskript.

Erstens wird es nicht offensichtlich sein, dass sie ein Multisig-Setup verwenden, wenn man die Blockchain beobachtet, so dass sie dadurch, wie im Fall von Lightning, mit allem anderen harmonieren. Ein entscheidender Vorteil liegt jedoch in wirtschaftlicher Hinsicht: Die Verwendung von Multisignatur erfordert derzeit die Bereitstellung einer separaten Signatur für jeden Schlüssel, der letztendlich an der Ausgabe eines UTXO beteiligt ist. Mit Schnorr/MuSig werden die Dinge zu einer einzigen Signatur für den einzelnen kombinierten öffentlichen Schlüssel komprimiert, was bedeutet, dass die Ausgabe von Multisig-UTXOs mit MuSig viel billiger wird, da weniger Daten in die Blockchain übertragen werden.

Eine letzte coole Sache, die Schnorr-Signaturen bewirken, ist die drastische Vereinfachung der Implementierung von Adaptersignaturen. Stellen Sie sich eine Adaptersignatur vor, die durch einen Wert „verschlüsselt“ wird, der zu einer gültigen Signatur hinzugefügt oder von ihr subtrahiert wurde. Es ist erst gültig, wenn Sie diese mathematische Operation rückgängig machen oder es mit dem „Schlüssel“ „entschlüsseln“, mit dem es manipuliert wurde. Dies ist mit ECDSA möglich, aber da die Mathematik im Vergleich zu Schnorr nichtlinear ist, ist es relativ kompliziert und bei der Implementierung sind viele Sicherheitsbedenken zu berücksichtigen.

Aufgrund der linearen Eigenschaften von Schnorr ist eine Adaptersignatur jedoch so einfach wie das Nehmen einer einzelnen Zahl (z. B. die Zahl 9,300,030) und das Subtrahieren eines Werts davon (z. B. 30). Sobald die Partei, die die Adaptersignatur besitzt, den subtrahierten Wert erfährt, kann sie ihn einfach wieder hinzufügen und hinzufügen voila, sie haben wieder eine gültige Signatur.

Die Auswirkungen von Pfahlwurzel

Wie oben etwas besprochen, ist Taproot in Wirklichkeit im Wesentlichen nur MAST, außer dass es nicht wie P2SH funktioniert (wo Sie das Skript hashen, oder im Fall von MAST die Merkle-Wurzel oben im Skriptbaum), sondern a „optimiert“. Öffentlicher Schnorr-Schlüssel an der Wurzel des Merkle-Baums.

Das Optimieren funktioniert aufgrund der linearen Eigenschaften von Schnorr. Wenn Sie einen öffentlichen Schlüssel mit einer Merkle-Wurzel „optimieren“ (diese Merkle-Wurzel zum öffentlichen Schlüssel hinzufügen), können Sie einfach die Merkle-Wurzel zum ursprünglichen privaten Schlüssel hinzufügen und den Ausgabenschlüssel dafür generieren der neue optimierte öffentliche Schlüssel. Das heißt, Sie fügen sowohl dem öffentlichen als auch dem privaten Schlüssel dasselbe hinzu, und sie sind immer noch ein gültiges Schlüsselpaar. Dies verbirgt die Existenz eines MAST-Baums, es sei denn, ein Zweig davon wird verwendet, aber im Grunde handelt es sich immer noch nur um einen MAST-Baum, nur um einen, dem man sich auf effizientere und privatere Weise verpflichtet.

Die Möglichkeit, sich auf verschiedene Ausgabeskripte in einem Merkle-Baum festzulegen und nur das verwendete Skript offenzulegen, ist ein enormer Skalierbarkeitsgewinn im Hinblick auf die Komplexität intelligenter Verträge, die auf Bitcoin aufbauen können.

Genauso wie die Blockgröße die Anzahl der Transaktionen pro Block begrenzt, gibt es eine Beschränkung der Transaktionsgröße von 100 Kilobyte. Der einzige Unterschied besteht darin, dass es sich nicht um eine Konsensregel, sondern um eine Richtlinienregel handelt. Das bedeutet, dass ein Miner eine Transaktion schürfen kann, die größer als 100 Kilobyte ist, aber standardmäßig wird kein Knoten im Netzwerk eine größere Transaktion überhaupt an den Miner weiterleiten.

Dies begrenzt grundsätzlich die Größe des Skripts, das zum Sperren eines Bitcoin UTXO verwendet wird. Selbst bei P2SH, bei dem das UTXO an einen Hash des Skripts gebunden ist, der erst angezeigt wird, wenn Sie es ausgeben, müssen Sie bei der Ausgabe irgendwann immer noch das vollständige Skript preisgeben. Taproot erhöht diese Skalierbarkeitsgrenze des Skripts, indem es nicht erfordert, dass Sie das gesamte Skript offenlegen, wenn Sie es verwenden. Anstatt die Gesamtgröße aller Möglichkeiten, wie Sie UTXO ausgeben können, auf die Transaktionsgrößenbeschränkung zu beschränken, müssen Sie nur sicherstellen, dass jede einzelne Möglichkeit, ein Taproot-UTXO auszugeben, diese Einschränkung respektiert.

Taproot bietet auch zahlreiche Datenschutzvorteile. Einer der großen Vorteile eines MAST-Baums ist die Möglichkeit, alle Arten von bedingten Situationen zu schaffen, in denen Münzen von anderen Parteien ausgegeben werden können.

Stellen Sie sich Dinge wie Erbschaftspläne vor, bei denen Ihre Kinder nach etwa einem Jahr Ihre Münzen ausgeben können, oder für den Fall, dass Sie sich weigern zu unterzeichnen, Ihre Frau und ein Anwalt einen möglichen Weg haben, die Münzen zurückzuerlangen. Über diese Ausgabebedingungen wird der Öffentlichkeit nichts bekannt, es sei denn, sie werden tatsächlich genutzt. Dieser zweifache Prozess bietet anderen Parteien, die an den verschiedenen von Ihnen erstellten Ausgabenzweigen beteiligt sind, eine plausible Abstreitbarkeit ihrer Beteiligung an diesem UTXO und schützt sie außerdem vor einem Dieb oder Angreifer, der sie präventiv ins Visier nimmt, da sie wissen, dass sie ein gewisses Maß an Kontrolle über sie haben UTXOs des Ziels.

Auch auf technischer Ebene ist Taproot relativ gut entwickelt. Jeder Leser, der mit Segregated Witness auf einer tieferen Ebene vertraut ist, sollte mit der Zeugenversion vertraut sein.

Als Segregated Witness implementiert wurde, wurde der neue Abschnitt „Zeuge“ einer Transaktion erstellt, in den Signaturdaten verschoben wurden. Zeugendaten hatten ein Versionsflag, sodass sie auf neue Funktionen aktualisiert werden konnten, ohne undefinierte OP_CODEs auf der Basisschicht für neue Funktionen verbrauchen zu müssen.

Auf diese Weise wurden Taproot/Schnorr tatsächlich implementiert. Segregated Witness-Transaktionen verwenden die Zeugenversion Null. Wenn Taproot/Schnorr bald live geht, werden sie die neue Witness-Version eins verwenden, um sie von älteren Segregated Witness-Transaktionen zu unterscheiden. Auf die gleiche Weise, wie SegWit Zeugenversionen eingeführt hat, führt Taproot die „Tapleaf-Version“ für die Tapscripts ein, die in den MAST-Bäumen für UTXOs verwendet werden, die Taproot verwenden. Dadurch können nicht nur die in MAST vergrabenen Skripte aktualisiert werden, ohne neue OP_CODEs auf der Basisschicht zu verwenden, sondern auch, ohne Zeugenversionen aktualisieren zu müssen! Deshalb wurde Taproot so konzipiert, dass zukünftige Upgrades so effizient wie möglich sind, ohne andere unabhängige Upgrades des Protokolls einzuschränken.

Taproot wird viele unterschiedliche Anwendungsfälle mit sich bringen. Zunächst einmal können alle nicht kooperativen Klauseln in einem Lightning-Kanal, wie z. B. Strafschlüssel oder Zeitschlösser, um deren Verwendung zu ermöglichen, unter einem MAST mit Taproot vergraben werden. Niemand wird jemals erfahren, dass sie existieren, es sei denn, sie müssen verwendet werden, wodurch noch unklarer wird, welche UTXOs tatsächlich Lightning-Kanäle sind und welche nicht.

Vererbungsschemata sind ein weiterer Anwendungsfall. Stellen Sie sich einen Pfahlwurzelbaum vor, der so strukturiert ist, dass Ihre ganze Familie nach sechs Monaten, in denen Sie Ihr Geld nicht bewegen, zusammenkommen und das UTXO ausgeben kann, wie sie möchte. Dann, sechs Monate später, kann jeder außer einer Person es ausgeben (stellen Sie sich also vor, Sie hätten Ihre Frau, zwei Kinder und Eltern als Schlüsselhalter, dann stellen Sie sich vor, dass nach den zusätzlichen sechs Monaten Ihre Frau, ein Kind und Ihre Eltern unterschreiben können , oder Ihre beiden Kinder und Eltern können ohne Ihre Frau unterschreiben usw.).

Dann, sechs Monate später, kann es jeder bis auf zwei Personen ausgeben. Letztendlich könnte es darauf hinauslaufen, dass nur eine Person mit Hilfe eines Anwalts (um sicherzustellen, dass keine Spielereien passieren) die UTXO ausgeben kann.

Oder was ist, wenn Sie Multisig verwenden, um Ihren Cold Storage zu sichern, Sie aber nur einen Ort haben, den Sie langfristig als sicher und vorhersehbar betrachten? Sie könnten einen MAST erstellen, in dem nach ein paar Jahren der Schlüssel an diesem sicheren Ort diese Münzen allein ausgeben kann, nur für den Fall, dass andere Schlüssel verloren gehen oder zerstört werden, ohne dass Ihre Münzen jedoch in diesem Fall sofort dem Risiko eines Diebstahls ausgesetzt werden Ein Schlüssel wurde kompromittiert.

Dabei handelt es sich um ein erstaunliches und umfassendes Upgrade von Bitcoin, an dem wohl fast seit der Geburt von Bitcoin selbst gearbeitet wird, und nicht erst seit den letzten Jahren, in denen die eigentlichen Implementierungsdetails ausgearbeitet und implementiert wurden.

Es ist wirklich in vielerlei Hinsicht ein Gewinn für die Skalierbarkeit und Nützlichkeit des Bitcoin-Protokolls, dass es schwer zu vermitteln ist, weil einige davon so subtil und „unsexy“ sind. Aber das tut dem Sieg keinen Abbruch. Also schnallen Sie sich alle an und sind bereit, mit den neuen Spielzeugen zu spielen, die wir bald verwenden müssen, denn Taproot kommt!

Dies ist ein Gastbeitrag von Shinobi. Die geäußerten Meinungen sind ausschließlich ihre eigenen und spiegeln nicht unbedingt die von BTC Inc oder . wider Bitcoin Magazin.

Quelle: https://bitcoinmagazine.com/technical/bitcoin-taproot-explainer