Bitcoin-natives Finance ohne Brücken

Neugier

1. Wie kann ein Finanzvertrag in reinen Satoshis abgewickelt werden, ohne einen neuen Token oder eine neue Blockchain einzuführen?
2. Welche spezifischen Vertrauensannahmen werden bei der Verwendung eines Orakels für Preisdaten im Vergleich zur lokalen Überprüfung vorgenommen?
3. Warum gilt die Fähigkeit, einseitig in die Basisschicht zurückzukehren, als wichtigster Sicherheitsindikator für Bitcoin-basierte Finanzsysteme?

Erkunden

1. Die von T. Dryja im Jahr 2017 vorgeschlagenen Discreet Log Contracts ermöglichen finanzielle Verträge mit Bitcoin unter Verwendung ausschließlich von Eigenwährungen. Beide Parteien sichern die Mittel in einem 2-of-2 Multisig-Ausgang ab und unterschreiben im Voraus eine Auszahlungstransaktion für jedes mögliche Ergebnis. Jede dieser Transaktionen kann nur durch eine Anpassungssignatur verwendet werden – diese wird erst mit der Signatur des Orakels für dieses jeweilige Ergebnis gültig. Das Orakel veröffentlicht seine Bestätigung, ohne zu wissen, dass es einen Vertrag gibt. Wenn es bestätigt, wird die entsprechende Auszahlung gültig; falls es versagt oder sich falsch verhält, ermöglicht ein Timelock den Teilnehmern, ihr Kapital nach Ablauf einer festgelegten Zeit zurückzuerhalten. Dieses Design vermeidet es, Bitcoin in Tokens einer anderen Kette einzubinden, führt aber zu einer entscheidenden Abhängigkeit: Der Nutzer muss dem Orakel trauen, dass es nicht bösartig signiert, und darauf vertrauen, dass das Netzwerk den Timelock durchsetzt.
2. Multisig- und Timelock-Strukturen ermöglichen Kreditprotokolle, bei denen der Schuldner weiterhin die Kontrolle über seine Schlüssel behält, während die Sicherheiten gesperrt bleiben. In diesen Konzepten hält der Kreditgeber einen Schlüssel und der Schuldner einen anderen; ein Drittanbieter oder ein auf Skripten basierender Mechanismus kümmert sich um die Liquidation, falls die Sicherheiten unter einen bestimmten Schwellenwert fallen. Im Gegensatz zu verpackten Vermögenswerten, bei denen ein Verwalter Token auf einer anderen Kette erstellen muss, bleibt bei diesem Ansatz der gesamte Wert innerhalb des UTXO-Modells von Bitcoin. Der Trade-off besteht in der Komplexität der Schlüsselverwaltung sowie dem Risiko von Fehlern in der Software, die diese Transaktionen erstellt und signiert.
3. Lightning Network-Kanäle ermöglichen Zahlungsströme außerhalb der Blockchain, die erst beim Schließen des Kanals wieder auf der Basis-Blockchain abgewickelt werden. Dadurch wird die Überlastung sowie die Gebühren für hochfrequente Transaktionen verringert, während gleichzeitig die Garantien bezüglich der Endgültigkeit von Bitcoin beibehalten werden. Ark ermöglicht es vielen Nutzern, sich einen von einem Operator koordinierten Ausgangspunkt innerhalb der Blockchain zu teilen; jeder Nutzer besitzt außerdem einen im Voraus unterzeichneten Weg, um allein auf die Blockchain zurückzugelangen, falls der Operator verschwindet. Die Sicherheit dieser Systeme beruht vollständig auf dem Konsensmechanismus der zugrunde liegenden Blockchain; es werden keine neuen Validatoren eingeführt, wodurch das dezentralisierte Sicherheitsmodell, das in früheren Schritten etabliert wurde, erhalten bleibt.
4. BitVM-basierte Konzepte zielen darauf ab, beliebige Berechnungen zu überprüfen, ohne die Konsensregeln von Bitcoin zu ändern. BitVM (Robin Linus, 2023) ist optimistisch: Ein Bewerber gibt ein Ergebnis außerhalb des Blockchainsystems an – falls jemand dieses in Frage stellt, wird durch den Einsatz von Bitcoin-Script eine Fehlerstelle ermittelt und der Bewerber bestraft. Der Hauptanwendungsfall sind Brücken, bei denen für die Sicherheit nur ein ehrlicher Überprüfer unter vielen erforderlich ist – anstatt einer vertrauenswürdigen Federation. Dies stellt einen bedeutenden Wandel von allgemein einsetzbaren, Turing-vollständigen Blockchain-Systemen hin zu selektiven, überprüfbaren Berechnungen dar.
5. Jeder dieser Mechanismen setzt unterschiedliche Vertrauensannahmen voraus, die im Vergleich zu den Kerneigenschaften von Bitcoin bewertet werden müssen. Orakel erfordern Vertrauen in externe Datensätze; Multisig-Verträge erfordern Vertrauen in die Korrektheit des Codes sowie in die Verwaltung der Schlüssel; State-Channels erfordern Vertrauen in Mechanismen zur Streitbeilegung. Der gemeinsame Nenner ist die Beibehaltung der Selbstverwaltung: Nutzer können jederzeit auf native Satoshis umsteigen, ohne Genehmigung einer Stiftung oder eines Admin-Schlüssels zu benötigen. Dies steht im krassen Gegensatz zu verpackten Vermögenswerten, bei denen ein Umstieg über vertrauenswürdige Zwischenhändler erfolgen muss, wodurch das Gegenparteirisiko wieder entsteht, das bei nativen Designs vermieden wird.
6. Lesen Sie die Transaktionsstruktur in den DLC-Spezifikationen (dlcspecs): Eine Finanzierungstransaktion mit einem 2-of-2-Multisig-Ausgang, eine vorab unterzeichnete Ausführungstransaktion pro Ergebnis sowie eine Rückerstattungstransaktion, die bis zu einer festgelegten Zeit gesperrt bleibt, falls der Oracle niemals bestätigt. Markieren Sie, wofür jede Partei – der Oracle und die Kette – als vertrauenswürdig gilt.

Kernfakten

Übung neun, sechs, drei, eins

Faktcheck

Datumsangaben, Zahlen und Behauptungen wurden mit den unten aufgeführten veröffentlichten Quellen abgeglichen.

• T. Dryja, 'Discreet Log Contracts' (2017)
• R. Linus, 'BitVM: Compute Anything on Bitcoin' (2023); Discreet Log Contract specifications (github.com/discreetlogcontracts/dlcspecs)
• Lightning Network Whitepaper: J. Poon & T. Dryja (2015/2016)