Bitlayer-Kerntechnologie: DLC und ihre Optimierungsbetrachtungen

1. Einführung

Der Discreet Log Contract (DLC) ist ein Vertragsausführungsrahmen, der auf einem Orakel basiert, das von Tadge Dryja des Massachusetts Institute of Technology im Jahr 2018 vorgeschlagen wurde. DLC ermöglicht es zwei Parteien, bedingte Zahlungen auf der Grundlage vordefinierter Bedingungen auszuführen. Die Parteien bestimmen mögliche Ergebnisse, unterschreiben sie vorab und verwenden diese Vorunterschriften, um Zahlungen auszuführen, wenn das Orakel das Ergebnis bestätigt. DLC ermöglicht somit neue dezentralisierte Finanzanwendungen und gewährleistet die Sicherheit von Bitcoin-Einlagen.

Im Vergleich zum Lightning Network hat DLC folgende signifikante Vorteile:

• Datenschutz: DLC bietet einen besseren Datenschutz als das Lightning-Netzwerk. Vertragsdetails werden nur zwischen den beteiligten Parteien geteilt und nicht auf der Blockchain gespeichert. Im Gegensatz dazu werden Lightning-Netzwerktransaktionen über öffentliche Kanäle und Knoten geroutet, wodurch ihre Informationen öffentlich und transparent sind.
• Komplexität und Flexibilität von Finanzverträgen: DLC kann direkt komplexe Finanzverträge im Bitcoin-Netzwerk erstellen und ausführen, wie Derivate, Versicherungen und Wetten, während das Lightning-Netzwerk hauptsächlich für schnelle, geringwertige Zahlungen genutzt wird und keine komplexen Anwendungen unterstützen kann.
• Verringerung des Gegenparteirisikos: DLC-Fonds werden in Multi-Signatur-Verträgen gesperrt und nur freigegeben, wenn das Ergebnis eines vordefinierten Ereignisses eintritt, was das Risiko verringert, dass eine Partei den Vertrag nicht einhält. Obwohl das Lightning-Netzwerk den Bedarf an Vertrauen verringert, birgt es dennoch bestimmte Gegenparteirisiken im Kanalmanagement und der Liquiditätsbereitstellung.
• Keine Notwendigkeit, Zahlungskanäle zu verwalten: DLC-Operationen erfordern nicht die Erstellung oder Aufrechterhaltung von Zahlungskanälen, die für das Lightning-Netzwerk zentral sind und komplexe und ressourcenintensive Verwaltung erfordern.
• Skalierbarkeit für spezifische Anwendungsfälle: Während das Lightning-Netzwerk die Transaktionsdurchsatz von Bitcoin in gewissem Maße erhöht, bietet DLC eine bessere Skalierbarkeit für komplexe Verträge auf Bitcoin.

Obwohl DLCs bedeutende Vorteile im Bitcoin-Ökosystem bieten, gibt es immer noch einige Risiken und Probleme, wie zum Beispiel:

• Hauptgefahr: Es besteht das Risiko eines Lecks oder Verlusts der privaten Schlüssel von Oracle und der verpflichteten Nonces, was zum Verlust von Benutzeranlagen führen kann.
• Zentralisiertes Vertrauensrisiko: Zentralisierung in Oracles kann leicht zu Denial-of-Service-Angriffen führen.
• Dezentrales Schlüsselableitungsproblem: Wenn das Orakel dezentralisiert ist, besitzen die Orakelknoten nur Anteile am privaten Schlüssel. Dezentralisierte Orakelknoten können jedoch BIP32 nicht direkt zur Schlüsselableitung basierend auf diesen privaten Schlüsselanteilen verwenden.
• Kollusionsrisiko: Wenn Orakelknoten untereinander oder mit einer Partei kolludieren, bleibt das Vertrauensproblem bei Orakeln ungelöst. Ein zuverlässiger Überwachungsmechanismus ist erforderlich, um das Vertrauen in Orakel zu minimieren.
• Problem der festen Nennwertänderung: Bedingte Signaturen erfordern eine deterministische, aufzählbare Menge von Ereignissen, bevor der Vertrag zur Konstruktion der Transaktion erstellt wird. Daher führt die Verwendung von DLC für die Vermögensumverteilung zu einer Mindestmengenbeschränkung, die zu dem Problem der festen Nennwertänderung führt.

Um diese zu adressieren, schlägt dieses Papier mehrere Lösungen und Optimierungsideen vor, um die Risiken und Probleme im Zusammenhang mit DLCs zu mildern und so die Sicherheit des Bitcoin-Ökosystems zu verbessern.

2. DLC-Prinzip

Alice und Bob schließen eine Wettvereinbarung darüber ab, ob der Hashwert des (n+k)-ten Blocks ungerade oder gerade ist. Wenn er ungerade ist, gewinnt Alice das Spiel und kann die Vermögenswerte innerhalb der Zeit t abheben; wenn er gerade ist, gewinnt Bob das Spiel und kann die Vermögenswerte innerhalb der Zeit t abheben. Unter Verwendung von DLC wird die Information des (n+k)-ten Blocks über ein Oracle übertragen, um eine bedingte Signatur zu erstellen, die sicherstellt, dass der richtige Gewinner alle Vermögenswerte erhält.

Initialisierung: Der Generator der elliptischen Kurve ist G, und ihre Ordnung ist q.

Schlüsselerzeugung: Das Orakel, Alice und Bob generieren unabhängig voneinander ihre eigenen privaten und öffentlichen Schlüssel.

• Der private Schlüssel des Orakels ist z, und sein öffentlicher Schlüssel ist Z, der die Gleichung Z=z⋅G erfüllt;
• Der private Schlüssel von Alice ist x, und ihr öffentlicher Schlüssel ist X, der die Bedingung X=x⋅G erfüllt;
• Bobs privater Schlüssel ist y, und sein öffentlicher Schlüssel ist Y, der die Bedingung Y=y⋅G erfüllt.

Finanzierungstransaktion: Alice und Bob erstellen gemeinsam eine Finanzierungstransaktion, bei der jeweils 1 BTC in einem 2-aus-2-Multi-Signatur-Output gesperrt wird (ein öffentlicher Schlüssel X gehört zu Alice und der andere Y zu Bob).

Vertragsabschluss-Transaktionen (CET): Alice und Bob erstellen zwei CETs, um die Finanzierungstransaktion auszugeben.

Der Oracle berechnet das Commitment

und berechnet dann S und S′

und überträgt (R, S, S′).

Alice und Bob berechnen jeweils den entsprechenden neuen öffentlichen Schlüssel

Abwicklung: Nachdem der (n+k)-te Block erscheint, generiert das Oracle das entsprechende s oder s′ basierend auf dem Hashwert dieses Blocks.

• Wenn der Hash-Wert des (n+k)-ten Blocks ungerade ist, berechnet und sendet das Oracle

• Wenn der Hash-Wert des (n+k)-ten Blocks gerade ist, berechnet und sendet das Orakel

Abhebung: Entweder Alice oder Bob kann die Vermögenswerte basierend auf dem von der Oracle ausgestrahlten s oder s′ abheben.

• Wenn das Orakel s überträgt, kann Alice den neuen privaten Schlüssel sk^{Alice} berechnen und die gesperrten 2 BTC abheben

• Wenn das Orakel s′ sendet, kann Bob den neuen privaten Schlüssel sk^{Bob} berechnen und die gesperrten 2 BTC abheben

Analyse: Der neue private Schlüssel sk^{Alice}, der von Alice berechnet wurde, und der neue öffentliche Schlüssel PK^{Alice} erfüllen die diskrete Logarithmusbeziehung.

Daher wird Alices Abhebung erfolgreich sein.

Ebenso erfüllen der von Bob berechnete neue private Schlüssel sk^{Bob} und der neue öffentliche Schlüssel PK^{Bob} die diskrete Logarithmusbeziehung.

Daher wird Bobs Abhebung erfolgreich sein.

Darüber hinaus ist es nützlich für Alice, wenn das Oracle s sendet, aber nicht für Bob, da Bob den entsprechenden neuen privaten Schlüssel sk^{Bob} nicht berechnen kann. Ebenso ist es für Bob nützlich, wenn das Oracle s′ sendet, aber nicht für Alice, da Alice den entsprechenden neuen privaten Schlüssel sk^{Alice} nicht berechnen kann. Schließlich fehlt die obige Beschreibung der Zeitverriegelung. Eine Zeitverriegelung muss hinzugefügt werden, um einer Partei zu ermöglichen, den neuen privaten Schlüssel zu berechnen und innerhalb der Zeit t abzuheben. Andernfalls kann die andere Partei bei Überschreitung der Zeit t den ursprünglichen privaten Schlüssel verwenden, um die Vermögenswerte abzuheben.

3. DLC-Optimierungen

3.1 Schlüsselverwaltung

Im DLC-Protokoll sind der private Schlüssel des Orakels und der verpflichtete Nonce entscheidend. Ein Leck oder Verlust des privaten Schlüssels des Orakels und des verpflichteten Nonce kann zu den folgenden vier Sicherheitsproblemen führen:

(1) Oracle verliert den privaten Schlüssel z

Wenn das Oracle seinen privaten Schlüssel verliert, kann das DLC nicht abgewickelt werden, was die Ausführung eines DLC-Rückerstattungsvertrags erforderlich macht. Daher enthält das DLC-Protokoll eine Rückerstattungstransaktion, um die Folgen des Verlusts des privaten Schlüssels des Oracle zu verhindern.

(2) Oracle's Private Key z Leakage

Wenn der private Schlüssel des Orakels durchsickert, sind alle auf diesem privaten Schlüssel basierenden DLCs einem Risiko für betrügerische Abrechnungen ausgesetzt. Ein Angreifer, der den privaten Schlüssel stiehlt, kann jede gewünschte Nachricht signieren und so die vollständige Kontrolle über die Ergebnisse aller zukünftigen Verträge erlangen. Darüber hinaus ist der Angreifer nicht darauf beschränkt, eine einzelne signierte Nachricht auszugeben, sondern kann auch widersprüchliche Nachrichten veröffentlichen, wie z.B. die Signatur, dass der Hash-Wert des (n+k)-ten Blocks sowohl ungerade als auch gerade ist.

(3) Orakels Undichtigkeit oder Wiederverwendung von Nonce k

Wenn das Oracle den Nonce k preisgibt, kann ein Angreifer in der Abrechnungsphase unabhängig davon, ob das Oracle s oder s′ überträgt, den privaten Schlüssel z des Oracles wie folgt berechnen:

Wenn das Orakel den Nonce k wiederverwendet, dann kann ein Angreifer nach zwei Abwicklungen das Gleichungssystem anhand der Rundfunksignaturen des Orakels lösen, um den privaten Schlüssel z des Orakels in einem von vier möglichen Szenarien abzuleiten,

Fall 1:

Fall 2:

Fall 3:

Fall 4:

(4) Oracle Verliert Nonce k

Wenn das Oracle den Zufallswert k verliert, kann das entsprechende DLC nicht abgewickelt werden, was die Ausführung eines DLC-Rückerstattungsvertrags erforderlich macht.

Daher ist es ratsam, zur Erhöhung der Sicherheit des privaten Schlüssels des Orakels BIP32 zu verwenden, um Kind- oder Enkelknoten zum Signieren abzuleiten. Darüber hinaus sollte zur Erhöhung der Sicherheit des Nonce der Hashwert k:=hash(z, counter) als Nonce k verwendet werden, um Wiederholungen oder Verlust des Nonce zu verhindern.

3.2 Dezentralisierter Oracle

In DLC ist die Rolle des Orakels entscheidend, da es wichtige externe Daten bereitstellt, die das Ergebnis des Vertrags bestimmen. Zur Verbesserung der Sicherheit dieser Verträge sind dezentralisierte Orakel erforderlich. Im Gegensatz zu zentralisierten Orakeln verteilen dezentralisierte Orakel die Verantwortung für die Bereitstellung genauer und manipulationssicherer Daten auf mehrere unabhängige Knoten, wodurch das Risiko eines einzelnen Ausfallpunkts verringert und die Wahrscheinlichkeit von Manipulationen oder gezielten Angriffen verringert wird. Mit einem dezentralen Orakel können DLCs ein höheres Maß an Vertrauenslosigkeit und Zuverlässigkeit erreichen und sicherstellen, dass die Vertragserfüllung ausschließlich auf der Objektivität vorbestimmter Bedingungen beruht.

Schnorr-Schwellensignaturen können verwendet werden, um dezentrale Orakel zu implementieren. Schnorr-Schwellensignaturen bieten folgende Vorteile:

• Erhöhte Sicherheit: Durch die Verteilung des Schlüsselmanagements reduzieren Schwellwertsignaturen das Risiko von einzelnen Ausfallpunkten. Selbst wenn die Schlüssel einiger Teilnehmer kompromittiert oder angegriffen werden, bleibt das gesamte System sicher, solange der Verstoß keinen vordefinierten Schwellenwert überschreitet.
• Verteilte Kontrolle: Schwellwertsigaturen ermöglichen eine verteilte Kontrolle über das Schlüsselmanagement, wodurch vermieden wird, dass eine einzige Entität alle Signaturbefugnisse innehat, was die mit der Machtkonzentration verbundenen Risiken reduziert.
• Verbesserte Verfügbarkeit: Signaturen können abgeschlossen werden, solange eine bestimmte Anzahl von Oracle-Knoten zustimmt, was die Flexibilität und Verfügbarkeit des Systems erhöht. Selbst wenn einige Knoten nicht verfügbar sind, wird die Gesamtzuverlässigkeit des Systems nicht beeinträchtigt.
• Flexibilität und Skalierbarkeit: Das Threshold-Signaturprotokoll kann bei Bedarf verschiedene Schwellenwerte festlegen, um verschiedenen Sicherheitsanforderungen und Szenarien gerecht zu werden. Darüber hinaus ist es für große Netzwerke geeignet und bietet eine gute Skalierbarkeit.
• Rechenschaftspflicht: Jeder Oracle-Knoten generiert einen Signaturschlüsselanteil basierend auf seinem privaten Schlüsselanteil, und andere Teilnehmer können die Korrektheit dieses Signaturschlüsselanteils mithilfe des entsprechenden öffentlichen Schlüsselanteils überprüfen, was Rechenschaftspflicht ermöglicht. Wenn korrekt, werden diese Signaturschlüsselanteile akkumuliert, um eine vollständige Signatur zu erzeugen.

Daher hat das Schnorr-Schwellensignatur-Protokoll erhebliche Vorteile in dezentralen Orakeln hinsichtlich Verbesserung der Sicherheit, Zuverlässigkeit, Flexibilität, Skalierbarkeit und Rechenschaftspflicht.

3.3 Kopplung von Dezentralisierung und Schlüsselverwaltung

In der Schlüsselverwaltungstechnologie besitzt ein Oracle einen vollständigen Schlüssel z und kann mithilfe von BIP32 und Inkrementen ω eine Vielzahl von Kinderschlüsseln z+ω^{(1)} und Enkelkinderschlüsseln z+ω^{(1)}+ω^{(2)} ableiten. Für verschiedene Ereignisse kann das Oracle verschiedene Enkel-Privatschlüssel z+ω^{(1)}+ω^{(2)} verwenden, um entsprechende Signaturen σ für die jeweiligen Ereignisse msg zu generieren.

In dem Szenario des dezentralen Orakels gibt es n Teilnehmer und eine Schwellensignatur erfordert t+1 Teilnehmer, wobei t

In einem dezentralen Oracle-Szenario erscheint der vollständige private Schlüssel z jedoch nicht, und daher ist eine direkte Schlüsselableitung mit BIP32 nicht möglich. Mit anderen Worten, dezentrale Oracle-Technologie und Schlüsselverwaltungstechnologie können nicht direkt integriert werden.

Das Papier „Verteilte Schlüsselableitung für das Multi-Party-Management von Blockchain-Digitalanlagen„schlägt ein verteiltes Schlüsselableitungsschema in Schwellwertszenarien vor. Die Kernidee basiert auf Lagrange-Interpolationspolynomen, bei denen das private Schlüsselteilz_i und der vollständige private Schlüssel z die folgende Interpolationsbeziehung erfüllen:

Wenn man das Inkrement ω zu beiden Seiten der Gleichung hinzufügt, ergibt sich:

Diese Gleichung zeigt, dass der private Schlüsselanteil z_i plus die Inkrement ω immer noch die Interpolationsbeziehung mit dem vollständigen privaten Schlüssel z plus ω erfüllt. Mit anderen Worten, der Kind-Private-Schlüsselanteil z_i+ω und der Kind-Schlüssel z+ω erfüllen die Interpolationsbeziehung. Daher kann jeder Teilnehmer seinen privaten Schlüsselanteil z_i plus das Inkrement ω verwenden, um den Kind-Privatschlüsselanteil z_i+ω abzuleiten, der verwendet wird, um Kind-Signaturanteile zu generieren, und sie mit dem entsprechenden Kind-öffentlichen Schlüssel Z+ω⋅G validieren.

Allerdings muss man gehärtete und nicht gehärtete BIP32 in Betracht ziehen. Gehärtetes BIP32 nimmt den privaten Schlüssel, den Kettencode und den Pfad als Eingabe, führt SHA512 durch und gibt den Inkrement und den Kind-Kettencode aus. Nicht gehärtetes BIP32 hingegen nimmt den öffentlichen Schlüssel, den Kettencode und den Pfad als Eingabe, führt SHA512 durch und gibt das Inkrement und den Kind-Kettencode aus. In einem Schwellenwertszenario für Signaturen existiert der private Schlüssel nicht, daher kann nur nicht gehärtetes BIP32 verwendet werden. Oder es kann eine homomorphe Hashfunktion verwendet werden, um gehärtetes BIP32 anzuwenden. Eine homomorphe Hashfunktion unterscheidet sich jedoch von SHA512 und ist nicht kompatibel mit dem ursprünglichen BIP32.

3.4 OP-DLC: Oracle Trust-minimized

Im DLC wird der Vertrag zwischen Alice und Bob auf Grundlage des vom Oracle unterzeichneten Ergebnisses ausgeführt, was ein gewisses Maß an Vertrauen in den Oracle erfordert. Daher ist das korrekte Verhalten des Oracle eine wichtige Voraussetzung für den Betrieb des DLC.

Um das Vertrauen in das Orakel zu verringern, wurden Untersuchungen zur Durchführung von DLC basierend auf den Ergebnissen von n Orakeln durchgeführt, um die Abhängigkeit von einem einzigen Orakel zu verringern.

• Das „n-von-n“-Modell beinhaltet die Verwendung von n Oracles zum Unterzeichnen des Vertrags und zur Ausführung des Vertrags basierend auf den Ergebnissen aller Oracles. Bei diesem Modell müssen alle Oracles online sein, um zu unterzeichnen. Wenn ein Oracle offline geht oder es Uneinigkeiten über die Ergebnisse gibt, beeinflusst dies die Ausführung des DLC-Vertrags. Die Vertrauensannahme hierbei ist, dass alle Oracles ehrlich sind.
• Das „k-of-n“-Modell beinhaltet die Verwendung von n Orakeln zur Unterzeichnung des Vertrags und zur Ausführung des Vertrags basierend auf den Ergebnissen von mindestens k Orakeln. Wenn mehr als k Orakel gemeinsame Sache machen, beeinflusst dies die faire Ausführung des Vertrags. Darüber hinaus ist die Anzahl der für das „k-of-n“-Modell erforderlichen CETs C_n^k-mal größer als die eines einzelnen Orakels oder des „n-of-n“-Modells. Die Vertrauensannahme in diesem Modell ist, dass mindestens k der n Orakel ehrlich sind.

Das bloße Erhöhen der Anzahl von Orakeln führt nicht zu einem Misstrauen gegenüber den Orakeln, da die geschädigte Partei im Vertrag nach bösartigen Handlungen eines Orakels keine Möglichkeit der On-Chain-Beschwerde hat.

Daher schlagen wir OP-DLC vor, das einen optimistischen Herausforderungsmechanismus in DLC integriert. Bevor Orakel an der Einrichtung des DLC teilnehmen, müssen sie sich verpflichten und ein erlaubnisloses On-Chain-OP-Spiel im Voraus aufbauen, wobei sie sich verpflichten, nicht bösartig zu handeln. Wenn ein Orakel bösartig handelt, können Alice, Bob, ein anderes ehrliches Orakel oder ein anderer unabhängiger ehrlicher Beobachter eine Herausforderung initiieren. Wenn der Herausforderer das Spiel gewinnt, bestraft das On-Chain-System das bösartige Orakel, indem es seine Einzahlung verwirkt. Darüber hinaus kann OP-DLC auch das „k-von-n“-Modell für das Signieren übernehmen, wobei der k-Wert sogar 1 sein kann. Daher wird die Vertrauensannahme auf nur einen ehrlichen Teilnehmer im Netzwerk reduziert, um eine OP-Herausforderung zu initiieren und ein bösartiges Orakelknoten zu bestrafen.

Beim Abwickeln von OP-DLC basierend auf den Ergebnissen der Layer 2-Berechnung:

• Wenn ein Oracle mit falschen Ergebnissen signiert, was dazu führt, dass Alice einen Verlust erleidet, kann Alice die korrekten Layer 2-Berechnungsergebnisse verwenden, um das Oracle's im Voraus zugesagte permissionless On-Chain-OP-Spiel herauszufordern. Wenn sie das Spiel gewinnt, kann Alice das bösartige Oracle bestrafen und ihren Verlust ausgleichen.
• Ebenso können Bob, andere ehrliche Oracle-Knoten und unabhängige ehrliche Beobachter Herausforderungen initiieren. Um jedoch bösartige Herausforderungen zu verhindern, muss der Herausforderer auch eine Zusicherung abgeben.

Daher erleichtert OP-DLC die gegenseitige Überwachung zwischen Oracle-Knoten, minimiert das Vertrauen in Orakel. Dieser Mechanismus erfordert nur einen ehrlichen Teilnehmer und hat eine Fehlertoleranz von 99%, wodurch das Risiko einer Orakelkollusion effektiv angegangen wird.

3.5 OP-DLC + BitVM Dual Bridge

Wenn DLC für Cross-Chain-Brücken verwendet wird, muss die Mittelverteilung bei der Abwicklung des DLC-Vertrags erfolgen:

• Es erfordert eine Voreinstellung über CETs, was bedeutet, dass die Fondsabrechnungsgranularität von DLC begrenzt ist, wie z.B. 0.1 BTC im Bison-Netzwerk. Dies wirft ein Problem auf: Layer 2-Vermögensinteraktionen für Benutzer sollten nicht durch die Fondsgranularität von DLC CETs eingeschränkt sein.
• Wenn Alice ihre Layer 2-Vermögenswerte abwickeln möchte, zwingt dies auch zur Abwicklung der Layer 2-Vermögenswerte des Benutzers Bob auf Layer 1. Dies wirft ein Problem auf: Jeder Layer 2-Benutzer sollte die Freiheit haben, ihre Ein- und Auszahlungen unabhängig von den Handlungen anderer Benutzer zu wählen.
• Alice und Bob verhandeln über Ausgaben. Das Problem hierbei ist, dass es erfordert, dass beide Parteien bereit sind, zusammenzuarbeiten.

Daher schlagen wir zur Lösung des oben genannten Problems die OP-DLC + BitVM Dual Bridge vor. Diese Lösung ermöglicht es den Benutzern, über die permissionless Bridge von BitVM sowie über den OP-DLC-Mechanismus Ein- und Auszahlungen vorzunehmen, um Änderungen in beliebiger Granularität zu erreichen und die Liquidität zu erhöhen.

Im OP-DLC ist das Oracle die BitVM-Föderation, mit Alice als regulärer Benutzer und Bob als BitVM-Föderation. Beim Einrichten von OP-DLC ermöglichen die gebauten CETs sofortige Ausgaben von Alice's Output auf Layer 1, während Bob's Output ein „DLC-Spiel, in dem Alice herausgefordert werden kann“, mit einer Timelock-Periode enthält. Wenn Alice abheben möchte:

• Wenn die BitVM-Föderation, die als Oracle fungiert, richtig unterschreibt, kann Alice auf Layer 1 abheben. Bob kann jedoch nach Ablauf der Sperrfrist auf Layer 1 abheben.
• Wenn die BitVM-Föderation, die als Orakel fungiert, betrügt und Alice einen Verlust verursacht, kann sie die UTXO von Bob herausfordern. Wenn die Herausforderung erfolgreich ist, kann der Betrag von Bob verwirkt werden. Hinweis: Ein anderes Mitglied der BitVM-Föderation kann auch die Herausforderung initiieren, aber Alice, als die geschädigte Partei, ist am motiviertesten, dies zu tun.
• Wenn die BitVM-Föderation, die als Oracle fungiert, betrügt und Bob, ein ehrliches Mitglied der BitVM-Föderation, einen Verlust verursacht, kann die "BitVM-Spiel"-Herausforderung gestellt werden, um den betrügerischen Oracle-Knoten zu bestrafen.

Darüber hinaus kann Benutzer Alice, wenn sie sich aus Layer 2 abmelden möchte, aber die voreingestellten CETs im OP-DLC-Vertrag nicht mit dem Betrag übereinstimmen, die folgenden Methoden wählen:

• Ziehen Sie sich über BitVM zurück, wobei der BitVM-Betreiber den Betrag auf Layer 1 vorschießt. Die BitVM-Brücke geht davon aus, dass es mindestens einen ehrlichen Teilnehmer im BitVM-Verband gibt.
• Ziehen Sie sich über ein bestimmtes CET in OP-DLC zurück, wobei der verbleibende Wechsel vom BitVM-Betreiber auf Layer 1 bereitgestellt wird. Ein Rückzug über OP-DLC schließt den DLC-Kanal, aber die verbleibenden Gelder im DLC-Kanal werden in den BitVM Layer 1-Pool verschoben, ohne andere Layer 2-Benutzer zum Abheben zu zwingen. Die OP-DLC-Brücke geht davon aus, dass es mindestens einen ehrlichen Teilnehmer im Kanal gibt.
• Alice und Bob verhandeln über Ausgaben ohne die Beteiligung eines Orakels und erfordern die Zusammenarbeit von Bob.

Daher bietet die OP-DLC + BitVM Dual Bridge folgende Vorteile:

• BitVM löst das Änderungsproblem des DLC-Kanals, reduziert die Anzahl der erforderlichen CETs und ist unbeeinflusst von der CET-Fondsgenauigkeit;
• Durch die Kombination der OP-DLC-Brücke mit der BitVM-Brücke bietet es den Benutzern mehrere Kanäle für Einzahlungen und Abhebungen und verbessert so die Benutzererfahrung;
• Die Einrichtung des BitVM-Konsortiums sowohl als Bob als auch als das Orakel und die Nutzung des OP-Mechanismus minimieren das Vertrauen in das Orakel;
• Die Integration des überschüssigen Abzugs aus dem DLC-Kanal in den BitVM-Brückenpool verbessert die Mittelverwendung.

4. Schluss

DLC entstand vor der Aktivierung von Segwit v1 (Taproot) und wurde bereits in das Lightning-Netzwerk integriert, was die Erweiterung von DLC ermöglicht, um fortlaufende Verträge innerhalb desselben DLC-Kanals zu aktualisieren und auszuführen. Mit Technologien wie Taproot und BitVM können komplexere Off-Chain-Vertragsverifizierungen und -abwicklungen innerhalb von DLC implementiert werden. Darüber hinaus ist es durch die Integration des OP-Herausforderungsmechanismus möglich, das Vertrauen in Oracles zu minimieren.

Aussage:

1. Dieser Artikel wurde ausgedruckt von mittel, ursprünglich mit dem Titel „Bitlayer Core Technology: DLC und dessen Optimierungsbetrachtungen“. Das Urheberrecht gehört dem Originalautor, Bitlayer. Wenn es Einwände gegen diesen Nachdruck gibt, wenden Sie sich bitte an den Gate Learn TeamDas Team wird es gemäß den relevanten Verfahren so schnell wie möglich bearbeiten.

2. Haftungsausschluss: Die Ansichten und Meinungen, die in diesem Artikel zum Ausdruck gebracht werden, repräsentieren nur die persönlichen Ansichten des Autors und stellen keine Anlageberatung dar.

3. Andere Sprachversionen des Artikels wurden vom Gate Learn-Team übersetzt. Ohne Erwähnung von Gate.com, die übersetzten Artikel dürfen nicht kopiert, verbreitet oder plagiiert werden.