CommerceBlock está lanzando Capa de Mercurio hoy, una versión mejorada de su variación de una cadena de estado. Puede leer una explicación más extensa de cómo funcionan sus cadenas de estado de Mercurio. aquí. La actualización a Mercury Layer representa una mejora enorme con respecto a la implementación inicial de la cadena de estado; Sin embargo, a diferencia de la versión inicial de Mercury Wallet, esta no está empaquetada como una billetera totalmente lista para el consumidor. Se lanza como una biblioteca y una herramienta CLI que otras billeteras pueden integrar. Aquí hay un resumen rápido de cómo funcionan:
Las cadenas estatales son esencialmente análogas a los canales de pago en muchos sentidos, es decir, son una UTXO compartida de forma colaborativa con una transacción prefirmada como mecanismo de último recurso para que las personas hagan cumplir su propiedad. La principal diferencia entre un canal Lightning y una cadena estatal son las partes involucradas en compartir colaborativamente el UTXO y cómo la propiedad de un reclamo ejecutable en su contra se transfiere a otras partes.
A diferencia de un canal Lightning, que se crea y comparte entre dos participantes estáticos, una cadena de estado se abre con un facilitador/operador y puede transferirse libremente en su totalidad entre dos participantes quienesquiera que estén dispuestos a confiar en que el operador es honesto y está completamente fuera de lugar. -cadena. Alguien que desee cargar una cadena de estado colabora con el operador para crear una única clave pública en la que tanto el creador como el operador comparten la clave privada correspondiente, sin que ninguno de los dos tenga una copia completa de la clave. Desde aquí, firman previamente una transacción que permite al creador reclamar sus monedas de forma unilateral después de un bloqueo de tiempo.
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 de 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 garantizar que pueda usar la suya antes que los propietarios anteriores). Este proceso se repite para cada transferencia hasta que el tiempo de bloqueo ya no se pueda acortar, 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 de tiempo se hayan reducido correctamente y el operador les ponga marcas de tiempo usando pilar, una variante de Opentimestamps donde cada dato tiene su propia «ranura» única en el árbol merkle para garantizar que solo se registre una única versión de los datos. Esto permitirá a todos auditar el historial de transferencias de una cadena estatal.
En la tierra de los ciegos
El gran cambio que Mercury Layer está aportando a la versión original de las cadenas estatales es cegador. El operador del servicio statechain ya no podrá saber nada sobre lo que se está transfiriendo: es decir, los TXID involucrados, las claves públicas involucradas, incluso las firmas que colaboran con los usuarios para crear las transacciones prefirmadas necesarias para reclamar. sus fondos unilateralmente.
Al presentar una variante ciega de Schnorr MuSig2, Mercury puede facilitar el proceso de firma de transacciones de reversión sin conocer ninguno de los detalles 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 estatal. Ni siquiera son capaces de validar la transacción que están firmando.
En la iteración anterior, el operador atestiguó la unicidad de un conjunto de transacciones/propietario de la cadena estatal actual mediante la publicación de todo el historial de transferencias de la cadena estatal con Mainstay. Esto no es posible aquí, ya que en la versión ciega el operador no conoce ningún detalle sobre estas transacciones. Esto requiere una nueva forma en que el operador certifique la propiedad actual de la cadena estatal. Todos estos datos se envían por completo a un modelo de validación del lado del cliente. El operador simplemente realiza un seguimiento de la cantidad de veces que ha firmado algo para una única cadena de estado y le informa al usuario ese número cuando se solicita. Luego, el usuario recibe las transacciones de estados anteriores de la cadena de estado del usuario que las envía y verifica por completo del lado del cliente que la cantidad de transacciones coincide con lo que afirmó el operador, y luego verifica completamente que todas las firmas sean válidas y que los bloqueos de tiempo disminuyen en la cantidad apropiada. cada vez. En lugar de publicar las transacciones completas de la cadena estatal y la orden de transferencia a Mainstay, debido a que está diseñado para desconocer 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 cadena estatal. usuario. Esto permite a cualquier usuario que reciba una cadena de estado verificar que el historial de transferencias y el estado actual sean legítimos con los datos de la transacción enviada por el remitente.
El servidor del operador realiza un seguimiento de las cadenas de estado únicas para contar las firmas pasadas asignando a cada cadena de estado un identificador aleatorio en el momento de la creación, almacenado con su denominación y sus claves privadas y públicas (no la clave pública agregada). completa). El nuevo esquema de coordinación para fragmentar y volver a fragmentar la clave se realiza de manera que el servidor pasa su parte de la clave al usuario, y los datos necesarios para una nueva fragmentación están ciegos, de modo que el servidor es incapaz de conocer la información completa del usuario. Clave pública, lo que le permite compartir la clave pública agregada completa e identificar la moneda en la cadena.
El diseño ni siquiera permite que el operador sepa 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 que intenta «gastar dos veces» una cadena estatal fuera de la cadena proporcionando una transacción falsa que no se pudo liquidar. En primer lugar, ese usuario vería en la cadena que el UTXO que respalda esa cadena de estado se gastó. En segundo lugar, el historial de transacciones, debido a que el operador debe firmar todas las actualizaciones estatales, 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 es legítima.
Las cadenas estatales también permiten que los canales Lightning se «pongan encima» de la cadena estatal al hacer que la cadena estatal pague a una dirección multifirma entre dos personas, y las dos negocian un conjunto convencional de transacciones de compromiso Lightning encima de ella. Tendría que cerrar la cadena estatal en la cadena antes de cerrar el canal Lightning, por lo que necesitaría usar períodos de bloqueo de tiempo más largos para los pagos Lightning, pero por lo demás funcionaría perfectamente normalmente.
En general, con las enormes mejoras de privacidad de la nueva iteración de las cadenas estatales y la componibilidad 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 los mempools y la presión de tarifas resultantes.
Ofrece el mismo tipo de beneficios de liquidez que Ark, es decir, poder ser transferible libremente sin necesidad de recibir liquidez, pero a diferencia de Ark, está activo y funcional en la actualidad. Sin lugar a dudas, es un modelo de confianza diferente a algo como Lightning por sí solo, pero por las enormes ganancias en flexibilidad y escalabilidad, definitivamente es una posibilidad para explorar.