Für einen Algorithmus f können zwei gegenseitig misstrauische Teilnehmer, Alice und Bob, auf folgende Weise Vertrauen aufbauen:
Für die oben genannten 2, 3 und 4 sei x Layer2-Transaktionen und der Anfangszustand, f das Layer2-Konsensprogramm und y der Transaktionsendzustand, der der Blockchain-Layer2-Skalierungslösung entspricht. Unter ihnen:
Tabelle 1: Möglichkeiten zur Vertrauensbildung
Darüber hinaus ist es wichtig zu beachten:
Derzeit werden aufgrund der Turing-vollständigen Smart Contracts von Solidity Betrugsnachweise und Gültigkeitsnachweise häufig in der Ethereum Layer2-Skalierung eingesetzt. Unter dem Bitcoin-Paradigma sind diese Technologien jedoch aufgrund der begrenzten Opcode-Funktionalität von Bitcoin, der 1000 Stapel-Elemente und anderer Einschränkungen noch immer in der explorativen Phase. Dieser Artikel fasst die Einschränkungen und Durchbruchstechnologien unter dem Bitcoin-Paradigma im Kontext der Bitcoin Layer2-Skalierung zusammen, untersucht Gültigkeitsnachweis- und Betrugsnachweistechnologien und skizziert die einzigartige Skriptsegmentierungstechnologie unter dem Bitcoin-Paradigma.
Es gibt viele Einschränkungen im Bitcoin-Paradigma, aber verschiedene clevere Methoden oder Techniken können verwendet werden, um diese Einschränkungen zu überwinden. Zum Beispiel kann die Bit-Commitment die stateless-Einschränkung des UTXO durchbrechen, der Taproot kann die Script-Space-Einschränkungen durchbrechen, der Connector-Output kann die UTXO-Spending-Methoden-Einschränkungen durchbrechen und Verträge können die Einschränkungen der Vor-Unterschrift durchbrechen.
Bitcoin verwendet das UTXO-Modell, bei dem jedes UTXO in einem Sperrskript gesperrt ist, das die Bedingungen definiert, die erfüllt sein müssen, um dieses UTXO auszugeben. Bitcoin-Skripte haben folgende Einschränkungen:
Derzeit sind Bitcoin-Skripte vollständig zustandslos. Bei der Ausführung eines Bitcoin-Skripts wird die Ausführungsumgebung nach jedem Skript zurückgesetzt. Dies führt dazu, dass Bitcoin-Skripte die nativ die Einschränkung von Skripten 1 und 2 mit dem gleichen x-Wert unterstützen können. Allerdings kann dieses Problem durch einige Methoden umgangen werden, wobei die Kernidee darin besteht, einen Wert auf irgendeine Weise zu signieren. Wenn für einen Wert eine Signatur erstellt werden kann, ist es möglich, zustandsbehaftete Bitcoin-Skripte zu erreichen. Das bedeutet, dass durch Überprüfung der Signatur des x-Werts in Skripten 1 und 2 durchgesetzt werden kann, dass derselbe x-Wert in beiden Skripten verwendet wird. Bei einer konkurrierenden Signatur, d. h. wenn zwei verschiedene Werte für dieselbe Variable x signiert werden, kann eine Strafe verhängt werden. Diese Lösung ist als Bit-Commitment bekannt.
Das Prinzip der Bit-Verpflichtung ist relativ einfach. Ein Bit bezieht sich auf das Festlegen von zwei unterschiedlichen Hash-Werten, Hash0 und Hash1, für jedes Bit in der zu signierenden Nachricht. Wenn der zu signierende Bit-Wert 0 ist, wird das Ursprungsbild0 von Hash0 offengelegt; wenn der zu signierende Bit-Wert 1 ist, wird das Ursprungsbild1 von Hash1 offengelegt.
Am Beispiel einer einzelnen Bitnachricht m ∈{0,1} besteht das entsprechende Bit-Commit-Entsperrskript nur aus einigen Vorbildern: Wenn der Bitwert 0 ist, ist das entsprechende Entsperrskript preimage0—"0xfa7fa5b1dea37d71a0b841967f6a3b119dbea140"; Wenn der Bitwert 1 ist, lautet das entsprechende Entsperrskript preimage1 – "0x47c31e611a3bd2f3a7a42207613046703fa27496". Daher ist es mit Bit-Engagement möglich, die zustandslose UTXO-Begrenzung zu durchbrechen und zustandsbehaftete Bitcoin-Skripte zu erhalten, die verschiedene interessante neue Funktionen ermöglichen.
OP_HASH160
OP_DUP
0xf592e757267b7f307324f1e78b34472f8b6f46f3> // Dies ist hash1
OP_EQUAL
OP_DUP
OP_ROT
0x100b9f19ebd537fdc371fa1367d7ccc802dc2524> // Dies ist hash0
OP_EQUAL
OP_BOOLOR
OP_VERIFY
Jetzt befindet sich der Wert der Bit-Bindung auf dem Stapel. Entweder "0" oder "1".
Derzeit gibt es 2 Implementierungen der Bit-Verpflichtung:
Derzeit implementiert die BitVM2-Bibliothek Winternitz-Signaturen auf Basis der Hash-Funktion Blake3. Die Signaturlänge, die einem einzelnen Bit entspricht, beträgt etwa 26 Bytes. Daher ist zu erkennen, dass die Einführung von Zustand durch Bit-Commitment kostspielig ist. In der BitVM2-Implementierung wird die Nachricht daher zunächst gehasht, um einen 256-Bit-Hash-Wert zu erhalten, und dann wird das Bit-Commitment auf den Hash-Wert durchgeführt, um Overhead zu sparen, anstatt sich direkt auf jedes Bit der ursprünglich längeren Nachricht zu verpflichten.
Das Bitcoin Taproot Soft Fork Upgrade, das im November 2021 aktiviert wurde, umfasst drei Vorschläge: Schnorr-Signaturen (BIP 340), Taproot (BIP 341) und TapScript (BIP 342). Es führt einen neuen Transaktionstyp ein - Pay-to-Taproot (P2TR)-Transaktionen. P2TR-Transaktionen können ein privateres, flexibleres und skalierbareres Transaktionsformat schaffen, indem sie die Vorteile von Taproot, MAST (Merkel Abstract Syntax Tree) und Schnorr-Signaturen kombinieren.
P2TR unterstützt zwei Ausgabemethoden: Ausgabe nach dem Schlüsselpfad oder dem Skriptpfad.
Gemäß den Bestimmungen in Taproot (BIP 341) darf beim Ausgeben über den Skriptpfad der entsprechende Merkle-Pfad eine maximale Länge von 128 nicht überschreiten. Dies bedeutet, dass die Anzahl der Tapleafs im Taptree 2^128 nicht überschreiten kann. Seit dem SegWit-Upgrade im Jahr 2017 misst das Bitcoin-Netzwerk die Blockgröße in Gewichtseinheiten, mit einer maximalen Unterstützung von 4 Millionen Gewichtseinheiten (ungefähr 4 MB). Wenn ein P2TR-Ausgang über den Skriptpfad ausgegeben wird, muss nur ein einzelnes Tapleaf-Skript offengelegt werden, was bedeutet, dass der Block mit einem einzigen Tapleaf-Skript gepackt ist. Das bedeutet, dass für P2TR-Transaktionen die Skriptgröße, die jedem Tapleaf entspricht, maximal etwa 4 MB betragen kann. Unter der Standardrichtlinie von Bitcoin leiten jedoch viele Knoten nur Transaktionen kleiner als 400K weiter; größere Transaktionen müssen mit Minern zusammenarbeiten, um gepackt zu werden.
Die von Taproot mitgebrachte Script-Space-Prämie macht es wertvoller, kryptografische Operationen wie Multiplikation und Hashing mit vorhandenen Opcodes zu simulieren.
Bei der Erstellung überprüfbarer Berechnungen auf der Grundlage von P2TR ist die entsprechende Skriptgröße nicht mehr auf die 4-MB-Einschränkung beschränkt, sondern kann in mehrere Unterfunktionen aufgeteilt werden, die auf mehrere Tapleafs verteilt sind, wodurch die 4-MB-Skriptplatzbeschränkung durchbrochen wird. Tatsächlich hat der Groth16-Verifier-Algorithmus, der im aktuellen BitVM2 implementiert ist, eine Größe von bis zu 2 GB. Sie kann jedoch aufgeteilt und auf etwa 1000 Tapleafs verteilt werden, und durch die Kombination mit Bitbindung kann die Konsistenz zwischen den Ein- und Ausgängen jeder Unterfunktion eingeschränkt werden, wodurch die Integrität und Richtigkeit der gesamten Berechnung sichergestellt wird.
Derzeit bietet Bitcoin zwei native Ausgabemethoden für einen einzelnen UTXO: Ausgaben per Skript oder per öffentlichem Schlüssel. Solange die korrekten Signatur- oder Skriptbedingungen des öffentlichen Schlüssels erfüllt sind, kann der UTXO daher ausgegeben werden. Zwei UTXOs können unabhängig voneinander ausgegeben werden, und es können keine Einschränkungen hinzugefügt werden, um die beiden UTXOs einzuschränken, was bedeutet, dass zusätzliche Bedingungen erfüllt sein müssen, damit sie ausgegeben werden können.
Jedoch machte Burak, der Gründer des Ark-Protokolls, cleveren Gebrauch vom SIGHASH-Flag, um den Connector-Output zu erreichen. Konkret kann Alice eine Signatur erstellen, um ihre BTC an Bob zu senden. Da die Signatur jedoch mehrere Inputs bestätigen kann, kann Alice ihre Signatur bedingt setzen: Die Signatur ist für die Taketx-Transaktion gültig, wenn und nur wenn diese Transaktion den zweiten Input verbraucht. Der zweite Input wird als Connector bezeichnet und verbindet UTXO A und UTXO B. Mit anderen Worten ist die Taketx-Transaktion nur dann gültig, wenn UTXO B nicht von Challengetx ausgegeben wurde. Durch die Zerstörung des Connector-Outputs kann die Wirksamkeit der Taketx-Transaktion blockiert werden.
Abbildung 1: Illustration der Anschlussausgabe
Im BitVM2-Protokoll fungiert der Connector-Ausgang als eine if...else-Funktion. Sobald der Connector-Ausgang von einer Transaktion ausgegeben wurde, kann er nicht von einer anderen Transaktion ausgegeben werden, um seine exklusive Ausgabe sicherzustellen. Bei praktischer Implementierung werden zusätzliche UTXOs mit Zeitsperre eingeführt, um eine Herausforderungs-Antwort-Periode zu ermöglichen. Darüber hinaus kann der entsprechende Connector-Ausgang je nach Bedarf auch mit unterschiedlichen Ausgabestrategien festgelegt werden, z.B. indem er allen Parteien erlaubt wird, bei Herausforderungstransaktionen auszugeben, während nur dem Operator das Ausgeben gestattet ist oder indem allen nach Ablauf einer Zeitspanne das Ausgeben gestattet wird, um auf Antworttransaktionen zu reagieren.
Derzeit schränken Bitcoin-Skripte hauptsächlich die Bedingungen für die Freischaltung ein, ohne einzuschränken, wie der UTXO weiter ausgegeben werden kann. Dies liegt daran, dass Bitcoin-Skripte den Inhalt der Transaktion selbst nicht lesen können, was bedeutet, dass sie keine Transaktionsintrospektion erreichen können. Wenn Bitcoin-Skripte jeden Inhalt der Transaktion (einschließlich der Ausgaben) überprüfen könnten, könnte die Vertragsfunktionalität realisiert werden.
Aktuelle Vertragsimplementierungen können in zwei Kategorien unterteilt werden:
Sowohl Gültigkeitsnachweise als auch Betrugsnachweise können für das Bitcoin-L2-Scaling verwendet werden, wobei die Hauptunterschiede in Tabelle 2 dargestellt sind.
Tabelle 2: Gültigkeitsnachweise vs. Betrugsnachweise
Basierend auf Bit-Commitment, Taproot, Pre-Signing und Connector Output können Betrugsnachweise auf Bitcoin-Basis erstellt werden. Basierend auf Taproot können auch Gültigkeitsnachweise auf Bitcoin-Basis erstellt werden, indem Vertrags-OP-Codes wie OP_CAT eingeführt werden. Darüber hinaus können Betrugsnachweise je nachdem, ob Bob ein Zulassungssystem hat, in permissioned Betrugsnachweise und permissionless Betrugsnachweise unterteilt werden. Bei permissioned Betrugsnachweisen können nur bestimmte Gruppen als Bob handeln, um Herausforderungen zu initiieren, während bei permissionless Betrugsnachweisen jede dritte Partei als Bob handeln kann, um Herausforderungen zu initiieren. Die Sicherheit von permissionless Betrugsnachweisen ist gegenüber permissioned Betrugsnachweisen überlegen und verringert das Risiko von Kollusion unter den zugelassenen Teilnehmern.
Je nach Anzahl der Challenge-Response-Interaktionen zwischen Alice und Bob können Betrugsnachweise in Ein-Runden-Betrugsnachweise und Mehr-Runden-Betrugsnachweise unterteilt werden, wie in Abbildung 2 gezeigt.
Abbildung 2: Ein-Runden-Betrugsnachweise gegen Mehr-Runden-Betrugsnachweise
Wie in Tabelle 3 gezeigt, können Betrugsnachweise durch verschiedene Interaktionsmodelle umgesetzt werden, einschließlich Ein-Runden-Interaktionsmodelle und Mehr-Runden-Interaktionsmodelle.
Tabelle 3: Ein-Runden-Interaktion vs. Mehr-Runden-Interaktion
Im Bitcoin Layer2-Skalierungsparadigma übernimmt BitVM1 einen Mehrfach-Betrugsnachweismechanismus, während BitVM2 einen Einmal-Betrugsnachweismechanismus verwendet, und bitcoin-circle stark Gültigkeitsnachweise nutzt. Unter diesen können BitVM1 und BitVM2 ohne Änderungen am Bitcoin-Protokoll implementiert werden, während bitcoin-circle stark die Einführung eines neuen Opcodes OP_CAT erfordert.
Für die meisten Rechenaufgaben können das Signet, das Testnetz und das Mainnet von Bitcoin ein 4-MB-Skript nicht vollständig darstellen, was den Einsatz der Skript-Split-Technologie erfordert, d. h. die Aufteilung des gesamten Berechnungsskripts in Blöcke, die kleiner als 4 MB sind und auf verschiedene Tapleafs verteilt sind.
Wie in Tabelle 3 gezeigt, eignen sich mehrstufige Betrugsnachweise für Szenarien, in denen der Wunsch besteht, die On-Chain-Schiedsberechnung zu reduzieren und/oder in denen es nicht möglich ist, problematische Berechnungssegmente auf einmal zu lokalisieren. Wie der Name schon sagt, erfordern mehrstufige Betrugsnachweise mehrere Interaktionsrunden zwischen dem Beweiser und dem Überprüfer, um die problematischen Berechnungssegmente zu lokalisieren, gefolgt von einer Schiedsentscheidung auf der Grundlage der identifizierten Segmente.
Robin Linus frühes BitVM-Whitepaper (gemeinhin als BitVM1 bezeichnet) verwendete mehrstufige Betrugsnachweise. Wenn wir davon ausgehen, dass jeder Herausforderungszeitraum eine Woche dauert und eine binäre Suchmethode verwendet wird, um die problematischen Berechnungssegmente zu lokalisieren, könnte sich der On-Chain-Herausforderungsantwortzeitraum für den Groth16-Verifizierer auf bis zu 30 Wochen erstrecken, was zu einer schlechten Aktualität führt. Obwohl derzeit Teams nach effizienteren n-ären Suchmethoden als der binären Suche forschen, ist ihre Aktualität immer noch erheblich niedriger im Vergleich zu den 2-wöchigen Zyklen bei Einrunden-Betrugsnachweisen.
Derzeit verwenden Mehrfachrunden-Betrugsnachweise im Bitcoin-Paradigma genehmigte Herausforderungen, während Einrunden-Betrugsnachweise eine genehmigungslose Herausforderungsmethode erreicht haben, die das Risiko von Absprachen zwischen den Teilnehmern verringert und somit die Sicherheit erhöht. Zu diesem Zweck hat Robin Linus die Vorteile von Taproot voll ausgeschöpft, um BitVM1 zu optimieren. Nicht nur wurde die Anzahl der Interaktionsrunden auf eins reduziert, sondern auch die Herausforderungsmethode auf einen genehmigungslosen Ansatz erweitert, wenn auch auf Kosten einer erhöhten Berechnung der On-Chain-Schiedsgerichtsbarkeit.
In diesem Modell kann die Überprüfung von Betrugsnachweisen durch eine einzige Interaktion zwischen dem Beweisenden und dem Verifizierenden abgeschlossen werden. Der Verifizierende muss nur eine Herausforderung initiieren, und der Beweisende muss nur einmal antworten. In dieser Antwort muss der Beweisende Beweise liefern, die behaupten, dass seine Berechnung korrekt ist. Wenn der Verifizierende Unstimmigkeiten in diesen Beweisen feststellen kann, ist die Herausforderung erfolgreich, sonst scheitert sie. Die Merkmale von einstufigen interaktiven Betrugsnachweisen sind in Tabelle 3 dargestellt.
Abbildung 3: Betrugsnachweis in einer Runde
Am 15. August 2024 veröffentlichte Robin Linus das BitVM2: Brücken von Bitcoin zu Second Layers Technical White Paper, das eine Cross-Chain-Brücke mithilfe einer One-Round-Betrugsnachweismethode implementierte, die der in Abbildung 3 gezeigten ähnelt.
OPCAT war Teil der ursprünglichen Skriptsprache, als Bitcoin veröffentlicht wurde, wurde aber 2010 aufgrund von Sicherheitslücken deaktiviert. Die Bitcoin-Community diskutiert jedoch seit Jahren über die Wiederaktivierung. OPCAT wurde nun die Nummer 347 zugewiesen und auf dem Signet von Bitcoin aktiviert.
Die Hauptfunktion von OP_CAT besteht darin, zwei Elemente im Stapel zu kombinieren und das zusammengeführte Ergebnis zurück auf den Stapel zu drücken. Diese Funktionalität eröffnet die Möglichkeit für Verträge und STARK-Verifizierer auf Bitcoin:
Obwohl die Rechenlast, die zum Ausführen des entsprechenden Verifikationsalgorithmus zur Überprüfung des Nachweises nach SNARK/STARK-Nachweis erforderlich ist, viel geringer ist als die zum direkten Ausführen der ursprünglichen Berechnung f erforderliche Last, ist die Menge des Skripts, das erforderlich ist, um es in Bitcoin-Skript zu implementieren, immer noch enorm. Der optimierte Groth16-Verifikationsskript-Größe und der Fflonk-Verifikationsskript-Größe basierend auf den vorhandenen Bitcoin-Opcode sind jedoch immer noch größer als 2 GB. Die Größe eines einzelnen Bitcoin-Blocks beträgt jedoch nur 4 MB, so dass es unmöglich ist, das gesamte Verifikationsskript innerhalb eines einzelnen Blocks auszuführen. Seit dem Taproot-Upgrade unterstützt Bitcoin jedoch die Ausführung von Skripten durch Tapleaf, wodurch das Verifikationsskript in mehrere Teile aufgeteilt werden kann, wobei jeder Teil als Tapleaf fungiert, um einen Taptree zu konstruieren. Die Konsistenz der Werte zwischen den Teilen kann durch Bit Commitment sichergestellt werden.
In Anwesenheit von OP_CAT-Verträgen kann der STARK-Verifizierer in mehrere Standardtransaktionen aufgeteilt werden, die kleiner als 400 KB sind, sodass die gesamte STARK-Gültigkeitsprüfung ohne Zusammenarbeit mit Minern abgeschlossen werden kann.
Dieser Abschnitt konzentriert sich auf die relevante Split-Technologie von Bitcoin-Skripten unter den bestehenden Bedingungen, ohne neue Opcodes einzuführen oder zu aktivieren.
Beim Durchführen der Skriptaufteilung müssen die folgenden Informationsdimensionen ausgeglichen werden:
Derzeit lassen sich die Methoden zur Skript-Aufteilung in die folgenden drei Hauptkategorien einteilen:
Beispielsweise wurde nach mehreren Runden der Optimierung die Skriptgröße des Groth16-Verifizierers von etwa 7 GB auf ungefähr 1,26 GB reduziert. Neben dieser allgemeinen Rechenoptimierung kann auch jeder Chunk individuell optimiert werden, um den Stapelspeicher vollständig zu nutzen. Durch die Einführung von besseren Algorithmus basierten Suchtabellen und dem dynamischen Laden und Entladen der Suchtabelle kann beispielsweise die Skriptgröße jedes Chunks weiter reduziert werden.
Die Rechenkosten und Laufzeitumgebungen von Web2-Programmiersprachen sind völlig unterschiedlich von denen der Bitcoin-Skripte. Daher ist es nicht machbar, einfach bestehende Implementierungen für verschiedene Algorithmen in Bitcoin-Skripte zu übersetzen. Daher müssen Optimierungen speziell für das Bitcoin-Szenario berücksichtigt werden:
Dieser Artikel stellt zunächst die Grenzen von Bitcoin-Skripten vor und diskutiert die Verwendung von Bitcoin-Commitments, um die UTXO-zustandslose Begrenzung zu überwinden, die Verwendung von Taproot, um Skriptplatzbegrenzungen zu überwinden, die Verwendung von Connector-Ausgaben zur Umgehung von UTXO-Ausgabenmethodenbeschränkungen und die Verwendung von Verträgen zur Überwindung von Vorzeichnungsgrenzen. Anschließend wird ein umfassender Überblick und eine Zusammenfassung der Merkmale von Betrugsnachweisen und Gültigkeitsnachweisen gegeben, der Funktionen von genehmigten und nicht genehmigten Betrugsnachweisen, der Unterschiede zwischen einrunden und mehrstufigen Betrugsnachweisen sowie der Technologie der Aufteilung von Bitcoin-Skripten.
Für einen Algorithmus f können zwei gegenseitig misstrauische Teilnehmer, Alice und Bob, auf folgende Weise Vertrauen aufbauen:
Für die oben genannten 2, 3 und 4 sei x Layer2-Transaktionen und der Anfangszustand, f das Layer2-Konsensprogramm und y der Transaktionsendzustand, der der Blockchain-Layer2-Skalierungslösung entspricht. Unter ihnen:
Tabelle 1: Möglichkeiten zur Vertrauensbildung
Darüber hinaus ist es wichtig zu beachten:
Derzeit werden aufgrund der Turing-vollständigen Smart Contracts von Solidity Betrugsnachweise und Gültigkeitsnachweise häufig in der Ethereum Layer2-Skalierung eingesetzt. Unter dem Bitcoin-Paradigma sind diese Technologien jedoch aufgrund der begrenzten Opcode-Funktionalität von Bitcoin, der 1000 Stapel-Elemente und anderer Einschränkungen noch immer in der explorativen Phase. Dieser Artikel fasst die Einschränkungen und Durchbruchstechnologien unter dem Bitcoin-Paradigma im Kontext der Bitcoin Layer2-Skalierung zusammen, untersucht Gültigkeitsnachweis- und Betrugsnachweistechnologien und skizziert die einzigartige Skriptsegmentierungstechnologie unter dem Bitcoin-Paradigma.
Es gibt viele Einschränkungen im Bitcoin-Paradigma, aber verschiedene clevere Methoden oder Techniken können verwendet werden, um diese Einschränkungen zu überwinden. Zum Beispiel kann die Bit-Commitment die stateless-Einschränkung des UTXO durchbrechen, der Taproot kann die Script-Space-Einschränkungen durchbrechen, der Connector-Output kann die UTXO-Spending-Methoden-Einschränkungen durchbrechen und Verträge können die Einschränkungen der Vor-Unterschrift durchbrechen.
Bitcoin verwendet das UTXO-Modell, bei dem jedes UTXO in einem Sperrskript gesperrt ist, das die Bedingungen definiert, die erfüllt sein müssen, um dieses UTXO auszugeben. Bitcoin-Skripte haben folgende Einschränkungen:
Derzeit sind Bitcoin-Skripte vollständig zustandslos. Bei der Ausführung eines Bitcoin-Skripts wird die Ausführungsumgebung nach jedem Skript zurückgesetzt. Dies führt dazu, dass Bitcoin-Skripte die nativ die Einschränkung von Skripten 1 und 2 mit dem gleichen x-Wert unterstützen können. Allerdings kann dieses Problem durch einige Methoden umgangen werden, wobei die Kernidee darin besteht, einen Wert auf irgendeine Weise zu signieren. Wenn für einen Wert eine Signatur erstellt werden kann, ist es möglich, zustandsbehaftete Bitcoin-Skripte zu erreichen. Das bedeutet, dass durch Überprüfung der Signatur des x-Werts in Skripten 1 und 2 durchgesetzt werden kann, dass derselbe x-Wert in beiden Skripten verwendet wird. Bei einer konkurrierenden Signatur, d. h. wenn zwei verschiedene Werte für dieselbe Variable x signiert werden, kann eine Strafe verhängt werden. Diese Lösung ist als Bit-Commitment bekannt.
Das Prinzip der Bit-Verpflichtung ist relativ einfach. Ein Bit bezieht sich auf das Festlegen von zwei unterschiedlichen Hash-Werten, Hash0 und Hash1, für jedes Bit in der zu signierenden Nachricht. Wenn der zu signierende Bit-Wert 0 ist, wird das Ursprungsbild0 von Hash0 offengelegt; wenn der zu signierende Bit-Wert 1 ist, wird das Ursprungsbild1 von Hash1 offengelegt.
Am Beispiel einer einzelnen Bitnachricht m ∈{0,1} besteht das entsprechende Bit-Commit-Entsperrskript nur aus einigen Vorbildern: Wenn der Bitwert 0 ist, ist das entsprechende Entsperrskript preimage0—"0xfa7fa5b1dea37d71a0b841967f6a3b119dbea140"; Wenn der Bitwert 1 ist, lautet das entsprechende Entsperrskript preimage1 – "0x47c31e611a3bd2f3a7a42207613046703fa27496". Daher ist es mit Bit-Engagement möglich, die zustandslose UTXO-Begrenzung zu durchbrechen und zustandsbehaftete Bitcoin-Skripte zu erhalten, die verschiedene interessante neue Funktionen ermöglichen.
OP_HASH160
OP_DUP
0xf592e757267b7f307324f1e78b34472f8b6f46f3> // Dies ist hash1
OP_EQUAL
OP_DUP
OP_ROT
0x100b9f19ebd537fdc371fa1367d7ccc802dc2524> // Dies ist hash0
OP_EQUAL
OP_BOOLOR
OP_VERIFY
Jetzt befindet sich der Wert der Bit-Bindung auf dem Stapel. Entweder "0" oder "1".
Derzeit gibt es 2 Implementierungen der Bit-Verpflichtung:
Derzeit implementiert die BitVM2-Bibliothek Winternitz-Signaturen auf Basis der Hash-Funktion Blake3. Die Signaturlänge, die einem einzelnen Bit entspricht, beträgt etwa 26 Bytes. Daher ist zu erkennen, dass die Einführung von Zustand durch Bit-Commitment kostspielig ist. In der BitVM2-Implementierung wird die Nachricht daher zunächst gehasht, um einen 256-Bit-Hash-Wert zu erhalten, und dann wird das Bit-Commitment auf den Hash-Wert durchgeführt, um Overhead zu sparen, anstatt sich direkt auf jedes Bit der ursprünglich längeren Nachricht zu verpflichten.
Das Bitcoin Taproot Soft Fork Upgrade, das im November 2021 aktiviert wurde, umfasst drei Vorschläge: Schnorr-Signaturen (BIP 340), Taproot (BIP 341) und TapScript (BIP 342). Es führt einen neuen Transaktionstyp ein - Pay-to-Taproot (P2TR)-Transaktionen. P2TR-Transaktionen können ein privateres, flexibleres und skalierbareres Transaktionsformat schaffen, indem sie die Vorteile von Taproot, MAST (Merkel Abstract Syntax Tree) und Schnorr-Signaturen kombinieren.
P2TR unterstützt zwei Ausgabemethoden: Ausgabe nach dem Schlüsselpfad oder dem Skriptpfad.
Gemäß den Bestimmungen in Taproot (BIP 341) darf beim Ausgeben über den Skriptpfad der entsprechende Merkle-Pfad eine maximale Länge von 128 nicht überschreiten. Dies bedeutet, dass die Anzahl der Tapleafs im Taptree 2^128 nicht überschreiten kann. Seit dem SegWit-Upgrade im Jahr 2017 misst das Bitcoin-Netzwerk die Blockgröße in Gewichtseinheiten, mit einer maximalen Unterstützung von 4 Millionen Gewichtseinheiten (ungefähr 4 MB). Wenn ein P2TR-Ausgang über den Skriptpfad ausgegeben wird, muss nur ein einzelnes Tapleaf-Skript offengelegt werden, was bedeutet, dass der Block mit einem einzigen Tapleaf-Skript gepackt ist. Das bedeutet, dass für P2TR-Transaktionen die Skriptgröße, die jedem Tapleaf entspricht, maximal etwa 4 MB betragen kann. Unter der Standardrichtlinie von Bitcoin leiten jedoch viele Knoten nur Transaktionen kleiner als 400K weiter; größere Transaktionen müssen mit Minern zusammenarbeiten, um gepackt zu werden.
Die von Taproot mitgebrachte Script-Space-Prämie macht es wertvoller, kryptografische Operationen wie Multiplikation und Hashing mit vorhandenen Opcodes zu simulieren.
Bei der Erstellung überprüfbarer Berechnungen auf der Grundlage von P2TR ist die entsprechende Skriptgröße nicht mehr auf die 4-MB-Einschränkung beschränkt, sondern kann in mehrere Unterfunktionen aufgeteilt werden, die auf mehrere Tapleafs verteilt sind, wodurch die 4-MB-Skriptplatzbeschränkung durchbrochen wird. Tatsächlich hat der Groth16-Verifier-Algorithmus, der im aktuellen BitVM2 implementiert ist, eine Größe von bis zu 2 GB. Sie kann jedoch aufgeteilt und auf etwa 1000 Tapleafs verteilt werden, und durch die Kombination mit Bitbindung kann die Konsistenz zwischen den Ein- und Ausgängen jeder Unterfunktion eingeschränkt werden, wodurch die Integrität und Richtigkeit der gesamten Berechnung sichergestellt wird.
Derzeit bietet Bitcoin zwei native Ausgabemethoden für einen einzelnen UTXO: Ausgaben per Skript oder per öffentlichem Schlüssel. Solange die korrekten Signatur- oder Skriptbedingungen des öffentlichen Schlüssels erfüllt sind, kann der UTXO daher ausgegeben werden. Zwei UTXOs können unabhängig voneinander ausgegeben werden, und es können keine Einschränkungen hinzugefügt werden, um die beiden UTXOs einzuschränken, was bedeutet, dass zusätzliche Bedingungen erfüllt sein müssen, damit sie ausgegeben werden können.
Jedoch machte Burak, der Gründer des Ark-Protokolls, cleveren Gebrauch vom SIGHASH-Flag, um den Connector-Output zu erreichen. Konkret kann Alice eine Signatur erstellen, um ihre BTC an Bob zu senden. Da die Signatur jedoch mehrere Inputs bestätigen kann, kann Alice ihre Signatur bedingt setzen: Die Signatur ist für die Taketx-Transaktion gültig, wenn und nur wenn diese Transaktion den zweiten Input verbraucht. Der zweite Input wird als Connector bezeichnet und verbindet UTXO A und UTXO B. Mit anderen Worten ist die Taketx-Transaktion nur dann gültig, wenn UTXO B nicht von Challengetx ausgegeben wurde. Durch die Zerstörung des Connector-Outputs kann die Wirksamkeit der Taketx-Transaktion blockiert werden.
Abbildung 1: Illustration der Anschlussausgabe
Im BitVM2-Protokoll fungiert der Connector-Ausgang als eine if...else-Funktion. Sobald der Connector-Ausgang von einer Transaktion ausgegeben wurde, kann er nicht von einer anderen Transaktion ausgegeben werden, um seine exklusive Ausgabe sicherzustellen. Bei praktischer Implementierung werden zusätzliche UTXOs mit Zeitsperre eingeführt, um eine Herausforderungs-Antwort-Periode zu ermöglichen. Darüber hinaus kann der entsprechende Connector-Ausgang je nach Bedarf auch mit unterschiedlichen Ausgabestrategien festgelegt werden, z.B. indem er allen Parteien erlaubt wird, bei Herausforderungstransaktionen auszugeben, während nur dem Operator das Ausgeben gestattet ist oder indem allen nach Ablauf einer Zeitspanne das Ausgeben gestattet wird, um auf Antworttransaktionen zu reagieren.
Derzeit schränken Bitcoin-Skripte hauptsächlich die Bedingungen für die Freischaltung ein, ohne einzuschränken, wie der UTXO weiter ausgegeben werden kann. Dies liegt daran, dass Bitcoin-Skripte den Inhalt der Transaktion selbst nicht lesen können, was bedeutet, dass sie keine Transaktionsintrospektion erreichen können. Wenn Bitcoin-Skripte jeden Inhalt der Transaktion (einschließlich der Ausgaben) überprüfen könnten, könnte die Vertragsfunktionalität realisiert werden.
Aktuelle Vertragsimplementierungen können in zwei Kategorien unterteilt werden:
Sowohl Gültigkeitsnachweise als auch Betrugsnachweise können für das Bitcoin-L2-Scaling verwendet werden, wobei die Hauptunterschiede in Tabelle 2 dargestellt sind.
Tabelle 2: Gültigkeitsnachweise vs. Betrugsnachweise
Basierend auf Bit-Commitment, Taproot, Pre-Signing und Connector Output können Betrugsnachweise auf Bitcoin-Basis erstellt werden. Basierend auf Taproot können auch Gültigkeitsnachweise auf Bitcoin-Basis erstellt werden, indem Vertrags-OP-Codes wie OP_CAT eingeführt werden. Darüber hinaus können Betrugsnachweise je nachdem, ob Bob ein Zulassungssystem hat, in permissioned Betrugsnachweise und permissionless Betrugsnachweise unterteilt werden. Bei permissioned Betrugsnachweisen können nur bestimmte Gruppen als Bob handeln, um Herausforderungen zu initiieren, während bei permissionless Betrugsnachweisen jede dritte Partei als Bob handeln kann, um Herausforderungen zu initiieren. Die Sicherheit von permissionless Betrugsnachweisen ist gegenüber permissioned Betrugsnachweisen überlegen und verringert das Risiko von Kollusion unter den zugelassenen Teilnehmern.
Je nach Anzahl der Challenge-Response-Interaktionen zwischen Alice und Bob können Betrugsnachweise in Ein-Runden-Betrugsnachweise und Mehr-Runden-Betrugsnachweise unterteilt werden, wie in Abbildung 2 gezeigt.
Abbildung 2: Ein-Runden-Betrugsnachweise gegen Mehr-Runden-Betrugsnachweise
Wie in Tabelle 3 gezeigt, können Betrugsnachweise durch verschiedene Interaktionsmodelle umgesetzt werden, einschließlich Ein-Runden-Interaktionsmodelle und Mehr-Runden-Interaktionsmodelle.
Tabelle 3: Ein-Runden-Interaktion vs. Mehr-Runden-Interaktion
Im Bitcoin Layer2-Skalierungsparadigma übernimmt BitVM1 einen Mehrfach-Betrugsnachweismechanismus, während BitVM2 einen Einmal-Betrugsnachweismechanismus verwendet, und bitcoin-circle stark Gültigkeitsnachweise nutzt. Unter diesen können BitVM1 und BitVM2 ohne Änderungen am Bitcoin-Protokoll implementiert werden, während bitcoin-circle stark die Einführung eines neuen Opcodes OP_CAT erfordert.
Für die meisten Rechenaufgaben können das Signet, das Testnetz und das Mainnet von Bitcoin ein 4-MB-Skript nicht vollständig darstellen, was den Einsatz der Skript-Split-Technologie erfordert, d. h. die Aufteilung des gesamten Berechnungsskripts in Blöcke, die kleiner als 4 MB sind und auf verschiedene Tapleafs verteilt sind.
Wie in Tabelle 3 gezeigt, eignen sich mehrstufige Betrugsnachweise für Szenarien, in denen der Wunsch besteht, die On-Chain-Schiedsberechnung zu reduzieren und/oder in denen es nicht möglich ist, problematische Berechnungssegmente auf einmal zu lokalisieren. Wie der Name schon sagt, erfordern mehrstufige Betrugsnachweise mehrere Interaktionsrunden zwischen dem Beweiser und dem Überprüfer, um die problematischen Berechnungssegmente zu lokalisieren, gefolgt von einer Schiedsentscheidung auf der Grundlage der identifizierten Segmente.
Robin Linus frühes BitVM-Whitepaper (gemeinhin als BitVM1 bezeichnet) verwendete mehrstufige Betrugsnachweise. Wenn wir davon ausgehen, dass jeder Herausforderungszeitraum eine Woche dauert und eine binäre Suchmethode verwendet wird, um die problematischen Berechnungssegmente zu lokalisieren, könnte sich der On-Chain-Herausforderungsantwortzeitraum für den Groth16-Verifizierer auf bis zu 30 Wochen erstrecken, was zu einer schlechten Aktualität führt. Obwohl derzeit Teams nach effizienteren n-ären Suchmethoden als der binären Suche forschen, ist ihre Aktualität immer noch erheblich niedriger im Vergleich zu den 2-wöchigen Zyklen bei Einrunden-Betrugsnachweisen.
Derzeit verwenden Mehrfachrunden-Betrugsnachweise im Bitcoin-Paradigma genehmigte Herausforderungen, während Einrunden-Betrugsnachweise eine genehmigungslose Herausforderungsmethode erreicht haben, die das Risiko von Absprachen zwischen den Teilnehmern verringert und somit die Sicherheit erhöht. Zu diesem Zweck hat Robin Linus die Vorteile von Taproot voll ausgeschöpft, um BitVM1 zu optimieren. Nicht nur wurde die Anzahl der Interaktionsrunden auf eins reduziert, sondern auch die Herausforderungsmethode auf einen genehmigungslosen Ansatz erweitert, wenn auch auf Kosten einer erhöhten Berechnung der On-Chain-Schiedsgerichtsbarkeit.
In diesem Modell kann die Überprüfung von Betrugsnachweisen durch eine einzige Interaktion zwischen dem Beweisenden und dem Verifizierenden abgeschlossen werden. Der Verifizierende muss nur eine Herausforderung initiieren, und der Beweisende muss nur einmal antworten. In dieser Antwort muss der Beweisende Beweise liefern, die behaupten, dass seine Berechnung korrekt ist. Wenn der Verifizierende Unstimmigkeiten in diesen Beweisen feststellen kann, ist die Herausforderung erfolgreich, sonst scheitert sie. Die Merkmale von einstufigen interaktiven Betrugsnachweisen sind in Tabelle 3 dargestellt.
Abbildung 3: Betrugsnachweis in einer Runde
Am 15. August 2024 veröffentlichte Robin Linus das BitVM2: Brücken von Bitcoin zu Second Layers Technical White Paper, das eine Cross-Chain-Brücke mithilfe einer One-Round-Betrugsnachweismethode implementierte, die der in Abbildung 3 gezeigten ähnelt.
OPCAT war Teil der ursprünglichen Skriptsprache, als Bitcoin veröffentlicht wurde, wurde aber 2010 aufgrund von Sicherheitslücken deaktiviert. Die Bitcoin-Community diskutiert jedoch seit Jahren über die Wiederaktivierung. OPCAT wurde nun die Nummer 347 zugewiesen und auf dem Signet von Bitcoin aktiviert.
Die Hauptfunktion von OP_CAT besteht darin, zwei Elemente im Stapel zu kombinieren und das zusammengeführte Ergebnis zurück auf den Stapel zu drücken. Diese Funktionalität eröffnet die Möglichkeit für Verträge und STARK-Verifizierer auf Bitcoin:
Obwohl die Rechenlast, die zum Ausführen des entsprechenden Verifikationsalgorithmus zur Überprüfung des Nachweises nach SNARK/STARK-Nachweis erforderlich ist, viel geringer ist als die zum direkten Ausführen der ursprünglichen Berechnung f erforderliche Last, ist die Menge des Skripts, das erforderlich ist, um es in Bitcoin-Skript zu implementieren, immer noch enorm. Der optimierte Groth16-Verifikationsskript-Größe und der Fflonk-Verifikationsskript-Größe basierend auf den vorhandenen Bitcoin-Opcode sind jedoch immer noch größer als 2 GB. Die Größe eines einzelnen Bitcoin-Blocks beträgt jedoch nur 4 MB, so dass es unmöglich ist, das gesamte Verifikationsskript innerhalb eines einzelnen Blocks auszuführen. Seit dem Taproot-Upgrade unterstützt Bitcoin jedoch die Ausführung von Skripten durch Tapleaf, wodurch das Verifikationsskript in mehrere Teile aufgeteilt werden kann, wobei jeder Teil als Tapleaf fungiert, um einen Taptree zu konstruieren. Die Konsistenz der Werte zwischen den Teilen kann durch Bit Commitment sichergestellt werden.
In Anwesenheit von OP_CAT-Verträgen kann der STARK-Verifizierer in mehrere Standardtransaktionen aufgeteilt werden, die kleiner als 400 KB sind, sodass die gesamte STARK-Gültigkeitsprüfung ohne Zusammenarbeit mit Minern abgeschlossen werden kann.
Dieser Abschnitt konzentriert sich auf die relevante Split-Technologie von Bitcoin-Skripten unter den bestehenden Bedingungen, ohne neue Opcodes einzuführen oder zu aktivieren.
Beim Durchführen der Skriptaufteilung müssen die folgenden Informationsdimensionen ausgeglichen werden:
Derzeit lassen sich die Methoden zur Skript-Aufteilung in die folgenden drei Hauptkategorien einteilen:
Beispielsweise wurde nach mehreren Runden der Optimierung die Skriptgröße des Groth16-Verifizierers von etwa 7 GB auf ungefähr 1,26 GB reduziert. Neben dieser allgemeinen Rechenoptimierung kann auch jeder Chunk individuell optimiert werden, um den Stapelspeicher vollständig zu nutzen. Durch die Einführung von besseren Algorithmus basierten Suchtabellen und dem dynamischen Laden und Entladen der Suchtabelle kann beispielsweise die Skriptgröße jedes Chunks weiter reduziert werden.
Die Rechenkosten und Laufzeitumgebungen von Web2-Programmiersprachen sind völlig unterschiedlich von denen der Bitcoin-Skripte. Daher ist es nicht machbar, einfach bestehende Implementierungen für verschiedene Algorithmen in Bitcoin-Skripte zu übersetzen. Daher müssen Optimierungen speziell für das Bitcoin-Szenario berücksichtigt werden:
Dieser Artikel stellt zunächst die Grenzen von Bitcoin-Skripten vor und diskutiert die Verwendung von Bitcoin-Commitments, um die UTXO-zustandslose Begrenzung zu überwinden, die Verwendung von Taproot, um Skriptplatzbegrenzungen zu überwinden, die Verwendung von Connector-Ausgaben zur Umgehung von UTXO-Ausgabenmethodenbeschränkungen und die Verwendung von Verträgen zur Überwindung von Vorzeichnungsgrenzen. Anschließend wird ein umfassender Überblick und eine Zusammenfassung der Merkmale von Betrugsnachweisen und Gültigkeitsnachweisen gegeben, der Funktionen von genehmigten und nicht genehmigten Betrugsnachweisen, der Unterschiede zwischen einrunden und mehrstufigen Betrugsnachweisen sowie der Technologie der Aufteilung von Bitcoin-Skripten.