Firefish-Protokoll
Der Quellcode für die Firefish-Protokoll-Implementierung ist verfügbar unter protocol.firefish.io. Er enthält den Kreditnehmer-Client und Anweisungen für deterministische Builds.
Dieses Dokument beschreibt das technische Design des Firefish-Protokolls. Bitte beachte, dass die tatsächliche Implementierung – die über die Firefish-Plattform bereitgestellt wird – in bestimmten Aspekten abweichen kann, da sowohl die Plattform als auch das zugrunde liegende Escrow-System aktiv weiterentwickelt werden. Für die genauesten und aktuellsten Informationen über die aktuelle Funktionalität und Einschränkungen des Firefish-Protokolls siehe bitte die Nutzungsbedingungen.
Teilnehmer im Firefish-Protokoll
- Kreditnehmer: Eine Person oder Einrichtung, die Bitcoin besitzt und Fiat- oder Stablecoin-Liquidität sucht.
- Kreditgeber: Eine Person oder Einrichtung, die überschüssige Fiat- oder Stablecoin-Liquidität hat und Zinsen verdienen möchte.
- Liquidator: Eine Entität, die für die Liquidierung der Sicherheiten verantwortlich ist, wenn der Kreditnehmer ausfällt oder wenn der Wert der Sicherheiten unter den erforderlichen Schwellenwert fällt. Der Kreditgeber kann entweder selbst als Liquidator fungieren oder diese Rolle an eine andere Einrichtung delegieren.
- Preis-Orakel: Ein Orakel, das den Bitcoin-Preis bestätigt. Es kann als vertrauenswürdige Institution, öffentliches Orakel oder als Schwellenwert von Institutionen und öffentlichen Orakeln implementiert werden. Das Preis-Orakel wird derzeit von Firefish betrieben.
- Zahlungs-Orakel: Ein Orakel, das bestätigt, ob eine Geldüberweisung erfolgt ist (z. B. Kreditrückzahlung). Das Zahlungs-Orakel wird derzeit von Firefish betrieben.
- Firefish: Eine Plattform, die Kreditnehmer und Kreditgeber zusammenführt und ihre sichere Interaktion ermöglicht.
Kreditergebnisse
Nachfolgend findest du eine Tabelle mit möglichen Ergebnissen des Kredits, einschließlich (i) der Ergebnisdefinition (Beschreibung), (ii) wer entscheidet, dass das Ergebnis eingetreten ist (Auslöser), und (iii) was mit den Bitcoin-Sicherheiten bei diesem Ergebnis geschieht (Resultat).
| Kreditergebnis | Beschreibung | Resultat | Auslöser |
|---|---|---|---|
| Rückzahlung | Kredit erfolgreich zurückgezahlt | Alle Bitcoin-Sicherheiten werden an den Kreditnehmer zurückgegeben | Zahlungs-Orakel |
| Ausfall | Kredit nicht zurückgezahlt | Bitcoin-Sicherheiten werden an den Liquidator gesendet (Verteilungs-Escrow). Ein Teil der Sicherheiten wird verwendet, um den fälligen Betrag zu decken (entweder in Bitcoin für selbstverwaltete Liquidation oder in Kreditwährung für Firefish-Liquidation), der Rest wird an den Kreditnehmer zurückgegeben | Zahlungs-Orakel |
| Liquidation | Die Sicherheiten des Kreditnehmers sichern den Kredit aufgrund der Wertminderung nicht mehr vollständig ab | Alle Bitcoin-Sicherheiten werden an den Kreditgeber (für selbstverwaltete Liquidation) oder Liquidator (für Firefish-Liquidation) gesendet | Preis-Orakel und Zahlungs-Orakel |
| Stornierung | Kreditnehmer hat Bitcoin in Escrow gesperrt, aber Kreditgeber hat keine Kreditmittel an den Kreditnehmer bereitgestellt | Alle Bitcoin-Sicherheiten werden an den Kreditnehmer zurückgegeben | Zahlungs-Orakel |
| Katastrophe | Orakel reagieren nicht | Der Kreditnehmer kann alle Bitcoin-Sicherheiten einen Monat nach dem Fälligkeitsdatum über die Wiederherstellungstransaktion aus dem Escrow retten | Kreditnehmer |
Escrow-Vertrag
Der Escrow-Vertrag ist ein zentraler Bestandteil des Firefish-Protokolls. Er ermöglicht die Sperrung von Bitcoin-Sicherheiten in einer spezifischen Multi-Signatur-Adresse und definiert die Regeln, die bestimmen, wie diese Sicherheiten ausgegeben werden können.
Die erste Ebene des Escrow-Vertrags ist die Escrow-Transaktion (txescrow). Ihr Input ist das Bitcoin des Kreditnehmers (über die unten definierte Prefund-Transaktion) und ihr Output ist ein 3-von-3-Multisig, mit Schlüsseln gehalten von:
- Dem Preis-Orakel
- Dem Zahlungs-Orakel
- Dem Kreditnehmer (Escrow-Schlüssel des Kreditnehmers, genannt B-EPH)
Der Output der Escrow-Transaktion repräsentiert das Escrow selbst, und hier wird das Bitcoin während des Kredits gehalten.
Die zweite Ebene des Escrow-Vertrags wird durch eine Reihe von teilweise signierten Transaktionen (sogenannte Abschlusstransaktionen) dargestellt, die Bitcoin-Sicherheiten aus dem Escrow-Output entweder an Kreditgeber/Liquidator oder Kreditnehmer ausgeben, entsprechend den möglichen Ergebnissen des Kredits. Alle diese Transaktionen werden vom Kreditnehmer mit seinem Escrow-Schlüssel (B-EPH) vorsigniert. Dieser private Schlüssel wird dann verworfen, was ihn ephemer macht (daher der Name B-EPH). Das Verwerfen des privaten Schlüssels des Kreditnehmers stellt sicher, dass diese vorsignierten Transaktionen der einzige Weg werden, die Bitcoin-Sicherheiten aus dem Escrow zu bewegen, wodurch alle Parteien effektiv an die vereinbarten Regeln gebunden werden.
Neben der Vorsignierung durch den Kreditnehmer werden diese Abschlusstransaktionen vom Orakel vorsigniert, das nicht für das entsprechende Kreditergebnis verantwortlich ist. Später, wenn ein Kreditergebnis eintritt, bestätigt das verantwortliche Orakel dies, indem es die letzte fehlende Signatur zur zugrunde liegenden Abschlusstransaktion hinzufügt (wodurch diese Transaktion gültig wird) und diese Transaktion an das Bitcoin-Netzwerk sendet.
Timelocks
Einige Abschlusstransaktionen verwenden Timelocks, um sicherzustellen, dass diese Transaktionen nur ab einem bestimmten Datum in der Zukunft verwendet werden können. Konkret:
- Die Abschlusstransaktion, die dem Ausfall entspricht, hat einen Timelock, der auf das Fälligkeitsdatum gesetzt ist, da ein potenzieller Ausfall nicht früher als am Fälligkeitsdatum bewertet wird.
- the closing transaction corresponding to Disaster has a timelock set to one month after the maturity date, as the escrow would already be spent by this time when oracles are responsive.
Zusammenfassung der Abschlusstransaktionen
Es gibt insgesamt fünf Abschlusstransaktionen:
| Kreditergebnis | Abschlusstransaktion | Fehlende Signatur | Output an | Timelock |
|---|---|---|---|---|
| Rückzahlung | txrepayment | Zahlungs-Orakel | Kreditnehmer | - |
| Ausfall | txdefault | Zahlungs-Orakel | Liquidator | Fälligkeitsdatum |
| Liquidation | txliquidation | Preis-Orakel, Zahlungs-Orakel | Kreditgeber/Liquidator | - |
| Stornierung | txrepayment | Zahlungs-Orakel | Kreditnehmer | - |
| Katastrophe | txrecover | - | Kreditnehmer | Fälligkeitsdatum + 1 Monat |
Der Escrow-Vertrag kann schematisch wie folgt dargestellt werden:
Prefund-Vertrag
Um es für Kreditnehmer praktisch zu machen, die verschiedene Bitcoin-Infrastrukturen verwenden (Hardware-Wallets, Software-Wallets, Custodial-Wallets), schlagen wir vor, eine zusätzliche On-Chain-Transaktion zu verwenden, um die UTXOs zu konsolidieren und vorzubereiten, die zur Finanzierung des Escrow-Vertrags verwendet werden.
Diese Konstruktion macht es für Kreditnehmer einfach, mit dem Firefish-Protokoll zu interagieren. Zuerst senden sie ihre Bitcoin-Sicherheiten an eine spezifische Prefund-Adresse (Aprefund), die das Erstellen der nachfolgenden Escrow- und Abschlusstransaktionen ermöglicht.
Die Prefund-Adresse repräsentiert die folgende Ausgabebedingung:
- 3-von-3-Multisig (Prefund-Schlüssel des Kreditnehmers, Preis-Orakel, Zahlungs-Orakel), oder
- Prefund-Schlüssel des Kreditnehmers und ein relativer Timelock von 7 Tagen.
Die erste Ausgabebedingung unter Verwendung des Multisigs wird verwendet, um Bitcoin vom Prefund zum Escrow zu bewegen, wenn alle Parteien kooperieren. Die zweite Ausgabebedingung, die nur den Prefund-Schlüssel des Kreditnehmers mit einem relativen Timelock verwendet, dient als Sicherung für den Kreditnehmer, falls die Orakel während der Vertragseinrichtung nicht reagieren oder böswillig werden.
Sobald das Bitcoin im Prefund gesperrt ist, sind alle Informationen bekannt, um die Escrow- und Abschlusstransaktionen zu erstellen.
Das gesamte Firefish-Protokoll, einschließlich Prefund-, Escrow- und Abschlusstransaktionen, kann schematisch wie folgt dargestellt werden:
Protokoll-Implementierung
Das gesamte Firefish-Protokoll ist in Rust implementiert. To simplify the interaction with the protocol for Borrowers, the Borrower's part, called borrower-wasm, is compiled into WebAssembly and runs at Firefish platform. The source code for the borrower-wasm is available here. Der Quellcode für den borrower-client ist hier verfügbar.
Verifizierbarer Build-Showcase
Escrow-Einrichtungsverfahren
Nachfolgend findest du die vereinfachte Beschreibung der Escrow-Einrichtung und der Laufzeit des Kredits.
- Die Teilnehmer im Protokoll tauschen sicher die notwendigen Daten (wie Kreditdetails) und öffentliche Schlüssel aus, alles über die Firefish-Plattform.
- Der Kreditnehmer gibt seine Rückgabeadresse ein, an die die Bitcoin-Sicherheiten bei erfolgreicher Rückzahlung zurückgegeben werden.
- Mit dem borrower-client generiert der Kreditnehmer die Prefund-Adresse.
- Der Kreditnehmer sendet Bitcoin-Sicherheiten an die Prefund-Adresse mit seinem eigenen Wallet.
- Mit dem borrower-client erstellt der Kreditnehmer die Escrow- und Abschlusstransaktionen und fügt seine eigenen Signaturen zu den Abschlusstransaktionen hinzu.
- Die Orakel fügen ihre eigenen Signaturen zur Escrow-Transaktion und den Abschlusstransaktionen gemäß der Protokollspezifikation hinzu.
- Mit dem borrower-client überprüft der Kreditnehmer, dass alle Transaktionen und Signaturen vorhanden sind. Nach der Überprüfung fügt der Kreditnehmer die letzte fehlende Signatur zur Escrow-Transaktion hinzu.
- Mit dem borrower-client verwirft der Kreditnehmer seinen privaten Escrow-Schlüssel, um sicherzustellen, dass die Ausgabeoptionen für das Escrow auf die durch die Abschlusstransaktionen definierten beschränkt sind.
- Der Kreditnehmer sendet die nun vollständig signierte Escrow-Transaktion, wodurch die Bitcoin-Sicherheiten effektiv gesperrt werden. Das Escrow ist ordnungsgemäß eingerichtet.
- Der Kreditgeber sendet Gelder (Fiat oder Stablecoin) an den Kreditnehmer.
- Später, wenn das Kreditergebnis bekannt ist (z. B. Rückzahlung, Ausfall), wird die entsprechende Transaktion vom verantwortlichen Orakel für das gegebene Ergebnis signiert und gesendet, wodurch der Kredit effektiv geschlossen wird.
Hauptvorteile des Firefish-Protokolls
- Das Escrow hat eine „deterministische" Natur. Es kann nur auf die Adresse des Kreditnehmers oder Kreditgebers/Liquidators ausgegeben werden, aber nicht an eine andere Einrichtung.
- Der Kreditgeber muss kein kryptografisches Material besitzen oder anderweitig mit dem Bitcoin-Netzwerk interagieren. Dies ermöglicht es Einrichtungen, die nicht Bitcoin-nativ sind, auf der Firefish-Plattform zu investieren.
- Der Kreditnehmer muss nur während der Escrow-Einrichtungsphase online sein und mit der Plattform interagieren. Danach ist dies nicht mehr notwendig - er muss nichts anderes mehr signieren oder die Schlüssel online halten.
- Wenn die Orakel während einer Phase des Kredits aufhören zu kooperieren, kann der Kreditnehmer das Bitcoin nach Ablauf des Timelocks auf seine eigene Adresse ausgeben.
- Die Interaktion des Kreditnehmers mit dem Protokoll wird reduziert auf (i) Bereitstellung deiner Rückgabeadresse und (ii) Senden von Bitcoin an die Prefund-Adresse. Die gesamte Komplexität, wie das Erstellen der Adressen und das Signieren der Escrow- und Abschlusstransaktionen, wird vom borrower-client verarbeitet.
- Da die Interaktion so einfach ist, kann Firefish von Hardware-Wallet-Besitzern sowie Multi-Party-Computation (MPC) Wallets (Institutionen) oder sogar Custodial-Lösungen verwendet werden (obwohl dies nicht empfohlen wird).
Potenzielle Nachteile des Firefish-Protokolls
- Wie bei jedem anderen Bitcoin-besicherten Kreditprotokoll ist ein gewisses Maß an Vertrauen erforderlich, dass die Orakel ehrlich sind. Wir glauben jedoch, dass dieser Vertrauensbedarf auf Implementierungsebene minimiert werden kann (z. B. durch Dezentralisierung des Preis-Orakels, Verwendung von DLCs, Anonymisierungstechniken des Zahlungs-Orakels usw.).
- Der Vertrag kann nicht ohne die Zusammenarbeit der Orakel-Einrichtungen storniert werden, selbst wenn Kreditgeber und Kreditnehmer zustimmen.
- Die Komplexität der vorgeschlagenen Lösung und die Tatsache, dass die Sicherheits- und Geschäftsvorteile möglicherweise nicht sofort ersichtlich sind.
- Der Kreditgeber (und Kreditnehmer) muss ein gewisses Maß an Vertrauen in den Liquidator haben, dass dieser die Gelder/Bitcoin im Falle von Liquidation und Ausfall zurückgibt. Dies kann beispielsweise minimiert werden, indem der Liquidator eine Form von Sicherheit bereitstellt oder DLCs verwendet.