Geschrieben von: Chakra Research

Zusätzlich zu der im ersten Band erwähnten nativen Erweiterungslösung verwendet ein weiterer Erweiterungspfad für Bitcoin eine zusätzliche Protokollschicht über Bitcoin, die sogenannte Schicht 2. Die beiden kritischsten Punkte der Layer-2-Lösung sind die sichere bidirektionale Überbrückung und die Übernahme der Konsenssicherheit von Bitcoin.

Sidechain

Der Ursprung des Sidechain-Konzepts lässt sich auf „Enabling Blockchain Innovations with Pegged Sidechain“ zurückführen, das 2014 von blockStream vorgelegt wurde. Es handelt sich um einen relativ einfachen Expansionsplan.

Arbeitsprinzip

Die Seitenkette ist eine Blockchain, die völlig unabhängig von der Hauptkette arbeitet. Sie verfügt über ein eigenes Konsensprotokoll und kann als Testgelände für Innovationen in der Hauptkette verwendet werden. Wenn ein bösartiger Vorfall in der Seitenkette auftritt, beschränkt sich der Schaden vollständig auf die Seitenkette selbst und hat keine Auswirkungen auf die Hauptkette. Die Seitenkette kann ein höheres TPS-Konsensprotokoll verwenden, um die Programmierfähigkeiten in der Kette zu erhöhen und eine Verbesserung von BTC zu erreichen.

Die Seitenkette kann die Übertragung von Bitcoin zwischen verschiedenen Blockchains durch eine bidirektionale oder einseitige Bindung realisieren. Natürlich kann BTC tatsächlich nur im Bitcoin-Netzwerk bleiben, daher benötigen wir einen Verankerungsmechanismus, um die Seitenkette herzustellen BTC in der Kette ist mit BTC im Bitcoin-Netzwerk verbunden.

Bei der Einwegbindung müssen Benutzer BTC im Hauptnetzwerk zur Zerstörung an eine nicht verfügbare Adresse senden. Anschließend wird die entsprechende Anzahl BTC in der Seitenkette abgerufen. Der Vorgang kann jedoch nicht rückgängig gemacht werden. Die Zwei-Wege-Anbindung ist eine weitere Verbesserung der Einweg-Anbindung, die es BTC ermöglicht, sich zwischen der Hauptkette und den Seitenketten hin und her zu bewegen. Anstatt es zur Zerstörung an eine nicht verfügbare Adresse zu senden, sperrt die bidirektionale Anbindung BTC durch Kontrollskripte wie Multisignatur und erstellt neue BTC in der Seitenkette. Wenn der Benutzer zum Hauptnetzwerk zurückkehren möchte, wird der BTC in der Seitenkette verbrannt und der ursprünglich gesperrte B TC im Hauptnetzwerk freigegeben.

Die Implementierung einer Einweg-Anbindung ist viel einfacher als die einer Zwei-Wege-Anbindung, da der entsprechende Status im Bitcoin-Netzwerk nicht verwaltet werden muss, die durch die Einweg-Anbindung generierten Side-Chain-Assets jedoch möglicherweise wertlos sind Fehlen eines Rückwärtsverankerungsmechanismus.

Für die Verifizierung von Sperrtransaktionen auf der Hauptkette und Zerstörungstransaktionen auf der Seitenkette gibt es unterschiedliche Lösungen und unterschiedliche Sicherheitsstufen. Am einfachsten ist es, eine externe Verifizierung durch Teilnehmer mit mehreren Signaturen zu verwenden, aber das Risiko einer Zentralisierung ist hoch. Eine bessere Option ist die Verwendung von SPV Proof, um eine dezentrale Verifizierung zu erreichen. Da dem Bitcoin-Mainnet natürlich die notwendigen Programmierfähigkeiten fehlen, kann die SPV-Verifizierung nicht durchgeführt werden und es können nur andere Methoden gewählt werden, in der Regel die Verwahrung mit mehreren Signaturen.

Fragen und Ideen

Es gibt zwei Hauptprobleme, für die Seitenketten kritisiert werden:

Die Abhängigkeit von Cross-Chain-Assets von Verifizierern: Da das Bitcoin-Hauptnetzwerk noch nicht in der Lage ist, intelligente Verträge zu implementieren, ist es unmöglich, die Cross-Chain-Übertragung von Assets durch vertrauenswürdige Vertragslogik abzuwickeln, wenn sie von der Seitenkette zu Bitcoin zurückkehren , müssen Sie sich auf eine Gruppe von Prüfern verlassen, um den Vorgang abzuschließen, es besteht eine Vertrauensvoraussetzung und es besteht die Gefahr von Betrug.

Die Seitenkette kann nicht die Sicherheit der Hauptkette erben: Die Seitenkette läuft völlig unabhängig vom Hauptnetzwerk und kann nicht die Sicherheit des Hauptnetzwerks erben. Es können Ereignisse wie eine böswillige Blockreorganisation auftreten.

In diesem Zusammenhang umfassen die Ideen von Seitenketten die Abhängigkeit von Autorität (Allianztyp), die Abhängigkeit von wirtschaftlicher Sicherheit (PoS), die Abhängigkeit von dezentralen Bitcoin-Minern (Merged Mining), die Abhängigkeit von Hardware-Sicherheitsmodulen (HSM), die Fondsverwahrung und die Seitenkette Auf Bitcoin können verschiedene Rollen für die Blockproduktion der Kette verantwortlich sein, wodurch komplexere Sicherheitsmechanismen eingeführt werden.

Falleinführung

Flüssig

Die erste Form der Seitenkette ist die Allianz-Seitenkette, in der mehrere im Voraus ausgewählte Einheiten als Prüfer fungieren und für die Verwaltung der Hauptnetzwerkmittel und die Blockproduktion der Seitenkette verantwortlich sind.

Liquid ist der Vertreter der Allianz-Seitenkette, wobei 15 Teilnehmer als Verifizierer fungieren. Die Methode zur Verwaltung des privaten Schlüssels wird nicht bekannt gegeben und für die Verifizierung sind 11 Signaturen erforderlich. Die Blöcke auf der Liquid-Seitenkette werden ebenfalls von 15 Teilnehmern gemeinsam gepflegt. Die Allianzkette mit einer geringen Anzahl von Knoten kann höhere TPS erreichen und Expansionsziele erreichen.

Der Side-Chain-Ansatz der Allianz birgt erhebliche zentralisierte Sicherheitsrisiken.

Unterlage (RSK)

RSK verfügt außerdem über 15 Knoten, die als Mainnet-Fondsverwahrer fungieren, und für die Überprüfung sind nur 8 Unterschriften erforderlich. Der Unterschied zu Liquid besteht darin, dass der Multisignaturschlüssel vom Hardware-Sicherheitsmodul HSM verwaltet wird und die Peg-Out-Anweisung gemäß dem PoW-Konsens signiert wird, um zu verhindern, dass der Verifizierer, der den Schlüssel besitzt, die Treuhandgelder direkt manipuliert.

Im Hinblick auf den Side-Chain-Konsens nutzt RSK Merged Mining, um die Sicherheit von Transaktionen in der Side-Chain zu gewährleisten. Wenn der Anteil der Merged-Mining-Rechenleistung im Hauptnetzwerk hoch ist, kann die Seite besser verhindert werden Kette vor Beeinträchtigung. RSK hat Verbesserungen am Merged Mining vorgenommen, um die Sicherheit von Seitenketten bei niedrigen Hash-Raten zu gewährleisten. Es verwendet eine fork-bewusste Methode, um Konsenseingriffe außerhalb der Kette auf das Fork-Verhalten durchzuführen und die Wahrscheinlichkeit doppelter Ausgaben zu verringern.

Allerdings verändert Merged Mining die Anreize der Miner und erhöht die Risiken von MEV, was letztendlich zu einer Destabilisierung des Systems führen kann. Langfristig könnte Merged Mining die Zentralisierung des Bergbaus verstärken.

Stapel

Stacks verankert den Verlauf der Stacks-Kette an Bitcoin, indem es den Block-Hash der Side-Chain an den Bitcoin-Block übermittelt. Es hat die gleiche Endgültigkeit wie Bitcoin. Der Fork von Stacks kann nur durch die Fork von Bitcoin verbessert werden Vermeiden Sie Doppelausgaben.

sBTC führt einen neuen Token-STX und ein Anreizmodell ein, das einen Staking-Bridge-Ansatz verwendet, der bis zu 150 Mainnet-Validatoren ermöglicht. Bei der sogenannten Staking Bridge müssen Validatoren STX-Tokens einsetzen, um die Erlaubnis zur Genehmigung von Ein- und Auszahlungen zu erhalten. Die Sicherheit der Pfandbrücke hängt stark vom Wert der verpfändeten Vermögenswerte ab. Wenn der Wert der verpfändeten Vermögenswerte stark schwankt, kann die Sicherheit der BTC-Kette leicht beschädigt werden. Wenn der Wert der verpfändeten Vermögenswerte niedriger ist als der Wert der Cross-Chain-Vermögenswerte, besteht für den Validator ein Anreiz, Böses zu tun.

Es gibt auch einige Sidechain-Vorschläge, die in der Community ausführlich diskutiert werden.

Antriebskette

Am meisten Aufmerksamkeit erregte Drivechain, das 2015 von Paul Sztorc vorgeschlagen wurde. Den Schlüsseltechnologien im Plan wurden BIP 300 (Peg-Mechanismus) und BIP 301 (Blind Merged Mining) zugewiesen. BIP 300 definiert die Logik des Hinzufügens einer neuen Seitenkette im Detail. Die Aktivierung einer neuen Seitenkette ähnelt der Aktivierung eines Soft Forks durch Miner-Signale. Mit BIP 301 können Bitcoin-Miner zu Sidechain-Blockproduzenten werden, ohne bestimmte Transaktionsinhalte zu überprüfen.

Bitcoin-Miner müssen außerdem zunächst eine OP_RETURN-Ausgabe in der Coinbase-Transaktion des von ihnen geschürften Blocks erstellen. Danach kann jeder Miner über den Vorschlag abstimmen kann jederzeit für oder gegen den Vorschlag stimmen. Sobald eine Auszahlungstransaktion den Schwellenwert (13150 Blöcke) überschreitet, wird die Auszahlungstransaktion offiziell ausgeführt und von der Bitcoin-Hauptkette bestätigt.

Tatsächlich haben Miner die vollständige Kontrolle über die Gelder auf der Drivechain. Wenn Gelder gestohlen werden, können sich Benutzer nur durch UASF (user-activated soft fork) retten, aber es ist sehr schwierig, einen Konsens zu erzielen. Darüber hinaus verschärft die einzigartige Stellung der Miner in Drivechain die MEV-Risiken, wie bereits bei Ethereum gezeigt wurde.

Raumkette

Spacechain hat einen anderen Ansatz gewählt und verwendet Perpetual 1 way peg (P1WP). Benutzer verbrennen BTC, um Token auf Spacechain zu erhalten, und überspringen so direkt das Problem der Fondssicherheit. Dieser Token kann nur zur Versteigerung von Blockraum auf der Spacechain verwendet werden und hat keine Wertspeicherfunktion.

Um die Sicherheit der Seitenkette zu gewährleisten, nutzt Spacechain das Blind-Merge-Mining. Andere Benutzer nutzen ANYPREVOUT (APO), um öffentlich um das Recht zum Erstellen von Blöcken zu konkurrieren Seitenkette. Der Start von Spacechain erfordert jedoch die Unterstützung von Covanent, und die Bitcoin-Community diskutiert immer noch über die Notwendigkeit einer Soft Fork, um den Covanent-Opcode hinzuzufügen.

Im Allgemeinen kann Spacechain durch die Funktion des Bietens für Blöcke auf Bitcoin eine Seitenkette realisieren, die die gleichen Dezentralisierungs- und Anti-Zensur-Eigenschaften wie Bitcoin und mehr Programmierbarkeit aufweist.

Softchain

Softchain ist ein 2wp-Side-Chain-Vorschlag, der vom Spacechain-Autor Ruben Somsen vorgeschlagen wurde. Er nutzt den PoW-FP-Konsensmechanismus, um die Sicherheit der Side-Chain zu gewährleisten. Unter normalen Umständen muss der vollständige Knoten von Bitcoin nur den Blockheader der Softchain herunterladen und den Arbeitsnachweis überprüfen. Wenn eine Verzweigung auftritt, laden Sie den verwaisten Block und die entsprechende UTXO-Set-Verpflichtung herunter, um die Gültigkeit des Blocks zu überprüfen.

Beim 2wp-Mechanismus wird während des Peg-Ins eine Einzahlungstransaktion auf der Hauptkette erstellt, und die Hauptkettentransaktion wird auf der Softchain referenziert, um Gelder zu erhalten, während beim Peg-Out eine Auszahlungstransaktion auf der Softchain erstellt wird Auf die Transaktion wird in der Hauptkette verwiesen, um BTC abzurufen, und der Auszahlungsprozess muss eine lange Zeitspanne warten, bevor er abgeschlossen werden kann. Die spezifischen Peg-In- und Peg-Out-Mechanismen erfordern Soft-Fork-Unterstützung, daher heißt die Lösung Softchain.

Die Softchain-Lösung verursacht zusätzliche Verifizierungskosten für die vollständigen Knoten des Bitcoin-Hauptnetzwerks. Die Konsensaufteilung von Softchain kann sich auf das Erreichen des Hauptnetzwerkkonsenses auswirken und zu einem möglichen Angriffsmittel auf das Bitcoin-Hauptnetzwerk werden.

Lightning-Netzwerk

Das Lightning Network veröffentlichte 2015 ein Whitepaper und wurde 2018 offiziell gestartet. Als Layer-2-P2P-Zahlungsprotokoll auf Bitcoin zielt es darauf ab, eine große Anzahl kleiner Transaktionen mit hoher Frequenz in die Off-Chain-Verarbeitung zu übertragen Lange Zeit galt sie als die fortschrittlichste Technologie im Bitcoin-Netzwerk.

Kern Modul

Die Implementierung des Lightning Network ist untrennbar mit mehreren wichtigen Modulen in Bitcoin verbunden, die zusammen die Sicherheit von Lightning Network-Transaktionen gewährleisten.

Die erste ist die vorab unterzeichnete Transaktion. Vorsignierte Transaktionen wurden erst nach dem SegWit-Upgrade sicher und verfügbar. SegWit trennt Signaturen vom Rest der Transaktionsdaten und löst so Probleme wie potenzielle zirkuläre Abhängigkeiten, Transaktionsmanipulationen durch Dritte und Transaktionsmanipulationen durch Dritte. Die Sicherheit der Datenverarbeitung im Rahmen der Lightning Network-Kette wird durch die unwiderrufliche Verpflichtung der anderen Partei gewährleistet, und diese Verpflichtung wird durch vorab unterzeichnete Transaktionen umgesetzt. Nach Erhalt der von der anderen Partei vorab unterzeichneten Transaktion kann der Benutzer die Transaktion jederzeit an die Kette senden, um die Erfüllung des Versprechens abzuschließen.

An zweiter Stelle steht die Mehrfachsignatur. Für häufige Transfers von Off-Chain-Geldern zwischen zwei Parteien ist ein Träger erforderlich, der von beiden Parteien die Wahrung bestimmter Kontrollrechte verlangt. Daher ist im Allgemeinen eine 2/2-Mehrfachsignatur erforderlich, die die Übertragung von Geldern gewährleistet muss im gegenseitigen Einvernehmen beider Parteien erfolgen.

Allerdings führt die 2/2-Mehrfachsignatur zu Problemen bei der Lebendigkeit, d. h. wenn die andere Partei nicht kooperiert, kann der Benutzer keine Vermögenswerte von der Mehrfachsignaturadresse übertragen, was zum Verlust des ursprünglichen Geldes führt. Zeitsperren können das Lebendigkeitsproblem lösen. Durch die vorherige Unterzeichnung eines Vertrags mit einer Zeitsperre zur Rückgabe von Geldern kann sichergestellt werden, dass die andere Partei die ursprünglichen Mittel zurückerhalten kann, selbst wenn eine Partei inaktiv wird.

Schließlich gibt es noch die Hash-Sperre, die mehrere Statuskanäle verbinden und ein Netzwerk aufbauen kann. Das Originalbild des Hash wird als Kommunikationsmedium verwendet, um den korrekten Betrieb mehrerer Entitäten zu koordinieren.

Prozess ausführen

Zwei-Wege-Kanal

Beide Parteien, die das Lightning Network zur Durchführung von Transaktionen nutzen, müssen zunächst einen bidirektionalen Zahlungskanal auf Bitcoin eröffnen. Beide Parteien können eine beliebige Anzahl von Transaktionen außerhalb der Kette durchführen. Nachdem alle Transaktionen abgeschlossen sind, wird der aktuelle Status an die Bitcoin-Kette übermittelt um die Abrechnung abzuschließen und den Zahlungsgang zu schließen.

Konkret umfasst die Implementierung von Zahlungskanälen die folgenden wesentlichen Schritte:

  1. Erstellen Sie eine Adresse mit mehreren Signaturen. Beide Parteien des Kanals müssen zunächst eine 2-aus-2-Mehrfachsignaturadresse als Fondssperradresse des Kanals erstellen. Jede Partei verfügt über einen privaten Signaturschlüssel und stellt ihren eigenen öffentlichen Schlüssel bereit.

  2. Initialisieren Sie den Kanal. Beide Parteien übertragen eine Transaktion in der Kette und sperren einen bestimmten Bitcoin-Betrag als Anfangskapital des Kanals in die Multi-Signatur-Adresse. Diese Transaktion wird als „Anker“-Transaktion des Kanals bezeichnet.

  3. Kanalstatus aktualisieren. Bei einer Zahlung innerhalb des Kanals aktualisieren beide Parteien den Status des Kanals, indem sie vorab unterzeichnete Transaktionen austauschen. Bei jeder Aktualisierung wird eine neue „Verpflichtungstransaktion“ generiert, die den aktuellen Status der Mittelzuweisung darstellt. Die Verpflichtungstransaktion hat zwei Ausgänge, die den Fondsanteilen beider Parteien entsprechen.

  4. Übertragen Sie den neuesten Status. Jede Partei des Kanals kann jederzeit die letzte Verpflichtungstransaktion an die Blockchain senden, um ihren Anteil an den Geldern abzuheben. Um zu verhindern, dass die andere Partei den alten Status verbreitet, gibt es für jede Verpflichtungstransaktion eine entsprechende „Straftransaktion“. Wenn die andere Partei betrügt, können Sie alle Gelder der anderen Partei erhalten.

  5. Schließen Sie den Kanal. Wenn zwei Parteien beschließen, einen Kanal zu schließen, können sie zusammenarbeiten, um eine „Abrechnungstransaktion“ zu generieren, die den endgültigen Status der Mittelverteilung an die Blockchain sendet. Auf diese Weise werden die in der Multi-Signatur-Adresse gesperrten Gelder wieder an die persönlichen Adressen beider Parteien freigegeben.

  6. Schlichtung in der Kette. Wenn die beiden Parteien beim Schließen des Kanals keine Einigung erzielen können, kann jede Partei einseitig die letzte Verpflichtungstransaktion übertragen und das On-Chain-Schiedsverfahren einleiten. Wenn innerhalb eines bestimmten Zeitraums (z. B. 1 Tag) keine Einwände erhoben werden, werden die Gelder entsprechend der Zuordnung der vereinbarten Transaktion an beide Parteien gesendet.

Zahlungsnetzwerk

Zahlungskanäle können miteinander verbunden werden, um ein Netzwerk zu bilden, das Multi-Hop-Routing unterstützt und über HTLC implementiert wird. HTLC verwendet eine Hash-Sperre als direkte Bedingung und eine Signaturzahlung mit Zeitsperre als Sicherungsbedingung. Benutzer können mit dem gehashten Originalbild interagieren, bevor die Zeitsperre abläuft.

Wenn kein direkter Kanal zwischen zwei Benutzern besteht, kann die Zahlung mithilfe von HTLC zwischen Routern abgewickelt werden. Das Hash-Preimage R spielt im gesamten Prozess eine Schlüsselrolle und stellt die Atomizität der Zahlung sicher. Gleichzeitig soll die Zeitsperre von HTLC im Laufe der Zeit abnehmen, um sicherzustellen, dass jeder Hop genügend Zeit hat, die Zahlung zu verarbeiten und weiterzuleiten.

Probleme

Im Wesentlichen umgeht das Lightning Network die externe Vertrauensannahme der Asset-Überbrückung über P2P-Statuskanäle und verwendet gleichzeitig Zeitsperrskripte, um die ultimative Garantie für Assets und Fehlerschutz zu bieten. Wenn die andere Partei ihre Aktivität verliert und nicht kooperiert, kann ein einseitiger Rückzug abgeschlossen werden. Daher hat das Lightning Network in Zahlungsszenarien einen hohen Stellenwert, weist aber auch viele Einschränkungen auf, darunter:

  • Begrenzung der Kanalkapazität. Die Kapazität des Zahlungskanals im Lightning Network ist durch die anfänglich gesperrten Mittel begrenzt und kann keine großen Zahlungen unterstützen, die die Kanalkapazität überschreiten. Dies kann bestimmte Anwendungsszenarien einschränken, beispielsweise den Rohstoffhandel.

  • Online und synchronisiert. Um Zahlungen rechtzeitig zu empfangen und weiterzuleiten, müssen die Lightning Network-Knoten online bleiben. Wenn ein Knoten längere Zeit offline ist, kann es sein, dass einige Kanalstatusaktualisierungen fehlen, was dazu führt, dass der Status nicht mehr synchron ist. Dies kann für einzelne Benutzer und mobile Geräte eine Herausforderung darstellen und erhöht auch die Kosten für den Knotenbetrieb.

  • Liquiditätsmanagement. Die Routing-Effizienz des Lightning Network hängt von der Liquiditätsverteilung der Kanäle ab. Wenn die Gelder ungleichmäßig verteilt sind, können einige Zahlungswege fehlschlagen, was sich auf die Benutzererfahrung auswirkt. Die Verwaltung des Liquiditätssaldos des Kanals erfordert bestimmte technische und Kapitalkosten.

  • Datenschutzverletzung. Um verfügbare Zahlungswege zu finden, erfordert der Routing-Algorithmus des Lightning Network ein gewisses Maß an Kenntnissen über die Kapazität und Konnektivitätsinformationen des Kanals. Dadurch kann die Privatsphäre einiger Benutzer preisgegeben werden, z. B. bei der Fondsverteilung, den Kontrahenten usw. Durch das Öffnen und Schließen von Zahlungskanälen können auch Informationen über relevante Teilnehmer offengelegt werden.

RGB

Die ursprüngliche Idee des RGB-Protokolls wurde von den von Peter Todd vorgeschlagenen clientseitigen Verifizierungs- und einmaligen Versiegelungskonzepten inspiriert. Es wurde 2016 von Giacomo Zucco vorgeschlagen. Es handelt sich um ein skalierbares und die Privatsphäre schützendes Bitcoin-Protokoll der zweiten Schicht .

Hauptidee

Kundenüberprüfung

Der Verifizierungsprozess der Blockchain besteht darin, die aus Transaktionen bestehenden Blöcke an alle zu senden, sodass jeder Knoten die Transaktionen im Block berechnen und die Verifizierung abschließen kann. Dadurch entsteht tatsächlich ein öffentliches Gut, das heißt, Knoten im gesamten Netzwerk helfen jedem Einzelnen, der eine Transaktion einreicht, bei der vollständigen Verifizierung, und Benutzer stellen BTC als Bearbeitungsgebühr zur Verfügung, um einen Anreiz zu schaffen, bei der Verifizierung mitzuhelfen. Die clientseitige Überprüfung erfolgt nicht global, sondern wird von Einzelpersonen überprüft, die an bestimmten Statusübergängen beteiligt sind. Dies verbessert die Privatsphäre erheblich und verringert sie entlastet die Knoten und verbessert die Skalierbarkeit.

Einwegdichtung

Beim Punkt-zu-Punkt-Zustandsübergang besteht eine versteckte Gefahr: Wenn Benutzer nicht den vollständigen Zustandsübergangsverlauf erfassen können, werden sie möglicherweise betrogen und geben doppelt aus. Um dieses Problem zu lösen, wird eine Einwegversiegelung vorgeschlagen. Dabei wird ein spezieller Gegenstand verwendet, der nur einmal verwendet werden kann, um sicherzustellen, dass es nicht zu doppelten Ausgaben kommt, und um die Sicherheit zu verbessern. UTXO von Bitcoin ist das am besten geeignete einmalig versiegelte Objekt, das durch den Konsensmechanismus von Bitcoin und die Rechenleistung des gesamten Netzwerks garantiert wird, sodass RGB-Assets die Sicherheit von Bitcoin erben können.

Krypto-Versprechen

Das einmalige Siegel muss mit der Verschlüsselungsverpflichtung kombiniert werden, um sicherzustellen, dass der Benutzer den Zustandsübergang kennt und das Auftreten von Angriffen mit doppelten Ausgaben vermieden wird. Die sogenannte Verpflichtung besteht darin, andere darüber zu informieren, dass etwas passiert ist und später nicht mehr geändert werden kann. Es besteht jedoch keine Notwendigkeit, bestimmte Ereignisse offenzulegen, bis eine Überprüfung erforderlich ist. Wir können eine Hash-Funktion verwenden, um eine Verpflichtung einzugehen. In RGB ist der Inhalt der Verpflichtung der Zustandsübergang. Durch die Ausgabe von UTXO erhält der Empfänger des RGB-Assets das Signal des Zustandsübergangs und überprüft dann die Verpflichtung anhand der vom Spender außerhalb der Kette übertragenen Daten das Kapital.

Arbeitsprozess

RGB nutzt den Bitcoin-Konsens, um Sicherheit bei doppelten Ausgaben und Zensurresistenz zu gewährleisten. Die gesamte Überprüfung staatlicher Überweisungen wird außerhalb der Kette übertragen und nur durch den Kunden überprüft, der die Zahlung akzeptiert.

Für den Emittenten von RGB-Vermögenswerten muss durch Initiieren einer Transaktion ein RGB-Vertrag erstellt werden, und die Verpflichtung der spezifischen Informationen wird im OP_RETURN-Skript einer bestimmten Ausgabebedingung in der Taproot-Transaktion gespeichert.

Wenn der Inhaber eines RGB-Vermögenswerts etwas ausgeben möchte, muss er relevante Informationen vom Empfänger des Vermögenswerts einholen, eine RGB-Transaktion erstellen, die Details der RGB-Transaktion festschreiben und den Verpflichtungswert in das vom Vermögenswertempfänger angegebene UTXO einfügen . und geben Sie eine Transaktion aus, die das ursprüngliche UTXO ausgibt und das vom Empfänger angegebene UTXO erstellt. Wenn der Empfänger des Vermögenswerts feststellt, dass das UTXO, das das RGB-Vermögen ursprünglich gespeichert hat, verbraucht ist, kann er die Gültigkeit der RGB-Transaktion durch die Verpflichtung in der Bitcoin-Transaktion überprüfen. Sobald die Überprüfung gültig ist, geht er davon aus, dass er das tatsächlich erhalten hat RGB-Asset.

Für den Empfänger von RGB-Vermögenswerten muss der Zahler den ursprünglichen Status und die Statusübergangsregeln des Vertrags, die für jede Übertragung verwendeten Bitcoin-Transaktionen, die von jeder Bitcoin-Börse durchgeführten RGB-Transaktionen und die Gültigkeit jeder Bitcoin-Transaktion nachweisen. Wird vom Client des Empfängers anhand dieser Daten überprüft und überprüft die Gültigkeit der RGB-Transaktion. Unter anderem wird UTXO von Bitcoin als Container verwendet, um den Status des RGB-Vertrags zu speichern. Der Übertragungsverlauf jedes RGB-Vertrags kann als gerichtetes azyklisches Diagramm ausgedrückt werden. Der Empfänger des RGB-Assets kann nur die Informationen erhalten, die sich auf den RGB beziehen Das von ihm verwaltete Vermögen hat keinen Zugriff auf andere Filialen.

Vorteile und Nachteile

Leichte Verifizierung

Im Vergleich zur vollständigen Verifizierung der Blockchain reduziert das RGB-Protokoll die Verifizierungskosten erheblich. Benutzer müssen nicht alle historischen Blöcke durchlaufen, um den neuesten Status zu erhalten, sondern müssen lediglich die historischen Aufzeichnungen zu den Assets synchronisieren, die sie zur Überprüfung erhalten die Wirksamkeit der Transaktion.

Diese einfache Verifizierung erleichtert Peer-to-Peer-Transaktionen, wodurch die Notwendigkeit zentraler Dienstleister weiter entfällt und der Grad der Dezentralisierung erhöht wird.

Skalierbarkeit

Das RGB-Protokoll erbt die Sicherheit von Bitcoin nur durch die Festlegung eines Hashs. Durch Taproot-Skripte wird nahezu kein zusätzlicher Speicherplatz in der Bitcoin-Kette verbraucht, was eine komplexe Programmierbarkeit von Assets ermöglicht. Aufgrund der Verwendung von UTXO als Container verfügt das RGB-Protokoll über eine natürliche Parallelität. RGB-Assets auf verschiedenen Übertragungszweigen blockieren sich nicht gegenseitig und können gleichzeitig ausgegeben werden.

Privatsphäre

Anders als bei allgemeinen Protokollen kann nur der Empfänger von RGB-Assets den historischen Übertragungsstatus von RGB-Assets erhalten. Sobald die Ausgabe abgeschlossen ist, kann der zukünftige Übertragungsstatus nicht abgerufen werden, was die Privatsphäre des Benutzers erheblich gewährleistet. Es besteht kein Zusammenhang zwischen der Transaktion von RGB-Vermögenswerten und der Übertragung von Bitcoin UTXO, und andere können keine Spuren von RGB-Transaktionen in der Bitcoin-Kette erhalten.

Darüber hinaus unterstützt RGB auch Blindausgaben, und der Zahler kann nicht wissen, in welches UTXO die RGB-Vermögenswerte eingezahlt werden, was die Privatsphäre weiter verbessert und die Zensurresistenz erhöht.

unzureichend

Wenn RGB-Assets häufig den Besitzer wechseln, müssen neue Benutzer, die Vermögenswerte erhalten, eine lange Übertragungshistorie überprüfen, was zu einem höheren Überprüfungsaufwand führt, die Überprüfungszeit möglicherweise länger ist und die Möglichkeit einer schnellen Bestätigung verloren geht. Für Knoten, die weiterhin in der Blockchain laufen, ist die Zeit bis zum Empfang der schnellen Verifizierungsstatusübertragung der neuen Zone jedes Mal begrenzt, da der neueste Status immer synchronisiert wird.

Die Community diskutiert die Möglichkeit, historische Berechnungen wiederzuverwenden, und der rekursive ZK-Proof bietet die Möglichkeit, eine konstante Zeit- und Größenstatusüberprüfung zu erreichen.

Aufrollen

Überblick

Rollup ist die beste Erweiterungslösung, zu der das Ethereum-Ökosystem nach jahrelanger Erkundung gelangt ist, von staatlichen Kanälen über Plasma bis hin zu Rollup.

Rollup ist eine unabhängige Blockchain, die Transaktionen außerhalb der Bitcoin-Kette sammelt, mehrere Transaktionen in einem Batch zusammenfasst und ausführt und die Daten und Statusverpflichtungen dieses Batches an die Hauptkette übermittelt, wodurch Off-Chain-Transaktionen und Statusaktualisierungen realisiert werden. Um eine maximale Erweiterung zu erreichen, verwendet Rollup in dieser Phase normalerweise einen zentralen Sequenzer, um die Ausführungseffizienz zu verbessern, ohne die Sicherheit zu verlieren, da die Sicherheit durch die Überprüfung der Rollup-Statusübergänge in der Hauptkette gewährleistet wird.

Während die Rollup-Lösung des Ethereum-Ökosystems ausgereift ist, hat auch das Bitcoin-Ökosystem begonnen, mit Rollup zu experimentieren. Der kritischste Unterschied zwischen Bitcoin und Ethereum ist jedoch der Mangel an Programmierfähigkeiten und die Unfähigkeit, die zum Aufbau von Rollups in der Kette erforderlichen Berechnungen durchzuführen. Daher wird derzeit nur versucht, souveränes Rollup und OP-Rollup zu implementieren.

Einstufung

Entsprechend den verschiedenen Überprüfungsmethoden der Statusübertragung kann Rollup in zwei Hauptkategorien unterteilt werden: Optimistic Rollup und Validity Rollup (ZK Rollup).

Optimistic Rollup verwendet eine optimistische Verifizierungsmethode. Während des Streitzeitraums nach der Übermittlung jedes Transaktionsstapels kann jeder die Off-Chain-Daten überprüfen, Einwände gegen problematische Transaktionsstapel erheben, Betrugsnachweise an die Hauptkette übermitteln und den Sequencer verlieren. Wenn nach Ablauf des Streitzeitraums kein gültiger Betrugsbeweis vorliegt, gilt der Transaktionsstapel als gültig und die Statusaktualisierung wird in der Hauptkette bestätigt.

Validity Rollup verwendet einen Validitätsnachweis, um die Überprüfung abzuschließen, und Sequencer verwendet einen wissensfreien Beweisalgorithmus, um einen präzisen Gültigkeitsnachweis für jeden Transaktionsstapel zu generieren, der beweist, dass die Statusübertragung des Stapels korrekt ist. Bei jeder Aktualisierung muss der Transaktionsstapel übermittelt werden die Hauptkette ist ein Gültigkeitsnachweis. Die Hauptkette überprüft den Beweis und versteht und bestätigt dann die Statusaktualisierung.

Der Vorteil von Optimistic Rollup besteht darin, dass es relativ einfach zu implementieren ist und weniger Änderungen an der Hauptkette erfordert. Die Bestätigung von Transaktionen dauert jedoch länger (abhängig von der Einspruchsfrist) und erfordert eine höhere Datenverfügbarkeit. Validity Rollup-Transaktionen werden schnell bestätigt, sind nicht auf Einspruchsfristen angewiesen und Transaktionsdaten können privat bleiben, aber die Erstellung und Überprüfung von Zero-Knowledge-Beweisen erfordert einen hohen Rechenaufwand.

Celestia schlug außerdem das Konzept eines souveränen Rollups vor. Die Transaktionsdaten des Rollups werden in einer dedizierten DA-Layer-Blockchain veröffentlicht, die für die Datenverfügbarkeit verantwortlich ist, und der souveräne Rollup selbst ist für die Ausführung und Abwicklung verantwortlich.

Entdecken und diskutieren

Aufgrund der Unterschiede zwischen dem Buchhaltungsmodell und der Programmiersprache von Ethereum ist es schwierig, die praktischen Erfahrungen von Ethereum direkt zu kopieren.

Souveränitäts-Rollup

Am 5. März 2023 wurde Rollkit als erstes Framework zur Unterstützung von Bitcoin-Staats-Rollups angekündigt. Entwickler von Staats-Rollups können Verfügbarkeitsdaten zu Bitcoin über Rollkit veröffentlichen.

Rollkit ist von Ordinals inspiriert und veröffentlicht Daten über Taproot-Transaktionen. Eine standardmäßige Taproot-Transaktion über den öffentlichen Mempool kann bis zu 390 KB an Daten enthalten, und eine nicht standardmäßige Taproot-Transaktion, die direkt von einem Miner ausgegeben wird, kann fast 4 MB an beliebigen Daten enthalten.

Die eigentliche Aufgabe von Rollkit besteht darin, eine Schnittstelle für souveränes Rollup bereitzustellen, um Daten in Bitcoin zu lesen und zu schreiben, Middleware-Dienste für Kunden bereitzustellen und Bitcoin in eine DA-Schicht umzuwandeln.

Die Idee eines Sovereign Rollup stieß auf große Skepsis, und viele Gegner behaupteten, dass ein Sovereign Rollup auf Bitcoin nichts anderes sei, als Bitcoin als schwarzes Brett zu nutzen und überhaupt nicht in der Lage sei, die Sicherheit von Bitcoin zu erben. Wenn Sie nur Transaktionsdaten an Bitcoin übermitteln, können Sie tatsächlich nur die Lebendigkeit verbessern, dh alle Benutzer können die entsprechenden Daten zur Überprüfung über Bitcoin erhalten, aber die Sicherheit kann nur durch das souveräne Rollup selbst definiert werden und kann nicht vererbt werden. Darüber hinaus ist der Blockplatz bei Bitcoin knapp und die Übermittlung vollständiger Transaktionsdaten ist möglicherweise keine gute Entscheidung.

OP-Rollup und Gültigkeits-Rollup

Obwohl sich viele Bitcoin-Second-Layer-Projekte ZK Rollup nennen, was im Wesentlichen einem OP Rollup ähnelt, dabei aber die Validity Proof-Technologie beinhaltet, reichen die Programmierfähigkeiten von Bitcoin noch nicht aus, um eine direkte Validity Proof-Verifizierung zu unterstützen.

Derzeit ist der Opcode-Satz von Bitcoin sehr begrenzt und kann nicht einmal die Multiplikation direkt berechnen. Die Überprüfung des Gültigkeitsnachweises erfordert die Erweiterung von Opcodes und hängt auch stark von der Implementierung rekursiver Verträge ab. Zu den Opcodes, die derzeit in der Community diskutiert werden, gehören OP_CAT, OP_CHECKSIG. OP_TXHASH usw. Wenn wir OP_VERIFY_ZKP direkt hinzufügen könnten, bräuchten wir natürlich vielleicht keine weiteren Änderungen, aber das ist offensichtlich unwahrscheinlich. Darüber hinaus behindern Beschränkungen der Stapelgröße auch Bemühungen, den Gültigkeitsnachweis in Bitcoin-Skripten zu überprüfen, und viele Versuche werden derzeit geprüft.

Wie funktioniert der Gültigkeitsnachweis? Die meisten Projekte veröffentlichen den Status und den Gültigkeitsnachweis von Transaktionsstapeln in Form von Inschriften in Bitcoin und verwenden BitVM zur optimistischen Überprüfung. BitVM Bridge ersetzt hier die traditionelle Multi-Signatur-Lösung. Der Bridge-Betreiber wird eine N-Personen-Allianz bilden, um Benutzereinzahlungen zu planen. Bevor Benutzer eine Einzahlung tätigen, muss die Allianz das zu generierende UTXO vorab unterzeichnen, um sicherzustellen, dass die Einzahlung nur rechtmäßig vom Betreiber eingezogen werden kann. Nach Erhalt der Vorsignatur wird BTC an eine N/N-Taproot-Adresse mit mehreren Signaturen gesperrt.

Wenn ein Benutzer eine Auszahlungsanforderung stellt, sendet Rollup den Gültigkeitsnachweis mit dem Auszahlungs-Root an die Bitcoin-Kette. Der Betreiber wird zunächst die Auszahlungsanforderungen des Benutzers aus eigener Tasche erfüllen und dann die Gültigkeit durch den BitVM-Vertrag überprüfen. Wenn jeder Betreiber davon überzeugt ist, dass das Zertifikat gültig ist, erhält er eine Rückerstattung durch Mehrfachsignatur; solange jemand glaubt, dass ein Betrug vorliegt, wird ein Anfechtungsverfahren durchgeführt und die falsche Partei wird gekürzt.

Dieser Prozess ist eigentlich derselbe wie OP Rollup. Die Vertrauensannahme ist 1/N. Solange ein Prüfer ehrlich ist, ist das Protokoll sicher.

Allerdings kann es bei der technischen Umsetzung dieser Lösung zu Schwierigkeiten kommen. Im OP-Rollup-Projekt von Ethereum wird Arbitrum seit vielen Jahren entwickelt, und der aktuelle Fraud Proof wird immer noch von autorisierten Knoten eingereicht; Optimism gab erst kürzlich bekannt, dass er Fraud Proof unterstützt, was zeigt, wie schwierig die Implementierung ist.

Was die vorsignierte Operation in der BitVM-Brücke betrifft, kann sie mit der Unterstützung von Bitcoin Covenent effizienter implementiert werden, was noch auf den Konsens der Community wartet.

In Bezug auf die Sicherheitsattribute wird durch die Übermittlung des Rollup-Block-Hashs an Bitcoin eine Resistenz gegen Reorganisation und doppelte Ausgaben erreicht, und die Verwendung der Optimistic Bridge bringt eine 1/N-Sicherheitsannahme mit sich. Allerdings kann die Zensurresistenz der Brücke immer noch bestehen Warten Sie auf die weitere Entwicklung.

Fazit: Layer 2 ist kein Allheilmittel

Wenn wir uns so viele Layer-2-Lösungen ansehen, können wir leicht feststellen, dass jede Lösung nur begrenzte Aufgaben erfüllen kann. Unter bestimmten Vertrauensannahmen hängen die Effekte, die Schicht 2 erzielen kann, weitgehend von Schicht 1 ab, also den nativen Fähigkeiten von Bitcoin.

Ohne SegWit-Upgrades und Zeitsperren kann das Lightning-Netzwerk nicht erfolgreich aufgebaut werden; ohne Taproot-Upgrades können RGB-Verpflichtungen nicht erfolgreich ohne OP_CAT und andere Covanent übermittelt werden; Validity Rollup auf Bitcoin kann nicht erfolgreich aufgebaut werden …

Viele Bitcoin Maxi glauben, dass Bitcoin niemals geändert werden sollte und keine neuen Funktionen hinzugefügt werden sollten. Alle Mängel sollten durch Layer 2 behoben werden. Dies ist kein Allheilmittel. Wir brauchen eine leistungsfähigere Schicht 1, um eine sicherere, effizientere und skalierbarere Schicht 2 aufzubauen.

Im nächsten Artikel werden wir Versuche vorstellen, die Programmierbarkeit von Bitcoin zu verbessern, also bleiben Sie dran.