Diskrete Log-Verträge bringen private Smart-Verträge zu Bitcoin

„Republikanischer_Gewinner“; „Demokratischer_Gewinner“. Dies sind die Parameter (und Aufruffunktionen) für die erste intelligente Vertragshinterlegungswette, die im Hauptnetz von Bitcoin platziert wird.

Am 8. September gingen BTCPay-Server-Gründer Nicolas Dorier und Suredbits-Gründer Chris Stewart die Wette auf den Ausgang der US-Präsidentschaftswahlen 2020 mit einem diskreten Protokollvertrag (Discrete Log Contract, DSL) ein.

Diese Form eines intelligenten Vertrags wurde erst in diesem Jahr auf Bitcoin möglich, dank der technischen Fortschritte des unabhängigen Bitcoin-Entwicklers Lloyd Fournier im Bereich der so genannten „skriptlosen Skripte“ auf der Bitcoin-Blockkette.

Wer auf welcher Seite der Wette stand, haben Dorier und Stewart nicht gesagt. Selbst nach dem Wahltag, wenn die Stimmen ausgezählt sind, werden wir immer noch nicht wissen, wer die Wette gewonnen hat. Und genau das ist der springende Punkt.

Andernfalls wären die Verträge nicht diskret.

Was sind diskrete Protokollverträge?

Die vom Entwickler Gert-Jaap Glasbergen als „unsichtbare intelligente Verträge“ bezeichneten diskreten Log-Verträge sind so strukturiert, dass sie wie Standardtransaktionen mit mehreren Unterschriften in der Blockkette von Bitcoin aussehen.

Wenn jemand nach der Transaktion im Logbuch suchen würde, hätte er keine Möglichkeit, zu wissen, dass es sich um einen intelligenten Vertrag oder, im Fall von Dorier und Stewart, um die Details der Wette handelt.

Diese intelligenten Verträge sind seit der Gründung von Bitcoin theoretisch durchführbar, aber die bahnbrechende Arbeit mit ECDSA-Adapter-Signaturen (ein kryptographisches Signaturschema, das es „skriptlosen Skripten“ ermöglicht, intelligente Verträge auszuführen, ohne auf die Skriptsprache von Bitcoin angewiesen zu sein) im vergangenen Jahr hat sie von der Theorie zur Anwendung gebracht.

„Technisch gesehen hätten DLCs seit der ursprünglichen Veröffentlichung durchgeführt werden können, aber viele der Bausteine waren damals noch nicht bekannt. Zum Beispiel verwenden wir für DLCs ECDSA-Adapter-Signaturen, deren Anwendung für diesen Anwendungsfall erst in diesem Jahr [von Lloyd Fournier] entdeckt wurde“, sagte Suredbits-Entwickler Ben Carman gegenüber CoinDesk.

Suredbits ist zusammen mit Crypto Garage, Atomic Loans, dem von Square Crypto finanzierten unabhängigen Entwickler Loyd Fornier und dem Entwickler von Chaincode Labs, Antoine Riard, einer der Hauptakteure bei der DLC-Entwicklung.

Die Struktur einer DLC-Transaktion ist ziemlich unkompliziert. Aufbauend auf der Wette zwischen Dorier und Stewart senden zwei Parteien Gelder an eine Adresse mit mehreren Unterschriften. Um die Transaktion abzuwickeln, würde ein Orakel den Vertrag mit einer Unterschrift unterzeichnen, die dem Hash des Gewinnergebnisses entspricht (in diesem Fall entweder Republican_Win oder Democrat_Win).

Die Person mit dem Hash, der mit der Unterschrift des Orakels übereinstimmt, kann dann die Gelder aus dem Vertrag zurückziehen.

Mit den Worten Carmans: „Es ist eine ausgeklügelte Kryptographie, um zu zeigen, dass Ihr Vertrag auf der Unterschrift des Orakels basiert und Sie die Gelder nur ausgeben können, wenn Sie diese gültige Orakelunterschrift haben.

Die DLC-Entwicklung ist jung, aber vielversprechend

Carman sagte, DLCs seien „noch superfrüh“, so sehr, dass die Teams, die an ihnen arbeiten, immer noch Bibliotheken für Kodierungsspezifikationen erstellen.

Er fügte hinzu, dass DLCs sogar ein Zuhause im Lightning Network finden könnten, aber dies würde einige Fortschritte erfordern, wenn man bedenkt, dass die derzeitigen Implementierungen nicht hart kodiert sind, um ECDSA-Adapter-Signaturen aufzunehmen.

Die Anpassung von ECDSA an Lightning würde die Hinzufügung von Point-Time-Lock-Verträgen (PTLCs) erfordern, einer werksseitig aktualisierten Version der Hash-Time-Lock-Verträge, die derzeit auf Lightning funktionieren.

Schnorr-Signaturen wären eine ideale Grundlage für die Implementierung von PTLCs. Die lang erwartete Schnorr/Taproot-Aktualisierung sei für DLCs im Allgemeinen nach wie vor unerlässlich, sagte Carman.

Auch wenn DLCs heute ausgeführt werden können, werden fortgeschrittenere Anwendungsfälle viel einfacher zu implementieren sein, wenn die Codebasis von Bitcoin durch die Schnorr/Taproot-Softfork einen Schub erhält.

DLC-Anwendungsfälle

„Am Anfang werden Wetten der primäre Anwendungsfall sein – also Wahlen, Sport und das, was Sie haben“, sagte Carman gegenüber CoinDesk. „Sobald es etablierter ist und wir einen Markt für die Definition von Gegenparteien für Handelsgeschäfte haben, wird es Anwendungsfälle für Hedging oder synthetische Vermögenswerte geben.

Der Anwendungsfall für Hedging wird von Glasbergen in seinem Blogbeitrag „Invisible smart contracts on the Bitcoin blockchain“ skizziert. Die „Terminkontrakte“ würden bedeuten, dass zwei Parteien ein DLC eingehen, wobei sich eine Partei bereit erklärt, eine bestimmte Menge Bitcoin (BTC) zu einem vereinbarten Preis zu kaufen, und die andere Partei die Liquidität für diesen Kauf bereitstellt.

Wenn der Zeitpunkt für die Abwicklung des Vertrags gekommen ist, zahlt der Vertrag dem Käufer die Bitcoin-Menge pro Preis, der zum Zeitpunkt des Vertragsabschlusses festgelegt wurde, und nicht pro aktuellem Wechselkurs. Im Wesentlichen stellen diese Terminkontrakte eine Möglichkeit dar, Bitcoin zu kaufen oder zu verkaufen.

Dieselben Terminkontrakte könnten auch verwendet werden, um synthetische Waren (DLC-Kontrakte, die Waren wie z.B. Gold und/oder Silber repräsentieren) in Bitcoin-denominierten Bedingungen abzurechnen.