He escrito muchos artículos que cubren Omniston, STON.fi entre cadenas y, en general, STON.fi.
Uno de los términos que he usado con más frecuencia es RFQ.
Otro es HTLC
Se los he explicado varias veces mientras hablaba de cómo Omniston gestiona los swaps entre cadenas, pero hay un problema: si no ya entiendes lo que sucede entre bastidores, RFQ y HTLC pueden sonar como si no fueran más que dos acrónimos cripto complicados.
No lo son.
En términos sencillos, RFQ ayuda a determinar cómo debe ejecutarse un swap entre cadenas, mientras que HTLC proporciona un mecanismo para coordinar el intercambio entre dos cadenas de bloques separadas.
Pero ¿cómo trabajan exactamente juntos?
¿Y qué sucede entre el momento en que haces clic en Swap y el momento en que tus activos llegan a otra blockchain?
Desmenucémoslo.
❑ Por qué los swaps entre cadenas necesitan más que un botón de swap
Un swap normal de tokens es relativamente sencillo cuando ambos activos existen en la misma blockchain.
Un usuario aporta un activo, una fuente de liquidez aporta otro, y la transacción puede liquidarse dentro de la misma red.
Los swaps entre cadenas introducen otro problema.
Supongamos que quieres intercambiar TON por un activo en Ethereum. TON y Ethereum son blockchains independientes. No comparten un único estado de transacción nativo, así que una transacción en TON no puede simplemente decirle a Ethereum que algo ocurrió y esperar que Ethereum lo trate como parte de la misma transacción.
Por lo tanto, el sistema tiene que resolver dos problemas separados.
Primero, necesita encontrar a alguien capaz de proporcionar el activo en la cadena de destino.
En segundo lugar, necesita coordinar el intercambio para que un lado no se quede con una operación incompleta si algo sale mal.
Aquí es donde se vuelven importantes dos conceptos:
RFQ para encontrar la oferta de ejecución.
HTLC para la liquidación condicional.
Resuelven partes diferentes del mismo problema.
❑ RFQ: Preguntarle al mercado quién puede ejecutar tu swap
RFQ significa Request for Quote.
La forma más fácil de entenderlo es imaginar que quieres intercambiar una gran cantidad de dinero.
En lugar de ir con un solo agente y aceptar cualquier precio que te den, podrías pedirle a varios agentes:
"Quiero intercambiar esta cantidad. ¿Qué puedes ofrecerme?"
Esa es, esencialmente, la idea detrás de un sistema RFQ.
Una solicitud de swap puede incluir información como los activos involucrados, la cantidad, la salida solicitada, los requisitos de tiempo y la información de liquidación.
Los proveedores de liquidez pueden responder con cotizaciones que describen qué están dispuestos a ejecutar.
En Omniston, estos proveedores de liquidez se llaman resolvedores.
Lo importante es que RFQ no es el mecanismo que liquida el swap.
Se trata principalmente de descubrir una oferta que se pueda ejecutar.
El flujo básico es:
1. Un usuario envía una solicitud de swap.
2. Los resolvedores reciben la solicitud.
3. Los resolvedores devuelven cotizaciones ejecutables.
4. Se selecciona una cita adecuada.
5. La operación pasa a la fase de liquidación y ejecución.
Así que cuando veas "RFQ" en una explicación de un swap entre cadenas, piensa:
"¿Quién puede ejecutar esta operación y con qué términos?"
❑ El resolvedor: el contraparte detrás de la cotización
Entender los resolvedores hace que el modelo RFQ sea mucho más fácil de entender.
Un resolvedor es un servicio que proporciona tipos de cambio y participa en la ejecución de operaciones. En una ruta entre cadenas, el resolvedor también puede proporcionar la liquidez necesaria en la blockchain de destino.
Esto es diferente de un puente tradicional.
Un puente normalmente se centra en mover o representar activos entre redes. Un resolvedor en un sistema de swap basado en RFQ actúa más como un creador de mercado profesional o un proveedor de liquidez que puede cumplir una operación en particular.
Piensa en ello así:
RFQ: pedirle a varios agentes una oferta que se pueda ejecutar
Resolvedor: el agente capaz de completar la orden
Cotización: los términos ofrecidos para la operación
Si varios resolvedores responden, el sistema puede evaluar las cotizaciones disponibles y seleccionar la adecuada.
Pero encontrar un resolvedor es solo la mitad del problema.
Aún necesitas liquidar la operación.
❑ RFQ Encuentra el trato. Pero ¿Cómo se liquidan?
Imagina que estás de acuerdo con una operación entre cadenas.
Tú proporcionas TON en la cadena de origen.
El resolvedor promete proporcionar ETH en Ethereum.
Ahora considera qué pasa si primero envías tu TON pero el resolvedor nunca entrega el ETH.
O el resolvedor bloquea ETH pero nunca completas tu parte.
Una cotización de precio no puede resolver ese problema.
El sistema necesita una forma de hacer que las dos partes de la transacción sean condicionales al mismo evento.
Aquí es donde entra en juego HTLC.
❑ HTLC: Un bloqueo con un secreto y un plazo
HTLC significa Hash Time-Locked Contract.
El nombre suena complicado, pero describe dos mecanismos simples.
El primero es un hashlock.
Se genera un secreto y se usa un hash criptográfico de ese secreto como parte de la condición. Alguien que conoce el secreto original, llamado preimagen, puede cumplir la condición del hash.
El segundo es un timelock.
El contrato también contiene una condición basada en el tiempo. Si no ocurre la acción requerida dentro del período correspondiente, la ruta de reembolso pasa a estar disponible.
Una analogía simple es una caja fuerte que requiere una contraseña específica para abrirse, pero también tiene una condición de caducidad.
Puedes pensarlo así:
Hashlock = "Necesitas el secreto correcto."
Timelock = "Solo tienes una cantidad de tiempo determinada."
Juntos, crean un bloqueo condicional.
❑ Por qué se necesitan dos HTLCs
Para un swap atómico entre cadenas, un solo HTLC no es suficiente.
Necesitas condiciones enlazadas en ambos lados de la operación.
Por ejemplo, imagina que un usuario está intercambiando TON en la cadena de origen por un activo en Ethereum.
Un HTLC puede retener el activo del lado de origen del usuario, mientras que otro retiene el activo del lado de destino del resolvedor.
Ambas partes usan el mismo hashlock.
La relación importante es:
HTLC del lado de origen ↔ HTLC del lado de destino
El mismo secreto conecta las dos partes.
Cuando el secreto se revela mediante el proceso de reclamación correspondiente, puede usarse para cumplir la condición correspondiente en el otro lado.
Si no ocurre la liquidación requerida, el timelock correspondiente eventualmente hace que la ruta de reembolso esté disponible.
Esta es la base del diseño todo-o-reembolso usado en swaps atómicos basados en HTLC.
❑ ¿Qué sucede realmente cuando haces clic en "Swap"?
Ahora juntémoslo todo.
Imagina que estás intercambiando un activo en TON por un activo en otra blockchain compatible.
1. Envías la solicitud del swap
La aplicación crea un RFQ que describe lo que quieres negociar.
Contiene los activos relevantes, las cantidades y los requisitos de ejecución.
2. Los resolvedores responden
Los resolvedores reciben la solicitud y proporcionan cotizaciones ejecutables.
Cada cotización describe qué está preparado para ejecutar ese resolvedor.
3. Se selecciona una cotización
El sistema selecciona la cotización relevante según las condiciones de ejecución disponibles.
En este punto, RFQ ya hizo su trabajo principal.
El sistema encontró una oferta de ejecución.
4. Comienza la orden entre cadenas
La operación pasa a su fase de liquidación.
Los activos del lado de origen entran en el proceso de liquidación adecuado, mientras que el resolvedor prepara la liquidez del lado de destino.
5. Las dos partes se vinculan condicionalmente
Para el flujo entre cadenas basado en HTLC, las partes de origen y destino se conectan mediante el mismo hashlock.
El resolvedor proporciona la liquidez del lado de destino requerida para la operación.
6. El secreto se revela
Una vez que se cumple la condición relevante de liquidación, el secreto puede revelarse.
Ese secreto permite a la parte adecuada reclamar los activos bloqueados para ella.
7. Ambas partes liquidan
El usuario recibe el activo de destino.
El resolvedor recibe el activo de origen.
Por lo tanto, las dos partes están conectadas mediante la misma condición criptográfica en lugar de depender de una simple promesa de que la otra parte completará la operación.
8. Si la operación no se completa
Si la condición de liquidación requerida no se cumple antes del plazo correspondiente, la ruta de reembolso pasa a estar disponible según las reglas de liquidación.
Esta es una distinción importante.
El sistema no está diciendo que cada swap deba tener éxito.
Un swap fallido puede ser un resultado válido si los activos pueden recuperarse mediante el mecanismo de timeout y reembolso diseñado.
❑ RFQ y HTLC no son competidores
Probablemente esta sea la forma más fácil de recordar todo.
RFQ - Encuentra liquidez ejecutable y términos de la operación
Resolvedor | Aporta liquidez y ejecuta la ruta
HTLC - Coordina la liquidación condicional entre cadenas
Omniston - Conecta estos componentes en un sistema de ejecución entre cadenas
Así que preguntar si RFQ o HTLC es "mejor" realmente no tiene mucho sentido.
Operan en capas diferentes.
RFQ resuelve el problema del descubrimiento de la ejecución.
HTLC resuelve un problema de liquidación condicional.
Necesitas entender ambos para comprender la arquitectura.
❑ Dónde encaja Omniston en el panorama
Aquí es donde los conceptos se conectan con una implementación real.
Omniston comenzó como un sistema de agregación de liquidez en TON y evolucionó hacia un modelo de ejecución más amplio entre cadenas.
Su arquitectura separa el proceso de solicitar cotizaciones de la liquidación real de la operación.
Para rutas entre cadenas, el modelo incluye RFQs, resolvedores, selección de cotizaciones y liquidación entre cadenas.
En el modelo basado en HTLC, las patas del lado de origen y del lado de destino se coordinan mediante HTLCs emparejados.
Eso significa que Omniston no es simplemente "un HTLC".
Es la capa más amplia de ejecución que conecta los diferentes componentes necesarios para que el swap ocurra.
Una forma simplificada de ver la arquitectura es:
Usuario → RFQ → Resolvedores → Cotizaciones → Ejecución seleccionada → Liquidación entre cadenas → Activo de destino
Para la ruta entre cadenas basada en HTLC, la fase de liquidación conecta entonces los lados de origen y destino mediante el hashlock compartido y sus condiciones de timeout respectivas.
Esta distinción importa porque RFQ y HTLC no son dos tecnologías competidoras dentro de Omniston. Funcionan en etapas diferentes del proceso de ejecución.
❑ ¿Qué pasa cuando algo sale mal?
Entender el fallo es tan importante como entender el éxito.
Si ningún resolvedor proporciona una cotización ejecutable adecuada, la operación no necesita continuar.
Si la ejecución comienza pero no se satisfacen las condiciones de liquidación requeridas, los mecanismos de timeout correspondientes eventualmente pueden hacer que la ruta de reembolso esté disponible.
Y si todo funciona como se pretende, el secreto conecta las dos partes y los respectivos participantes reclaman sus activos.
Por eso también es importante no interpretar "atómico" como que "nunca puede salir mal".
La liquidación atómica describe cómo se vinculan condicionalmente las dos partes.
El sistema general todavía depende de cosas como la disponibilidad de la blockchain, la lógica correcta del contrato, la configuración adecuada de timeouts, la ejecución de transacciones y la disponibilidad de liquidez.
La fortaleza del mecanismo es que una ejecución fallida puede tener una ruta de recuperación definida, en lugar de simplemente dejar las dos partes permanentemente dependientes entre sí.
❑ Por qué esto es diferente de simplemente hacer puente de un activo
Es útil distinguir un swap entre cadenas del modelo tradicional de puente.
Un puente tradicional puede implicar bloquear un activo en una red y crear o representar un activo en otra red.
Un swap atómico entre cadenas coordina un intercambio entre activos en cadenas separadas.
La arquitectura entre cadenas de Omniston usa resolvedores para proporcionar liquidez del lado de destino y usa mecanismos de liquidación entre cadenas para coordinar la transacción.
Por eso entender el resolvedor es tan importante como entender el HTLC.
❑ La parte que a menudo se simplifica en exceso
Los HTLC son potentes, pero no son magia.
Decir que un swap entre cadenas es "atómico" no significa que cada transacción intentada siempre tendrá éxito ni que desaparezca cualquier riesgo posible.
El mecanismo aún depende de las blockchains subyacentes, los contratos inteligentes, la configuración de timeouts, la ejecución de transacciones y la disponibilidad del proveedor de liquidez participante.
También existe una distinción importante entre el éxito automático y la recuperabilidad.
Si no se cumplen las condiciones requeridas para la operación, el timelock puede hacer que una ruta de reembolso esté disponible. Dependiendo de la implementación y la etapa de liquidación, esa recuperación puede requerir la reclamación en cadena o la transacción de reembolso adecuada.
Así que el modelo mental útil no es:
"HTLC no significa que no pueda salir mal."
Es:
"HTLC crea reglas de liquidación condicional que conectan las dos partes y proporcionan una ruta de recuperación basada en timeouts si la condición requerida no se cumple."
Esa es una forma mucho más precisa de entender la tecnología.
❑ Dos siglas, dos trabajos diferentes
Una vez que entiendes RFQ y HTLC, los swaps entre cadenas se vuelven mucho más fáciles de razonar.
Hay varios problemas diferentes que se están resolviendo a la vez.
RFQ encuentra la oferta de ejecución.
Los resolvedores aportan liquidez y ejecutan la ruta.
HTLC proporciona liquidación condicional entre cadenas independientes.
Y Omniston conecta estas piezas en un flujo de ejecución entre cadenas.
La próxima vez que veas RFQ y HTLC mencionados en una explicación de un swap entre cadenas, no tienes que tratarlos como dos siglas cripto más para memorizar.
Solo recuerda:
RFQ encuentra el trato.
El resolvedor proporciona la liquidez.
HTLC conecta las condiciones de liquidación.
Y eso es lo que ocurre detrás del botón de swap.