Protocolo Firefish

Código Fuente Disponible

El código fuente de la implementación del Protocolo Firefish está disponible en protocol.firefish.io. Incluye el cliente del prestatario e instrucciones para compilaciones determinísticas.

Este documento describe el diseño técnico del Protocolo Firefish. Ten en cuenta que la implementación real—entregada a través de la plataforma Firefish—puede diferir en ciertos aspectos, ya que tanto la plataforma como el sistema de escrow subyacente permanecen en desarrollo activo. Para obtener la información más precisa y actualizada sobre la funcionalidad actual y las limitaciones del Protocolo Firefish, consulta los Términos de Servicio.

Participantes en el Protocolo Firefish

• Prestatario: Un individuo o entidad que posee bitcoin y busca liquidez en fiat o stablecoins.
• Prestamista: Un individuo o entidad que tiene exceso de liquidez en fiat o stablecoins y desea obtener intereses.
• Liquidador: Una entidad responsable de liquidar el colateral si el Prestatario incumple o si el valor del colateral cae por debajo del umbral requerido. El Prestamista puede actuar como Liquidador él mismo o delegar este rol a otra entidad.
• Oráculo de Precio: Un Oráculo que certifica el precio del bitcoin. Puede implementarse como una institución de confianza, un oráculo público, o un umbral de instituciones y oráculos públicos. El Oráculo de Precio es actualmente operado por Firefish.
• Oráculo de Pago: Un Oráculo que certifica si se ha realizado una transferencia de fondos (por ejemplo, el reembolso del préstamo). El Oráculo de Pago es actualmente operado por Firefish.
• Firefish: Una plataforma que conecta a Prestatarios y Prestamistas y facilita su interacción segura.

Resultados del préstamo

A continuación se muestra una tabla de posibles resultados del préstamo, incluyendo (i) definición del resultado (Descripción), (ii) quién decide que el resultado ocurrió (Activador), y (iii) qué sucede con el colateral en bitcoin para ese resultado (Resultado).

Resultado del préstamo	Descripción	Resultado	Desencadenante
Reembolso	Préstamo reembolsado exitosamente	Todo el colateral en bitcoin se devuelve al Prestatario	Oráculo de Pago
Incumplimiento	Préstamo no reembolsado	El colateral en bitcoin se envía al Liquidador (escrow de distribución). Parte del colateral se utiliza para cubrir el monto adeudado (ya sea en bitcoin para liquidación autogestionada o en la moneda del préstamo para liquidación de Firefish), el resto se devuelve al Prestatario	Oráculo de Pago
Liquidación	El colateral del Prestatario ya no asegura completamente el préstamo debido a la disminución de su valor	Todo el colateral en bitcoin se envía al Prestamista (para liquidación autogestionada) o al Liquidador (para liquidación de Firefish)	Oráculo de Precio y Oráculo de Pago
Cancelación	El Prestatario bloqueó bitcoin en escrow pero el Prestamista no proporcionó los fondos del préstamo al Prestatario	Todo el colateral en bitcoin se devuelve al Prestatario	Oráculo de Pago
Desastre	Los Oráculos no responden	El Prestatario puede rescatar todo el colateral en bitcoin del escrow un mes después de la fecha de vencimiento mediante la transacción de recuperación	Prestatario

Contrato de Escrow

El contrato de escrow es una parte central del Protocolo Firefish. Permite bloquear el colateral en bitcoin en una dirección multifirma específica y define las reglas que gobiernan cómo se puede gastar este colateral.

La primera capa del contrato de escrow es la transacción de escrow (tx_escrow). Su entrada es el bitcoin del Prestatario (a través de la transacción Prefund definida a continuación) y su salida es un multisig 3-de-3, con claves en poder de:

• El Oráculo de Precio
• El Oráculo de Pago
• El Prestatario (clave de escrow del Prestatario, llamada B-EPH)

La salida de la transacción de escrow representa el escrow en sí, y aquí es donde se mantiene el bitcoin durante el préstamo.

La segunda capa del contrato de escrow está representada por un conjunto de transacciones parcialmente firmadas (llamadas transacciones de cierre) que gastan el colateral en bitcoin desde la salida del escrow ya sea al Prestamista/Liquidador o al Prestatario, correspondiendo a los posibles resultados del préstamo. Todas estas transacciones son pre-firmadas por el Prestatario usando su clave de escrow (B-EPH). Esta clave privada luego se descarta, haciéndola efímera (de ahí el nombre B-EPH). Descartar la clave privada del Prestatario asegura que estas transacciones pre-firmadas se conviertan en la única forma de mover el colateral en bitcoin desde el escrow, bloqueando efectivamente a todas las partes en las reglas acordadas.

Además de ser pre-firmadas por el Prestatario, estas transacciones de cierre son pre-firmadas por el oráculo que no es responsable del resultado del préstamo correspondiente. Posteriormente, cuando ocurre un resultado del préstamo, el oráculo responsable lo confirma añadiendo la última firma faltante a la transacción de cierre subyacente (haciendo válida esta transacción), y transmite esta transacción a la red de Bitcoin.

Timelocks

Algunas transacciones de cierre utilizan timelocks, asegurando que estas transacciones solo puedan usarse a partir de una fecha específica en el futuro. Concretamente:

• La transacción de cierre correspondiente al Incumplimiento tiene un timelock establecido en la fecha de vencimiento, ya que un potencial Incumplimiento se evalúa no antes de la fecha de vencimiento.
• La transacción de cierre correspondiente al Desastre tiene un timelock establecido en un mes después de la fecha de vencimiento, ya que el escrow ya habría sido gastado para ese momento cuando los oráculos responden.

Resumen de Transacciones de Cierre

Hay un total de cinco transacciones de cierre:

Resultado del préstamo	Transacción de Cierre	Falta firma	Salida a	Timelock
Reembolso	txreembolso	Oráculo de Pago	Prestatario	-
Incumplimiento	tximpago	Oráculo de Pago	Liquidador	fecha de vencimiento
Liquidación	txliquidación	Oráculo de Precio, Oráculo de Pago	Prestamista/Liquidador	-
Cancelación	txreembolso	Oráculo de Pago	Prestatario	-
Desastre	txrecuperar	-	Prestatario	fecha de vencimiento + 1 mes

El contrato de escrow puede representarse esquemáticamente de la siguiente manera:

Contrato Prefund

Para hacerlo práctico para los Prestatarios que utilizan una variedad de infraestructura de bitcoin (wallets de hardware, wallets de software, wallets custodiales), proponemos usar una transacción adicional en cadena para consolidar y preparar los UTXOs que se utilizarán para financiar el contrato de escrow.

Esta construcción facilita a los Prestatarios interactuar con el protocolo Firefish. Primero, envían su colateral en bitcoin a una dirección prefund específica (A_prefund), lo que permite crear las transacciones de escrow y cierre subsiguientes.

La dirección prefund representa la siguiente condición de gasto:

• Multisig 3-de-3 (clave prefund del Prestatario, Oráculo de Precio, Oráculo de Pago), o
• Clave prefund del Prestatario y un timelock relativo de 7 días.

La primera condición de gasto usando el multisig se utiliza para mover bitcoin desde prefund a escrow cuando todas las partes cooperan. La segunda condición de gasto usando solo la clave prefund del Prestatario con un timelock relativo funciona como una salvaguarda para el Prestatario, en caso de que los oráculos dejen de responder o se vuelvan maliciosos durante la configuración del contrato.

Una vez que el bitcoin está bloqueado en prefund, se conoce toda la información para crear las transacciones de escrow y cierre.

El protocolo Firefish completo, incluyendo las transacciones prefund, escrow y de cierre, puede representarse esquemáticamente de la siguiente manera:

Implementación del Protocolo

El protocolo Firefish completo está implementado en Rust. El código fuente para borrower-wasm está disponible aquí. También contiene instrucciones para compilaciones determinísticas, permitiendo a los Prestatarios verificar que el cliente utilizado en la plataforma Firefish corresponde al código fuente publicado. Para simplificar la interacción con el protocolo para los Prestatarios, la parte del Prestatario, llamada borrower-wasm, se compila en WebAssembly y se ejecuta en la plataforma Firefish.

Exhibición de Compilación Verificable

Procedimiento de Configuración del Escrow

A continuación puedes encontrar la descripción simplificada de la configuración del escrow y el tiempo de vida del préstamo.

1. Los participantes en el protocolo intercambian de forma segura los datos necesarios (como detalles del préstamo) y claves públicas, todo a través de la plataforma Firefish.
2. El Prestatario ingresa su dirección de retorno donde se devolverá el colateral en bitcoin tras un reembolso exitoso.
3. Usando el borrower-client, el Prestatario genera la dirección prefund.
4. El Prestatario envía el colateral en bitcoin a la dirección prefund usando su propio wallet.
5. Usando el borrower-client, el Prestatario construye las transacciones de escrow y cierre, y añade sus propias firmas a las transacciones de cierre.
6. Los oráculos añaden sus propias firmas a la transacción de escrow y a las transacciones de cierre según la especificación del protocolo.
7. Usando el borrower-client, el Prestatario verifica que todas las transacciones y firmas están en su lugar. Después de la verificación, el Prestatario añade la última firma faltante a la transacción de escrow.
8. Usando el borrower-client, el Prestatario descarta su clave privada de escrow, asegurando que las opciones de gasto para el escrow se limiten a las definidas por las transacciones de cierre.
9. El Prestatario transmite la transacción de escrow ahora completamente firmada, bloqueando efectivamente el colateral en bitcoin. El escrow está correctamente configurado.
10. El Prestamista envía fondos (fiat o stablecoin) al Prestatario.
11. Posteriormente, cuando se conoce el resultado del préstamo (por ejemplo, reembolso, incumplimiento), la transacción correspondiente es firmada y transmitida por el oráculo responsable del resultado dado, cerrando efectivamente el préstamo.

Beneficios Clave del Protocolo Firefish

• El escrow tiene una naturaleza "determinística". Solo puede gastarse en la dirección del Prestatario o del Prestamista/Liquidador, pero no en ninguna otra entidad.
• El Prestamista no necesita poseer ningún material criptográfico ni interactuar de otra manera con la red de Bitcoin. Esto permite que entidades que no son nativas de Bitcoin inviertan en la plataforma Firefish.
• El Prestatario solo necesita estar en línea e interactuar con la plataforma durante la fase de configuración del escrow. Después, esto ya no es necesario - no necesitan firmar nada más ni mantener las claves en línea.
• Si los Oráculos dejan de cooperar durante cualquier fase del préstamo, el Prestatario puede gastar el bitcoin en su propia dirección después de que expire el timelock.
• La interacción del Prestatario con el protocolo se reduce a (i) proporcionar tu dirección de retorno y (ii) enviar bitcoin a la dirección prefund. Toda la complejidad, como crear las direcciones y firmar las transacciones de escrow y cierre, es procesada por el borrower-client.
• Como la interacción es tan simple, Firefish puede ser usado por propietarios de wallets de hardware así como wallets de Computación Multi-Parte (MPC) (instituciones) o incluso soluciones custodiales (aunque esto no se recomienda).

Posibles Desventajas del Protocolo Firefish

• Como con cualquier otro protocolo de préstamos respaldados por bitcoin, se requiere cierto nivel de confianza en que los oráculos sean honestos. Sin embargo, creemos que esta necesidad de confianza puede minimizarse a nivel de implementación (por ejemplo, descentralizando el Oráculo de Precio, usando DLCs, técnicas de anonimización usadas por el Oráculo de Pago, etc.).
• El contrato no puede cancelarse sin la cooperación de las entidades de oráculo, incluso si el Prestamista y el Prestatario están de acuerdo.
• La complejidad de la solución propuesta y el hecho de que las ventajas de seguridad y negocio pueden no ser inmediatamente aparentes.
• El Prestamista (y el Prestatario) debe tener cierto nivel de confianza en el Liquidador de que devolverá los fondos/bitcoin en caso de liquidación e incumplimiento. Esto puede minimizarse, por ejemplo, si el Liquidador proporciona alguna forma de garantía o usa DLCs.