Commerceblock ha lanzado un nuevo protocolo de intercambio atómico para usar con cadenas estatales en su Protocolo de la capa de mercurio. El servidor HSM ha introducido una funcionalidad para admitir el intercambio atómico de dos cadenas de estado, además de imponer un intercambio atómico de una cadena de estado para un pago Lightning. Este es el primer ejemplo de interacciones concretamente definidas y construidas entre cadenas estatales y Lightning Network. La sinergia entre ambos protocolos se ha postulado desde que Rubén Somsen propuso originalmente el concepto de cadena de estado, específicamente como una forma de resolver la limitación de tener que transferir una UTXO de cadena de estado completa a la vez.
Swaps básicos de cadenas de estado
Para admitir los nuevos protocolos de intercambio, el servidor HSM necesita agregar algunos campos nuevos a las entradas de su base de datos que rastrean cada cadena de estado que está facilitando. Para facilitar el intercambio de statechain a statechain, el servidor necesita realizar un seguimiento de:
- Batch_id: un valor para asociar cadenas de estado que se intercambian en un grupo.
- Tiempo de lote: un tiempo que inicia un contador después del cual las cadenas de estado pueden “recuperarse” si el intercambio falla.
- Bloqueado: un valor que indica si la cadena de estado está bloqueada y restringida para transferencias regulares.
Esto permite que el servidor HSM rastree y aplique todas las variables necesarias para garantizar un intercambio atómico seguro. Al iniciar un intercambio, los usuarios deben comunicarse entre sí directamente para establecer un ID de lote compartido entre ellos. A partir de este punto, intercambian toda la información necesaria para facilitar una transferencia normal de la cadena de estado y envían esa información más el ID del lote y el tiempo del lote al servidor. Básicamente, inician el proceso de transferencia regular, pero también adjuntan las variables para conectar las cadenas de estado individuales como si participaran juntas en un intercambio y la duración del período de tiempo de espera para eso.
En este punto, el servidor aplicará un bloqueo a cada cadena de estado utilizando el mismo ID de lote en el proceso de transferencia. Hasta que expire el tiempo de espera, o hasta que los propietarios actuales hayan desbloqueado todas las cadenas de estado en su base de datos que utilizan el mismo ID de lote, el servidor no aprobará ninguna transferencia. Lo interesante de la forma en que HSM aplica la lógica de intercambio es que no importa quién contacta primero al servidor. Cuando el servidor recibe un mensaje usando un ID de lote, verifica cada cadena de estado en su base de datos y, si hay un tiempo de lote preexistente para ese ID de lote, lo configura como el mismo. Esto garantiza que, independientemente de quién registre el intercambio primero, todos utilicen el mismo valor de tiempo para la función de tiempo de espera.
Cada cliente involucrado en el intercambio en este punto verifica y descarga los mensajes que iniciaron el protocolo de transferencia y, al verificar que son correctos, envía un mensaje al servidor para desbloquear su cadena de estado, eliminando las restricciones de transferencia. Cada vez que alguien intenta finalizar una transferencia en el lado del receptor de cualquiera de las cadenas de estado involucradas en el intercambio, el servidor verifica que todas las cadenas de estado con el mismo ID de lote estén desbloqueadas. Si incluso uno solo con el ID de lote relacionado todavía está bloqueado, el servidor finalizará una transferencia para ninguno de ellos. Si un intercambio no tiene éxito antes del tiempo de espera, el servidor continuará restringiendo la finalización de la transferencia de intercambio, pero permitirá que los propietarios actuales inicialicen una nueva transferencia para cancelar efectivamente el intercambio.
Pestillo relámpago
La funcionalidad Lightning Latch, que cambia una cadena de estado por un pago Lightning, funciona de manera muy similar al intercambio de cadena de estado por cadena de estado. Estos son los nuevos campos que el servidor debe rastrear para el intercambio Lightning:
- Batch_id: un valor para asociar cadenas de estado que se intercambian en un grupo.
- Tiempo de lote: un tiempo que inicia un contador después del cual las cadenas de estado pueden “recuperarse” si el intercambio falla.
- Imagen previa: la imagen previa del pago Lightning, que genera el servidor HSM.
- Locked_1 y locked_2: existen dos campos de bloqueo para el intercambio Lightning, uno autorizado por cada usuario involucrado.
Al igual que con el intercambio de cadena de estado a cadena de estado, los usuarios establecen y comparten un ID de lote aleatorio. Luego, el propietario actual de la cadena de estado envía un mensaje al servidor con el ID de lote y la cadena de estado involucrados y solicita que genere una preimagen de hashlock para un pago Lightning. Luego, este usuario genera una factura Lightning utilizando esta imagen previa y el segundo usuario se comunica con el servidor para confirmar que generó la imagen previa. Luego, el propietario actual de la cadena de estado comienza el proceso de transferencia de la cadena de estado y carga el mensaje de transferencia al servidor.
Después de la confirmación de esto, el segundo usuario que intenta cambiar por la cadena de estado inicia el pago Lightning. En este momento, el servidor es el único que tiene la imagen previa, por lo que el propietario de la cadena estatal aún no puede finalizar el pago. El propietario actual, después de verificar el pago pendiente de Lighting, envía al servidor un mensaje de desbloqueo para eliminar el primer bloqueo en la cadena de estado. El receptor finalmente verifica el mensaje de transferencia y, si los mensajes son válidos, el servidor también elimina su bloqueo.
Ahora, con ambos bloqueos eliminados, el servidor HSM entregará la imagen previa al propietario actual de la cadena de estado para finalizar el pago Lightning y finalizará la transferencia de la cadena de estado al receptor.
Este esquema requiere confiar en que el operador de la cadena estatal funcione honestamente, pero eso no es fundamentalmente un cambio en el modelo de confianza preexistente de usar una cadena estatal en general. En ningún momento el operador tiene control sobre los fondos de los usuarios, ni aprende nada sobre los detalles de pago de Lightning.
¿Para qué es bueno esto?
Este esquema está muy lejos de la interacción propuesta originalmente entre cadenas estatales y canales Lightning, apilando uno encima del otro, pero incluso como un simple punto de partida, esto presenta una utilidad funcional para los usuarios existentes de Lightning. Reequilibrar los canales es algo necesario para muchos nodos; si la capacidad se desplaza por completo hacia un lado o hacia el otro, la utilidad de ese canal es limitada para enrutar los pagos. Muchas empresas y usuarios han comenzado a experimentar con el uso de Liquid como mecanismo para esto debido al aumento de las tarifas en la cadena y encarecimiento de los intercambios dentro y fuera de Lightning Network.
Las cadenas estatales ofrecen un mecanismo alternativo a una cadena lateral federada para aliviar algunos de los gastos de tarifas asociados con la gestión del saldo del canal. En lugar de tener que cambiar directamente a la cadena principal o utilizar una cadena lateral, los fondos se pueden intercambiar a una cadena estatal y retenerlos allí hasta que se necesiten para volver a intercambiar fondos en un canal. Se pueden obtener ahorros similares en tarifas y al mismo tiempo mantener la capacidad de reclamar unilateralmente sus fondos en la cadena principal.
Otro caso de uso potencial (ADVERTENCIA DE DISPARADOR) sería la posibilidad de mercados más eficientes para el comercio de ordinales. Dado que los ordinales son simplemente un esquema de índice que rastrea rutas hacia atrás en el historial de transacciones hasta satoshis específicos, se pueden sacar fácilmente de la cadena a una cadena de estado. Esa dinámica en combinación con Lightning Latch podría permitir compras de ordinales fuera de la cadena más baratas y rápidas. Alguien podría crear un mercado donde se puedan vender instantáneamente fuera de la cadena a través de Lightning Network.
Incluso es posible que algún día los clientes de Lightning puedan darse cuenta de alguna manera de en qué nodos Lightning específicos de los operadores de cadenas estatales confían en que Latch podría usarse para ayudar a enrutar los pagos al pasar cadenas estatales entre diferentes nodos en lugar de usar canales Lightning convencionales.
En el frente de las transferencias puras de cadena de estado a cadena de estado, esto ofrece la posibilidad de que una capa de paso de mensajes recree un sistema tipo coinjoin que mezcla monedas fuera de la cadena, similar al funcionalidad de mezcla original en la primera implementación de cadena de estado de Commerceblock.
Si bien es un punto de partida muy simple, Lightning Latch y la funcionalidad de intercambio de cadenas de estado abren la primera puerta para que las cadenas de estado se integren en la Lightning Network existente (y otras capas similares que vendrán en el futuro) de una manera que les permite a todas integrarse sin problemas y funcionar como una red singular en términos de enrutamiento de pagos y gestión de liquidez. Incluso mientras debatimos la necesidad y utilidad de los pactos, todavía hay mucho espacio para seguir construyendo con lo que ya tenemos.
Puede escuchar al equipo de Commerceblock explicar la lógica más allá del protocolo aquí:
Charlando con el Dr. @TTrevethan acerca de por qué construir un rayo @mercurylayer #bitcoin #capa2 pic.twitter.com/CKVG9aHTQ6
– Nicolás Gregorio (@gregory_nico) 15 de marzo de 2024
Y para una explicación más técnica, aquí:
Repasando los aspectos técnicos de cómo funcionará Lightning Latch con @TTrevethan en @mercurylayer #bitcoin #capa2 pic.twitter.com/aQIcjh2ukq
– Nicolás Gregorio (@gregory_nico) 16 de marzo de 2024
