Capa de Mercurio: Una Mejora Masiva en las Cadenas de Estado.

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:

Los Statechains son esencialmente análogos a los canales de pago en muchos aspectos, es decir, son un UTXO compartido colaborativamente con una transacción pre-firmada como mecanismo de último recurso para que las personas hagan valer su propiedad. La diferencia principal entre un canal Lightning y un statechain 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 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 única clave pública que tanto el creador como 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 temporal de forma unilateral.

Statechain: Transferencia segura y libre.

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 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 la cadena histórica completa de estados pasados con cada transferencia para que los usuarios puedan verificar que los timelocks han sido correctamente decrementados y el operador los marca con Mainstay, una variante de Opentimestamps donde cada pieza de datos tiene su propio «slot» único en el árbol de Merkle para garantizar que solo se estampe una versión de los datos. Esto permite que todos auditen el historial de transferencias de una statechain.

, 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 la Capa de Mercurio está trayendo a la versión original de statechains es impresionante. El operador del servicio de statechain 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 manera unilateral.

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 statechain. Ni siquiera son capaces de validar la transacción que están firmando en absoluto.

"Variante ciega Schnorr MuSig2"

En la iteración anterior, la singularidad del propietario actual de la cadena de estado / 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 ciega 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 de la cadena de estado y el orden de transferencia en Mainstay, porque está diseñado para no ser consciente 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 transacción enviados por el remitente.

Validación ciega de transacciones.

El servidor del operador mantiene un registro de cadenas de estado únicas para contar las firmas pasadas asignando a cada cadena de estado un identificador aleatorio al momento de su creación, almacenado junto con su denominación y sus comparticiones de clave privada y clave pública (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 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.

Registro de cadenas de estado

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 prefirmada 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 tratando de «doble gastar» una cadena de estado 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 que respalda esa cadena de estado 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 Statechains también permiten que los canales de Lightning sean «colocados encima» de la statechain al hacer que la statechain pague a una dirección multisig entre dos personas, y los dos negocien un conjunto convencional de transacciones de compromiso de Lightning encima de ella. Sería necesario cerrar la statechain 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 mejoras masivas 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, poder ser transferido libremente sin necesidad de recibir liquidez, pero a diferencia de Ark, está en vivo y funcional hoy en día. Sin duda, es un modelo de confianza diferente al de algo como Lightning solo, pero para obtener grandes ventajas en flexibilidad y escalabilidad, definitivamente es una posibilidad a explorar.

"Flexibilidad y escalabilidad"

Deja un comentario