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 …

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:

Comercio mejorado con statechains.

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 prefirmada como mecanismo de último recurso para que las personas hagan valer su propiedad. La principal diferencia entre un canal de Lightning y un statechain es las partes involucradas en compartir colaborativamente el UTXO, y cómo se transfiere la propiedad de un reclamo ejecutable contra él a otras partes.

"UTXO compartido colaborativo"

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 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 tiempo determinado de manera unilateral.

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 cual la cadena de estado debe cerrarse en la cadena.

Transferencia de cadena de estado.

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 fecha y hora. Esto permite que todos auditen el historial de transferencias de una statechain.

"Propietarios transfieren historial completo"

, 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 las 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.

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 válidas y los bloqueos de tiempo se decrementen por 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 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 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 transacciones enviados por el remitente.

Validación ciega de estado.

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 junto con su denominación y sus partes de clave privada y pública (no la clave pública agregada completa). El nuevo esquema de coordinación para la fragmentación y re-fragmentación de la clave se realiza de tal manera que el servidor pasa su parte de la clave al usuario, y los datos necesarios para una re-fragmentación 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 se ven detalles 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 estado de cadena 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 respaldando ese estado de cadena fue gastado. En segundo lugar, el historial de transacciones, debido a que 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.

"Diseño previene doble gasto"

Las Statechains también permiten que los canales Lightning se «colocen encima» de la statechain al hacer que la statechain 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 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, la capacidad de ser libremente transferible 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 ganancias en flexibilidad y escalabilidad, definitivamente es una posibilidad a explorar.