Las carteras multifirma son engañosamente simples en teoría. Dos amigos que quieren cofirmar transacciones, una tesorería DAO que requiere aprobación del consejo, un negocio con múltiples partes interesadas — el concepto es sencillo. La parte desafiante no es la criptografía ni los mecanismos on-chain. Es la coordinación.
¿Cómo descubren los participantes una sesión de firma pendiente? ¿Quién transmite la transacción final? ¿Qué sucede cuando Alice se desconecta a mitad de una firma, el coordinador de Bob falla y Charlie no puede recordar si ya envió su firma parcial? Las soluciones tradicionales evaden estas preguntas: "usa un servidor de confianza" o "coordina fuera de banda" o "simplemente ejecuta tu propia infraestructura."
Estas no son soluciones — son cesiones a la centralización o a la carga operativa. Pero la coordinación peer-to-peer es resoluble con ingeniería cuidadosa de sistemas distribuidos.
Este artículo describe cómo nosotros construimos una coordinación multifirma verdaderamente descentralizada para Lotus, y por qué importa para el ecosistema más amplio de criptomonedas.
¿Qué es MuSig2 y Por Qué Importa?
MuSig2 es un protocolo de multifirma para firmas Schnorr. Múltiples partes colaboran para producir una única firma agregada que es criptográficamente indistinguible de una transacción de firma única.
Las ganancias en privacidad y eficiencia son sustanciales. La multifirma tradicional P2SH para tres participantes requiere 99 bytes de claves públicas y 210 bytes de firmas — 309 bytes en total. MuSig2 con Taproot usa 33 bytes para la clave pública y 64 bytes para la firma — 97 bytes, una reducción del 69%. Más importante aún, la transacción no proporciona información sobre cuántas partes estuvieron involucradas o cuál era el umbral de firma.
Las propiedades de seguridad son rigurosas. MuSig2 previene ataques de clave maliciosa a través de coeficientes de agregación de claves derivados de todas las claves de los participantes. Previene ataques de reutilización de nonce (que filtrarían claves privadas) mediante una gestión cuidadosa de sesiones y generación determinística de nonces. El esquema es demostrablemente seguro bajo la suposición del logaritmo discreto, la misma suposición que asegura Schnorr y ECDSA de firma única.
Cuando se combina con Taproot, MuSig2 permite comportamientos sofisticados on-chain que parecen pagos básicos:
- Canales de pago con resolución de disputas complejas — el canal estilo Lightning de Alice y Bob aparece como una dirección estándar
- Tesorerías DAO que requieren aprobación unánime del consejo — una multifirma 3-de-3 o 5-de-5 aparece como una sola clave
- Bóvedas con bloqueos temporales — fondos bloqueados por seis meses a menos que todas las partes acuerden la liberación anticipada
- Gasto condicional — "paga a Bob si se cumplen estas condiciones, de lo contrario reembolsa a Alice"
Todo esto aparece on-chain como transacciones simples de firma única a menos que se use la ruta de script. Esto no es solo teatro de privacidad. Cuando las transacciones sofisticadas se mezclan perfectamente con la actividad cotidiana, el análisis de blockchain se vuelve fundamentalmente más difícil. Todos se benefician.
El protocolo está estandarizado como BIP-327, implementado en Bitcoin Core y auditado por criptógrafos. Pero aquí está el problema: MuSig2 requiere dos rondas de comunicación interactiva.
El Problema de la Coordinación Centralizada
MuSig2 no es un contrato inteligente que despliegas y olvidas. Es un protocolo interactivo que requiere orquestación cuidadosa:
Ronda 1: Intercambio de Nonces Cada participante genera nonces usando generación determinística RFC 6979 (con entropía aleatoria adicional por defecto para seguridad en producción) y comparte los nonces públicos. Todos deben recibir los nonces públicos de los demás antes de proceder.
Ronda 2: Intercambio de Firmas Parciales Cada participante crea una firma parcial usando su clave privada, el nonce agregado y los datos de la transacción. Estas firmas parciales se combinan en la firma final.
Transmisión Alguien tiene que enviar la transacción a la red. ¿Quién? ¿Qué pasa si se niega? ¿Qué pasa si su sistema falla?
Esto crea un problema de coordinación con varios subproblemas desafiantes:
Descubrimiento y Gestión de Sesiones
Cuando Alice quiere gastar desde una dirección 3-de-3 que comparte con Bob y Charlie, ¿cómo le dice su cartera a Bob y Charlie que se ha iniciado una sesión de firma? La blockchain no puede ayudar — todo el punto es que nada sucede on-chain hasta que la firma esté completa. Enfoques tradicionales:
- Servidor coordinador centralizado: Todos se conectan a un servicio central que retransmite mensajes. Esto funciona hasta que el servidor cae, censura transacciones, se ve comprometido, o el operador decide cobrar tarifas.
- Coordinación manual: "Alice envía un correo a Bob y Charlie con el hex de la transacción. Bob responde con su firma parcial. Charlie está de vacaciones y no responde en tres días." Esto no escala.
- Infraestructura propia: Todos ejecutan un servidor con IP pública y se coordinan mediante conexiones directas. Esto excluye carteras móviles, usuarios detrás de NAT, y cualquiera que no quiera gestionar infraestructura de servidores.
Autenticación y Seguridad
¿Cómo verifican los participantes que los mensajes realmente provienen de los cofirmantes esperados? En un sistema descentralizado sin autoridad central, cada par debe verificar independientemente la autenticidad de los mensajes. La solución requiere prueba criptográfica: los mensajes se firman con la clave privada del remitente, y los destinatarios verifican la firma contra la clave pública declarada antes de procesar.
Ataques de Repetición y Reutilización de Nonces
¿Qué impide que Eve grabe el nonce de Alice de una sesión anterior y lo reproduzca? Reutilizar nonces con mensajes diferentes filtra claves privadas. El protocolo debe imponer transiciones de fase estrictas: no puedes enviar una firma parcial antes de que se recopilen los nonces, no puedes reutilizar nonces entre sesiones y no puedes firmar transacciones diferentes en la misma sesión.
Fallos del Coordinador y Conmutación por Error
Alguien necesita agregar las firmas parciales y transmitir la transacción. La opción obvia es designar a un participante como coordinador. ¿Pero qué pasa cuando se desconecta? ¿Esperas indefinidamente? ¿Los participantes acuerdan manualmente un nuevo coordinador fuera de banda?
Limitación de Tasa y Protección contra DoS
En un sistema peer-to-peer, ¿qué impide que actores maliciosos inunden las sesiones de firma con basura? Necesitas limitación de tasa, seguimiento de reputación y la capacidad de vetar pares que se comporten mal — pero sin autoridad central.
La Solución de Lotusia
Nuestro enfoque combina tres patrones probados de sistemas distribuidos en una capa de coordinación peer-to-peer coherente:
1. Descubrimiento Multicapa
Usamos la infraestructura probada de libp2p con tres mecanismos de descubrimiento complementarios:
DHT (Tabla de Hash Distribuida): Los anuncios de sesión se almacenan en la DHT Kademlia (con replicación k=20) usando un identificador de sesión derivado de los firmantes participantes y el mensaje. Cuando Alice crea una sesión de firma, publica un anuncio en la DHT. Bob y Charlie pueden descubrirlo consultando la DHT con el ID de sesión. Esto proporciona almacenamiento persistente y descentralizado sin un servidor central — las sesiones permanecen descubribles incluso cuando el creador se desconecta.
GossipSub: Para el descubrimiento de firmantes en tiempo real, los participantes publican anuncios en temas PubSub organizados por tipo de transacción (por ejemplo, musig2:signers:SWAP). Cuando Bob anuncia disponibilidad para intercambios atómicos, Alice recibe la notificación en 10-100ms si está suscrita a ese tema. Esto proporciona descubrimiento instantáneo de pares sin retardos de consulta DHT.
Protocolo de Mensajes Directos: Una vez que los participantes se descubren entre sí, los mensajes de coordinación (nonces, firmas parciales) se envían a través del protocolo de mensajes de libp2p con enrutamiento peer-to-peer. Los mensajes están cifrados usando el protocolo Noise de libp2p y se enrutan a través de la red a pares específicos en lugar de transmitirse globalmente.
El enfoque por capas maneja escenarios diversos: DHT para almacenamiento persistente de sesiones y descubrimiento de participantes fuera de línea, GossipSub para anuncio de firmantes en tiempo real, y mensajería directa entre pares para las rondas de firma reales.
2. Seguridad Criptográfica Integral
Cada mensaje del protocolo está firmado criptográficamente usando firmas Schnorr. Los anuncios de sesión, los anuncios de firmantes, las solicitudes de firma y las incorporaciones de participantes llevan firmas que demuestran que el remitente controla su clave privada declarada. Esta capa de autenticación previene el envenenamiento de DHT, ataques de suplantación y manipulación de mensajes.
La arquitectura de seguridad implementa defensa en profundidad a través de múltiples capas independientes:
Limitación de Tasa: Los pares pueden enviar como máximo un anuncio por cada 60 segundos. Las violaciones activan una escalada automática — 10 violaciones resultan en un bloqueo permanente.
Resistencia a Sybil: Cada par puede anunciar como máximo 10 claves públicas por defecto (50 para identidades verificadas, 100 para usuarios institucionales). Esto previene que actores individuales inunden la red con participantes falsos.
Seguimiento de Reputación de Pares: El sistema mantiene listas negras (bloqueos permanentes) y listas grises (suspensiones temporales) basadas en el comportamiento. Firmas inválidas, violaciones de límites de tasa e intentos de spam contribuyen a las puntuaciones de reputación que determinan el tratamiento de los pares.
Aplicación de Fases del Protocolo: Las máquinas de estado aseguran el orden correcto de los mensajes. Los nonces no pueden enviarse antes del establecimiento de la sesión. Las firmas parciales no pueden enviarse antes de que se complete la agregación de nonces. Las transacciones no pueden transmitirse antes de la finalización de la firma.
Protección contra Repetición de Mensajes: Cada mensaje incluye un número de secuencia estrictamente creciente por firmante por sesión. Los números de secuencia duplicados o desordenados activan el rechazo y penalizaciones de reputación.
Identidad Basada en Quema (opcional): Los participantes pueden anclar su identidad a transacciones de blockchain quemando XPI de manera demostrable en un formato etiquetado con LOKAD específico. Estas identidades permiten la rotación de claves sin pérdida de reputación — la identidad está vinculada a (txId, outputIndex), no a claves efímeras, y requiere períodos de maduración (144 bloques para registro, 6 bloques para rotación) para prevenir ataques temporales. En una implementación futura, esto podría convertirse en un componente obligatorio para establecer la reputación de pares.
3. Elección Determinística del Coordinador
Esta es la pieza que hace que la conmutación por error funcione elegantemente. En lugar de designar manualmente un coordinador, todos los participantes ejecutan el mismo algoritmo determinístico.
El método de elección predeterminado es la ordenación lexicográfica:
function electCoordinator(signers: PublicKey[]): ElectionResult {
// Sort public keys by binary buffer comparison
const sorted = signers
.map((pk, idx) => ({
originalIndex: idx,
publicKey: pk,
buffer: pk.toBuffer(),
}))
.sort((a, b) => a.buffer.compare(b.buffer))
// First in sorted order becomes coordinator
return {
coordinatorIndex: 0,
coordinatorPublicKey: sorted[0].publicKey,
sortedSigners: sorted.map(item => item.publicKey),
// ... index mappings and election proof
}
}
Todos proporcionan las mismas claves públicas, todos las ordenan de forma idéntica, todos seleccionan la primera — sin votación, sin comunicación, sin ambigüedad. La ordenación coincide exactamente con cómo la agregación de claves de MuSig2 ordena a los participantes, asegurando consistencia a lo largo del protocolo.
¿Cuando el coordinador falla o se niega a transmitir? El sistema automáticamente conmuta al siguiente participante en el orden de clasificación. Esto continúa hasta N-1 fallos, lo que significa que una multifirma 3-de-3 solo se vuelve irresponsiva si los tres participantes están fuera de línea simultáneamente.
El determinismo es crítico. En sistemas distribuidos, el consenso es costoso. Pero cuando puedes tomar una decisión sin coordinarte — porque todos calculan independientemente la misma respuesta — eliminas clases enteras de modos de fallo. La implementación también soporta métodos de elección basados en hash, primer firmante y último firmante para casos de uso específicos.
Lo Que Esto Habilita
Estos patrones se combinan para soportar casos de uso que anteriormente requerían infraestructura centralizada:
Tesorerías Multifirma: Desde cuentas compartidas 2-de-2 hasta tesorerías de consejo 10-de-10 (todas n-de-n), con conmutación por error automática del coordinador que asegura la capacidad de gasto incluso durante interrupciones parciales.
Canales de Pago: Canales entre dos partes (Alice ↔ Bob) donde cualquier parte puede iniciar actualizaciones del canal, y el canal permanece operativo incluso si el software coordinador de una parte falla.
Intercambios Atómicos: Verdaderos intercambios entre cadenas peer-to-peer donde los participantes coordinan la firma simultánea de ambos lados del intercambio sin un tercero.
Bóvedas con Bloqueo Temporal: Fondos que requieren que todos los participantes firmen antes de un tiempo límite, firma única después — con la coordinación multifirma ocurriendo de manera transparente en segundo plano.
Protocolo de Privacidad SwapSig: Nuestro equivalente de CoinJoin donde múltiples partes se coordinan para crear una sola transacción con entradas y salidas fusionadas, rompiendo la trazabilidad on-chain mientras se mantiene la verificación individual de firmas. Un futuro artículo del blog hará un análisis profundo de SwapSig.
La infraestructura es de propósito general. Cualquier cosa que requiera firma multiparte interactiva puede usarla.
Implicaciones para el Ecosistema Más Amplio de Criptomonedas
Esta implementación es agnóstica respecto a la criptomoneda. La capa de coordinación opera independientemente del consenso de blockchain — es pura red P2P y paso de mensajes criptográficos. Bitcoin puede adoptarla para multifirma Taproot. Ethereum puede usarla para firmas de umbral en abstracción de cuentas. Cualquier criptomoneda que soporte firmas Schnorr puede integrar esta infraestructura. Los canales Lightning, intercambios atómicos, protocolos de privacidad, gobernanza DAO y operaciones DeFi — todos requieren coordinación multiparte interactiva. La misma infraestructura resuelve todos estos problemas.
Más importante aún, esto demuestra que la coordinación descentralizada es viable para sistemas en producción. La industria ha recurrido por defecto a coordinadores centralizados no porque la coordinación P2P sea imposible, sino porque nadie había entregado una implementación funcional. Cuando existe infraestructura reutilizable — como TCP/IP para redes o TLS para cifrado — los desarrolladores dejan de tratar el problema como opcional. Esto cambia la expectativa base: la coordinación descentralizada se convierte en el estándar en lugar de la excepción.
Estado de la Implementación y Próximos Pasos
La implementación está completa y funcionando. Más de 91 pruebas validan la implementación del protocolo, la elección del coordinador, los escenarios de conmutación por error, la autenticación de mensajes y la protección contra repetición. El código ha estado en desarrollo activo durante semanas y maneja casos límite que descubrimos a través de pruebas exhaustivas.
La gestión de conexiones está debidamente aislada. Tu cartera mantiene conexiones P2P generales a la red Lotus, y estas están separadas de las conexiones de firma específicas de sesión. Los límites de conexión de la cartera no bloquearán las sesiones multifirma, y la actividad multifirma no agotará tus slots generales de pares.
La clave pública agregada de MuSig2 se convierte en la clave interna de Taproot. Los árboles de script complejos (para condiciones de respaldo o bloqueos temporales) permanecen ocultos a menos que se gaste a través de la ruta de script, revelando solo la rama que se utilizó.
La implementación se encuentra en lotus-sdk, nuestro moderno SDK en TypeScript para Lotus. Los ejemplos funcionales demuestran:
- Firma básica 2-de-2 con descubrimiento automático
- Elección de coordinador multiparte y conmutación por error
- Integración con Taproot con gasto por ruta de clave y ruta de script
- Gestión de sesiones y protección contra repetición
La documentación técnica cubre decisiones de arquitectura, consideraciones de seguridad, uso de la API y procedimientos de prueba.
El Camino Hacia Adelante
MuSig2 resolvió el problema matemático de las firmas Schnorr multiparte de manera elegante y demostrable, pero la infraestructura de coordinación permaneció centralizada. Esta implementación demuestra que la coordinación peer-to-peer es práctica. La infraestructura es de propósito general y reutilizable — constrúyela una vez, úsala en todas partes. La tecnología debería mejorar las relaciones humanas, no obstaculizarlas ni reemplazarlas.
Ahora viene la parte crítica: experimentación e iteración. El software madura a través del uso genuino, no de la especulación. Mira cómo funciona la reputación comunitaria en la práctica en los perfiles sociales de Lotusia, o lee sobre cómo clasificamos el contenido. Instala lotus-sdk, experimenta con los ejemplos, rompe el protocolo, reporta problemas. El uso en el mundo real descubrirá casos límite e informará la próxima iteración. Lotus siempre ha consistido en hacer las cosas correctamente. La Tortuga Lotusiana se mueve lentamente, pero deliberadamente, hacia la victoria; un paso cuidadoso a la vez.
Recursos:
- Documentación de MuSig2 P2P - Referencia completa de la API y ejemplos
- Repositorio lotus-sdk - Código fuente y suite de pruebas
- Especificación BIP-327 - Especificación del protocolo MuSig2
- Documentación de Lotus - Guías de blockchain y desarrollo
Comunidad:
- Discord - Discusión técnica en tiempo real
- Telegram - Discurso comunitario
- GitHub Issues - Reportes de errores y solicitudes de funcionalidades