Capa de Mercurio: Una mejora masiva en las Statechains.

By: subirimagenes

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 prefirmada como mecanismo de último recurso para que las personas hagan valer su propiedad. La diferencia principal 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.

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í, firman previamente una transacción que permite al creador reclamar sus monedas después de un tiempo determinado de forma 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.

Los propietarios transfieren toda la cadena histórica de estados pasados ​​con cada transferencia para que los usuarios puedan verificar que los timelocks se hayan decrementado correctamente y el operador los selle 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 selle una versión de los datos. Esto permite a todos auditar el historial de transferencias de una statechain.

"Propietarios transfieren cadena histórica"

, The One-Eyed Man Is King.

En el país 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 deslumbrante. 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 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 y 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.

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 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 de los estados anteriores de la cadena de estado 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 que los bloqueos de tiempo se hayan decrementado 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.

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 partes de clave privada y 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 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 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 intentando «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 Lightning se «pongan encima» de la statechain al hacer que la statechain pague a una dirección multisig entre dos personas, y que ambas 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.

"Statechains con Lightning"

En general, con las mejoras masivas en privacidad de la nueva iteración de statechains y la composabilidad con Lightning, se abren muchas puertas para la viabilidad económica y flexibilidad de los 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.

Mejoras de privacidad y flexibilidad en Bitcoin.

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 ganancias en flexibilidad y escalabilidad, definitivamente es una posibilidad a explorar.

"Flexibilidad y escalabilidad"

Deja un comentario