💻 computer science

Enabling Threshold Custody for the Lightning Network with Nested Threshold Multi-Signatures

Este artículo presenta "Iceberg", una novedosa construcción criptográfica para firmas MuSig2 de umbral anidado que permite que un lado de un canal de la Lightning Network de Bitcoin opere como un grupo de umbral $t$ -de- $n$ seguro sin requerir ninguna modificación al protocolo subyacente, a Bitcoin o a las contrapartes, mientras mantiene un alto rendimiento de pagos.

Autores originales: Paul Gerhart, Nadav Kohen, Jesse Posner, Matias Furszyfer

Publicado 2026-08-24

📖 7 min de lectura🧠 Análisis profundo

CC BY 4.0

Autores originales: Paul Gerhart, Nadav Kohen, Jesse Posner, Matias Furszyfer

Artículo original bajo licencia CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo

En el mundo digital de Bitcoin, el dinero se mueve a través de dos capas distintas. La capa principal, conocida como la cadena de bloques (blockchain), es un libro de contabilidad público donde las transacciones se registran de forma permanente. Sobre esta se asienta la Lightning Network, un sistema más rápido y privado diseñado para gestionar miles de pagos por segundo sin saturar el libro de contabilidad principal. Para utilizar este sistema, dos personas abren un canal privado entre ellas, bloqueando sus fondos bajo un candado digital especial que requiere la aprobación de ambos para poder gastarlos. Esta configuración se ha vuelto vital para las grandes instituciones financieras, gestionando cientos de millones de dólares en valor. Sin embargo, una debilidad crítica ha persistido desde el inicio de la red: las llaves digitales que controlan estos fondos en cada lado del canal se encuentran en un único dispositivo. Si ese único dispositivo es robado, hackeado o simplemente se pierde, los fondos desaparecen para siempre. No hay copia de seguridad, no hay recuperación y no hay forma de dividir la autoridad entre varias personas o máquinas.

Durante años, los expertos han sabido que la solución reside en la "custodia de umbral" (threshold custody), un método donde un grupo de personas debe acordar la firma de una transacción, pero no es necesario que todos los miembros estén presentes. Esta es una práctica estándar para asegurar grandes sumas en la cadena de bloques principal, pero ha sido imposible de aplicar a la Lightning Network. La razón es un estancamiento técnico: la Lightning Network requiere un apretón de manos específico y rígido entre dos partes para actualizar los saldos, y este apretón de manos no permite que un lado revele repentinamente que en realidad es un grupo de personas. Si un lado intentara usar una llave de grupo, rompería el protocolo, obligando a la otra persona a cambiar su software o a que toda la red se adapte. Esto ha dejado a la Lightning Network vulnerable, dependiendo de puntos únicos de fallo frágiles mientras el resto del mundo financiero avanza hacia una seguridad más robusta y distribuida.

Un equipo de investigadores ha resuelto este problema mediante la invención de un nuevo método criptográfico llamado Iceberg. Su trabajo permite que un lado de un canal de Lightning opere como un grupo seguro de firmantes mientras aparece ante el otro lado como un usuario único y ordinario. Imagine una caja fuerte bancaria que requiere que tres gerentes la abran, pero que para el mundo exterior parezca que una sola persona está girando la llave. Los investigadores lograron esto creando un sistema donde el acuerdo interno del grupo ocurre de forma invisible, entre bastidores, sin alterar nunca los mensajes enviados a la contraparte. El resultado es una forma de distribuir el riesgo y evitar la pérdida total sin requerir cambios en la red Bitcoin, en el protocolo Lightning o en el software utilizado por la otra persona en el canal.

El núcleo de la innovación reside en cómo el grupo gestiona los "nonces" digitales, que son números aleatorios utilizados para crear una firma. En la Lightning Network, estos números deben acordarse antes de que siquiera se conozcan los detalles específicos de la transacción. Esto crea un desafío único: si el grupo cambia sus miembros entre el momento en que se elige el número y el momento en que se firma la transacción, la firma podría fallar o volverse insegura. Los intentos previos de resolver esto requerían que todos los miembros estuvieran conectados al mismo tiempo o forzaban al grupo a revelar su estructura interna. El sistema Iceberg supera esto mediante el uso de una técnica llamada intercambio de secretos replicado (replicated secret sharing). En esta configuración, cada miembro del grupo posee una pieza de la clave secreta, pero las piezas están dispuestas de tal manera que cualquier pequeña mayoría del grupo puede reconstruir los números necesarios, independientemente de quién esté conectado en ese momento. Crucialmente, el sistema deriva estos números de una manera que depende únicamente del estado del canal, no de qué miembros específicos estén presentes. Esto significa que si algunos miembros se desconectan o si la composición del grupo cambia, los miembros restantes aún pueden producir la misma firma exacta que se prometió anteriormente, manteniendo el canal seguro y funcional.

Para demostrar que este concepto funciona en el mundo real, los investigadores construyeron un prototipo funcional y lo integraron en un nodo de producción de Lightning, una pieza de software utilizada para enrutar pagos. Probaron el sistema bajo diversas condiciones, simulando grupos de diferentes tamaños y tolerando distintos números de miembros defectuosos o ausentes. Los resultados mostraron que el nuevo método añade solo una cantidad mínima de tiempo al proceso de pago. Para un grupo diseñado para tolerar un miembro corrupto, el tiempo adicional requerido fue de apenas 3,8 milisegundos por pago. Esto representa un incremento de apenas el 6,7 por ciento en el trabajo computacional que ya requiere una transacción estándar. Incluso con grupos más grandes diseñados para manejar más fallos, el sistema mantuvo una alta velocidad, sosteniendo más del 93 por ciento del rendimiento de pagos de un canal estándar y sin modificar. Esto demuestra que la seguridad de la custodia de umbral puede añadirse a la Lightning Network hoy mismo sin sacrificar la velocidad que hace que la red sea útil.

La seguridad de este nuevo sistema también fue rigurosamente probada. Los investigadores demostraron que, mientras el grupo tenga una mayoría de miembros honestos, es matemáticamente imposible que un atacante falsifique una firma o robe los fondos, incluso si controla algunos de los dispositivos del grupo. La prueba tiene en cuenta la compleja realidad de la Lightning Network, donde los miembros pueden desconectarse, los mensajes pueden retrasarse y el grupo puede necesitar acordar el estado actual del canal antes de firmar. Al formalizar un nuevo tipo de primitiva criptográfica llamada "multifirmas de umbral anidadas" (nested threshold multi-signatures), el equipo proporcionó una garantía matemática de que el grupo actúa como una entidad única y segura. Esto significa que las instituciones y los individuos pueden ahora desplegar esta protección de forma unilateral; pueden mejorar su propia seguridad sin pedir a nadie más que cambie su software o sin esperar a una actualización de toda la red.

Las implicaciones de este trabajo van más allá de simplemente solucionar una vulnerabilidad; cambian nuestra forma de pensar sobre la seguridad de los activos digitales en un sistema distribuido. Durante años, la Lightning Network fue vista como un compromiso: la velocidad y la privacidad venían al costo de depender de llaves únicas y frágiles. Iceberg elimina ese compromiso, permitiendo que la red escale con el mismo nivel de seguridad que las grandes instituciones ya demandan para sus activos en la cadena (on-chain). Los investigadores verificaron que su sistema funciona perfectamente con el hardware y el software existentes, lo que significa que la transición a este modelo más seguro puede ocurrir de inmediato. Al integrar la solución en un nodo del mundo real y medir su rendimiento, trasladaron el concepto de una posibilidad teórica a una herramienta práctica. Los hallazgos confirman que la Lightning Network puede ahora soportar el tipo de custodia multipartita robusta que protege contra el robo y la pérdida accidental.

Este avance no depende de cambiar las reglas fundamentales de Bitcoin o de la Lightning Network. En su lugar, funciona encajando un complejo sistema de seguridad multipersona dentro del espacio simple de una sola persona que la red espera. Es un recordatorio de que, a veces, las soluciones más efectivas no consisten en construir algo nuevo desde cero, sino en encontrar una manera de hacer que las estructuras existentes soporten más peso. Los investigadores han demostrado que, con el enfoque matemático adecuado, es posible ocultar un grupo de guardianes detrás de una sola cara, asegurando que el dinero digital que se mueve a la velocidad de la luz sea tan seguro como las personas que lo utilizan. El camino a seguir es ahora claro: la tecnología para proteger estos fondos existe, y la única barrera que queda es la decisión de adoptarla.

Resumen Técnico: Habilitación de la Custodia de Umbral para la Red Lightning mediante Multi-firmas de Umbral Anidadas

1. Planteamiento del Problema

La Red Lightning de Bitcoin asegura cientos de millones de dólares en valor, sin embargo, su modelo de seguridad descansa sobre una base frágil: cada extremo de canal está controlado por una única clave en línea. Esto crea un punto único de falla, susceptible tanto al compromiso (robo) como a la pérdida (inaccesibilidad). Si bien la custodia de umbral (firma t-de-n) es una práctica estándar para los activos on-chain de Bitcoin para mitigar estos riesgos, no ha sido desplegable de manera práctica para los canales de Lightning.

El obstáculo técnico central es la estructura del protocolo Lightning, específicamente su dependencia del esquema de multi-firma MuSig2 (estandarizado en BIP 327). En un canal de Lightning, dos partes (Alice y Bob) bloquean fondos bajo una clave agregada. Para actualizar los saldos o cerrar el canal, deben intercambiar nonces y firmas parciales en un protocolo estricto de dos rondas.

La Restricción del Nonce: MuSig2 requiere que el nonce de la sesión se fije en la primera ronda, antes de que se conozca el mensaje (la transacción a firmar).
El Conflicto de Umbral: Si una parte (por ejemplo, Alice) es un grupo de umbral, el conjunto de firmantes en línea puede cambiar entre la primera ronda (generación del nonce) y la segunda ronda (generación de la firma). Los esquemas de firma de umbral estándar (como FROST) vinculan el nonce agregado al conjunto específico de firmantes que participan en esa ronda. Si el quórum cambia, el nonce reconstruido diferirá del que Alice prometió a Bob en la primera ronda, rompiendo el protocolo.
Estatalidad vs. Seguridad: Las firmas de umbral sin estado (que derivan los nonces de forma determinista a partir del mensaje) no pueden usarse porque el mensaje es desconocido durante la primera ronda. Además, los firmantes completamente sin estado en Lightning serían vulnerables a firmar estados de canal desactualizados, activando los mecanismos de penalización de la red (confiscación de fondos).

Consecuentemente, la comunidad ha carecido de un método para "anidar" un grupo de umbral dentro de una sesión MuSig2 existente sin alterar el protocolo, la contraparte o la cadena de bloques.

2. Metodología y Diseño

Los autores proponen Iceberg, la primera construcción para firmas MuSig2 de umbral anidadas. Iceberg permite que un grupo t-de-n ocupe un único espacio de firmante en un protocolo MuSig2, apareciendo indistinguible de un participante de clave única estándar ante la contraparte y la cadena de bloques.

La solución se basa en tres decisiones de diseño clave para satisfacer las restricciones del entorno de Lightning:

Distribución de Secretos Replicada (RSS): Para asegurar que el nonce permanezca consistente independientemente de qué subconjunto de firmantes esté en línea, Iceberg utiliza distribución de secretos replicada en lugar de la distribución de Shamir estándar. La clave secreta se divide en partes para cada subconjunto de $t-1$ miembros. Cada miembro posee partes correspondientes a los subconjuntos en los que no participa. Esto permite que cualquier quórum calificado ( $2t-1$ miembros) reconstruya las mismas partes de nonce deterministas sin necesidad de comunicarse con los miembros que estuvieron fuera de línea durante la primera ronda.
Nonces Únicos Pre-Mensaje: Dado que el nonce debe fijarse antes de que se conozca el mensaje, Iceberg deriva el nonce de forma determinista a partir del identificador de sesión (que incluye el número de compromiso del canal) en lugar del mensaje mismo. Esto asegura que el nonce sea fijo en la primera ronda pero único para cada actualización del estado del canal, evitando la filtración de claves que ocurriría si se reutilizara el mismo nonce para diferentes mensajes.
Consenso sobre el Estado Vivo: Para prevenir el riesgo de seguridad de firmar dos mensajes diferentes bajo el mismo identificador de sesión (lo que filtraría la clave), el protocolo depende del requisito existente de consenso sobre el número de compromiso actual en el canal de Lightning. El grupo de umbral debe acordar el estado vivo antes de firmar, asegurando que una supermayoría honesta ( $n \ge 3t-2$ ) impida que una minoría corrupta fuerce una segunda firma sobre el mismo estado.

Flujo del Protocolo:

KeyGen: El grupo genera una clave secreta compartida usando RSS. La clave pública agregada ocupa el espacio del grupo en la salida de financiación.
PreRound (Fuera de Línea): Antes de que exista el mensaje, el grupo computa las partes del nonce basadas en el identificador de sesión. Estas se agregan en un único nonce de grupo $R_A$ enviado a la contraparte.
SignRound (En Línea): Una vez que el mensaje y el nonce de la contraparte son conocidos, el quórum en línea computa las firmas parciales utilizando sus partes de clave y partes de nonce. Estas se agregan en una única firma parcial $s_A$ .
Resultado: La contraparte combina $s_A$ y su propia $s_B$ para formar una firma MuSig2 válida. La cadena de bloques solo ve una firma Schnorr estándar bajo la clave agregada.

3. Contribuciones Clave

Formalización de las Multi-firmas de Umbral Anidadas: El artículo introduce un nuevo primitivo criptográfico diseñado para umbralizar un participante dentro de un protocolo de multi-firma existente sin alterar el flujo de mensajes o el intercambio de nonces del protocolo externo.
La Construcción Iceberg: Una implementación concreta y demostrablemente segura de MuSig2 de umbral anidado. Es el primer esquema que soporta quórums dinámicos (donde el conjunto de firma puede cambiar entre rondas) manteniendo los estrictos requisitos de nonce de Lightning.
Prueba de Seguridad: Los autores demuestran la infalsificabilidad de Iceberg bajo el modelo de seguridad TS-MS-EUF-CMA. La prueba reduce la seguridad de Iceberg a la seguridad del esquema MuSig2 anidado subyacente, demostrando que la infalsificabilidad se mantiene incluso si un adversario compromete hasta $t-1$ miembros y controla al co-firmante externo.
Integración en Producción: Iceberg fue integrado en eclair, una implementación de nodo Lightning de producción. La integración no requirió cambios en la lógica del canal, el flujo de mensajes o el software de la contraparte.

4. Resultados y Rendimiento

Los autores evaluaron el rendimiento de Iceberg en un entorno de producción utilizando la curva secp256k1 y el nodo eclair.

Sobrecarga: El proceso de umbral en un canal incurre en una sobrecarga computacional modesta.
- Para una configuración 2-de-4 (tolerando 1 falla), el costo adicional total por pago es de 3.8 ms (específicamente 3,844 µs), lo que representa el 6.7% del trabajo que ya cuesta un pago.
- Para una configuración 3-de-7 (tolerando 2 fallas), el costo adicional total es de 8.2 ms (específicamente 8,246 µs), lo que representa aproximadamente el 14.3% del trabajo de pago.
Capacidad de Procesamiento (Throughput): Un extremo con umbral mantiene un alto rendimiento. Un grupo 2-de-4 mantiene más del 93% del rendimiento de pagos de un extremo no modificado (aprox. 16.3 pagos por segundo en un solo núcleo frente a 17.4 para una clave única).
Escalabilidad: El crecimiento del costo es impulsado principalmente por el umbral de tolerancia a fallas ( $t$ ) más que por el tamaño total del grupo ( $n$ ), siempre que $n$ se mantenga dentro de límites prácticos (por ejemplo, una docena de dispositivos).
Compatibilidad: El prototipo pasó con éxito todas las pruebas de canal existentes de eclair y verificó que el grupo nunca revisa su nonce incluso cuando el quórum de firma cambia entre rondas, satisfaciendo las estrictas restricciones del protocolo Lightning.

5. Significado y Reivindicaciones

El artículo afirma que Iceberg permite el despliegue unilateral de la custodia de umbral en la Red Lightning hoy mismo.

Sin Cambios en el Protocolo: A diferencia de propuestas anteriores que requerían cambios en Bitcoin Script o en el propio protocolo Lightning, Iceberg funciona dentro de la especificación actual de MuSig2 de BIP 327.
Sin Cambios en la Contraparte: La contraparte (Bob) y la cadena de bloques solo ven un participante de clave única estándar de MuSig2. No se requiere coordinación ni actualizaciones de software por parte del otro lado del canal.
Practicidad: La sobrecarga de rendimiento es lo suficientemente baja como para que las instituciones y los usuarios puedan adoptar la custodia de umbral de inmediato sin sacrificar la velocidad o la capacidad de la Red Lightning.

Los autores concluyen que Iceberg resuelve un problema de larga data en la comunidad de Bitcoin, demostrando que el proceso de umbral en un canal de Lightning es alcanzable sin comprometer la eficiencia o las garantías de seguridad del protocolo. Señalan que trabajos futuros podrían explorar la renovación proactiva de las partes o el cambio de membresía mientras un canal está abierto, siempre que la clave agregada permanezca constante.