Weiterleiten des Originaltitels '系统解读Fiber：把闪电网络嫁接到CKB上的宏大实验'

Am 23. August veröffentlichte CKB offiziell das Fiber Network, eine Lightning Network-Lösung, die auf CKB basiert. Diese Nachricht löste schnell eine intensive Diskussion in der Community aus, die zu einem Anstieg des CKB-Preises um fast 30% innerhalb eines einzigen Tages führte. Die starke Reaktion kann auf die überzeugende Erzählung des Lightning Network und die Tatsache zurückgeführt werden, dass Fiber eine verbesserte Lösung gegenüber dem traditionellen Lightning Network mit zahlreichen Verbesserungen bietet. Zum Beispiel unterstützt Fiber nativ mehrere Asset-Typen, darunter CKB, BTC und Stablecoins, und profitiert von den niedrigeren Transaktionsgebühren und schnelleren Reaktionszeiten von CKB, die erhebliche UX-Fortschritte ermöglichen. Darüber hinaus hat Fiber mehrere Optimierungen in Bezug auf Datenschutz und Sicherheit vorgenommen. Darüber hinaus können Glasfaser und das BTC Lightning Network miteinander verbunden werden, wodurch ein größeres P2P-Netzwerk entsteht. Die Beamten von CKB erwähnten sogar, dass sie planen, 100.000 physische Knoten in Fiber und dem Lightning Network während Offline-Events einzurichten, um das P2P-Zahlungsnetzwerk zu verbessern und voranzutreiben. Dies ist zweifellos eine großartige und beispiellose Geschichte

Wenn die offizielle Vision von CKB in der Zukunft verwirklicht wird, wäre dies ein bedeutender Vorteil für das Lightning Network, CKB und das breitere Bitcoin-Ökosystem. Laut Mempool-Daten hält das BTC Lightning Network derzeit über 300 Millionen US-Dollar an Mitteln, mit etwa 12.000 Knoten und fast 50.000 Zahlungskanälen, die zwischen ihnen eingerichtet wurden.

Auf spendmybtc.com können wir beobachten, dass immer mehr Händler Zahlungen über das Lightning Network unterstützen. Da die Anerkennung von BTC wächst, wird der Aufstieg von Off-Chain-Zahlungslösungen wie dem Lightning Network und Fiber wahrscheinlich an Dynamik gewinnen. Um die technische Lösung von Fiber systematisch zu analysieren, hat "Geek Web3" diesen Forschungsbericht über die gesamte Fiber-Lösung erstellt. Als Implementierung des Lightning Network auf Basis von CKB sind die Prinzipien von Fiber weitgehend konsistent mit dem Bitcoin Lightning Network, beinhalten aber Optimierungen in vielen Details. Die Gesamtarchitektur von Fiber besteht aus vier Kernkomponenten: Zahlungskanäle, WatchTower, Multi-Hop-Routing und domänenübergreifende Zahlungen. Beginnen wir mit der Erläuterung der wichtigsten Komponente: den Zahlungskanälen.

Die Grundlage des Lightning-Netzwerks und Fiber: Zahlungskanäle

Zahlungskanäle verlagern im Wesentlichen Transaktionen off-chain, wobei der endgültige Zustand nach einiger Zeit on-chain abgerechnet wird. Da Transaktionen off-chain abgeschlossen sind, umgehen sie oft die Leistungseinschränkungen der Hauptkette, wie z.B. BTC. Wenn beispielsweise Alice und Bob gemeinsam einen Kanal öffnen, erstellen sie zunächst ein Multi-Signatur-Konto on-chain und hinterlegen einige Mittel, sagen wir je 100 Einheiten, als ihr Guthaben im off-chain Kanal. Sie können dann mehrere Transaktionen innerhalb des Kanals durchführen, und wenn sie den Kanal schließen, synchronisieren sie die endgültigen Guthaben on-chain, wobei das Multi-Signatur-Konto Zahlungen an beide Parteien leistet - dies ist die "Abwicklung".

Zum Beispiel, wenn beide Parteien jeweils mit 100 Einheiten beginnen und Alice 50 Einheiten an Bob überweist, gefolgt von einer weiteren Überweisung von 10 Einheiten, und dann Bob 30 Einheiten an Alice zurückschickt, wären ihre Endguthaben: Alice - 70 Einheiten, Bob - 130 Einheiten. Das Gesamtguthaben bleibt unverändert, wie am Beispiel der Abakusperlen veranschaulicht. Wenn eine Partei den Kanal verlässt, werden die Endguthaben (Alice: 70, Bob: 130) auf der Chain synchronisiert, und die 200 Einheiten des Multi-Signatur-Kontos werden gemäß diesen Endguthaben verteilt, um die Abrechnung abzuschließen.

Obwohl dieser Prozess einfach erscheint, ist er in der Praxis mit komplexen Überlegungen verbunden. Sie können nicht vorhersagen, wann die andere Partei den Kanal verlassen wird. Zum Beispiel könnte Bob nach der zweiten Transaktion oder sogar nach der ersten Transaktion aussteigen, da der Kanal es den Teilnehmern ermöglicht, frei auszusteigen. Um dieses Problem zu beheben, geht das System davon aus, dass jeder jederzeit aussteigen kann und jede Partei den endgültigen Saldo zur Begleichung an die Kette übermitteln kann. Dies wird durch "Verpflichtungstransaktionen" verwaltet, die die letzten Salden im Kanal aufzeichnen. Jede Transaktion erzeugt eine entsprechende Obligotransaktion. Um den Kanal zu verlassen, übermitteln Sie die letzte Verpflichtungstransaktion an die Kette, um Ihren Anteil vom Multi-Signatur-Konto abzuheben.

Wir können schlussfolgern, dass Verpflichtungstransaktionen verwendet werden, um die Salden beider Parteien im Kanal on-chain abzurechnen, wobei jede Partei die neueste Verpflichtungstransaktion zur Beendigung des Kanals einreichen kann. Es gibt jedoch ein entscheidendes bösartiges Szenario: Bob könnte einen veralteten Saldo und eine Verpflichtungstransaktion an die Kette übermitteln. Beispielsweise beträgt Bobs Saldo nach der Generierung von Commit Tx3 130 Einheiten. Aber zu seinem Vorteil könnte Bob die veraltete Commit Tx2 übermitteln, die einen Saldo von 160 Einheiten zeigt. Dieser veraltete Saldo stellt einen klassischen "Double-Spending"-Angriff dar.

Um solche Doppelausgaben zu verhindern, muss es entsprechende Sanktionsmaßnahmen geben. Die Gestaltung dieser Strafmaßnahmen ist der Kern des Eins-zu-Eins-Zahlungskanalsystems, und es ist wichtig, dies zu verstehen, um zu verstehen, wie Zahlungskanäle funktionieren. Wenn eine der Parteien im Channel-Design eine veraltete Zustands- und Verpflichtungstransaktion an die Kette übermittelt, wird sie feststellen, dass die andere Partei alle Gelder abheben kann, anstatt davon zu profitieren. Dabei werden die Konzepte der "asymmetrischen Verpflichtungstransaktionen" und der "Widerrufsschlüssel" verwendet, die von entscheidender Bedeutung sind. Lassen Sie uns zunächst "asymmetrische Verpflichtungstransaktionen" am Beispiel von Commit Tx3 erläutern.

In diesem Szenario erstellt Bob eine Verpflichtungstransaktion und sendet sie zur Bearbeitung an Alice. Wie gezeigt, handelt es sich bei dieser Transaktion um eine Bitcoin-Überweisung, bei der deklariert wird, dass 70 Einheiten aus dem Multi-Signatur-Konto Alice und 130 Einheiten Bob zugewiesen werden. Die Bedingungen für die Freischaltung sind jedoch "asymmetrisch", was Alice härtere Einschränkungen auferlegt und Bob zugute kommt.

Wenn Alice die Commitment-Transaktion von Bob erhält, kann sie ihre Unterschrift hinzufügen, um die 2/2-Multisig-Anforderung zu erfüllen. Alice kann dann wählen, diese Commitment-Transaktion on-chain einzureichen, um den Kanal zu verlassen. Alternativ kann sie weiterhin Transaktionen innerhalb des Kanals durchführen, wenn sie sie nicht einreicht.

Es ist wichtig zu beachten, dass diese Verpflichtungstransaktion von Bob erstellt wird und für Alice ungünstige Bedingungen hat. Alice hat die Wahl, sie entweder anzunehmen oder abzulehnen, aber wir müssen sicherstellen, dass sie eine gewisse Autonomie behält. Bei der Gestaltung von Zahlungskanälen kann nur Alice die 'ungünstige' Verpflichtungstransaktion an die Kette senden, da Verpflichtungstransaktionen eine 2/2-Multisignatur erfordern. Nachdem Bob die Transaktion lokal erstellt hat, enthält sie nur seine Unterschrift und fehlt die Unterschrift von Alice.

Alice kann "Bobs Unterschrift akzeptieren, aber ihre eigene zurückhalten". Dies ist vergleichbar mit einem Vertrag, der eine doppelte Unterschrift erfordert. Wenn Bob zuerst unterschreibt und den Vertrag an Alice sendet, kann sie sich dafür entscheiden, ihre Unterschrift nicht zu leisten. Um den Vertrag wirksam zu machen, müsste Alice ihn unterschreiben und dann einreichen. Andernfalls kann sie davon absehen, es zu unterschreiben oder einzureichen. In diesem Fall hat Alice also die Möglichkeit, Bobs Handlungen einzuschränken.

Hier ist der Schlüsselpunkt: Jedes Mal, wenn eine Transaktion innerhalb des Kanals stattfindet, werden ein Paar Verpflichtungstransaktionen generiert, mit zwei gespiegelten Versionen, wie unten dargestellt. Alice und Bob können jeweils Verpflichtungstransaktionen erstellen, die für sie vorteilhaft sind, und ihre jeweiligen Bilanzen oder Beträge festlegen, die beim Verlassen zu erhalten sind, und diese Transaktionen dann zur Bearbeitung aneinander senden.

Interessanterweise unterscheiden sich die beiden Verpflichtungstransaktionen in ihren Rücknahmebedingungen, obwohl sie den gleichen "Betrag, der beim Verlassen erhalten werden soll", erklären. Dies veranschaulicht das Konzept der zuvor erwähnten "asymmetrischen Verpflichtungstransaktionen".

Wie bereits erklärt, erfordert jede Verpflichtungstransaktion eine 2/2 Mehrfachsignatur, um gültig zu sein. Die von Bob erstellte Verpflichtungstransaktion, die ihm selbst zugute kommt, erfüllt nicht die Anforderungen der 2/2 Mehrfachsignatur, während die Verpflichtungstransaktion, die diese Anforderungen erfüllt, von Alice gehalten wird und nur von ihr eingereicht werden kann, um einen Kontroll- und Gleichgewichtsmechanismus zu schaffen. Die gleiche Logik gilt umgekehrt.

Somit können Alice und Bob nur Verpflichtungstransaktionen einreichen, die für sie ungünstig sind. Wenn eine der Parteien eine Verpflichtungstransaktion an die Kette einreicht und diese wirksam wird, wird der Kanal geschlossen.

In Bezug auf das zuvor diskutierte Szenario des „Double-Spendings“ kommt das Konzept der „Widerrufsschlüssel“ ins Spiel, wenn jemand eine veraltete Commitment-Transaktion an die Kette sendet. Wenn Bob beispielsweise die veraltete Tx2 an die Kette sendet, kann Alice den mit Tx2 verbundenen Widerrufsschlüssel verwenden, um die Gelder abzuziehen, die Bob erhalten sollte.

In dem Beispiel-Diagramm, unter der Annahme, dass die neueste Verpflichtungstransaktion Commit Tx3 ist und Tx2 veraltet ist, kann Alice innerhalb des Time-Lock-Zeitraums handeln, indem sie den Widerrufsschlüssel von Tx2 verwendet, um Bobs Geld abzuheben, wenn Bob das veraltete Tx2 einreicht.

In Bezug auf das neueste Tx3 besitzt Alice keinen Rücknahmeschlüssel und wird diesen erst erhalten, nachdem Tx4 in der Zukunft erstellt wurde. Dies liegt an der Natur der Public/Private-Key-Kryptographie und der UTXO-Eigenschaften. Zur Kürze werden hier keine Implementierungsdetails von Rücknahmeschlüsseln erörtert.

Der wichtigste Punkt ist, dass wenn Bob es wagt, eine veraltete Verpflichtungstransaktion an die Kette zu übermitteln, kann Alice den Widerrufsschlüssel verwenden, um Bobs Gelder als Strafe abzuziehen. Ebenso kann Bob bei bösartigem Verhalten von Alice dieselbe Strafe gegen sie anwenden. Dieser Mechanismus stellt sicher, dass eins-zu-eins-Zahlungskanäle doppelte Ausgaben effektiv verhindern, da vernünftige Teilnehmer bösartige Handlungen vermeiden würden.

In diesem Kontext bietet Fiber, basierend auf CKB, wesentliche Verbesserungen gegenüber dem Bitcoin Lightning Network. Es unterstützt native Transaktionen und Überweisungen von mehreren Vermögenswerten, einschließlich CKB, BTC und RGB++ Stablecoins, während das Lightning Network nur Bitcoin nativ unterstützt. Selbst mit dem Taproot Asset-Upgrade kann das Bitcoin Lightning Network immer noch keine nicht-BTC-Vermögenswerte nativ unterstützen und kann nur indirekt Stablecoins unterstützen.

(Bildquelle: Dapangdun) Darüber hinaus sind die Gebühren für das Öffnen und Schließen von Kanälen bei Fiber aufgrund der Verwendung von CKB als Layer 1-Hauptkette im Vergleich zum BTC Lightning Network erheblich niedriger. Dies reduziert die Transaktionskosten für den Benutzer und bietet somit einen klaren Vorteil in Bezug auf die Benutzererfahrung (UX).

24/7 Sicherheit: WatchTower

Eine Herausforderung bei Widerrufsschlüsseln besteht darin, dass die Kanalteilnehmer einander ständig überwachen müssen, um die Einreichung veralteter Verpflichtungstransaktionen zu verhindern. Niemand kann jedoch rund um die Uhr online sein, also was passiert, wenn eine Partei böswillig handelt, während die andere offline ist? Sowohl Fiber als auch das Bitcoin Lightning Network beheben dieses Problem mit dem Design von WatchTowers.

WatchTowers sind darauf ausgelegt, rund um die Uhr die On-Chain-Aktivitäten zu überwachen. Wenn jemand eine veraltete Commitment-Transaktion einreicht, wird der WatchTower rechtzeitig Maßnahmen ergreifen, um den Kanal und die Gelder zu schützen. So funktioniert es:

Nachdem Alice oder Bob die veraltete Bindungstransaktion veröffentlicht haben, können sie im Voraus eine entsprechende Straftransaktion vorbereiten (unter Verwendung des Widerrufsschlüssels um die veraltete Bindungstransaktion zu behandeln, wobei der Begünstigte als sie selbst angegeben wird). Anschließend geben sie den Klartext dieser Straftransaktion an den WatchTower.

Wenn der WatchTower feststellt, dass eine veraltete Bestätigungstransaktion an die Kette übermittelt wird, wird er auch die vorbereitete Straftransaktion übermitteln, um die Strafe durchzusetzen und die Integrität des Kanals zu schützen.

Fiber schützt die Privatsphäre der Teilnehmer, indem es Benutzer zwingt, nur den "Hash der veralteten Commitment-Transaktion + Klartext der Penalty-Transaktion" an den WatchTower zu senden. Auf diese Weise kennt der WatchTower zunächst nur den Hash der Commitment-Transaktion, nicht aber ihren Klartext. Der WatchTower sieht den Klartext nur dann, wenn jemand tatsächlich die veraltete Commitment-Transaktion On-Chain einreicht, und wird zu diesem Zeitpunkt auch die Penalty-Transaktion einreichen. Dadurch wird sichergestellt, dass der WatchTower nur dann einen Transaktionsverlauf eines Teilnehmers sieht, wenn tatsächlich Fehlverhalten vorliegt, und selbst dann wird er nur eine einzige Transaktion sehen.

In Bezug auf Optimierung verbessert Fiber den Ansatz des Bitcoin Lightning Network für Strafmechanismen. Der „LN-Penalty“ des Lightning Network hat einen bemerkenswerten Nachteil: WatchTowers müssen alle veralteten Commitment-Transaktions-Hashes und entsprechenden Rücknahmeschlüssel speichern, was zu erheblichem Speicherdruck führt. Im Jahr 2018 schlug die Bitcoin-Community eine Lösung namens „eltoo“ vor, um dieses Problem zu lösen. Eltoo würde es der neuesten Commitment-Transaktion ermöglichen, veraltete Transaktionen zu bestrafen und so die Notwendigkeit zu verringern, alle vorherigen Transaktionen zu speichern. Diese Lösung erfordert jedoch die Aktivierung des SIGHASH_ANYPREVOUT-Opcodes, der noch nicht implementiert wurde.

Fiber hingegen verwendet das Daric-Protokoll, das das Design des Widerrufsschlüssels modifiziert, um einen einzigen Widerrufsschlüssel auf mehrere veraltete Commitment-Transaktionen anwendbar zu machen. Dieser Ansatz reduziert den Speicherbedarf für WatchTowers und Benutzerclients erheblich.

In Bezug auf Netzwerkverkehrssysteme: Zahlungskanäle eignen sich für Transaktionen von einer Partei zur anderen, aber das Lightning-Netzwerk unterstützt Mehrfach-Hop-Zahlungen, die Transaktionen zwischen Parteien ermöglichen, die keine direkte Verbindung haben, indem sie über Zwischenknoten geroutet werden. Wenn zum Beispiel Alice und Ken keine direkte Verbindung haben, Ken und Bob jedoch eine haben, und Bob und Alice auch, kann Bob als Vermittler fungieren, um Transaktionen zwischen Alice und Ken zu ermöglichen.

"Multi-Hop-Routing" verbessert die Netzwerkflexibilität und -abdeckung. Sender müssen jedoch den Status aller öffentlichen Knoten und Kanäle kennen. Bei Fiber ist die gesamte Netzwerkstruktur, einschließlich aller öffentlichen Kanäle, vollständig transparent, sodass jeder Knoten auf Netzwerkinformationen von anderen Knoten zugreifen kann. Da sich der Netzwerkzustand im Lightning-Netzwerk ständig ändert, verwendet Fiber den Dijkstra-Algorithmus, um den kürzesten Routenpfad zu finden, um die Anzahl der Vermittler zu minimieren und einen Transaktionspfad zwischen den beiden Parteien zu etablieren.

Um das Vertrauensproblem mit Intermediären anzugehen: Wie können Sie sicherstellen, dass sie ehrlich sind? Wenn beispielsweise Alice eine Zahlung von 100 Einheiten an Ken leisten muss, kann Bob, der ein Vermittler zwischen ihnen ist, die Mittel zurückhalten. HTLC und PTLC werden eingesetzt, um ein solches bösartiges Verhalten zu verhindern. Angenommen, Alice möchte Daniel 100 Einheiten zahlen, aber sie haben keinen direkten Kanal. Alice findet heraus, dass sie die Zahlung über Vermittler Bob und Carol leiten kann. HTLC wird als Zahlungskanal eingeführt: Alice initiiert zuerst die Anfrage an Daniel, der ihr dann einen Hash r liefert, aber Alice kennt das Pre-Image R, das zu r korrespondiert, nicht.

Dann erstellt Alice die Zahlungsbedingungen mit Bob über HTLC: Alice ist bereit, Bob 102 Einheiten zu zahlen, aber Bob muss den Schlüssel R innerhalb von 30 Minuten offenlegen; sonst wird Alice das Geld abheben. Ebenso erstellt Bob ein HTLC mit Carol: Bob wird Carol 101 Einheiten zahlen, aber Carol muss den Schlüssel R innerhalb von 25 Minuten offenlegen; sonst wird Bob das Geld abheben. Carol macht dasselbe mit Daniel: Carol ist bereit, Daniel 100 Einheiten zu zahlen, aber Daniel muss den Schlüssel R innerhalb von 20 Minuten offenlegen; sonst wird Carol das Geld abheben.

Daniel versteht, dass der von Carol angeforderte Schlüssel R eigentlich das ist, was Alice will, da nur Alice am Wert von R interessiert ist. Also arbeitet Daniel mit Carol zusammen, stellt den Schlüssel R zur Verfügung und erhält 100 Einheiten von Carol. Auf diese Weise erreicht Alice ihr Ziel, Daniel 100 Einheiten zu bezahlen.

Anschließend gibt Carol den Schlüssel R an Bob und erhält 101 Einheiten. Bob gibt dann den Schlüssel R an Alice und erhält 102 Einheiten. Beobachtet man die Gewinne und Verluste für alle, verliert Alice 102 Einheiten, Bob und Carol verdienen jeweils ein Nettoergebnis von 1 Einheit und Daniel erhält 100 Einheiten. Die 1 Einheit, die Bob und Carol verdienen, ist ihre Gebühr, die sie von Alice abgezogen haben.

Auch wenn jemand im Zahlungspfad, wie z.B. Carol, den Schlüssel R nicht an den nachfolgenden Bob weitergeben kann, führt dies nicht zu einem Verlust für Bob: Nach Ablauf der Timeout-Frist kann Bob das von ihm konstruierte HTLC zurückziehen. Das Gleiche gilt für Alice. Allerdings hat das Lightning-Netzwerk seine Probleme: Pfade sollten nicht zu lang sein. Wenn der Pfad mit zu vielen Vermittlern zu lang ist, kann dies die Zuverlässigkeit der Zahlung verringern. Einige Vermittler können offline sein oder über nicht ausreichende Mittel verfügen, um ein bestimmtes HTLC zu konstruieren (z.B. muss jeder Vermittler im vorherigen Beispiel über mehr als 100 Einheiten verfügen). Daher erhöht die Hinzufügung weiterer Vermittler die Wahrscheinlichkeit von Fehlern.

Darüber hinaus können HTLCs die Privatsphäre beeinträchtigen. Obwohl Onion-Routing einen gewissen Datenschutz bieten kann, indem die Routinginformationen bei jedem Hop verschlüsselt werden, sodass jeder Teilnehmer nur seine unmittelbaren Nachbarn und nicht den vollständigen Pfad kennt, sind HTLCs immer noch anfällig für Rückschlüsse auf Beziehungen. Aus einer höheren Perspektive lässt sich noch der komplette Routing-Pfad ableiten.

Angenommen, dass Bob und Daniel von derselben Entität kontrolliert werden und jeden Tag viele HTLCs erhalten. Sie stellen fest, dass der von Alice und Carol angeforderte Schlüssel R immer derselbe ist und dass der nachgelagerte Knoten Eve, der mit Daniel verbunden ist, immer den Inhalt des Schlüssels R kennt. Daher können Daniel und Bob schlussfolgern, dass es einen Zahlungsweg zwischen Alice und Eve gibt, da sie immer mit dem gleichen Schlüssel umgehen und ihre Beziehung überwachen können. Um dies zu lösen, verwendet Fiber PTLCs, die die Privatsphäre über HTLCs verbessern, indem für das Entsperren jedes PTLC im Zahlungspfad verschiedene Schlüssel verwendet werden. Allein durch die Beobachtung von PTLCs können keine Beziehungen zwischen den Knoten bestimmt werden. Durch die Kombination von PTLCs mit Zwiebel-Routing wird Fiber zu einer idealen Lösung für die anonyme Abwicklung von Zahlungen.

Darüber hinaus ist das traditionelle Lightning Network anfällig für einen 'Replacement Cycling Angriff', bei dem Vermögenswerte von Vermittlern im Zahlungsweg gestohlen werden können. Dieses Problem führte dazu, dass der Entwickler Antoine Riard sich aus der Lightning Network Entwicklung zurückzog. Bislang fehlt dem Bitcoin Lightning Network eine grundlegende Lösung für dieses Problem, was es zu einem Schmerzpunkt macht. CKB behebt dieses Angriffsszenario derzeit durch Verbesserungen auf der Transaktionspool-Ebene, die es Fiber ermöglichen, das Problem zu mildern. Da der Replacement Cycling Angriff und seine Lösungen recht komplex sind, wird in diesem Artikel nicht weiter darauf eingegangen. Interessierte Leser können sich für weitere Informationen auf verwandte Artikel von BTCStudy und offizielle CKB-Ressourcen beziehen.

Insgesamt stellt Fiber eine signifikante Verbesserung gegenüber dem traditionellen Lightning Network sowohl in Bezug auf Datenschutz als auch Sicherheitsaspekte dar. Fiber verbessert die atomaren Zahlungen zwischen sich selbst und dem Bitcoin Lightning Network über Domänen hinweg.

Mit HTLC und PTLC kann Fiber mit dem Bitcoin Lightning Network länderübergreifende Zahlungen durchführen und die „Atomizität von länderübergreifenden Aktionen“ gewährleisten, d.h. alle Schritte der länderübergreifenden Transaktion sind entweder vollständig erfolgreich oder vollständig gescheitert, ohne teilweisen Erfolg oder Misserfolg. Mit der gewährleisteten länderübergreifenden Atomizität wird das Risiko eines Vermögensverlustes gemindert. Dies ermöglicht es Fiber, sich mit dem Bitcoin Lightning Network zu verbinden, um direkte Zahlungen von Fiber an Benutzer im BTC Lightning Network (wobei der Empfänger auf BTC beschränkt ist) durchzuführen und die Konvertierung von CK

B und RGB++-Vermögenswerte in äquivalentes Bitcoin innerhalb des BTC Lightning-Netzwerks umwandeln.

Hier ist eine vereinfachte Erklärung des Prozesses: Angenommen, Alice betreibt einen Knoten innerhalb des Fiber-Netzwerks, und Bob betreibt einen Knoten innerhalb des Bitcoin Lightning-Netzwerks. Wenn Alice etwas Geld an Bob überweisen möchte, kann sie dies über einen interdomänen Vermittler namens Ingrid tun. Ingrid wird Knoten in beiden Fiber- und BTC Lightning-Netzwerken ausführen und als Vermittler im Zahlungsweg fungieren.

Wenn Bob 1 BTC erhalten möchte, kann Alice mit Ingrid einen Wechselkurs aushandeln und 1 CKB gleich 1 BTC setzen. Alice würde dann 1,1 CKB innerhalb des Fiber-Netzwerks an Ingrid senden, und Ingrid würde 1 BTC an Bob im Bitcoin Lightning Network senden und 0,1 CKB als Gebühr behalten.

Der Prozess beinhaltet die Einrichtung eines Zahlungspfads zwischen Alice, Ingrid und Bob unter Verwendung von HTLC. Bob muss Ingrid den Schlüssel R zur Verfügung stellen, um die Mittel zu erhalten. Sobald Ingrid den Schlüssel R hat, kann sie die von Alice im HTLC gesperrten Mittel freischalten.

Die kreisübergreifenden Aktionen zwischen dem BTC Lightning Network und Fiber sind atomar, was bedeutet, dass entweder beide HTLCs entsperrt werden und die kreisübergreifende Zahlung erfolgreich ausgeführt wird, oder keiner von beiden entsperrt wird und die Zahlung fehlschlägt. Dies stellt sicher, dass Alice kein Geld verliert, wenn Bob es nicht erhält.

Ingrid könnte möglicherweise Alice's HTLC nicht entsperren, nachdem sie den Schlüssel R kennt, aber das würde Ingrid schaden, nicht Alice. Daher gewährleistet das Design von Fiber die Sicherheit für Benutzer und erfordert kein Vertrauen in Dritte, ermöglicht Überweisungen zwischen verschiedenen P2P-Netzwerken mit minimalen Änderungen.

Weitere Vorteile von Fiber im Vergleich zum BTC Lightning Network

Zuvor haben wir erwähnt, dass Fiber native CKB-Vermögenswerte und RGB++-Vermögenswerte (insbesondere Stablecoins) unterstützt und damit ein erhebliches Potenzial für Echtzeitzahlungen bietet und sich daher gut für tägliche kleine Transaktionen eignet.

Im Gegensatz dazu ist ein großes Problem des Bitcoin-Lightning-Netzwerks das Liquiditätsmanagement. Wie wir am Anfang besprochen haben, ist das Gesamtsaldo in einem Zahlungskanal festgelegt. Wenn das Gleichgewicht einer Partei aufgebraucht ist, kann sie keine Gelder an die andere Partei übertragen, es sei denn, die andere Partei sendet zuerst Geld. Dies erfordert das Wiederaufladen von Mitteln oder das Öffnen eines neuen Kanals.

Darüber hinaus kann in einem komplexen Multi-Hop-Netzwerk, wenn einige Zwischenknoten einen unzureichenden Kontostand haben und Zahlungen nicht weiterleiten können, dies dazu führen, dass der gesamte Zahlungsweg scheitert. Dies ist einer der Schwachpunkte des Lightning-Netzwerks. Die typische Lösung besteht darin, effiziente Mechanismen zur Liquiditätsinjektion bereitzustellen, um sicherzustellen, dass die meisten Knoten bei Bedarf Mittel bereitstellen können.

Im Bitcoin Lightning Network finden jedoch Liquiditätsinjektionen sowie das Öffnen oder Schließen von Kanälen auf der Bitcoin-Blockchain statt. Wenn die Gebühren für das Bitcoin-Netzwerk sehr hoch sind, wirkt sich dies negativ auf die Benutzererfahrung der Zahlungskanäle aus. Wenn Sie beispielsweise einen Kanal mit einer Kapazität von 100 US-Dollar eröffnen möchten, die Einrichtungsgebühr jedoch 10 US-Dollar beträgt, bedeutet dies, dass 10 % Ihres Geldes nur für die Einrichtung des Kanals verbraucht werden, was für die meisten Benutzer inakzeptabel ist. Das Gleiche gilt für die Liquiditätsspritze.

Im Gegensatz dazu bietet Fiber erhebliche Vorteile. Erstens ist die TPS (Transaktionen pro Sekunde) von CKB viel höher als die von Bitcoin, wobei die Gebühren Centebene erreichen. Zweitens plant Fiber, um Liquiditätsengpässe zu beheben und reibungslose Transaktionen zu gewährleisten, mit Mercury Layer zusammenzuarbeiten, um neue Lösungen einzuführen, die die Notwendigkeit von On-Chain-Operationen zur Liquiditätseinspritzung beseitigen und somit UX- und Kostenprobleme lösen.

Wir haben nun die gesamte technische Architektur von Fiber systematisch skizziert und eine Zusammenfassung mit dem Bitcoin Lightning Network wie im obigen Bild gezeigt verglichen. Angesichts der Komplexität und Breite der von Fiber und dem Lightning Network behandelten Themen kann ein einzelner Artikel möglicherweise nicht jeden Aspekt behandeln. Wir werden in Zukunft eine Reihe von Artikeln veröffentlichen, die sich auf verschiedene Aspekte sowohl des Lightning Network als auch von Fiber konzentrieren. Bleiben Sie dran für weitere Updates.

Haftungsausschluss:

1. Dieser Artikel wurde aus [ wiedergegeben极客web3]. Weiterleiten des Originaltitels '系统解读Fiber：把闪电网络嫁接到CKB上的宏大实验'. Alle Urheberrechte liegen beim ursprünglichen Autor [Faust & Nickqiao, Geek web3]. Wenn es Einwände gegen diesen Nachdruck gibt, wenden Sie sich bitte an die Gate LearnTeam, und sie werden es umgehend bearbeiten.
2. Haftungsausschluss: Die Ansichten und Meinungen, die in diesem Artikel zum Ausdruck gebracht werden, 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.