1 Einführung

Für einen Algorithmus f können zwei gegenseitig misstrauische Teilnehmer, Alice und Bob, auf folgende Weise Vertrauen aufbauen:

1. Alice gibt x ein, führt den Algorithmus f aus und erhält das Ergebnis y. Bob führt auch den Algorithmus f mit demselben Eingang x aus, was zu y′ führt. Wenn y = y′, bestätigt Bob den von Alice bereitgestellten Eingang x und das Ergebnis y. Dies ist ein spezieller Gültigkeitsnachweismechanismus, der häufig beim Blockchain-Konsens verwendet wird, wobei Alice der Knoten ist, der den Block verpackt, und Bob der Knoten ist, der am Konsens teilnimmt.
2. Alice gibt x ein, führt das zk.prove-Programm auf Algorithmus f aus und erhält das Ergebnis y und den Nachweis proof. Bob führt das zk.verify-Programm basierend auf f, y und proof aus. Wenn das Ergebnis wahr ist, bestätigt Bob das Ergebnis y von Alice. Wenn das Ergebnis falsch ist, bestätigt Bob das Ergebnis y von Alice nicht. Dies ist ein Gültigkeitsnachweis, bei dem Bob ein On-Chain-Vertrag sein kann.
3. Alice gibt x ein, führt den Algorithmus f aus und erhält das Ergebnis y. Bob führt auch den Algorithmus f mit demselben Eingang x aus und erhält y′. Wenn y = y′, wird nichts unternommen; wenn y ≠ y′, fordert Bob Alice heraus, wobei das angefochtene Programm f ist. Die Anzahl der Interaktionen zwischen Alice und Bob kann ein oder mehrere sein. Die Schlichtung erfolgt durch den Herausforderungs-Antwort-Prozess. Dies ist ein Betrugsnachweis, bei dem Bob der Herausforderer ist, der Off-Chain lauscht und On-Chain herausfordert.
4. Alice gibt x ein, führt das zk.prove-Programm auf dem Algorithmus f aus und erhält das Ergebnis y und den Nachweis proof. Bob führt das zk.verify-Programm basierend auf f, y und proof aus. Wenn das Ergebnis wahr ist, wird nichts unternommen; wenn das Ergebnis falsch ist, fordert Bob Alice heraus, wobei das herausgeforderte Programm zk.verify ist. Die Anzahl der Interaktionen zwischen Alice und Bob kann eins oder mehrere sein. Die Schiedsgerichtsbarkeit wird durch den Challenge-Response-Prozess erreicht. Dies ist ein Betrugsnachweis, bei dem Bob der Herausforderer ist, der off-chain lauscht und on-chain herausfordert.

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:

• Gültigkeitsnachweis: Basierend auf einer pessimistischen Annahme muss er vor der Annahme als gültig nachgewiesen werden und tritt sofort in Kraft. Bei einem Gültigkeitsnachweis muss ein Nachweis für korrekte L2-Zustandsübergänge erbracht werden, der eine pessimistische Sichtweise der Welt widerspiegelt—nur wenn ein Zustand als korrekt nachgewiesen wird, wird er akzeptiert.
• Betrugsnachweis: Basierend auf einer optimistischen Annahme wird er standardmäßig akzeptiert, es sei denn, jemand beweist, dass er inkorrekt ist. Es hat ein Herausforderungsfenster, das nur nach Ablauf des Herausforderungsfensters wirksam wird. Bei einem Betrugsnachweis muss ein Nachweis für inkorrekte L2-Zustandsübergänge erbracht werden, der eine optimistische Sichtweise der Welt widerspiegelt - ein Zustandsübergang wird als korrekt angesehen, es sei denn, das Gegenteil wird bewiesen.

Tabelle 1: Möglichkeiten zur Vertrauensbildung

Darüber hinaus ist es wichtig zu beachten:

• Der Schlüssel zur Unterscheidung zwischen Betrugsnachweisen und Gültigkeitsnachweisen liegt nicht darin, ob ZK-Beweissysteme wie SNARK/STARK verwendet werden. Das ZK-Beweissystem drückt die verwendete Beweismethode aus, während Betrug oder Gültigkeit den zu beweisenden Inhalt darstellt. Deshalb wird Szenario 1 in Tabelle 1 als Gültigkeitsnachweis bezeichnet.
• Gültigkeitsnachweise haben eine bessere Aktualität, aber die Komplexität der On-Chain-Verifikation ist relativ hoch; Betrugsnachweise haben eine geringere Komplexität der On-Chain-Verifikation, aber ihre Aktualität ist relativ schlecht.
• Für die Fälle 2 und 4 in Tabelle 1 können durch die Verwendung von ZK-Rekursion und Kombinationstechniken mehrere f berechnet und komprimiert werden, was die Verifizierungskosten der Off-Chain-Berechnung auf der Chain erheblich reduziert.

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.

2 Einschränkungen und Durchbrüche im 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.

2.1 UTXO-Modell und Skriptbeschränkungen

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:

1. Bitcoin-Skripte sind zustandslos;
2. Für P2TR-Ausgabetypen beträgt die maximale Anzahl der Opcodes, die in einer einzigen Transaktion untergebracht werden können, etwa 4 Millionen, was den gesamten Block füllt, während es für andere Ausgabetypen nur 10.000 Opcodes gibt.
3. Die Ausgabemethoden eines einzelnen UTXO sind begrenzt und es mangelt an der Erforschung kombinierter Ausgabemethoden;
4. Flexible Vertragsfunktionen werden nicht unterstützt;
5. Die Stapelgröße ist auf maximal 1000 Elemente (altstack + stack) begrenzt, und die maximale Größe eines einzelnen Elements beträgt 520 Bytes;
6. Arithmetische Operationen (wie Addition und Subtraktion) sind auf 4-Byte-Elemente beschränkt. Sie können nicht in lange Elemente wie 20 Bytes oder größer geändert werden, die für kryptographische Operationen erforderlich sind;
7. Opcodes wie OPMUL und OPCAT wurden deaktiviert, und ihre Simulation mit vorhandenen Opcodes verursacht extrem hohe Kosten, z. B. die Simulation eines BLAKE3-Hashes in einer Runde mit einem Skript von etwa 75K.

2.2 Bit Commitment: Überwindung der UTXO-Statusgrenze

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:

• Lamport-Einmal-Signatur: Das Prinzip ist relativ einfach und erfordert nur die Verwendung von Hash-Funktionen, was es Bitcoin-freundlich macht. Für jedes Bit in der Nachricht müssen zwei Hash-Werte verpflichtet werden, was zu relativ großen Signaturdaten führt. Mit anderen Worten, für eine Nachricht der Länge v Bits beträgt die Länge des öffentlichen Schlüssels 2v Bits und die Länge der Signatur v Bits.
• Winternitz One-Time Signature: Im Vergleich zu Lamport-Signaturen reduziert es die Länge von Signaturen und öffentlichen Schlüsseln erheblich, erhöht aber die Komplexität des Signierens und Verifizierens. Dieses Schema ermöglicht die flexible Einstellung verschiedener Hashkettenlängen d und sorgt so für ein ausgewogenes Verhältnis von Länge und Komplexität. Wenn Sie z. B. d = 15 festlegen, sind sowohl die Länge des öffentlichen Schlüssels als auch die Länge der Signatur etwa 4-mal kürzer, aber die Überprüfungskomplexität erhöht sich um das 4-fache. Dies ist im Wesentlichen ein Kompromiss zwischen dem Stapelplatz von Bitcoin und der Skriptgröße. Lamport-Signaturen können als Spezialfall der Winternitz-Signaturen angesehen werden, wenn d = 1 ist.

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.

2.3 Taproot: Überwindung von Script-Speicherbegrenzungen

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.

2.4 Connector-Ausgabe: Überwindung der Einschränkungen der UTXO-Ausgabemethode

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.

2.5 Verträge: Überwindung von Vorunterschriftenbeschränkungen

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:

• Vorab-Unterzeichnung: Basierend auf bestehenden Bitcoin-Skript-Funktionen werden vorab festgelegte Verträge mit eingeschränkter Funktionalität durch Vorab-Unterzeichnung erstellt. Das bedeutet, dass alle möglichen zukünftigen Transaktionen im Voraus entworfen und signiert werden müssen, wobei die Teilnehmer an bestimmte private Schlüssel und Gebührensätze gebunden sind. Einige Systeme verlangen sogar, dass die Teilnehmer kurzfristige private Schlüssel für alle vorsignierten Transaktionen generieren. Sobald die Vorabsignatur abgeschlossen ist, werden diese kurzfristigen privaten Schlüssel sicher gelöscht, um Angreifer daran zu hindern, sie zu erhalten und Gelder zu stehlen. Jedes Mal, wenn ein neuer Teilnehmer hinzugefügt oder ein Vorgang aktualisiert wird, muss der oben beschriebene Vorgang jedoch wiederholt werden, was zu hohen Wartungskosten führt. Zum Beispiel erreicht das Lightning Network Zwei-Parteien-Verträge durch Vorab-Signierung und nutzt die Hash Time-Locked Contracts (HTLC)-Technologie, um Routing-Funktionen für mehrere Zwei-Parteien-Verträge zu implementieren und so eine vertrauensminimierte Skalierungsstrategie zu erreichen. Das Lightning Network erfordert jedoch das Vorsignieren mehrerer Transaktionen und ist auf zwei Parteien beschränkt, was es etwas umständlich macht. In BitVM1 müssen bei jeder Initialisierung Hunderte von Transaktionen vorsigniert werden, während im optimierten BitVM2 die Anzahl der Transaktionen, die bei jeder Initialisierung vorsigniert werden müssen, ebenfalls Dutzende erreicht. Sowohl bei BitVM1 als auch bei BitVM2 haben nur Betreiber, die an der Vorabzeichnung teilnehmen, Anspruch auf Erstattung. Wenn n Teilnehmer an der Vorabsignatur beteiligt sind und jeder Teilnehmer m Transaktionen vorab signieren muss, beträgt die Komplexität der Vorabsignatur für jeden Teilnehmer n * m.
• Einführung von Vertrags-Opcodes: Die Einführung neuer Vertragsfunktions-Opcodes kann die Kommunikationskomplexität und die Wartungskosten zwischen den Vertragsteilnehmern erheblich reduzieren und somit eine flexiblere Vertragsumsetzungsmethode für Bitcoin einführen. Zum Beispiel OPCAT: wird verwendet, um Byte-Zeichenfolgen zu verketten. Obwohl seine Funktion sehr einfach ist, ist er sehr leistungsfähig und kann die Komplexität von BitVM erheblich reduzieren. OPTXHASH: ermöglicht eine bessere granulare Kontrolle von Aktionen innerhalb des Vertrags. Wenn es in BitVM verwendet wird, kann es eine größere Anzahl von Operatoren unterstützen, wodurch die Sicherheitsannahmen von BitVM erheblich verbessert und das Vertrauen minimiert wird. Darüber hinaus bedeutet die Pre-Signing-Methode von Natur aus, dass die Betreiber in BitVM nur einen Erstattungsprozess einführen können, was zu einer geringeren Effizienz der Kapitalnutzung führt. In der Erwägung, dass es durch neue Kontrakt-Opcodes möglich sein könnte, direkt aus dem Peg-in-Fondspool an die Output-Nutzer auszuzahlen, wodurch die Kapitaleffizienz weiter verbessert wird. Daher wird ein flexibles Vertragsmodell die traditionellen Einschränkungen vor der Unterzeichnung effektiv durchbrechen.

3 Bitcoin Layer 2 Skalierung: Gültigkeitsnachweise und Betrugsnachweise

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.

3.1 Mehrstufige Betrugsnachweise auf Bitcoin

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.

3.2 Ein-Runden-Betrugsnachweise auf Bitcoin

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.

3.3 Gültigkeitsnachweise zu Bitcoin mit OP_CAT

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:

• Verträge: Andrew Poelstra schlug CAT und Schnorr Tricks I vor, die OPCAT und Schnorr-Techniken verwenden, um Verträge auf Bitcoin zu implementieren. Der Schnorr-Algorithmus ist eine digitale Signatur für P2TR-Ausgabetypen; für andere Ausgabetypen können ähnliche ECDSA-Techniken verwendet werden, wie sie in Covenants mit CAT und ECDSA zu sehen sind. Mit Hilfe von OPCAT-Verträgen kann der STARK-Verifier-Algorithmus in mehrere Transaktionen aufgeteilt werden, um allmählich den gesamten STARK-Nachweis zu überprüfen.
• STARK Verifier: Der STARK Verifier verbindet im Wesentlichen Daten miteinander und hasht sie. Im Gegensatz zu algebraischen Operationen ist das Hashing eine native Bitcoin-Skriptoperation, die eine erhebliche Menge an Overhead einsparen kann. Zum Beispiel ist OPSHA256 ein einzelner Opcode in seiner nativen Form, während eine simulierte Version Hunderte von K-Opcodes erfordert. Die wichtigsten Hashing-Operationen in STARK umfassen die Überprüfung von Merkle-Pfaden und Fiat-Shamir-Transformationen. Daher ist OPCAT sehr freundlich gegenüber dem STARK Verifier-Algorithmus.

3.4 Bitcoin Script Split Technologie

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:

• Die Größe eines einzelnen Chunk-Skripts darf 4 MB nicht überschreiten und sollte Eingabe-Bit-Commitment-Skripte, Transaktionssignaturen und anderen Speicherplatz enthalten.
• Die maximale Stapelgröße eines einzelnen Chunks darf 1000 nicht überschreiten. Daher sollte der Stapel jedes Chunks nur die notwendigen Elemente behalten, um ausreichend Platz für die Optimierung der Skriptgröße zu reservieren, da die Bitcoin-Transaktionsgebühren nicht von der verwendeten Stapelgröße abhängen.
• Bit-Commitment bei Bitcoin ist teuer. Daher sollte die Anzahl der Bits im Eingang und Ausgang zwischen zwei benachbarten Chunks minimiert werden, da derzeit 1 Bit 26 Bytes entspricht.
• Für eine einfache Überprüfung sollte die Funktionalität jedes Abschnitts so klar wie möglich sein.

Derzeit lassen sich die Methoden zur Skript-Aufteilung in die folgenden drei Hauptkategorien einteilen:

• Automatische Aufteilung: Diese Methode sucht einen Aufteilungsansatz, bei dem die Skriptgröße etwa 3 MB beträgt und die Stapelgröße minimiert wird, basierend auf der Stapelgröße und Skriptgröße. Die Vorteile dieser Methode sind, dass sie unabhängig von bestimmten Verifiziereralgorithmen ist und auf Skriptaufteilung für jede Berechnung erweitert werden kann. Die Nachteile sind: (1) der gesamte logische Block muss separat markiert werden, z.B. OP_IF-Codeblöcke, die nicht aufgeteilt werden können; andernfalls ist das Ausführungsergebnis des aufgeteilten Skripts falsch; (2) das Ausführungsergebnis eines Chunks kann mehreren Elementen auf dem Stapel entsprechen, wodurch die Anzahl der Stapellemente markiert werden muss, die Bitcommitment auf der Grundlage der tatsächlichen Berechnungslogik erfordern; (3) die Lesbarkeit der logischen Funktion, die von jedem Chunkskript implementiert wird, ist schlecht, was die Überprüfung schwierig macht; (4) der Stapel kann Elemente enthalten, die für den nächsten Chunk nicht benötigt werden und damit den Stapelspeicherplatz verschwenden.
• Funktionale Aufteilung: Diese Methode teilt auf der Grundlage verschiedener funktionaler Unterfunktionen in der Berechnung auf, mit klaren Ein- und Ausgabewerten für die Unterfunktionen. Beim Aufteilen des Skripts werden auch die erforderlichen Bit-Commit-Skripts für jeden Block implementiert, um sicherzustellen, dass die Gesamtskriptgröße der letzten Blöcke weniger als 4 MB und die Stapelgröße weniger als 1000 beträgt. Die Vorteile sind: klare Funktionalität, klare Logik für jeden Chunk, gute Lesbarkeit und einfache Auditierung. Die Nachteile sind: Der Ausdruck der ursprünglichen Berechnungslogik stimmt möglicherweise nicht mit der Logik auf Skriptebene überein, und die ursprünglichen Berechnungsunterfunktionen sind möglicherweise optimal, stellen aber keine Optimalität auf Skriptebene dar.
• Manuelle Aufteilung: Bei dieser Methode basieren die Aufteilungspunkte nicht auf funktionalen Teilfunktionen, sondern werden manuell festgelegt. Dies ist besonders geeignet für Fälle, in denen die Größe einer einzigen Teilfunktion 4 MB überschreitet. Die Vorteile sind: Es ermöglicht die manuelle Aufteilung von schweren Skriptgrößen-Teilfunktionen, wie z.B. solche, die mit Fq12-Berechnungen zusammenhängen; klare Logik für jeden Chunk, gute Lesbarkeit und einfache Prüfung. Die Nachteile sind: Begrenzt durch manuelle Anpassungsmöglichkeiten, wenn das Gesamt-Skript optimiert wurde, können zuvor festgelegte manuelle Aufteilungspunkte möglicherweise nicht optimal sein und müssen neu angepasst werden.

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:

• Suchen Sie nach Algorithmen, die die Speicherlokalität optimieren, selbst wenn dies zu einer höheren Rechenlast führt, um die Anzahl der Ein-/Ausgabe-Bits zwischen den Chunks zu reduzieren und dadurch die Datenmenge zu verringern, die für Verpflichtungen im assertTx-Transaktionsdesign von BitVM2 erforderlich ist.
• Nutzen Sie die Kommutativität verwandter Operationen (z.B. logische Operationen), wie z.B. x&y = y&x, um fast die Hälfte der Suchtabelle zu sparen.
• Derzeit ist die Skriptgröße, die den Fq12-Operationen entspricht, groß; in Betracht ziehen, Fiat-Shamir, Schwartz-Zipple und polynomiale Verpflichtungsschemata zu nutzen, um die Rechenkomplexität der Fq12-Erweiterungsoperationen erheblich zu reduzieren.

4 Zusammenfassung

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.

Haftungsausschluss:

1. Dieser Artikel wurde von [ reprinted.AICOIN]. Alle Urheberrechte gehören dem Originalautor [ mutourend & lynndell, Bitlayer Labs]. Wenn es Einwände gegen diesen Nachdruck gibt, wenden Sie sich bitte an die Gate LearnTeam, und sie werden es schnell bearbeiten.
2. Haftungsausschluss: Die in diesem Artikel geäußerten Ansichten und Meinungen sind ausschließlich die des Autors und stellen keine Anlageberatung dar.
3. Übersetzungen des Artikels in andere Sprachen werden vom Gate Learn-Team durchgeführt. Sofern nicht anders angegeben, ist das Kopieren, Verteilen oder Plagiieren der übersetzten Artikel untersagt.