Wie kann Bitcoin ZK unterstützen, von OP_CAT über Proof of State bis hin zu BitVM?

Ursprünglicher Autor: Janos Nick, Blockstream

Originaltext zusammengestellt von: Bai Ding, Faust, Geek Web3

Zusammenfassung: Dieser Artikel zeigt prägnant, aber auf den Punkt, wie Bitcoin die ZK-Verifizierungsfunktion unterstützen kann. Zu den spezifischen Themen, die behandelt werden, gehören die Funktionsfehler von Bitcoin UTXO und Skripten, Konzepte wie Taproot und OP_CAT sowie BitVM und Chain State Proof allgemeiner Inhalt. Der Artikel vertritt einen relativ klaren Standpunkt:

Die Einführung von ZK in das Bitcoin-Protokoll ist ein unvermeidlicher Trend. Dafür gibt es zwei Wege: Der eine besteht darin, Bitcoin-Skripten die direkte Unterstützung der SNARK-Überprüfung zu ermöglichen, was die Hilfe des OP_CAT-Operationscodes erfordert, und die Wahrscheinlichkeit, dass OP_CAT schließlich erfolgreich ist ist sehr hoch; die zweite Route basiert auf BitVM. Es ist notwendig, eine betrugssichere Methode einzuführen, und das ZeroSync-Team hat auch Chain State Proofs vorgeschlagen, um die Kosten für die Überprüfung historischer Daten durch den Knoten-Client zu senken.

Text: Um Bitcoin besser zu verstehen, ist es am besten, es als soziales System zu betrachten. Als Bitcoin in seinen Anfängen auf den Markt kam, legten die Entwickler die Softwareprogramme fest, die Bitcoin-Knoten ausführen mussten, genau wie sie eine Reihe von Regeln festlegten, denen ein soziales System folgen sollte. Der Grund, warum das soziale System von Bitcoin stabil funktionieren kann, liegt darin, dass jeder einen gewissen Konsens über Schlüsselfragen wie „Was ist das Wesen von Bitcoin“ und „Was sollte es sein“ hat. Es bleibt natürlich nicht einfach, einen Konsens zu erzielen weit verbreitete und sich entwickelnde Meinungsverschiedenheit zu den oben genannten Themen.

Dies geht auf den historischen Ursprung von Bitcoin zurück. Als Satoshi Nakamoto das Bitcoin-Whitepaper veröffentlichte, sagte er einmal: „Ich arbeite an einem brandneuen elektronischen Zahlungssystem. Dieses System ist vollständig P2P und muss nicht auf Dritte angewiesen sein.“ Diese Passage wurde auf der Cypherpunks-Mailingliste veröffentlicht (einer E-Mail-Diskussionsgruppe, die 1992 von einer Gruppe von Kryptografen und Technologiebegeisterten gegründet wurde, die sich mit Datenschutz und Kryptografietechnologie befassen).

Allerdings begrenzt Bitcoin den Datendurchsatz auf der Ebene des Produktdesigns. Die Anzahl der Transaktionen, die pro Zeiteinheit verarbeitet werden können, ist begrenzt. Wenn die Anzahl der zu verarbeitenden Transaktionen schnell zunimmt, beginnen Benutzer einen Preiskampf, um die Transaktion schnell erfolgreich abzuschließen, was die gezahlten Bearbeitungsgebühren schnell erhöht. Die Einzeltransaktion mit der höchsten Bearbeitungsgebühr im Bitcoin-Netzwerk erfolgte nach der Halbierung der Blockbelohnung im Jahr 2024, und die Bearbeitungsgebühr für eine Transaktion mit mittlerer Priorität in der Kette erreichte 150 US-Dollar. Man kann sagen, dass die teuren Transaktionsgebühren des Bitcoin-Netzwerks zu einem Problem geworden sind.

Um das Problem der Transaktionsgebühren zu lösen, haben die Menschen viele Ressourcen in die Entwicklung des Lightning Network investiert. Laut einem 2016 veröffentlichten Papier kann das Lightning Network in der Praxis jedoch höchstens mehrere zehn Millionen Benutzer unterstützen und verfehlt damit die Verwirklichung seiner Vision eines globalen Zahlungssystems.

Neben den zu hohen Transaktionsgebühren besteht auch das Problem, dass Bitcoin nie die angestrebte Anonymität erreichen konnte. Satoshi Nakamoto wies in einer Cypherpunk-E-Mail-Diskussionsgruppe darauf hin, dass Bitcoin über eine Datenschutzfunktion verfügt und der Transaktionsinitiator völlig anonym sein kann. Obwohl Transaktionsinitiatoren kein KYC benötigen, gehen bei Transaktionsdaten in der Bitcoin-Kette viele Informationen verloren, wodurch die Privatsphäre der Benutzer weitgehend gefährdet wird.

Obwohl es einige Wallet-Clients mit Datenschutzfunktionen gibt, die die oben genannten Probleme bis zu einem gewissen Grad lösen, sind die Entwickler dieser Wallet-Clients mit Bedrohungen unterschiedlicher Größe konfrontiert. Beispielsweise wurden die Entwickler des Samourai CoinJoin-Wallets im April 2024 vom FBI verhaftet, und eine Woche später schalteten die Entwickler des Wasabi-Wallets ihre CoinJoin-Koordinationskomponente ab. Offensichtlich verdienen diese sogenannten Privacy Wallets das Vertrauen der Nutzer nicht ganz.

Zusammenfassend lässt sich sagen, dass viele der Konzepte von Bitcoin bis heute noch lange nicht verwirklicht sind und sich die damit verbundenen Technologien noch immer in der kontinuierlichen Entwicklung befinden. Trotzdem glauben viele Leute in der Bitcoin-Community, dass das Protokolldesign von Bitcoin unverändert bleiben sollte, aber es gibt auch viele Leute, wie ich, die sich leidenschaftlich für Verbesserungen an Bitcoin einsetzen. In welche Richtung sollte sich Bitcoin also verbessern?

Als Reaktion auf die oben genannten Probleme gibt es in der Bitcoin-Community viele Vorschläge, und diejenigen mit der besten theoretischen Wirkung sollten sich auf ZK und SNARKs beziehen. Mit ZK und SNARKs können folgende Eigenschaften erreicht werden:

1. Verbessern Sie die Privatsphäre erheblich: Verwenden Sie homomorphes Peterson, um den Transaktionsbetrag und den Bereichsnachweis festzulegen, um die Privatsphäre der Benutzer erheblich zu verbessern (wie dies in der Element-Seitenkette von Blockstream geschieht). Verstecken Sie Transaktionsspuren durch verknüpfbare Signaturen (z. B. Monero). Zcash).

2. Verbessern Sie den Transaktionsdurchsatz

Tatsächlich gibt es viele technische Möglichkeiten, die bei Bitcoin bestehenden Probleme zu lösen, aber warum wurden diese Technologien bis heute nicht zum Bitcoin-Protokoll hinzugefügt? Dies liegt daran, dass das Bitcoin-Protokoll schwer zu ändern ist. Es gibt keine ähnliche Organisation wie die Ethereum Foundation im Bitcoin-Ökosystem. Jede Änderung des Protokolls erfordert ein hohes Maß an Community-Konsens. Dies erfordert viele Spiele und Machtüberprüfungen, daher wird es im Gegensatz zu Ethereum jeweils EVM-Betriebscodes geben Jahr gab es seit seiner Einführung nur sehr wenige Aktualisierungen des Bitcoin-Protokolls.

Tatsächlich ist es gut, dass das Protokoll bis zu einem gewissen Grad schwer zu ändern ist. Wenn die Änderung des Bitcoin-Protokolls einfach ist, ist es auch einfach, böswillige Änderungen und Angriffe vorzunehmen. Dies wirft die Frage auf: Gibt es Möglichkeiten, die Leistung von Bitcoin zu verbessern, ohne das Design des Bitcoin-Protokolls zu ändern?

Um diese Frage zu beantworten, müssen wir zunächst überprüfen, was wir über Bitcoin wissen. Wenn wir Bitcoin an jemand anderen übertragen möchten, müssen wir eine Transaktion erstellen und diese an das Bitcoin-Netzwerk senden. Die Ausgabedaten der Transaktion geben den Betrag der übertragenen BTC an, und der BTC-Empfänger kann eine neue Transaktion erstellen, um die erhaltenen BTC auszugeben. Anschließend generiert diese neue Transaktion neue Ausgabedaten und sendet BTC an andere.

Hierbei ist zu beachten, dass Bitcoin keinen globalen Status wie Ethereum hat, insbesondere keinen Status ohne Konten, sondern nur Transaktionsausgabedaten. Die Ausgabe jeder Transaktion hat zwei Zustände: vom Empfänger ausgegeben oder nicht ausgegeben. Die nicht ausgegebene Transaktionsausgabe ist das bekannte UTXO.

Zusätzlich zum zugehörigen BTC-Betrag verfügt jede Transaktionsausgabe natürlich über ein zusätzliches Programm, das in einer Sprache namens Bitcoin Script geschrieben ist. Wer den richtigen Beweis für dieses Programm liefern kann, kann die Transaktionsausgabe (UTXO) ausgeben. Bitcoin Script selbst ist eine stapelbasierte Programmiersprache, die eine Reihe von Opcodes enthält. Die oben genannten UTXO-Appender bestehen häufig aus mehreren Opcodes. Sie führen Berechnungen basierend auf dem Stapel durch und legen die Ergebnisse wieder auf dem Stapel ab.

Es gibt viele Arten gängiger Bitcoin-Skripte, die es seit den Anfängen von Bitcoin gibt. Das häufigste Skript in Bitcoin besteht beispielsweise aus einem öffentlichen Schlüssel + einem Opcode, der eine digitale Signatur prüft. Dieser Opcode legt fest, dass zum Ausgeben/Freischalten eines UTXO die digitale Signatur des entsprechenden öffentlichen Schlüssels vorgelegt werden muss.

Hier fassen wir die Funktionalität von Bitcoin Script zusammen. Was kann Bitcoin Script zunächst tun?

· Der Stapel kann neu angeordnet werden, es können Gleichheitsprüfungen durchgeführt werden (Verwenden Sie die Gleichheitsprüfung, um zu überprüfen, ob bestimmte Bedingungen erfüllt sind, um so die Sicherheit und Gültigkeit von Transaktionen sicherzustellen) und Verzweigungsoperationen ähnlich wie if-else können durchgeführt werden.

· Kann begrenzte arithmetische Operationen mit 32-Bit-Zahlen durchführen, nämlich Addition und Subtraktion.

· Daten können gehasht werden und ECDSA- und Schnorr-Signaturen können überprüft werden.

Was kann Bitcoin Script nicht?

· Es gibt keine Schleifen, Sprünge oder Rekursionen, das heißt, es ist nicht Turing-vollständig und seine Programmiermöglichkeiten sind sehr begrenzt.

· Bitweise Operationen sind nicht möglich. Fehlende Opcodes für Multiplikation und Division.

· Elemente auf dem Stapel können nicht verkettet werden.

· Geringe Fähigkeit, On-Chain-Transaktionsdaten zu lesen und zu überprüfen.

· Bitcoin-Skripte können nicht direkt auf den Betrag jeder Transaktion zugreifen und es gibt keine Möglichkeit, den Status zu übergeben (UTXOs werden nur einmal verwendet und die alten werden bei jeder Übertragung zerstört und neue generiert).

In den frühen Versionen von Bitcoin waren einige der Dinge, die in den oben genannten Skripten „nicht möglich“ waren, tatsächlich möglich, einige Funktionen wurden jedoch später von Satoshi Nakamoto deaktiviert, weil Satoshi Nakamoto entdeckte, dass es Lücken in diesen Opcodes gab Sie können beispielsweise den Opcode OP_CAT, der zwei Elemente im Stapel kombiniert, verwenden, um einen Bitcoin-Knoten aus der Ferne anzugreifen, um ihn zum Absturz zu bringen, und einige andere Opcodes wurden ebenfalls deaktiviert.

Kann Bitcoin Script also SNARKs verifizieren? Obwohl das Bitcoin-Skript theoretisch nicht Turing-vollständig ist, reichen seine Grundoperationen aus, um jede Berechnung zu verifizieren. In der Praxis kann die SNARK-Verifizierung jedoch nicht implementiert werden, da die für den Verifizierungsschritt erforderliche Programmgröße das maximale Blocklimit von Bitcoin überschreitet.

Vielleicht können wir versuchen, arithmetische Operationen in großen endlichen Feldern durchzuführen, aber die Kosten sind sehr hoch. Beispielsweise erreicht die von BitVM implementierte Multiplikation zweier 254-Bit-Ganzzahlen eine zugehörige Bitcoin-Skriptgröße von fast 8 KB.

Außerdem ist die Überprüfung von Merkle-Proofs ohne OP_CAT kostspielig, da dafür Vorgänge erforderlich sind, die einer for-Schleife ähneln.

Also zurück zur vorherigen Frage: Warum können wir nicht einfach das Bitcoin-Protokoll ändern und leistungsfähigere Opcodes hinzufügen?

Wie bereits erwähnt, ist es sehr schwierig, einen Mehrheitskonsens über neue Protokollregeln zu erzielen, da es im Bitcoin-Ökosystem keinen zentralen Entscheidungsträger gibt. Gegen jeden Vorschlag zur Verbesserung des Bitcoin-Skripts gibt es viele Einwände. Im Bitcoin-Netzwerk gibt es keine gute Möglichkeit zu messen, ob die Community einen Mehrheitskonsens erreicht hat, und das Erzwingen einer Aktualisierung führt in diesem Fall zu einer Kettengabelung.

Natürlich ist Bitcoin nicht völlig statisch, die neuesten Updates waren SegWit im Jahr 2017 und Taproot im Jahr 2021.

Durch das Taproot-Upgrade wurden viele Regeln geändert, und von der theoretischen Veröffentlichung bis zur tatsächlichen Aktivierung dauerte es dreieinhalb Jahre. Der Schlüsselfaktor bei der Aktivierung von Taproot besteht darin, dass bestehende Sicherheitsannahmen nicht geändert werden und das Bitcoin-Protokoll deutlich verbessert wird. Es ermöglicht beispielsweise die Verwendung von Schnorr-Signaturen anstelle von ECDSA. Beide basieren auf der Annahme eines diskreten Logarithmus und verwenden dieselben elliptischen Kurven, erstere ist jedoch effizienter und weniger rechenintensiv als letztere.

Darüber hinaus sind die Verbesserungen von Taproot an Bitcoin hauptsächlich in die folgenden drei Teile unterteilt:

Erstens reduziert Taproot die Verifizierungskosten von Skripten durch eine große Anzahl selektiver Verzweigungen, wodurch Bitcoin komplexere Programme unterstützen kann;

Zweitens reduziert Taproot die Skriptdaten, die in der Kette offengelegt werden müssen. Sie können mehrere Skripte in einem Merkle-Baum zusammenstellen, wobei sich jedes Skript auf einem anderen Blatt befindet. Wenn Sie ein bestimmtes Skript auslösen möchten, müssen Sie es nur offenlegen . Das Blatt, in dem es sich befindet, und der Merkle-Beweis;

Drittens hat Taproot auch andere mechanische Designs hinzugefügt.

Da Bitcoin jedoch einen Präzedenzfall für das Hinzufügen leistungsfähigerer Funktionen wie Tarpoot hat, warum nicht einen dedizierten Opcode zur Überprüfung von SNARK hinzufügen? Dies liegt daran, dass sich das Hinzufügen eines sogenannten OP_SNARK-Opcodes stark von einem Taproot-Upgrade unterscheidet.

Erstens gibt es viele Designideen für OP_SNARK, und es ist für die meisten Menschen schwierig, eine einzelne Lösung zu unterstützen. Zweitens müssen alle Bitcoin-Knoten diese spezifische OP_SNARK-Lösung unterstützen, was zu enormen technischen Herausforderungen führt . Last.

Darüber hinaus ist auch die Komplexität von OP_SNARK selbst eine große Herausforderung. Taproot fügt nur etwa 1600 Codezeilen hinzu, was akzeptabel ist, wenn keine Tests enthalten sind, während OP_SNARK viel komplexeren Code enthält.

Wer prüft außerdem, ob der Opcode OP_SNARK aktiviert werden sollte? Wie kann man einen Konsens innerhalb des Bitcoin-Ökosystems erreichen, ohne dass ein paar Leute dessen Details verstehen? Das sind alles Fragen. Daher wird das OP_SNARK-Upgrade insgesamt nicht in kurzer Zeit erfolgen.

Es gibt jedoch auch andere Möglichkeiten, SNARKs in Bitcoin Script zu verifizieren. Wir können Bitcoin-Skripte funktionaler gestalten, indem wir einfachere Opcodes hinzufügen, die es den Leuten ermöglichen, SNARK-Validierungsprogramme in ihren Skripten zu implementieren. Tatsächlich ist es jedoch sehr schwierig, ein SNARK-Verifizierungsprogramm in der Bitcoin-Skriptsprache zu schreiben.

Aus diesem Grund entwickelt das Blockstream-Forschungsteam Simplicity, eine Programmiersprache, die Bitcoin Script ersetzen soll. Simplicity wurde speziell für Blockchain-Konsenssysteme entwickelt und ist absichtlich nicht Turing-vollständig, was die statische Analyse und formale Verifizierung erleichtert.

Im Folgenden werden wir über einen sehr einfachen, aber schwergewichtigen Vorschlag sprechen, der Bitcoin Script leistungsfähiger machen könnte, den OP_CAT-Opcode. Wie bereits erwähnt, existierte OP_CAT in der ersten Version von Bitcoin, aber dieser Opcode kann unter bestimmten Bedingungen einen DOS-Angriff auf Bitcoin-Knoten ermöglichen, weshalb er von Satoshi Nakamoto deaktiviert wurde. Jetzt möchten einige Leute in der Bitcoin-Community ihn wieder aktivieren . Es.

Was OP_CAT tut, ist, die beiden Elemente oben auf dem Stapel abzulegen, sie zu verketten und sie dann wieder auf den Stapel zu legen. Das klingt sehr einfach, kann aber enorme funktionale Verbesserungen bei Bitcoin-Skripten mit sich bringen.

Beispielsweise sind Bitcoin-Skripte ursprünglich nicht in der Lage, auf Statusinformationen wie die Anzahl der Transaktionen in der Kette zuzugreifen, aber mit OP_CAT kann dies auch zur Überprüfung von Merkle-Beweisen verwendet werden. Kurz gesagt, OP_CAT ist ein Upgrade auf der zugrunde liegenden Opcode-Ebene, das viele neue Funktionen ableiten wird. Viele Leute haben die Auswirkungen vorgeschlagen, die durch die Verwendung von OP_CAT erzielt werden können.

Und hilft OP_CAT bei der Überprüfung von SNARKs in Skripten? Die Antwort ist, dass es hilft, denn die Unterstützung für die Überprüfung von Merkle-Beweisen hilft bei der Überprüfung von FRI-basierten SNARKs, und OP_CAT kann dies unterstützen. In der Vergangenheit waren die an der SNARK-Verifizierung beteiligten Skripte möglicherweise zu groß, um in einen Bitcoin-Block zu passen. Mit OP_CAT kann die Größe des Programms reduziert werden.

OP_CAT wird seit vielen Jahren diskutiert und seine Rolle bei der Transaktionsinspektion (Introspektion) wird zunehmend anerkannt. Der Vorteil von OP_CAT im Vergleich zu anderen Vorschlägen besteht darin, dass es bereits zuvor in Bitcoin Script existierte, was es einfacher macht, einen Konsens in der Community zu erzielen. Allerdings kann die Aktivierung von OP_CAT auch dazu führen, dass das MEV-Einkommen einiger Leute geschädigt wird, sodass die Bitcoin-Community noch keinen Konsens darüber erzielt hat.

Zusammenfassend lässt sich sagen, dass es für Bitcoin möglicherweise einen Weg gibt, die Überprüfung von SNARKs in Bitcoin-Skripten zu ermöglichen, indem einfache Opcodes wie OP_CAT aktiviert werden. Erwähnenswert ist auch, dass es einen aktuellen Vorschlag namens „Great Script Restoration“ gibt, der Multiplikations-Opcodes ermöglicht und es allen arithmetischen Opcodes ermöglicht, mit beliebiger Genauigkeit zu arbeiten.

Wenn wir außerdem die Auswirkungen von OP_CAT auf das Bitcoin-Netzwerk betrachten, können wir die Auswirkungen auf Bitcoin-Knotenbetreiber nach seiner Verabschiedung untersuchen. Um Bitcoin zensurresistent und dezentral zu machen, möchte die Bitcoin-Community, dass möglichst viele Menschen Knoten zur Überprüfung der Daten betreiben. Wenn Bitcoin SNARK-Verifizierungsvorgänge unterstützt, werden die Kosten für den Betrieb eines Bitcoin-Knotens immer noch nicht wesentlich steigen, was der Sicherheit und Zensurresistenz von Bitcoin keinen großen Schaden zufügen wird.

Derzeit kann ein Bitcoin-Block bis zu 4 MB an Daten enthalten, und da alle 10 Minuten ein Block geschürft werden soll, können fast alle Blöcke mit Bitcoin-Skripten und Witness-Zeugen (ähnlich digitalen Signaturen) gefüllt werden. Umgerechnet kann jeder Block derzeit bis zu 80.000 Signaturüberprüfungen enthalten, und im Durchschnitt unterstützt jeder Block 7.000 bis 10.000 Signaturüberprüfungen. Meine 2020 Intel CPU benötigt durchschnittlich 3,2 Sekunden, um einen Bitcoin-Block zu überprüfen. Natürlich wirkt sich nicht nur die zeitaufwändige Signaturprüfung auf die Geschwindigkeit der Blockprüfung aus.

Darüber hinaus scheint es nicht schädlich zu sein, die Transaktionsgenerierungszeit zu verlängern, wenn Bitcoin-Transaktionen in Zukunft die ZK-ifizierung unterstützen. Hardware-Wallets, die zur langfristigen Speicherung von Vermögenswerten verwendet werden, verfügen in der Regel über Bildschirme und sind nicht groß. Ihre Funktion besteht darin, Schlüssel zu speichern und Signaturen zu generieren. Hardware-Wallets verfügen im Allgemeinen über eine schwache CPU, beispielsweise eine 240-MHz-Dual-Core-CPU mit einer gewissen Menge an Speicher, die beim Signieren von Bitcoin-Transaktionen sehr schnell reagiert.

Ich habe eine kleine Umfrage durchgeführt und Benutzer nach der maximalen Verzögerung gefragt, die sie akzeptieren würden, bis ein Signiergerät einen Beweis erstellt. Viele Leute waren mit einer längeren Wartezeit einverstanden, insbesondere wenn dadurch erhebliche Vorteile erzielt werden könnten. Wenn wir also ZK in Bitcoin-Transaktionen einführen, scheint es keine großen Probleme zu geben.

Wir haben oben viel Raum darauf verwendet, darüber zu diskutieren, wie das zugrunde liegende Design von Bitcoin geändert werden kann, aber tatsächlich gibt es viele Anwendungsszenarien, die implementiert werden können, ohne Bitcoin zu ändern. Hier möchte ich eine Anwendung im Zusammenhang mit BitVM – Chain State Proofs – hervorheben, die in Kombination mit ZK die Gültigkeit des Block-Hashs beweisen kann.

Welche Veränderungen hat diese Technologie für Bitcoin mit sich gebracht? Erstens kann mit Chain State Proofs der Arbeitsaufwand für die Synchronisierung und Überprüfung von Bitcoin-Kalenderdaten komprimiert werden, wodurch die Kosten für den Betrieb von Knoten erheblich gesenkt werden. Derzeit dauert es 5 Stunden und 30 Minuten, den neuesten Bitcoin-Block vom Genesis-Block auf einem Gerät mit guter Hardware zu synchronisieren und zu überprüfen, während es auf einem Raspberry Pi-Level-Gerät mehrere Tage dauern wird, wenn der Statusnachweis eingeführt wird Der aufwendige Prozess kann stark reduziert werden. Zweitens ist der Chain State Proof ein wichtiger Teil, der mit BitVM verwendet werden kann und die Implementierung von BitVM fördern wird.

Das ZeroSync-Team hat eingehende Untersuchungen zu Chain State Proofs durchgeführt und eine leichtere „Header-Chain-Proofs“ erstellt. Diese Lösung beweist in Kombination mit ZK nur die Gültigkeit des Bitcoin-Blockheaders und bildet so eine „Header-Kette“, die alle 850.000 enthält Blockheader im Bitcoin-Verlauf und generiert einen 80-Byte-Hash für jeden Blockheader.

Dieses Schema erfordert eine doppelte SHA-256-Berechnung jedes Bitcoin-Blockheaders, um den entsprechenden PoW-Nachweis zu überprüfen. ZeroSync verwendet STARKs, um den Proof der Bitcoin-Header-Kette zu generieren. Die Kosten für die Erstellung des Proofs betragen etwa 4.000 US-Dollar und die Überprüfung des Proofs mit meinem Browser dauert nur 3 Sekunden.

Da es jedoch nicht den Überprüfungsprozess des Transaktionsinhalts im Block umfasst, kann der Header-Chain-Proof nur davon ausgehen, dass die Blockchain mit den meisten POW-Proofs gültig ist, und ermöglicht dem Bitcoin-Client standardmäßig, den neuesten Block in dieser Kette zu synchronisieren . Obwohl der Angreifer in diesem Szenario einen Block mit ungültigen Transaktionen erstellen, nach diesem Block weitere Blöcke hinzufügen und einen Header-Chain-Proof generieren kann, um den Bitcoin-Client zu täuschen, der historische Daten synchronisiert, wäre der Angriff in diesem Szenario äußerst kostspielig direkt von bestehenden Bitcoin-Full-Node-Clients entlarvt werden.

Trotz der geringen Erfolgsquote dieses Angriffsszenarios kann der Header-Chain-Proof jedoch nicht als narrensichere Lösung angesehen werden, wenn er es einem Angreifer ermöglicht, eine große Menge BTC zu stehlen. Wenn wir den vollständigen Kettenzustand beweisen wollen, müssen wir direkt beweisen, dass alles im Bitcoin-Block gültig ist, einschließlich der ECDSA- und Schnorr-Signaturüberprüfung basierend auf den elliptischen Kurven von secp256k1.

Die monatlichen historischen Blöcke von Bitcoin können 30 Millionen Signaturen enthalten, und der Verlauf enthält insgesamt 2,5 Milliarden Signaturoperationen sowie eine große Anzahl von SHA-256-Operationen. Auf diese Weise generiert das Bitcoin-Netzwerk jeden Monat etwa 7 GB Blockdaten, und alle historischen Daten belaufen sich auf mehr als 650 GB. In Wirklichkeit kann diese Zahl das Zwei- bis Dreifache betragen.

Schauen wir uns nun BitVM an. BitVM ermöglicht es Bitcoin, jede Rechenaufgabe zu verifizieren und ist der beste Weg, um eine SNARK-Verifizierung zu erreichen, ohne das Protokoll zu ändern. BitVM verwendet zwei Techniken, um die Bitcoin-Blockbeschränkung der Skriptgröße zu umgehen. Erstens nutzt es die Skriptstruktur von Taproot MerkleTree;

Zweitens ermöglicht es ein KV-Speicherschema, auf das über ein einzelnes Skript zugegriffen werden kann, wodurch Verbindungen zu einer großen Anzahl von Skripten möglich sind. Das Bitcoin-Protokoll erzwingt jedoch nicht die Integrität des oben genannten KV-Speicherschemas. BitVM muss den böswilligen Prüfer durch Betrugsnachweise überprüfen. Wenn der Prüfer eine ungültige Erklärung oder einen problematischen KV-Speicher ausgibt, können andere eine Transaktion in der Bitcoin-Kette initiieren. , was darauf hindeutet, dass Prover unangemessen gehandelt und seine vorab verpfändeten Vermögenswerte weggenommen hat.

Zusammenfassend lässt sich sagen, dass Bitcoin vor großen Herausforderungen steht und verschiedene Lösungen zur Lösung dieser Probleme vorgeschlagen wurden. Diese Vorschläge werden jedoch nicht schnell von der Bitcoin-Community angenommen und Änderungen am Protokoll können nicht kurzfristig abgeschlossen werden Eine gute und eine schlechte Sache, es bedeutet auch, dass Bitcoin dezentralisiert und sicherer ist.

Viele in der Bitcoin-Community sind vom Potenzial von SNARK/STARK begeistert. Die praktikabelste Methode, um mittel- bis langfristig eine SNARK-Verifizierung zu erreichen, ist höchstwahrscheinlich BitVM, aber es erfordert mehr Investitionen in Forschung und Entwicklung, um in der Praxis effektiv zu sein;

Die erneute Aktivierung des OP_CAT-Opcodes ist ebenfalls eine Idee, es muss jedoch nachgewiesen werden, dass die Vorteile eines Neustarts des Opcodes die Risiken bei weitem überwiegen, und es muss untersucht werden, welche einfachen Opcodes eine SNARK-Verifizierung in Bitcoin-Skripten ermöglichen können, oder es muss untersucht werden, welche Szenarien den OP_CAT-Funktionen ähneln erreicht werden kann. Unabhängig davon, welche Lösung gewählt wird, muss das ultimative Ziel der Bitcoin-Community darin bestehen, das Produkt praktisch zu machen und umsetzbarere Szenarien zu unterstützen.

Ursprünglicher Link