Capa de Mercurio: Una mejora masiva en las Statechains.

CommerceBlock está lanzando hoy Mercury Layer, una versión mejorada de su variación de una statechain. Puedes leer una explicación más detallada de cómo funcionan sus statechains de Mercury aquí. La actualización a Mercury Layer representa una mejora masiva en comparación con la implementación inicial de statechain, sin embargo, a diferencia del lanzamiento inicial de Mercury Wallet, esto no está empaquetado como una billetera completamente lista para el consumidor. Se está lanzando como una biblioteca y una herramienta CLI que otras billeteras pueden integrar. Aquí hay un resumen rápido de cómo funcionan:

Las cadenas de estado son esencialmente análogas a los canales de pago en muchos aspectos, es decir, son un UTXO compartido colaborativamente con una transacción prefirmada como mecanismo de último recurso para que las personas hagan valer su propiedad. La principal diferencia entre un canal Lightning y una cadena de estado es las partes involucradas en compartir colaborativamente el UTXO y cómo se transfiere la propiedad de una reclamación ejecutable contra él a otras partes.

A diferencia de un canal de Lightning, que se crea y comparte entre dos participantes estáticos, una statechain se abre con un facilitador / operador y puede ser transferida libremente en su totalidad entre cualquier dos participantes que estén dispuestos a confiar en que el operador sea honesto, completamente fuera de la cadena. Alguien que desee cargar una statechain colabora con el operador para crear una sola clave pública que el creador y el operador poseen una parte de la clave privada correspondiente, sin que ninguno tenga una copia completa de la clave. A partir de aquí, pre-firman una transacción que permite al creador reclamar sus monedas después de un bloqueo de tiempo de forma unilateral.

Statechain: Transferencia libre de monedas.

Para transferir una cadena de estado, el propietario actual colabora con el receptor y el operador para firmar una prueba criptográfica con su clave compartida que están transfiriendo la moneda, y luego el receptor y el operador generan un nuevo par de claves compartidas que suman a la misma clave privada y firman una transacción con límite de tiempo para el nuevo propietario con un límite de tiempo más corto que el original (para asegurarse de que puedan usarla antes que los propietarios anteriores). Este proceso se repite para cada transferencia hasta que el límite de tiempo no se pueda acortar más, momento en el que la cadena de estado debe cerrarse en la cadena.

Los propietarios transfieren toda la cadena histórica de estados pasados con cada transferencia para que los usuarios puedan verificar que los bloqueos temporales se hayan decrementado correctamente y el operador los selle con Mainstay, una variante de Opentimestamps donde cada pieza de datos tiene su propio «espacio» único en el árbol de Merkle para garantizar que solo se selle una versión de los datos. Esto permite que todos auditen el historial de transferencias de una cadena de estados.

, The One-Eyed Man Is King

En la tierra de los ciegos, el hombre de un solo ojo es rey.

La gran transformación que Mercury Layer está trayendo a la versión original de statechains es impresionante. El operador del servicio de statechains ya no podrá aprender nada sobre lo que se está transfiriendo: es decir, los TXIDs involucrados, las claves públicas involucradas, incluso las firmas con las que colabora con los usuarios para crear las transacciones pre-firmadas necesarias para reclamar sus fondos de forma unilateral.

Transformación revolucionaria de statechains.

Presentando una variante ciega de Schnorr MuSig2, Mercury puede facilitar el proceso de firma de transacciones de retroceso sin aprender ningún detalle de lo que están firmando. Esto requiere algunos cambios de diseño para tener en cuenta el hecho de que el operador ya no puede ver ni publicar la totalidad del historial de transferencias de una cadena de estado. Ni siquiera son capaces de validar la transacción que están firmando en absoluto.

En la iteración anterior, la unicidad del propietario de la cadena de estado actual / conjunto de transacciones fue atestiguada por el operador a través de la publicación de todo el historial de transferencias de la cadena de estado con Mainstay. Eso no es posible aquí, ya que en la versión cegada el operador no aprende ningún detalle sobre estas transacciones. Esto requiere una nueva forma de que el operador atestigüe la propiedad actual de la cadena de estado. Todos estos datos se empujan completamente a un modelo de validación del lado del cliente. El operador simplemente lleva un registro del número de veces que ha firmado algo para una sola cadena de estado, y le dice a un usuario ese número cuando se solicita. El usuario luego recibe las transacciones del estado anterior de la cadena del usuario que les envía, y verifica completamente del lado del cliente que el número de transacciones coincida con lo que el operador afirmó, y luego verifica completamente que las firmas sean válidas y los bloqueos de tiempo se decrementen en la cantidad apropiada cada vez. En lugar de publicar todas las transacciones y el orden de transferencia de la cadena de estado a Mainstay, porque está diseñado para no tener conocimiento de toda esa información, publica su parte de la clave pública (no la clave pública agregada completa) para el usuario actual para cada usuario de la cadena de estado. Esto permite a cualquier usuario que reciba una cadena de estado verificar que el historial de transferencias y el estado actual sean legítimos en comparación con los datos de transacciones enviados por el remitente.

El servidor operador mantiene un registro de statechains únicos para contar las firmas pasadas asignando a cada statechain un identificador aleatorio al momento de su creación, almacenado junto con su denominación y sus claves privadas y compartidas (no la clave pública agregada completa). El nuevo esquema de coordinación para el fragmentado y re-fragmentado de la clave se realiza de tal manera que el servidor pasa su parte de la clave al usuario, y los datos necesarios para un re-fragmentado están enmascarados para que el servidor sea incapaz de aprender la parte completa de la clave pública del usuario, lo que le permite crear la clave pública agregada completa e identificar la moneda en la cadena.

El diseño ni siquiera permite al operador saber cuándo ha firmado un cierre cooperativo con el propietario actual en lugar de una transacción pre-firmada para un nuevo propietario fuera de la cadena; no ve ningún detalle para distinguir los dos casos entre sí. Sin embargo, esto es seguro para los usuarios que podrían ser atacados por alguien intentando «doble gastar» un statechain fuera de la cadena proporcionando una transacción falsa que no se podría liquidar. En primer lugar, ese usuario vería en la cadena que el UTXO respaldando ese statechain fue gastado. En segundo lugar, el historial de transacciones, porque el operador debe firmar todas las actualizaciones de estado, solo tendría un cierre cooperativo claro en la cadena de transacciones pasadas. Ambas cosas permitirían al usuario rechazar la transacción sabiendo que no era legítima.

Las cadenas de estado también permiten que los canales de Lightning se «pongan encima» de la cadena de estado al hacer que la cadena de estado pague a una dirección multisig entre dos personas, y las dos personas negocien un conjunto convencional de transacciones de compromiso de Lightning encima de ella. Sería necesario cerrar la cadena de estado en la cadena antes de cerrar el canal de Lightning, por lo que se necesitarían plazos de bloqueo más largos para los pagos de Lightning, pero de lo contrario funcionaría perfectamente normalmente.

En general, con las grandes mejoras de privacidad de la nueva iteración de statechains, y la composabilidad con Lightning, esto abre muchas puertas para la viabilidad económica y flexibilidad de mecanismos transaccionales de segunda capa en Bitcoin. Especialmente a la luz de los recientes cambios radicales en la dinámica del mempool y la presión de las tarifas resultante.

Ofrece los mismos beneficios de liquidez que Ark, es decir, la posibilidad de ser transferido libremente sin necesidad de recibir liquidez, pero a diferencia de Ark, está en vivo y funcional hoy en día. Indudablemente, es un modelo de confianza diferente al de algo como Lightning solo, pero para obtener grandes ganancias en flexibilidad y escalabilidad, definitivamente es una posibilidad a explorar.

"Beneficios de liquidez similares"

Deja un comentario