Capa de Mercurio: Una mejora masiva en 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 de línea de comandos 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 de 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 Lightning, que se crea y se 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 de confianza.

Para transferir una statechain, 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 cual la statechain 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 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 una versión de los datos sea marcada con la hora. 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 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.

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.

"Variante ciega de Schnorr"

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 le 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 todas 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 completa 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 de 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.

El servidor del operador lleva un registro de las 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 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 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, permitiéndole 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 prefirmada para un nuevo propietario fuera de la cadena; no muestra 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 que intenta «doble gastar» una cadena de estado fuera de la cadena proporcionando una transacción falsa que no se puede 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 anteriores. Ambas cosas permitirían al usuario rechazar la transacción sabiendo que no era legítima.

Las cadenas estatales también permiten que los canales de Lightning se coloquen «encima» de la cadena estatal al hacer que la cadena estatal 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 estatal 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.

Cadenas estatales "encima" de Lightning.

En general, con las mejoras masivas de privacidad de la nueva iteración de statechains y la composibilidad con Lightning, esto abre muchas puertas para la viabilidad económica y la flexibilidad de los mecanismos transaccionales de segunda capa en Bitcoin. Especialmente a la luz de los recientes cambios radicales en la dinámica de la 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. Sin duda, es un modelo de confianza diferente al de Lightning solo, pero para obtener grandes ganancias en flexibilidad y escalabilidad, definitivamente es una posibilidad a explorar.

Deja un comentario