Firefish protokol
Zdrojový kód pro implementaci protokolu Firefish je dostupný na protocol.firefish.io. Zahrnuje klienta a pokyny pro deterministické sestavení.
Tento dokument popisuje technický design protokolu Firefish. Vezměte prosím na vědomí, že samotná implementace – dodaná prostřednictvím platformy Firefish – se může v určitých aspektech lišit, protože jak platforma, tak underlying escrow systém jsou stále aktivně vyvíjeny. Pro nejpřesnější a nejaktuálnější informace o současné funkčnosti a omezeních protokolu Firefish se prosím podívejte na podmínky služby.
Účastníci protokolu Firefish
- Dlužník: Jednotlivec nebo subjekt, který vlastní bitcoin a hledá likviditu ve fiat měně nebo stablecoinu.
- Investor: Fyzická nebo právnická osoba, která má nadbytečné peníze ve fiatu nebo stablecoin a chce získávat úroky.
- Likvidátor: Subjekt odpovědný za likvidaci zástavy, pokud dlužník nesplní své závazky, nebo pokud hodnota zajištění klesne pod požadovaný práh. Investor může buď sám jednat jako likvidátor, nebo tuto roli delegovat na Firefish.
- Price Oracle: Oracle, který ověřuje cenu bitcoinu. Může být implementováno jako důvěryhodná instituce, veřejný orákl, nebo prahová hodnota institucí a veřejných oráklů. Price Oracle je v současnosti provozován společností Firefish.
- Payment Oracle: Oracle, který potvrzuje, zda byla provedena převod peněz (např. splácení půjčky). Payment Oracle v současnosti provozuje Firefish.
- Firefish: Platforma, která spojuje Investora a Dlužníka a zajišťuje jejich bezpečnou interakci.
Jednotlivé výstupy z půjček
Níže se nachází tabulka možných výstupů úvěru, včetně (i) definice výsledku (Popis), (ii) kdo rozhoduje, že k výsledku došlo (Spoušť), a (iii) co se stane s bitcoinovým zástavou pro tento výstup.
| Výstup z půjčky | Popis | Výsledek | Spouštěč |
|---|---|---|---|
| Splacení | Úvěr byl úspěšně splacen | Veškerá bitcoinová zástava je vrácena dlužníkovi | Payment Oracle |
| Default | Půjčka není splacena | Zástava je odeslána likvidátorovi (distribuční úschova). Část zajištění se použije k pokrytí dlužné částky (buď v bitcoinech pro samosprávnou likvidaci, nebo v měně půjčky pro likvidaci Firefish), zbytek je vrácen Dlužníkovi | Payment Oracle |
| Likvidace | Zajištění dlužníka již plně nezajišťuje půjčku kvůli poklesu její hodnoty | Veškerý kolaterál je odesílán věřiteli (pro samo-řízenou likvidaci) nebo likvidátorovi (pro Firefish likvidaci) | Price Oracle a Payment Oracle |
| Zrušení | Žadatel uzamknul bitcoin do escrow, ale věřitel neposkytl půjčku | Veškerá bitcoinová zástava je vrácena dlužníkovi | Payment Oracle |
| Apokalypsa | Oracly nereagují | Dlužník může získat veškeré bitcoinové zajištění z úschovy jeden měsíc po datu splatnosti prostřednictvím obnovovací transakce (recovery transakce) | Žadatel o půjčku |
Escrow kontrakt
Escrow kontrakt je nedílnou součástí protokolu Firefish. Umožňuje uzamknout kolaterál na konkrétní multisig adrese a definuje pravidla, která udávají, jak může být tento kolaterál uvolněn.
První vrstva Escrow kontraktu je escrow transakce (txescrow). Jeho vstupem je bitcoin dlužníka (prostřednictvím transakce odeslané na Prefund definované níže) a jeho výstupem je 3-z-3 multisig, s klíči drženými:
- Price Oracle
- Payment Oracle
- Dlužník (escrow klíč dlužníka, označovaný jako B-EPH)
Výstup z escrow transakce představuje samotnou úschovu a zde se uchovává bitcoin během celé doby trvání půjčky.
Druhá vrstva smlouvy o úschově je reprezentována sadou částečně podepsaných transakcí (nazývaných uzavírací transakce), které používají bitcoinovou zástavu z výstupu úschovy buď pro věřitele/liquidátora, nebo pro dlužníka, přičemž odpovídají různým výsledkům půjčky. Všechny tyto transakce jsou předem podepsány Dlužníkem pomocí jejich escrow klíče (B-EPH). Tento soukromý klíč je poté zahozen, jelikož je dočasný/efemérní (odtud název B-EPH). Zahodit soukromý klíč Dlužníka zajišťuje, že tyto předem podepsané transakce se stanou jediným způsobem, jak přesunout bitcoinovou zástavu z úschovy, což efektivně pojistí všechny strany podle dohodnutých pravidel.
Kromě toho, že jsou předem podepsány Dlužníkem, jsou tyto uzavírací transakce předem podepsány oraklem, které nenese odpovědnost za odpovídající výsledek půjčky. Později, když známe výsledný status půjčky, odpovědný oracle toto potvrdí přidáním posledního chybějícího podpisu na základní uzavírací transakci (tím se transakce stává platnou) a vysílá tuto transakci do bitcoinové sítě.
Timelocks
Některé uzavírací transakce používají časové zámky, což zajišťuje, že tyto transakce lze použít pouze od určitého data v budoucnu. Konkrétně:
- uzavření transakce odpovídající Default má nastavený časový zámek na datum splatnosti, protože potenciální Default je hodnocen nejdříve k datu splatnosti.
- uzavírající transakce odpovídající katastrofě má časový zámek nastavený na jeden měsíc po datu splatnosti (dlužník si tak může vrátit bitcoin touto transakcí, i kdyby naše Oracles neodpovídali)
Shrnutí uzavíracích transakcí
Celkem máme pět uzavíracích transakcí:
| Jednotlivé výstupy z půjček | Uzavření transakce | Chybějící podpis | Výstup na | Timelock |
|---|---|---|---|---|
| Splacení | txsplacení | Payment Oracle | Žadatel o půjčku | - |
| Default | txDefault | Payment Oracle | Likvidátor | datum splatnosti |
| Likvidace | txlikvidace | Price Oracle a Payment Oracle | Věřitel/Likvidátor | - |
| Zrušení | txsplacení | Payment Oracle | Žadatel o půjčku | - |
| Apokalypsa | txobnovovací transakce | - | Žadatel o půjčku | datum splatnosti + 1 měsíc |
Escrow kontrakt může být schematicky zobrazen takto:
Prefund kontrakt
Abychom escrow proces učinili praktický pro dlužníky, kteří používají různé bitcoinové infrastruktury (hardwarové peněženky, softwarové peněženky,custodial peněženky), navrhujeme nejprve zkonsolidovat zůstatky UTXO ve vaší peněžence, které budou následně použity jako zástava k dané půjčce.
Toto řešení usnadňuje Žadatelům o půjčku interakci s Firefish protokolem. Nejprve odešlou svou bitcoinovou zástavu na konkrétní prefund adresu (Aprefund), což umožňuje vytvoření následného escrow a všech uzavírajících transakcí.
The prefund address represents the following spending condition:
- 3-of-3 multisig (Borrower’s prefund key, Price Oracle, Payment Oracle), or
- Borrower’s prefund key and a relative timelock of 7 days.
The first spending condition using the multisig is used to move bitcoin from prefund to escrow when all parties cooperate. The second spending condition using only Borrower’s prefund key with a relative timelock works as a safeguard for the Borrower, should oracles become unresponsive or malicious during the contract setup.
Once the bitcoin is locked into prefund, all information is known to create the escrow and closing transactions.
The whole Firefish protocol, including prefund, escrow and closing transactions, can be schematically depicted as follows:
Protocol Implementation
The whole Firefish protocol is implemented in Rust. 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. It also contains instructions for deterministic builds, allowing Borrowers to verify that the client used at Firefish platform corresponds to the published source code.
Verifiable Build Showcase
Escrow Setup Procedure
Below you can find the simplified description of the escrow setup and the lifetime of the loan.
- The participants in the protocol securely exchange necessary data (such as loan details) and public keys, all via the Firefish platform.
- Borrower enters their return address where bitcoin collateral will be returned upon successful repayment.
- Using the borrower-client, the Borrower generates the prefund address.
- The Borrower sends bitcoin collateral to the prefund address using their own wallet.
- Using the borrower-client, the Borrower constructs the escrow and closing transactions, and adds their own signatures to the closing transactions.
- The oracles add their own signatures to the escrow transaction and the closing transactions according to the protocol specification.
- Using the borrower-client, the Borrower verifies that all transactions and signatures are in place. After verification, Borrower adds the last missing signature to the escrow transaction.
- Using the borrower-client, the Borrower discards their escrow private key, ensuring that the spending options for the escrow are limited to those defined by the closing transactions.
- Borrower broadcasts the now fully signed escrow transaction, effectively locking bitcoin collateral. The escrow is properly set.
- Lender sends funds (fiat or stablecoin) to the Borrower.
- Later, when the loan outcome is known (e.g., repayment, default), the corresponding transaction is signed and broadcast by the responsible oracle for the given outcome, effectively closing the loan.
Key Benefits of Firefish Protocol
- The escrow has a "deterministic" nature. It can only be spent on the Borrower's or Lender's/Liquidator's address, but not to any other entity.
- The Lender does not need to possess any cryptographic material or otherwise interact with the Bitcoin network. This allows entities that are not Bitcoin-native to invest on the Firefish platform.
- The Borrower only needs to be online and interact with the platform during the escrow setup phase. Afterwards, this is no longer necessary - they do not need to sign anything else or keep the keys online.
- If the Oracles stop cooperating during any phase of the loan, the Borrower can spend the bitcoin on their own address after the timelock expires.
- The interaction of the Borrower with the protocol is reduced to (i) provide your return address and (ii) send bitcoin to the prefund address. The whole complexity, such as creating the addresses and signing the escrow and closing transactions, is processed by the borrower-client.
- Since the interaction is so simple, Firefish can be used by hardware wallet owners as well as Multi-Party Computation (MPC) wallets (institutions) or even custodial solutions (though this is not recommended).
Potential Drawbacks of Firefish Protocol
- Stejně jako u jakéhokoli jiného protokolu půjček krytých bitcoinem je vyžadována jistá úroveň důvěry v Oracles a jejich správné vyhodnocení. Věříme však, že tuto potřebu důvěry lze na úrovni implementace minimalizovat (například decentralizací Price Oracle, využitím DLC, anonymizačními technikami používanými Payment Oracle atd.).
- Smlouvu není možné zrušit bez spolupráce oracles, i když se věřitel a dlužník dohodnou.
- Složitost navrhovaného řešení a fakt, že bezpečnostní a obchodní výhody nemusí být okamžitě zřejmé.
- Investor (a Dlužník) musí mít určitou úroveň důvěry v likvidátora, že vrátí prostředky/bitcoin v případě likvidace a defaultu. Toto může být minimalizováno, například tím, že Likvidátor poskytne nějakou formu zajištění nebo využije DLC.