Autor: mutourend & lynndell, Bitlayer Research Group

1. Einleitung

Discreet Log Contract (DLC) ist ein Oracle-basiertes Vertragsausführungs-Framework, das 2018 von Tadge Dryja vom MIT vorgeschlagen wurde. DLC ermöglicht es zwei Parteien, bedingte Zahlungen basierend auf vordefinierten Bedingungen zu leisten. Beide Parteien bestimmen und unterzeichnen die möglichen Ergebnisse im Voraus und verwenden diese Vorsignaturen, um die Zahlung auszuführen, wenn das Orakel die Ergebnisse unterzeichnet. Daher ermöglicht DLC neue dezentrale Finanzanwendungen und gewährleistet gleichzeitig die Sicherheit von Bitcoin-Einzahlungen.

Der vorherige Artikel „Analyse der DLC-Prinzipien und Optimierungsgedanken“ fasste die Vorteile von DLC in Bezug auf Datenschutz, komplexe Verträge und geringes Vermögensrisiko zusammen und analysierte auch das Vorhandensein von Schlüsselrisiken, dezentralen Vertrauensrisiken, Absprachenrisiken usw DLC.-Probleme und führen Sie dezentrale Orakel, Schwellenwertsignaturen, optimistische Herausforderungsmechanismen usw. in DLC ein, um verschiedene Probleme zu lösen, mit denen es konfrontiert sein sollte. Da an DLC drei Parteien beteiligt sind: das Orakel, Alice und Bob, ist es für verschiedene Parteien relativ komplex, gemeinsam einen umfassenden Angriff durchzuführen, was zu einer relativ komplexen Präventionsstrategie führt. Komplexe Verteidigungsstrategien sind nicht perfekt, entsprechen nicht dem Prinzip der Einfachheit und es fehlt ihnen die Schönheit der Einfachheit.

Bei Bitcoin muss jedes Verhalten eines Teilnehmers über UTXO umgesetzt werden. Daher kann die Verwendung eines Konsensmechanismus, um sicherzustellen, dass UTXO korrekt ist, willkürlichen Angriffen widerstehen. Ebenso muss bei DLC jedes Verhalten eines Teilnehmers durch CET (Contract Execution Transaction) umgesetzt werden. Daher kann die Verwendung eines optimistischen Herausforderungsmechanismus, um sicherzustellen, dass CET korrekt ist, willkürlichen Angriffen widerstehen. Konkret kann das Orakel CET signieren, nachdem es 2 BTC zugesagt hat. Fügen Sie CET einen optimistischen Herausforderungsmechanismus hinzu. Wenn CET nicht angefochten wird oder die Anfechtung erfolgreich gemeistert wird, CET korrekt ist und die Abrechnung abgeschlossen werden kann und das Orakel keine Einsätze macht und Bearbeitungsgebühren erhält, wenn das Orakel versucht, Böses zu tun, kann jeder erfolgreich Anfechtung leisten, das CET wird nicht erfolgen abgerechnet, und das Orakel wird verlieren. Die Anzahlung ist verpfändet und das Orakel kann dieselbe CET nicht erneut unterzeichnen. Im Einklang mit der großen Einfachheit besitzt es die Schönheit der Einfachheit.

2.DLC-Prinzip

Alice und Bob unterzeichnen eine Wettvereinbarung: Sie wetten darauf, dass der Hashwert des ξ-ten Blocks eine ungerade oder gerade Zahl ist. Wenn es eine ungerade Zahl ist, gewinnt Alice das Spiel und kann das Guthaben abheben; ist es eine gerade Zahl, gewinnt Bob das Spiel und kann das Guthaben abheben. Mithilfe von DLC werden die Informationen des ξ-ten Blocks durch das Orakel geleitet, um eine bedingte Signatur zu erstellen, sodass der richtige Gewinner alle Vermögenswerte gewinnt.

Der Generator der elliptischen Kurve ist G und die Ordnung ist q. Die Schlüsselpaare des Orakels, Alice und Bob, sind (z, Z), (x, X), (y, Y).

Kapitalinjektionstransaktion (on-chain): Alice und Bob erstellen gemeinsam eine Kapitalinjektionstransaktion, wobei jeder 10 BTC in einer 2-aus-2-Mehrfachsignaturausgabe sperrt (ein öffentlicher Schlüssel X gehört Alice und ein öffentlicher Schlüssel Y gehört zu Alice). Bob).

Aufbau von CET (Off-Chain): Alice und Bob erstellen CET1 und CET2 für Ausgabenfinanzierungstransaktionen.

Das Orakel berechnet die Verpflichtung R = k · G und berechnet dann S und S'

S := R - Hash(UngeradeZahl, R) · Z

S' := R - Hash(GeradeZahl, R) · Z

Dann lauten die neuen öffentlichen Schlüssel, die Alice und Bob entsprechen, wie folgt:

PK^{Alice} := X + S

PK^{Bob} := Y + S'.

Abrechnung (Off-Chain -> On-Chain): Wenn der ξ-te Block erfolgreich generiert wurde, signiert das Orakel den entsprechenden CET1 oder CET2 basierend auf dem Hash-Wert des Blocks.

Wenn der Hash ungerade ist, signiert das Orakel s wie folgt

s := k - hash(UngeradeZahl, R) z

Ausstrahlung MEZ1.

Wenn der Hash gerade ist, signiert das Orakel s'

s' := k - hash(GeradeZahl, R) z

Übertragung CET2.

Münzen abheben (on-chain): Wenn das Orakel CET1 sendet, kann Alice den neuen privaten Schlüssel berechnen und die gesperrten 20 BTC ausgeben

sk^{Alice} = x + s

Wenn das Orakel CET2 sendet, kann Bob den neuen privaten Schlüssel berechnen und die gesperrten 20 BTC ausgeben

sk^{Bob} = y + s'

Das Bitlayer-Forschungsteam stellte fest, dass im oben genannten Prozess jedes Verhalten durch CET implementiert werden muss. Daher muss nur der optimistische Herausforderungsmechanismus verwendet werden, um sicherzustellen, dass CET korrekt ist und jedem Angriff widerstehen kann. Falsche CETs werden angefochten und nicht ausgeführt, während korrekte CETs ausgeführt werden. Darüber hinaus muss das Orakel einen Preis für böswilliges Verhalten zahlen.

Das herauszufordernde Programm ist f(t), dann sollte CET wie folgt aufgebaut sein

s = k - Hash(f(t), R) z.

Angenommen, die reale Situation ist, dass der Hash-Wert des ξ-ten Blocks eine ungerade Zahl ist, d. h. f(ξ) = OddNumber, und das Orakel sollte CET1 signieren

s := k - Hash(ungeradeZahl, R) z.

Das Orakel hat jedoch etwas Böses getan und den Funktionswert in „Even“ geändert und CET2 signiert:

s' := k - hash(GeradeZahl, R) z.

Daher kann jeder Benutzer dieses bösartige Verhalten gemäß f(ξ) ≠ OddNumber besiegen.

3.OP-DLC 2

OP-DLC umfasst die folgenden 5 Bestimmungen:

• Das Orakel besteht aus einer Koalition. Die Koalition besteht aus n Mitgliedern, und jedes Mitglied kann CET unterzeichnen. Nur durch die Verpfändung von 2 BTC kann die Oracle-Maschine Signaturen ausstellen und Bearbeitungsgebühren verdienen. Wenn ein Mitglied Böses tut, ist der Einsatz verloren. Andere Mitglieder können weiterhin CET unterzeichnen, um sicherzustellen, dass Benutzer Geld abheben können. Alice und Bob können auch zu Orakeln werden, die wirklich nur sich selbst vertrauen und das Vertrauen minimieren.

• Wenn das Orakel Böses tut und das Ergebnis verändert, wird es unweigerlich zu der Situation f1(ξ) ≠ z1, f2(z1) ≠ z2 führen. Daher kann jeder Teilnehmer eine Challenge initiieren, also eine Disprove-CET1-Transaktion durchführen.

• Wenn das Orakel CET ehrlich unterzeichnet, kann keine Partei eine gültige Disprove-Transaktion initiieren. Nach 1 Woche MEZ kann korrekt abgerechnet werden. Darüber hinaus erhält die Orakelmaschine eine Belohnung von 0,05 BTC als einwöchige Kapitalbesetzung ihrer zugesagten 2 BTC und die Bearbeitungsgebühr für die ehrliche Unterzeichnung von CET.

• Jeder Teilnehmer kann Oracle_sign herausfordern:

  • Wenn Oracle_sign ehrlich ist, kann die Disprove-CET1-Transaktion nicht initiiert werden und die CET-Abwicklung wird nach einer Woche ausgeführt. Darüber hinaus ist die Orakelmaschine verpflichtet, Bearbeitungsgebühren zu entsperren und zu erhalten;

  • Wenn Oracle_sign unehrlich ist, das heißt, jemand hat die Disprove-CET1-Transaktion erfolgreich initiiert und die Ausgabe von Connector A erfolgreich ausgegeben, ist die Signatur des Oracle ungültig und die verpfändeten 2BTC gehen verloren und das Oracle kann nicht mehr verwendet werden Wenn eine Signatur mit dem gleichen Ergebnis initiiert wird, wird Settle-CET1, das auf dem Ausgang von Connector A basiert, dauerhaft ungültig.

• Die Herausforderungen im OP-DLC sind erlaubnisfrei, das heißt, jeder Teilnehmer kann überwachen, ob der Vertrag im OP-DLC korrekt ausgeführt wird. Daher wird das Vertrauen in das Orakel minimiert. Im Vergleich zum Lightning Network können Alice und Bob auch offline sein. Denn das Orakel wird CET nur mit ehrlichen Unterschriften regeln, und böse Orakel werden von jedem herausgefordert und bestraft.

Vorteil:

• Hohes Maß an Kontrolle über Vermögenswerte und nur Vertrauen in sich selbst: Alice und Bob können beide Orakel werden und CET unterzeichnen. Der optimistische Herausforderungsmechanismus wird das falsche CET besiegen, sodass kein Böses getan werden kann. Daher ermöglicht OP-DLC den Benutzern, nur an sich selbst zu glauben. Bei BitVM müssen Benutzer als Betreiber fungieren und an allen nachfolgenden Einzahlungen teilnehmen, um nur sich selbst zu vertrauen. Wenn ein Benutzer als Betreiber nur an einer einzigen UTXO-Einzahlung in BitVM beteiligt ist und die UTXO von jedem anderen (n-1) Betreiber rechtmäßig erstattet werden kann, muss der Benutzer weiterhin anderen Betreibern vertrauen, um in Zukunft Gelder vorzustrecken. Die Erstattungsberechtigungen des BitVM-Betreibers sind für jede einzelne UTXO-Einzahlung gesperrt.

• Hohe Kapitalauslastung: Wenn Benutzer nur sich selbst vertrauen, ist die Höhe der erforderlichen Mittel unterschiedlich. Bei OP-DLC verlassen sich Benutzer auf ihre eigenen Abhebungen und müssen nicht den gleichen Betrag vorstrecken. Bei BitVM müssen Benutzer den gleichen Betrag vorweisen und dann eine Rückerstattung erhalten. Dies bringt einen größeren finanziellen Druck mit sich.

• Das Orakel, das unterschreiben kann, muss bei der Einzahlung in OP-DLC festgelegt werden, aber der Benutzer kann auch selbst zum Orakel werden und unterschreiben.

Mangel:

• Die Auszahlungszeit beträgt 1 Woche: Im Wesentlichen bestehen die Kapitalzeitkosten von OP-DLC und BitVM und sind gleich. OP-DLC-Abhebungen müssen eine Anfechtungsfrist durchlaufen, bevor Gelder erhalten werden können. Wenn BitVM darauf angewiesen ist, dass Benutzer selbst Vorschüsse leisten, muss derselbe Betrag an vorgezogenen Mitteln ebenfalls eine Anfechtungsfrist durchlaufen, bevor sie erfolgreich erstattet werden können. Wenn BitVM bei schnellen Abhebungen auf andere Betreiber angewiesen ist, bedeutet dies, dass der Betreiber den gleichen Betrag an Geld- und Zeitkosten wie Bearbeitungsgebühren zahlen muss.

• Die Zahl der Unterschriften, die eine Vorabsignierung erfordern, wächst rasant und steht in linearem Zusammenhang mit der Zahl der CETs. Es werden so viele CETs wie möglich benötigt, um alle Auszahlungsergebnisse aufzulisten.

4. Fazit

OP-DLC führt den optimistischen Challenge-Mechanismus in CET ein, um sicherzustellen, dass kein falsches CET abgewickelt wird und das entsprechende böswillige Orakel sein Pfand verliert. Diese Methode widersteht jedem Angriff und hat den Charme ihrer Einfachheit.

Verweise

1. Spezifikation für diskrete Protokollverträge

2. Discreet Log-Verträge

3. Überlegungen zur Analyse und Optimierung des DLC-Prinzips

4. Optimistisches Rollup

5. BitVM 2: Erlaubnisfreie Verifizierung bei Bitcoin