-
Mercury Layer utiliza una tรฉcnica denominada "ceguera" que se basa en una variante de Schnorr.
-
A diferencia de Lightning, en las statechains, como Mercury, se emplea un operador.
CommerceBlock, compaรฑรญa especializada en soluciones con activos digitales y Bitcoin, presentรณ Mercury Layer, un protocolo de segunda capa para transacciones en Bitcoin. Similar โpero no idรฉnticaโ a la red Lightning, Mercury representa una mejora de la implementaciรณn inicial de statechains de esta empresa.
Las statechains de Bitcoin son segundas capas que funcionan de manera colaborativa, con un operador, y pueden transferirse libremente entre cualquier par de participantes. En la red Lightning, los canales de pago se establecen entre dos participantes de manera estรกtica, creando una conexiรณn directa entre ellos. Estos canales requieren una apertura y cierre on-chain, lo que significa que la transacciรณn inicial y la finalizaciรณn del canal deben registrarse en la cadena principal de Bitcoin.
La innovaciรณn clave en Mercury, cuyo servidor de pruebas se abriรณ al pรบblico, es la introducciรณn de una tรฉcnica denominada ยซcegueraยป (blinding), con la que el operador ya no puede conocer detalles especรญficos de las transacciones, como TXID (identificadores de transacciรณn), claves pรบblicas y firmas. Esto se logra mediante una variante ciega de Schnorr MuSig2 (multifirmas Schnorr), que permiten la firma de transacciones sin que el operador conozca los detalles.
Gestiรณn de las transacciones en Mercury Layer
En lugar de depender de la cadena principal de Bitcoin, las statechains se comparten colaborativamente fuera de la cadena. El proceso de transferencia implica la colaboraciรณn entre el propietario actual, el receptor y el operador, utilizando claves compartidas y firmas para demostrar la transferencia de propiedad.
Con respecto a este punto, Mercury facilita la transferencia de la propiedad de UTXO individuales controlados por una รบnica clave pรบblica de una parte a otra sin requerir una transacciรณn en la cadena de bloques de Bitcoin ni un cambio en las condiciones de gasto, se explica en el sitio web del proyecto. El SE (Statechain Operator) posibilita este cambio de propiedad sin tener la capacidad de incautar, confiscar o congelar la salida. Para lograr esto, se comparte la clave privada entre el SE y el propietario, de manera que ninguna de las partes conozca la clave privada completa.
El servidor del operador mantiene un seguimiento de statechains รบnicas asignรกndoles identificadores aleatorios, lo que le ayuda a mantener su coordinaciรณn. Ademรกs, la ceguera en las transacciones proporciona una capa adicional de privacidad al asegurar que el operador no conozca detalles sensibles.
Una caracterรญstica tambiรฉn relevante es la capacidad de poner canales de la red Lightning ยซencimaยป de la statechain. Esto permite una gran versatilidad, ya que brinda a los usuarios la opciรณn de realizar transacciones Lightning sobre Mercury.
Mercury Layer mejora su iteraciรณn inicial
Una diferencia clave entre el lanzamiento inicial de la Mercury Wallet y la actualizaciรณn anunciada es que el primer lanzamiento estaba diseรฑado como una wallet completamente lista para el consumidor. En cambio, la versiรณn actual, Mercury Layer, adopta un enfoque diferente.
En lugar de presentarse como una wallet lista para el usuario final, Mercury Layer se lanza como una biblioteca y una herramienta de lรญnea de comandos (CLI). Esto significa que se proporciona como un conjunto de recursos y funcionalidades que otras wallets ya existentes pueden integrar en sus propias interfaces y plataformas.
Una explicaciรณn mรกs profunda
Mediante una publicaciรณn en su cuenta oficial en la red social X (antes Twitter), el CEO de CommerceBlock, Nicholas Gregory, brindรณ otros detalles tรฉcnicos acerca del funcionamiento de Mercury Layer. Mรกs precisamente, explica el contrato de bloqueo empleado en Mercury Layer.
Ese contrato disminuye la vida รบtil de una moneda en 8 horas con cada transacciรณn. Este proceso se basa en el parรกmetro nLockTime en las transacciones, diseรฑado para mejorar la seguridad y abordar el riesgo de que un antiguo dueรฑo pueda malversar los fondos del dueรฑo actual.
Ademรกs, detalla Gregory, cuando el servidor de Mercury Layer no estรก disponible, surge la pregunta de cรณmo determinar quiรฉn es el dueรฑo actual legรญtimo de una moneda y quiรฉn tiene el derecho de recuperar sus fondos. Para resolver esto, cada transacciรณn incluye una transacciรณn de respaldo, que es esencialmente una transacciรณn prefirmada que permite al dueรฑo actual recuperar los fondos de forma independiente, sin depender del servidor.
En situaciones donde dos propietarios intentan recuperar la misma moneda, prevalece el propietario con la marca de tiempo de transacciรณn dentro de la ventana de tiempo vรกlida. Esta validez se determina por el nLockTime, que disminuye constantemente con cada cambio de moneda estatal. Tal sistema garantiza que solo el dueรฑo actual legรญtimo, segรบn el marco de tiempo mรกs reciente y vรกlido, pueda reclamar con รฉxito la moneda estatal.