Autor: Fu Shaoqing, SatoshiLab, Wanwudao BTC Studio
1 Einleitung
Beim Studium der Bitcoin-Technologie stellte der Autor fest, dass das Verständnis der drei Wissenspunkte SegWit, Taproot und TaprootAssets aus der Perspektive der Entwicklungsgeschichte von Segregated Witness das Lernen und das Erfassen ihrer Entwicklungsgesetze erleichtert. Zudem ermöglicht es ein besseres Verständnis des Taproot Assets-Protokolls des Lightning Network Labs, die Rolle von Universe und die Funktionen sowie die zukünftige Entwicklungsmöglichkeiten des TaprootAssets-Protokolls. Mit diesen Erkenntnissen können relevante Produkte besser für die Nutzer gestaltet werden.
Für das Lesen dieses Artikels sind zwei wichtige Denkrichtungen erforderlich: die Skalierung (Erweiterung der Kapazität) und die Erweiterung der Fähigkeiten von Bitcoin.
Skalierung bedeutet die Erweiterung der Datenkapazität, die Bitcoin verwalten und nutzen kann. In der Frühphase war dies auf die Blockgröße beschränkt, später auf die gesamte von Bitcoin verwaltbare Datenkapazität. Das Extrem der Skalierung ist die Verwaltung eines unbegrenzten Datenraums.
Erweiterung der Fähigkeiten bedeutet die Erweiterung der Funktionalität, die durch die Skriptbefehle von Bitcoin realisiert werden kann. Das Extrem der Erweiterung ist die Erreichung einer turing-vollständigen Programmierfähigkeit.
Die gesamte Entwicklungsgeschichte von Bitcoin ist die Geschichte der Skalierung und der Erweiterung der Fähigkeiten, einschließlich verschiedener Forks von Bitcoin sowie der Erforschung von OP_RETURN und den drei Versionen von Segregated Witness.
Die Detailgrafiken der drei Versionen können von den meisten Lesern ignoriert werden; sie dienen dem tieferen technischen Verständnis des Autors und beeinträchtigen das Leseerlebnis nicht.
Die im Artikel erwähnten BIP-Protokolle sind mit Zeitangaben versehen, damit die Leser den Zeitraum von der Entstehung einer Idee bis zur Implementierung in der Produktionsumgebung nachvollziehen können und so die Schwierigkeit der technischen Umsetzung einschätzen können. Noch wichtiger ist die Zeitspanne von der Entstehung der Protokolle der drei Segregated Witness-Versionen bis zu deren Aktivierung, wodurch die großen Entwicklungstrends sichtbar werden und zukünftige Entwicklungen besser vorhergesagt werden können. Für Teams, die auf Basis dieser Technologien und Protokolle Produkte entwickeln, bietet dies eine gute Orientierungshilfe für die Wahl des richtigen Zeitpunkts zur Beteiligung. Eine zu frühe Beteiligung kann aufgrund unreifer Technologien zum “Märtyrer” werden; eine zu späte Beteiligung führt zum Verlust der Chance und zum “Zuschauer”. Der Autor ist der Meinung, dass der Eintritt kurz vor der Nutzungsreife der beste Zeitpunkt ist. Diese Einschätzung basiert oft auf zeitlichen und technischen Detailanalysen.
# 1.1 Frühe Transaktionen (ohne Segregated Witness)
Im White Paper definierte Transaktionen (das einfachste Transaktionsmodell)
![] ( https://img-cdn.gateio.im/social/moments-b 1 d 1 e 13125 aa 4168 cb 4 b 94759 c 9 f 4386)
Die grundlegendste Bitcoin-Transaktion in der Frühphase erlaubt mehrere Eingaben und zwei Ausgaben. Eine Ausgabe ist das Wechselgeld für sich selbst, die andere ist die Überweisung an einen externen Empfänger. (Anmerkung: Die Differenz zwischen Gesamteingabe und Gesamtausgabe ist die Trading-Gebühr)
Die meisten Transaktionen haben zwei Ausgaben, es gibt aber auch Szenarien mit nur einer Ausgabe, zusammengefasst wie folgt:
![] ( https://img-cdn.gateio.im/social/moments-eb 2838590 b 599622064 e 59 c 7164 e 4672)
Um den Unterschied besser zu verdeutlichen, verwenden wir ein Beispiel mit zwei Eingaben und zwei Ausgaben. (Ein Hauptgrund ist, dass die von mir verwendeten Referenzmaterialien solche Bilder mit zwei Eingaben und zwei Ausgaben bieten, sodass ich keine neuen Grafiken erstellen muss. Ein bisschen Faulheit ^_^)
Ist es mit solchen Vergleichsbildern leichter zu verstehen?
![] ( https://img-cdn.gateio.im/social/moments- 3 bd 23 e 4224 babcd 8 d 070 dea 206 e 8 b 1 e 8)
Vergleich zwischen traditionellem Transaktionsbeispiel und Segregated Witness (Segwit) Transaktionsdiagramm
# 1.2 Erforschung von OP_RETURN
Warum wird bei der Besprechung von Segregated Witness auf OP_RETURN eingegangen? Weil dies eine frühere Erkundung als Segregated Witness ist und das Verständnis für die Entstehung von Segregated Witness verbessert.
OP_RETURN ist ein Operation Code, der das Skript beendet und den Wert oben auf dem Stack zurückgibt. Dieser Operation Code ähnelt der Rückgabefunktion in Programmiersprachen. In der Geschichte von Bitcoin wurde die Funktion von OP_RETURN mehrfach geändert, heute wird er hauptsächlich als Methode zur Speicherung von Daten im Ledger verwendet. Die Funktion von OP_RETURN hat sich im Laufe der Zeit stark verändert und ist heute ein wichtiges Mechanismus, mit dem beliebige Daten auf der Chain gespeichert werden können.
OP_RETURN wurde ursprünglich verwendet, um die Skriptausführung vorzeitig zu beenden und das Ergebnis als oberstes Element des Stacks darzustellen. Dieser Operation Code hatte anfangs eine leicht ausnutzbare Schwachstelle, die Satoshi Nakamoto jedoch schnell behoben hat.
Weitere Änderungen an der Funktion von OP_RETURN
Im Bitcoin Core v0.9.0 Upgrade wurde das “OP_RETURN Output”-Skript zum Standardausgabetyp gemacht, sodass Nutzer Daten an “unspendable transaction output” anhängen können. Die maximale Datenmenge in solchen Skripten war zunächst auf 40 Byte begrenzt und wurde später auf 80 Byte erhöht.
Daten auf der Blockchain speichern
Die Änderung von OP_RETURN zu einer immer “false” zurückgebenden Funktion führte zu interessanten Ergebnissen. Da nach OP_RETURN keine weiteren Operation Codes oder Daten ausgewertet werden, begannen die Nutzer, diesen Operation Code zur Speicherung beliebiger Datenformate zu verwenden.
In der Zeit von Bitcoin Cash (BCH), also vom 1. August 2017 bis zum 15. November 2018, wurde die an OP_RETURN-Ausgaben anhängbare Datenlänge auf 220 Byte erweitert. Größere Datenmengen förderten innovative Anwendungen auf der Blockchain, wie z.B. das Veröffentlichen von Inhalten auf Blockchain-basierten sozialen Medien.
Bei BSV blieb die 220-Byte-Grenze eine Zeit lang erhalten. Im Januar 2019, da OP_RETURN das Skript so beendet, dass Nodes keine weiteren Operation Codes überprüfen, prüfen die Nodes auch nicht, ob das Skript die maximale Größe von 520 Byte überschreitet. Daher beschlossen die Node-Betreiber, das maximale Transaktionsvolumen auf 100 KB zu erhöhen, was Entwicklern mehr Freiheit für innovative Anwendungen gab, sodass größere und komplexere Daten in das Bitcoin-Ledger eingefügt werden konnten. Es gab sogar ein Beispiel, bei dem eine komplette Website in das BSV-Ledger eingefügt wurde.
Obwohl OP_RETURN eine gewisse Funktionserweiterung bietet, sind die Möglichkeiten insgesamt begrenzt. Die Verbesserungen von OP_RETURN führen architektonisch nicht zu weiteren technischen Fortschritten (immer noch auf 1M Blockgröße beschränkt), daher entstand die Technologie von Segregated Witness. Die drei Versionen der Upgrades verdeutlichen die Korrektheit und die starke Wirkung von Segregated Witness in Bezug auf Skalierung und Erweiterung der Fähigkeiten.
# 1.3 Vergleichsdiagramm der frühen Transaktionen und der drei Segregated Witness-Versionen
Um das Verständnis der gesamten Geschichte von Segregated Witness bei Bitcoin zu erleichtern, zeigen wir zu Beginn des Artikels ein Vergleichsdiagramm der vier Phasen.
![] ( https://img-cdn.gateio.im/social/moments-c 2 d 61 a 4507 ac 2 e 8 aa 7 c 743 d 6 e 938650 e )
2 Erstes Segregated Witness-Version: Segwit
# 2.1 Einführung und relevante Protokolle
Segregated Witness, kurz SegWit, wurde von Pieter Wuile (Bitcoin Core Entwickler, Blockstream-Mitbegründer) erstmals im Dezember 2015 vorgeschlagen und später als Bitcoin BIP 141 umgesetzt. Segregated Witness löst hauptsächlich drei Probleme (siehe unten), die ersten beiden erhöhen die Sicherheit und Leistung, das dritte hat den größten Einfluss auf neue Technologien, indem es die Blockkapazität indirekt erhöht (siehe unten das Konzept “Block weight”) und damit die Grundlage für die Skalierung von Bitcoin legt, was durch das spätere Taproot (zweite Version von Segregated Witness) weiter verstärkt wurde.
Relevante Protokolle:
BIP-141: Segregated Witness ( Konsensschicht ) / 2015-12-21
BIP-143: Transaction Signature Verification for Version 0 Witness Program / 2016-01-03
BIP-144: Segregated Witness ( Peer Services ) / 2016-01-08
# 2.2 Ursache und Wirkung
Segregated Witness löst hauptsächlich folgende Probleme:
-
Transaction Malleability (Transaktionsveränderbarkeit).
-
In SPV-Nachweisen wird die Übertragung der Unterschrift optional, wodurch die Datenmenge für Merkle-Nachweise reduziert wird.
-
Indirekte Erhöhung der Blockkapazität.
Die ersten beiden Punkte erhöhen hauptsächlich die Sicherheit und Leistung, das dritte hat den größten Einfluss auf neue Technologien, indem es die Blockkapazität indirekt erhöht und damit die Grundlage für die Skalierung von Bitcoin legt, was durch das spätere Taproot (zweite Version von Segregated Witness) weiter verstärkt wurde.
Obwohl die Blockkapazität indirekt erhöht wurde, ist Segregated Witness weiterhin durch die Blockgröße begrenzt. Die Blockgröße von Bitcoin ist auf 1 MByte begrenzt, da Witness-Daten nicht in diese Begrenzung fallen, wird zur Vermeidung von Missbrauch dennoch eine Gesamtblockgrößenbegrenzung eingeführt. Es wurde ein neues Konzept namens Blockgewicht (Block weight) eingeführt:
Block weight = Basisgröße * 3 + Gesamtgröße
Basisgröße ist die Blockgröße ohne Witness-Daten.
Gesamtgröße ist die nach BIP 144 serialisierte Blockgröße (in Byte), einschließlich Basisdaten und Witness-Daten.
Segregated Witness begrenzt Block weight <= 4 M.
Segregated Witness ermöglicht technisch die Skalierung von Bitcoin durch das Lightning Network, dieser Teil wird hier nicht im Detail behandelt.
# 2.3 Detailanalyse der Funktionsweise
Die Segregated Witness (SegWit)-Technologie von Bitcoin führt zu drei wichtigen Änderungen:
- Änderung der Transaktionsstruktur;
- Erhöhung der Blockgröße;
- Eine neue Bitcoin-Adressformat.
(1) Die Transaktionsstruktur ist wie folgt dargestellt:
![] ( https://img-cdn.gateio.im/social/moments- 656 dc 57 a 1 fc 9 d 42 b 81 e 3 e 9 f 2381 e 397 f )
Im Vergleich zum ursprünglichen Bitcoin-Transaktionsdiagramm wurde der Witness-Bereich hinzugefügt, der den Entsperrcode enthält. Die Witness-Daten werden im erweiterten Datenbereich außerhalb des 1M-Blocks gespeichert.
Ein detailliertes Diagramm der Segwit-Transaktionsdaten:
![] ( https://img-cdn.gateio.im/social/moments- 1411673 aa 66 cdf 278 e 69966820 f 6 d 862)
Detailliertes SegWit-Transaktionsdiagramm
(2) Vorstellung der Transaktionsgröße
![] ( https://img-cdn.gateio.im/social/moments- 17 aada 02 e 03 d 03 cf 6029 fe 22336 f 410 c ) Erhöhung der Blockgröße
![] ( https://img-cdn.gateio.im/social/moments- 30 d 5482 c 73883 e 5 a 2 e 13 b 4 fb 03 ed 4 c 5 a )
Durch die Änderung der Signaturstruktur und den Inhalt von BIP-141 sehen wir, dass die maximale Blockgröße von Bitcoin tatsächlich auf 4 M erweitert werden kann, wobei die ursprünglichen 1 M die Basis-Transaktionsdaten sind und die zusätzlichen 3 M den Witness-Datenbereich bilden.
(3) Adressformat von Segregated Witness
Segregated Witness (SegWit) verwendet zwei neue Locking Scripts: P2WPKH und P2WSH, wodurch neue Adressen im Bech32-Format entstehen.
Das Bech32-Adressformat ist wie folgt definiert:
![] ( https://img-cdn.gateio.im/social/moments- 3 ec 5 d 37 f 2 e 39 d 77658 c 7 b 9512 ba 50803)
Die Formate der Locking Scripts P2WPKH und P2WSH werden wie folgt erläutert, hier ist auch ein Beispiel für eine Taproot-Adresse (zweite Version von Segregated Witness) enthalten.
![] ( https://img-cdn.gateio.im/social/moments-c 354 bfe 70 bd 53 cd 2 ab 07357 bbc 01 d 9 b 5)
Locking Script
P2WPKH
![] ( https://img-cdn.gateio.im/social/moments-d 65 edd 35659 bfd 5 a 1 ea 10211 c 40 c 0474)
Der 20 Byte lange Öffentlicher Schlüssel-Hash ist tatsächlich die ursprüngliche Form der Bitcoin-Adresse im Algorithmus.
P2WSH
![] ( https://img-cdn.gateio.im/social/moments- 621 e 4 c 57 b 92388 a 80 e 0 db 1 c 804 f 739 b 5)
wTXID Commitment
![] ( https://img-cdn.gateio.im/social/moments-c 9954 be 7248 a 41 edd 627 bae 7 d 2 f 27 cb 4)
Alle Transaktions-IDs (wTXID) im Witness-Bereich werden durch einen Hash-Baum zu einem Root-Hash zusammengefasst und im Coinbase gespeichert, die genaue Zusammensetzung siehe Diagramm.
Funktionsweise der Bildung einer einzelnen Witness-Transaktions-ID (wTXID):
wTXID
![] ( https://img-cdn.gateio.im/social/moments-ae 0 cb 158016248243 aed 51 bc 02 c 6 e 4 eb )
# 2.4 Entwicklung und Zusammenfassung
Die Segregated Witness-Technologie wurde im Dezember 2015 vorgeschlagen und im Jahr 2017 auf Blockhöhe 481824 aktiviert.
Block-Explorer-Link:
Detaillierte Lern- und Analyseinformationen:
Die Segregated Witness-Technologie ist eine der bedeutendsten Änderungen in der Geschichte von Bitcoin und markiert den Beginn der glanzvollen Entwicklung von Skalierung und Erweiterung der Fähigkeiten. Aus Sicht der Skalierung und Erweiterung hat Segregated Witness hauptsächlich die Skalierung realisiert. Folgt man dieser Richtung, wird die nächste Version die Erweiterung der Fähigkeiten sein.
![] ( https://img-cdn.gateio.im/social/moments- 3667342 ba 93 c 72 df 5621 d 9 abb 4 bd 9868)
3 Zweite Version von Segregated Witness: Taproot
Aus Sicht der Skalierung und Erweiterung der Fähigkeiten lässt sich die Funktion der zweiten Version von Segregated Witness vorhersagen.
# 3.1 Einführung und relevante Protokolle
Wenn man nur das Wort Taproot verwendet, denken viele, es sei ein neues Konzept. Wenn man jedoch erklärt, dass es sich um die zweite Version von Segregated Witness (SegWit) handelt, erkennen die meisten die Zusammenhänge. Die relevanten BIPs sind 340, 341, 342: BIP 340 (Schnorr Signatures for secp256k1), BIP 341 (Taproot: SegWit version 1 spending rules), BIP 342 (Validation of Taproot Scripts).
Relevante Protokolle:
BIP-341: Taproot: SegWit version 1 spending rules / 2020-1-9
BIP-342: Validation of Taproot Scripts / 2020-1-19
BIP-340: Schnorr Signatures for secp256k1 / 2020-1-19
Im November 2021 wurde Taproot als Soft Fork offiziell aktiviert. Dieses Upgrade besteht aus BIP 340, BIP 341 und BIP 342. BIP 340 führt die Schnorr-Unterschrift ein, die mehrere Transaktionen gleichzeitig verifizieren kann und die Elliptische-Kurven-Digitale-Signatur-Algorithmus (ECDSA) ersetzt, wodurch die Netzwerkkapazität erneut erhöht und die Verarbeitung von Batch-Transaktionen beschleunigt wird, was die Implementierung komplexer Smart Contracts ermöglicht; BIP 341 implementiert den Merkleized Abstract Syntax Tree (MAST) zur Optimierung der Speicherung von Transaktionsdaten auf der Blockchain; BIP 342 (Tapscript) erweitert die native Skriptfähigkeit von Bitcoin durch die Skriptsprache.
Durch die Erweiterung des Speicherraums von Segregated Witness (SegWit) und Taproot entstanden Schnorr, MAST und Taproot Scripts, deren Aufgabe die Erweiterung der Funktionalität des Bitcoin-Mainnet ist.
# 3.2 Ursache und Wirkung
Durch die Segregated Witness (SegWit)-Technologie wurde die Blockkapazität von Bitcoin erhöht. Dennoch blieben einige Probleme bestehen:
(1) In der SegWit-Version wird weiterhin ECDSA als Verschlüsselungsalgorithmus verwendet. (Für neue Entwicklungen wird ein besserer asymmetrischer Algorithmus benötigt, um mehr Funktionen und Spezialeffekte zu unterstützen. Daher wird der neue Schnorr-Unterschrift eingeführt.)
(2) Der Speicherplatz wurde erweitert, aber das Unlocking Script ist immer noch eine einfache Eins-zu-Eins-Struktur. (Daher entstand die MAST-Struktur mit komplexen Bedingungen.)
(3) SegWit hat die Skriptfähigkeit von Bitcoin nicht erweitert. (Daher entstand Tapscript.)
Die zweite Version von Segregated Witness, Taproot, löst diese Probleme sehr gut und ermöglicht eine bessere Entwicklung der Segregated Witness-Technologie, sodass mehr Funktionen realisiert werden können. BIP 340 löst das Problem (1); BIP 341 implementiert den Merkleized Abstract Syntax Tree (MAST) und löst das Problem (2); BIP 342 (Tapscript) erweitert die native Skriptfähigkeit von Bitcoin und löst das Problem (3).
# 3.3 Detailanalyse der Funktionsweise
Wichtige neue Eigenschaften der Taproot-Technologie:
l Einführung der Schnorr-Unterschrift
l Zwei Locking Scripts von P2TR: Key Path Spend (ähnlich P2WPKH); Script Path Spend (ähnlich P2WSH)
l Skriptbaum (MAST Merkle Abstract Syntax Tree)
l Taproot Script
1 Schnorr-Unterschrift
Mit der Entwicklung von Taproot und der Erweiterung der Fähigkeiten wurden Anforderungen an den Signaturalgorithmus gestellt, sodass die Schnorr-Unterschrift eingeführt wurde, um die Elliptische-Kurven-Digitale-Signatur-Algorithmus (ECDSA) zu ersetzen. Die Schnorr-Unterschrift ist ein digitales Signaturschema, das Transaktionen und Nachrichten effizient und sicher signieren kann. Sie wurde erstmals 1991 von Claus Schnorr beschrieben. Schnorr wird für seine Einfachheit, nachweisbare Sicherheit und Linearität gelobt.
Vorteile der Schnorr-Unterschrift:
Schnorr-Unterschriften bieten viele Vorteile, darunter Effizienz, verbesserte Privatsphäre und die Beibehaltung aller Funktionen und Sicherheitsannahmen von ECDSA. Sie ermöglichen kleinere Signaturgrößen, schnellere Verifizierungszeiten und eine verbesserte Widerstandsfähigkeit gegen bestimmte Angriffsarten.
Das auffälligste Merkmal der Schnorr-Unterschrift ist die Schlüsselaggregation (key aggregation), bei der mehrere Unterschriften zu einer einzigen aggregiert werden, die für die Summe der Schlüssel gültig ist. Mit anderen Worten, mehrere Parteien können gemeinsam eine Unterschrift erzeugen, die für die Summe ihrer Öffentlicher Schlüssel gültig ist. Die Aggregation von Unterschriften ermöglicht es, dass die Unterschriften mehrerer Unterzeichner zu einer einzigen zusammengefasst werden. Die Schlüsselaggregation reduziert die Transaktionsgebühren und verbessert die Skalierbarkeit, da die elektronische Unterschrift aus einer Multisignatur-Konfiguration im Block genauso viel Platz einnimmt wie die Unterschrift einer Einzeltransaktion. Dieses Merkmal kann verwendet werden, um die Größe von Multisignatur-Zahlungen und anderen Multisignatur-bezogenen Transaktionen zu reduzieren, z.B. bei Lightning Network-Kanaltransaktionen.
Ein weiteres wichtiges Merkmal der Schnorr-Unterschrift ist die Unveränderbarkeit.
Schnorr bietet auch viele Vorteile für die Privatsphäre. Multisignatur-Schemata können von herkömmlichen Einzel-Öffentlicher Schlüssel von außen nicht unterschieden werden, sodass es für Beobachter schwieriger ist, Multisignatur-Ausgaben und Einzelunterschriften-Ausgaben auf der Chain zu unterscheiden. Außerdem ist es in n-of-m-Multisignatur-Konfigurationen für externe Beobachter schwieriger, anhand der Chain-Informationen zu erkennen, welche Teilnehmer die Transaktion unterschrieben haben und welche nicht.
Die Schnorr-Unterschrift wurde in BIP-340 implementiert, als Teil des Taproot-Soft-Fork-Upgrades, und am 14. November 2021 auf Blockhöhe 709,632 aktiviert. Schnorr macht die digitalen Unterschriften von BTC schneller, sicherer und einfacher zu verarbeiten. Bemerkenswert ist, dass die Schnorr-Unterschrift mit den kryptografischen Algorithmen von BTC rückwärtskompatibel ist, sodass sie durch ein Soft Fork eingeführt werden kann.
2 Grundprinzipdiagramm und Key Path Spend, Script Path Spend
![] ( https://img-cdn.gateio.im/social/moments- 0 eaaa 87 a 0 cb 8 da 7 ebdc 33600 d 49 f 61 f 8)
3 MAST Merkle Abstract Syntax Tree
Nachdem wir Key Path Spend und Script Path Spend verstanden haben, ist das Wichtigste, dass diese Skripte in einer Baumstruktur organisiert werden können.
Dieser Baum ist eine Integration von AST (Abstract Syntax Tree) und Merkle Tree. Wie im folgenden Diagramm dargestellt:
AST-Baum
![] ( https://img-cdn.gateio.im/social/moments- 093 eed 4 d 3754 b 7 bf 9029 abc 37 af 0569 c ) ![] ( https://img-cdn.gateio.im/social/moments- 5 d 3 c 25 d 5 c 0 b 9621 a 12 c 71 d 0 ce 66541 ed )
Die oben dargestellte Syntaxbaumstruktur wird zu einem Merkle Tree aufgebaut, wie folgt:
![] ( https://img-cdn.gateio.im/social/moments-c 03 ec 3788 c 9 a 3 ee 1 d 7 e 207 ac 9 a 937460)
4 Taproot Scripts
Im BIP 342-Protokoll wurde das Tapscript-Skript eingeführt. Taprootscript ist eine Weiterentwicklung des ursprünglichen Bitcoin-Skripts und kann als eine Sprache betrachtet werden, ist aber tatsächlich eine Sammlung von Operation Codes mit Befehlen, die die Implementierung der anderen beiden BIPs unterstützen. Taprootscript hebt die Begrenzung der Skriptgröße von 10.000 Byte auf und bietet eine bessere Umgebung für die Erstellung von Smart Contracts im Bitcoin-Netzwerk. (Dieses Upgrade legte auch den Grundstein für die Entstehung von Ordinals, da das Ordinals-Protokoll die Taproot script-path spend scripts zur Implementierung von Zusatzdaten verwendet.) Weitere Informationen finden Sie auf der offiziellen Website:
Die Fähigkeiten von TaprootScript sind derzeit noch nicht voll ausgeschöpft, spätere Entwicklungen werden seine Stärke zeigen. Beispielsweise sollte die Verbindungstechnologie zwischen Bitcoin Layer 1 und Layer 2 verstärkt Taproot, MAST und TaprootScripts verwenden.
Hinweis: Tatsächlich sind die Fähigkeiten von TaprootScript auf Layer 1 noch relativ eingeschränkt, da die Unterstützung durch die Bitcoin-Virtuelle Maschine erforderlich ist. Im dritten Version von Segregated Witness, dem TaprootAssets-Protokoll, gibt es eine spezielle Virtuelle Maschine TAP-VM für TaprootScript, die die Erweiterung der Fähigkeiten stärkt und die Trennung vom Bitcoin-Mainnet-Umfeld verbessert.
# 3.4 Entwicklung und Zusammenfassung
Die Taproot-Technologie wurde im Januar 2020 vorgeschlagen und im November 2021 als Soft Fork aktiviert. Nach der Einführung von Taproot im Bitcoin-Ökosystem entstanden neue Anwendungen, zunächst leichte und einfache Anwendungen.
Typische Anwendungen sind:
(1) Ordinals-Protokoll, Inscription, BRC20
(2) Weitere Protokolle: Atomicals, ARC20
(3) Weitere Protokolle: RUNE
SegWit und Taproot haben die erste Erkundung von Skalierung und Erweiterung der Fähigkeiten abgeschlossen, sind aber durch die bestehende Struktur begrenzt.
Die erste Skalierung von Bitcoin hat die Blockgröße von 1M auf 4M erweitert. Wenn man diese Richtung weiterverfolgt, würde eine weitere Skalierung, selbst wenn technisch möglich, wie bei anderen Bitcoin-Forks zu riesigen Blöcken führen, was zu einer Zentralisierung von Bitcoin und anderen schwerwiegenden Problemen führen und die Sicherheit der Blockchain gefährden würde. Daher ist für die nächste Skalierung eine andere technische Herangehensweise erforderlich.
Obwohl Taproot die erste Erweiterung der Fähigkeiten von Bitcoin abgeschlossen hat, ist auch diese Erweiterung begrenzt. Im Bitcoin-Mainnet verwenden die Virtuelle Maschine für BTCScript und TapScript dieselbe Virtuelle Maschine (Stack-Computing von Bitcoin), was die Erweiterung stark einschränkt und die Stabilität und Sicherheit des Mainnets beeinträchtigen kann. Wenn die neue Erweiterung von der Virtuelle Maschine des Bitcoin-Mainnet getrennt wird und eine unabhängige Virtuelle Maschine gemäß dem Layered-Protokoll zusammen mit der Virtuelle Maschine des Mainnets arbeitet, ist dies eine vernünftigere Entwicklung. Diese isolierte Virtuelle Maschine könnte sich von nicht-turing-vollständig zu turing-vollständig entwickeln.
![] ( https://img-cdn.gateio.im/social/moments- 21 f 0 bc 002 d 952 b 8 cd 84 e 2 dc 4 dd 8 af 0 b 3)
4 Dritte Version von Segregated Witness: TaprootAssets-Protokoll
Nach der Einführung der ersten Skalierungs- und Erweiterungstechnologien im Bitcoin-Mainnet boten diese eine hervorragende technische Referenz und Umsetzungsidee für die weitere Skalierung und Erweiterung. Die nächste Entwicklung von Bitcoin sollte hauptsächlich die weitere Skalierung lösen. Natürlich wäre es ideal, Skalierung und Erweiterung gleichzeitig zu unterstützen, aber zwei große Änderungen gleichzeitig sind sehr riskant und machen die technische Umsetzung extrem schwierig. Daher entstand eine weitere Skalierungstechnologie für das Bitcoin-Mainnet (mit einigen kleineren Erweiterungstechnologien).
# 4.1 Ursache und Wirkung
Durch die Entwicklung von Taproot entstanden im Bitcoin-Ökosystem neue Möglichkeiten, die sich in mehreren Aspekten zeigen:
(1) Ist es möglich, den Blockraum von Bitcoin nicht zu beanspruchen und eine weitergehende Segregated Witness zu realisieren, d.h. die Speicherung der Daten im Witness-Bereich außerhalb des Bitcoin-Blocks, wobei nur der Nachweis im Bitcoin-Mainnet gespeichert wird?
(2) Können die Daten im Witness-Bereich eine reichhaltigere Struktur haben, um mehr Geschäftsanforderungen zu erfüllen?
(3) Erweiterung der Fähigkeiten von TaprootScript durch eine eigene Virtuelle Maschine für die Berechnung.
Wenn diese Ziele erreicht werden können, lassen sich bei vollständiger Wahrung der Eigenschaften des Bitcoin-Mainnet sehr umfangreiche Funktionen realisieren.
Reicht die zweite Version von Segregated Witness, Taproot, für die Entwicklung der Bitcoin-Technologie aus? Gibt es noch Raum für weitere Upgrades und Erweiterungen?
# 4.2 Einführung und relevante Protokolle
Das Lightning Network Lab hat aus den oben genannten Gründen und Hintergründen Ende 2021 das Taproot Assets-Protokoll entwickelt. Taproot Assets-Protokoll (früher “Taro” genannt). Das Taproot Assets-Protokoll ist leistungsfähiger als Taproot und seine Struktur ist sehr ausgeklügelt. (Ein besonderer Dank gilt dem Protokoll-Designer, CTO des Lightning Network Labs, Olaoluwa Osuntokun)
Das Taproot Assets-Protokoll besteht aus sieben wichtigen BIPs (derzeit noch ohne BIP-Nummer):
BIP-TAP-ADDR: Taproot Asset On Chain Addresses Draft / 2021-12-10
BIP-TAP-MS-SMT: Merkle Sum Sparse Merkle Trees Draft / 2021-12-10
BIP-TAP-PROOF: Taproot Asset Flat File Proof Format Draft / 2021-12-10
BIP-TAP-PSBT: Taproot Assets PSBT Draft / 2023-02-24
BIP-TAP-UNIVERSE: Taproot Asset Universes Draft / 2021-12-10
BIP-TAP-VM: Taproot Asset Script v1 Draft / 2021-12-10
BIP-TAP: TAP: Taproot Assets Protocol Draft / 2021-12-10
Das TaprootAssets-Protokoll schöpft die Skalierung und Erweiterung der Fähigkeiten von Bitcoin nahezu vollständig aus. Der Speicherraum ist dank Universe praktisch unbegrenzt (theoretisch unendlicher Raum); die Obergrenze der Fähigkeiten ist die Skriptfähigkeit von TaprootScript und die Eigenschaften seiner Virtuelle Maschine. (Die aktuelle TAP-VM ist noch nicht turing-vollständig)
# 4.3 Detailanalyse der Funktionsweise
Wichtige neue Eigenschaften des Taproot Assets-Protokolls:
- Die Daten befinden sich vollständig außerhalb des Bitcoin-Mainnet, der Nachweis der Off-Chain-Daten wird im Block des Bitcoin-Mainnet gespeichert;
- Die Off-Chain-Daten haben eine vollständigere Struktur, das Design ist sehr ausgeklügelt und bietet bessere Erweiterbarkeit;
- Die Off-Chain-Daten werden von einer leistungsstarken Virtuelle Maschine (VM) unterstützt, die sich vom Bitcoin-Mainnet zu trennen beginnt und mehr Funktionen als das Mainnet ermöglicht;
1 Speicherung von Off-Chain-Daten und Nachweis auf der Chain
Das Taproot Assets-Protokoll verwendet Universe zur Speicherung von Off-Chain-Daten, was große Vorteile bietet: Die Daten können öffentlich für Besucher bereitgestellt oder privat gespeichert werden, um die Privatsphäre zu schützen.
Im aktuellen Taproot Assets-Protokoll werden Sparse Merkle Sum Trees zur Lösung von Vermögenswert-bezogenen Anforderungen verwendet.
![] ( https://img-cdn.gateio.im/social/moments- 20 cff 3175 ce 1 c 38197 a 830762864 d 3 f 3)
Diese Grafik zeigt die Ausgabe verschiedener Vermögenswerte mit MS-SMT
![] ( https://img-cdn.gateio.im/social/moments-fcf 5 b 332 c 34 dc 2596 fa 22 f 833002 dc 42)
Diese Grafik zeigt die Übertragung und den Besitz von Vermögenswerten mit TaprootAssets.
2 Vollständige Datenstruktur – MS-SMT (Sparse Merkle Sum Tree)
Das Taproot Assets-Protokoll verwendet für die Ausgabe von Vermögenswerten das gleiche UTXO-Modell wie das Bitcoin-Mainnet, genannt vUTXO. Die Kontrolle der Gesamtmenge von vUTXO, die Aufteilung, Zusammenführung und Übertragung von vUTXO erfolgt mit MS-SMT Sparse Merkle Sum Tree. Die Summen gewährleisten die Unveränderlichkeit der Gesamtmenge, der Sparse Merkle Tree zeichnet den Status aller vUTXO auf.
( Vom Virtual Byte in SegWit zum Virtual UTXO in TA – was für eine ähnliche Entwicklung! )
“Merkle Sum Sparse Merkle Tree” (im Folgenden als “MS-SMT” abgekürzt) ist eine Variante des Merkle Tree, definiert durch bip-tap-ms-smt. Da der Schlüssel 256 Bit lang ist, hat er 2^256 Blätter. Die meisten Blätter sind leer.
Jedes Blatt enthält eine Menge, und jeder Zweigknoten bestätigt die Summe der Mengen aller Blätter in seinem Teilbaum. Selbst wenn der Inhalt eines Teilbaums unbekannt ist, kann man durch Überprüfung des Zweigknotens die Gesamtmenge des Teilbaums feststellen. Die Wurzel bestätigt die Gesamtmenge aller Blätter.
Wie beim allgemeinen Merkle Tree kann man mit einem beschnittenen Baum, der das Zielblatt enthält, einen Nachweis (Merkle Proof) für das Zielblatt erbringen. MS-SMT unterstützt jedoch auch “Nichtvorhandenseinsnachweise”. Dies wird durch eine Einschränkung erreicht: Die Menge des Blattes, das einen nicht vorhandenen Schlüssel darstellt, muss explizit auf einen Wert gesetzt werden, der das Nichtvorhandensein (None) anzeigt (das Vorhandensein von “None” ist also der Nachweis für das Nichtvorhandensein). Daher besteht der Standard-MS-SMT aus 2^256 Blättern mit “None”.
Asset-Blatt (Asset-UTXO)
Der untere MS-MST der Asset-Baum verwendet asset_script_key als Schlüssel und das Asset-Blatt als Wert. Jedes Asset-Blatt repräsentiert ein UTXO dieses Vermögenswerts (im Folgenden einfach als “UTXO” bezeichnet – nicht das Bitcoin-UTXO), und die folgenden Attribute (einschließlich eines optionalen) werden im “Typ-Länge-Wert”-Format serialisiert.
taproot_asset_version
asset_genesis
asset_id
asset_type
amt
lock_time
relative_lock_time
prev_asset_witnesses
-
prev_asset_id
-
asset_witness
-
split_commitment_proof
split_commitment
asset_script_version
asset_script_key
asset_group_key
canonical_universe
asset_genesis ist das Urbild, aus dem asset_id abgeleitet wird.
asset_script_key ist sowohl der Schlüssel des Asset-Blattes als auch ein Taproot-Öffentlicher Schlüssel (definiert von einer vom Bitcoin unabhängigen tap-vm) und die Bedingung für die Ausgabe des durch das Asset-Blatt repräsentierten UTXO.
Beim Ausgeben eines UTXO müssen zunächst die (externen) Bitcoin-Ausgabebedingungen und dann die (internen) TAP-Ausgabebedingungen erfüllt werden, die durch asset_script_key festgelegt werden und von prev_asset_id und asset_witness erfüllt werden müssen. Zum Beispiel ist asset_witness die Unterschrift des asset_script_key des ausgegebenen UTXO.
![] ( https://img-cdn.gateio.im/social/moments- 4 bbc 1 d 2 e 0 de 7 f 871 ff 1 aa 4440933 bc 0 d )
Wenn bei einer Vermögenswertübertragung ein UTXO aufgeteilt wird, sind split_commitment und split_commitment_proof erforderlich. split_commitment ist ein MS-SMT, der alle nach der Aufteilung entstandenen UTXO repräsentiert (in diesem Sinne hat der Asset-Baum tatsächlich drei Ebenen), und die Summe im Root ist die Gesamtmenge der übertragenen Vermögenswerte.
split_commitment_proof ist ein Merkle-Nachweis für split_commitment, der das Vorhandensein einer Aufteilung belegt.
Bei allen Aufteilungen gibt es nur eine mit prev_asset_id, asset_witness und split_commitment. Alle anderen Aufteilungen haben nur split_commitment_proof. Alle Aufteilungen teilen sich prev_asset_id und asset_witness.
3 Virtuelle Maschine TAP-VM des Taproot Assets-Protokolls
Im BIP-TAP-VM: Taproot Asset Script v1 wird eine speziell für dieses Protokoll verwendete Virtuelle Maschine definiert. Anfangs basiert sie hauptsächlich auf geringfügigen Anpassungen von BIP-341 und BIP-342 (den beiden Haupt-BIPs von Taproot), also leichten Erweiterungen von BTCScript und TaprootScript.
Der Autor ist jedoch überzeugt, dass mit dieser Struktur die Ausführungsumgebung der TAP-VM bereits vom Bitcoin-Mainnet getrennt ist und durch die Entwicklung der tapd-Anwendung des Lightning Network Labs eine leistungsfähigere Virtuelle Maschine entstehen kann. Aus Sicherheits- und Stabilitätsgründen verläuft dieser Prozess jedoch langsam, was den Eigenschaften von Bitcoin-Ökosystemanwendungen entspricht.
TrustlessSwap ist eine wichtige Grundfunktion des TaprootAssets-Protokolls, mit der bereits recht komplexe native Bitcoin-Anwendungen entwickelt werden können.
![] ( https://img-cdn.gateio.im/social/moments- 55 dabd 37240 b 415487 a 51 a 4 f 01121 de 5)
In unserem Projektteam haben wir bereits einige leistungsstarke Funktionen erlebt. Beispielsweise kann TrustlessSwap komplexe Funktionalitäten zwischen Bitcoin und den darauf ausgegebenen Vermögenswerten realisieren.
In der nächsten Zeit wird der Schwerpunkt des TaprootAssets-Protokolls auf der Weiterentwicklung der Funktionen der TAP-VM liegen, sobald die Vermögensausgabe stabil und ausgereift ist.
Nebenbemerkung: Ich habe eine Frage – kann sich die TAP-VM durch ständige Weiterentwicklung zu einer turing-vollständigen Virtuelle Maschine entwickeln? Ich denke, wenn die Entwicklung lange genug dauert, ist dies letztlich möglich. Daraus ergibt sich die zweite Frage: Braucht man langfristig eine turing-vollständige Virtuelle Maschine im TaprootAssets-Protokoll?
# 4.4 Entwicklung und Zusammenfassung
Das Taproot Assets-Protokoll entstand Ende 2021 mit den ersten Protokolldateien, und mit der Veröffentlichung der Taro-Version 2023 wurde die Anfangsphase der Erkundung abgeschlossen. Die Taro-Version hatte jedoch viele Designmängel, sodass die Anwendungen darauf nicht gut unterstützt wurden und
