paint-brush
ZKByte: Eine vertrauenswürdige Bitcoin Layer2-Skalierungslösung, die Zero Knowledge und BitVM nutztby@zkspace
490
490

ZKByte: Eine vertrauenswürdige Bitcoin Layer2-Skalierungslösung, die Zero Knowledge und BitVM nutzt

ZKSpace4m2023/12/30
Read on Terminal Reader

Das Layer-2-Netzwerk für BTC ist strategisch konzipiert, um der steigenden Nachfrage nach schnelleren und effizienteren Transaktionen innerhalb des Bitcoin-Ökosystems gerecht zu werden. Dies wird dadurch erreicht, dass bestimmte Transaktionsverarbeitungsaufgaben aus der Hauptblockchain ausgelagert werden, um die Überlastung zu verringern. Ein UTXO wird verwendet, um alle Layer-2-Zustände zu verfolgen, und ein vertrauenswürdiges Oracle wird eingesetzt, um sicherzustellen, dass nur die Sperr-/Entsperrskripts der Eingabe-/Ausgabeskripte dem Layer-2-Protokoll folgen.
featured image - ZKByte: Eine vertrauenswürdige Bitcoin Layer2-Skalierungslösung, die Zero Knowledge und BitVM nutzt
ZKSpace HackerNoon profile picture
0-item
1-item
2-item

Das Hauptziel dieses Entwurfs besteht darin, ein Layer-2-Netzwerk aufzubauen, das speziell auf die Bitcoin-Blockchain zugeschnitten ist. Das Layer-2-Netzwerk für BTC ist strategisch konzipiert, um der steigenden Nachfrage nach schnelleren und effizienteren Transaktionen innerhalb des Bitcoin-Ökosystems gerecht zu werden.


Dies wird durch die Auslagerung bestimmter Transaktionsverarbeitungsaufgaben aus der Hauptblockchain erreicht. Ziel ist es, die Überlastung zu verringern und den Zeit- und Ressourcenaufwand für Transaktionsbestätigungen erheblich zu reduzieren.


Unser Design ist sich der inhärenten Einschränkungen der Rechenkapazitäten der Bitcoin Virtual Machine (VM) bewusst und verwendet BitVM, was das Potenzial für die Ausführung intelligenter Verträge zwischen zwei Parteien demonstriert. BitVM nutzt ein Challenge-and-Response-Schema und stellt einen neuartigen Ansatz vor, um die Programmierbarkeit des Bitcoin-Netzwerks zu verbessern und traditionelle Einschränkungen zu überwinden.


Um die Sicherheit und Integrität des Layer-2-Netzwerks zu verbessern, wird die Zustandsüberprüfung durch die Integration von Zero-Knowledge-Proof-Technologien erleichtert.


Diese fortschrittlichen kryptografischen Techniken ermöglichen es Layer 1, die Zustände des Layer 2-Netzwerks effizient zu überprüfen, ohne die Privatsphäre und Vertraulichkeit der zugrunde liegenden Transaktionen zu gefährden.

0. Architektur

Die Layer-2-Blockchain verwendet ein Kontomodell. Der Status der gesamten Blockchain wird durch zkVM nachgewiesen, basierend auf dem Halo2-Prüfsystem. Der Layer-2-Status wird mit dem Bitcoin-Netzwerk synchronisiert und alle Layer-2-Status werden durch den von BitVM implementierten Zero-Knowledge Proof (ZKP)-Verifizierer überprüft. Ein UTXO wird verwendet, um alle Layer-2-Zustände zu verfolgen. Darüber hinaus wird ein vertrauenswürdiges Oracle eingesetzt, um sicherzustellen, dass nur die Sperr-/Entsperrskripts von Eingabe-/Ausgabe-UTXOs dem Layer-2-Protokoll folgen.



1. Layer-2-Komitee und vertrauenswürdiges Oracle

Eine ausgewählte Gruppe von Benutzern bildet das Layer-2-Komitee, das für die Überwachung des Gesamtzustands des Layer-2-Netzwerks verantwortlich ist. Bei Protokollproblemen kann das Komitee eingreifen, um das Protokoll zu stoppen und die Vermögenswerte aller Benutzer zu schützen. Das vertrauenswürdige Orakel ist entscheidend für die Validierung der Korrektheit von Eingabe-/Ausgabe-UTXOs und Skripten.

2. Schicht 1 bis Schicht 2

Im Bitcoin-Netzwerk wird eine einzelne Taproot-Adresse erstellt, um das Layer-2-Protokoll darzustellen. Wenn ein UTXO erstellt und an die Taproot-Adresse übertragen wird, wird das entsprechende UTXO effektiv von Schicht 1 auf Schicht 2 „verschoben“. Protokoll- oder Ausschusskonten wickeln ausschließlich die „Übertragung“ aller „hinterlegten“ UTXO-Assets ab.



3. Blockiert die Synchronisierung mit Layer 1

Alle Layer-2-Netzwerkzustände werden in Form von Blöcken mit Layer 1 synchronisiert. Für einen Block sollten die folgenden Informationen bereitgestellt werden: Transaktionen in einem bestimmten Block, der Status neuer Konten mit diesen angewendeten Transaktionen, neue UTXOs für den aktuellen Blockstatus (immer bereit, auch wenn das Protokoll unterbrochen ist), Blockinformationen des Bitcoin-Netzwerks, wissensfreier Nachweis ( Dies beweist, dass der Zustandsübergang vom letzten Block zum aktuellen Block korrekt ist. Alle diese Zustände in Schicht 1 werden in einem UTXO-Transaktionsverlauf aufgezeichnet.




3.1 Mehr zum Beweis

Zur Überprüfung der Korrektheit der Schicht 2 wird ein wissensfreier Beweis eingesetzt. Der Beweis versucht zu beweisen: Blocktransaktionen der Schicht 2 sind korrekt signiert. Der neue Status aller Konten wird korrekt behandelt. Alle Einzahlungen bis zu einem bestimmten Block der Schicht 1 werden korrekt verarbeitet. Nach dem aktuellen Stand werden alle UTXO-Distributionen korrekt erstellt.

3.2 Blockinformationsherausforderung

Um die Richtigkeit der angegebenen Blockinformationen in Schicht 1 sicherzustellen, wird ein Challenge-and-Response-Schema verwendet. Prüfer können die Genauigkeit von Blockinformationen nachweisen, indem sie das Vorhandensein von N weiteren Blöcken nach einem bestimmten Block innerhalb eines gesperrten Zeitraums angeben.


3.3 ZKP-Schaltung und BitVM-Verbesserung

Wie im BitVM-Papier dargestellt, kann die ZKP-Proof-Verifizierung als eine binäre Schaltung ausgedrückt werden, die von zwei Parteien angefochten werden kann. Bei vorsignierten Transaktionen können Herausforderungen gesendet werden, um Bit-Zusagen der Schaltung zu erhalten. Wenn 0 und 1 durch Herausforderungen aufgedeckt werden, gewinnt der Herausforderer. Um BitVM zur Überprüfung der ZKP-Verifizierung zu verwenden, sollten zwei Dinge beachtet werden: Die gleichen Binärschaltkreisverpflichtungen sollten einmal verwendet werden. Das heißt, wenn dieselben Schaltungskommentare für viele Blöcke verwendet werden, können 0 und 1 einer Ein-Bit-Verpflichtung offengelegt werden. Für die ZKP-Verifizierung sollte neben der Schaltungszufriedenheit auch der „öffentliche Input“ überprüft werden. Um diese beiden Mängel zu beheben, wird für jeden Block der Schicht 2 eine eindeutige Binärschaltung erstellt und die „öffentlichen Eingänge“ werden festgelegt. Bitcoin-Skripte werden für das Hashing und die Überprüfung öffentlicher Eingaben verwendet. Und die korrekten öffentlichen Input-Bit-Verpflichtungen werden von einem vertrauenswürdigen Orakel überprüft. Im Hinblick auf die Zufriedenheit mit der Schaltung hat jedes Mitglied innerhalb des Komitees die Möglichkeit, Herausforderungen zu stellen.




4. Schicht 2 bis Schicht 1

Vermögenswerte können durch zwei Methoden von Schicht 2 auf Schicht 1 verschoben werden: Entnahme und erzwungener Entzug. Auszahlungstransaktionen werden von Layer 2 aus ausgelöst und ZKP-Schaltkreise stellen die erwartete Transaktionsabwicklung sicher. Zwangsabhebungstransaktionen werden vom Bitcoin-Netzwerk initiiert.

4.1 Auszahlung und erzwungene Auszahlung der Transaktion

Von Layer 2 ausgelöste Auszahlungstransaktionen werden mithilfe von ZKP-Schaltungen überprüft, um eine ordnungsgemäße Transaktionsabwicklung sicherzustellen. Force-Withdraw-Transaktionen, die vom Bitcoin-Netzwerk initiiert werden, müssen in der nächsten Aktualisierung des Blockstatus enthalten sein. 4.2 UTXO-Verteilungen Wenn der Status eines Blocks aktualisiert wird, wird die UTXO-Verteilung synchronisiert. Im Falle eines Protokollstopps können alle UTXOs angewendet werden, um die Sicherheit aller Benutzerressourcen zu gewährleisten. Und von diesen UTXOs sind nur UTXOs zum Zurückziehen oder erzwungenen Zurückziehen per Protokoll signiert.

5. Ausgang der Schicht 2

Sobald der ZKP-Beweis NICHT verifiziert ist, muss das Komitee das Protokoll anhalten und verlassen. Wenn das Protokoll stoppt, signiert das Komitee alle UTXO-Verteilungen, die im letzten Blockstatus von Layer 2 angegeben sind. Mit den Signaturen kann ein Benutzer Layer 2 ohne Verlust verlassen.





Referenz

  1. BitVM: https://bitvm.org/bitvm.pdf
  2. Bitcoin-Whitepaper: https://bitcoin.org/bitcoin.pdf
  3. Halo2-Erklärung: https://electriccoin.co/blog/explaining-halo-2/