Coordinamento Multi-Firma in un Mondo Peer-to-Peer

Stiamo risolvendo il coordinamento multi-firma senza server — il problema difficile che il settore ha centralizzato

·

Coordinamento Multi-Firma in un Mondo Peer-to-Peer hero image

I wallet multi-firma sono ingannevolmente semplici in teoria. Due amici che vogliono co-firmare transazioni, una DAO treasury che richiede l'approvazione del consiglio, un'azienda con più stakeholder — il concetto è lineare. La parte difficile non è la crittografia né i meccanismi on-chain. È il coordinamento.

Come fanno i partecipanti a scoprire una sessione di firma in corso? Chi trasmette la transazione finale? Cosa succede quando Alice va offline a metà firma, il coordinatore di Bob va in crash e Charlie non ricorda se ha già inviato la sua firma parziale? Le soluzioni tradizionali glissano su queste domande: "usate un server fidato" o "coordinatevi fuori banda" o "semplicemente gestite la vostra infrastruttura."

Queste non sono soluzioni — sono scaricabarile verso la centralizzazione o l'onere operativo. Ma il coordinamento peer-to-peer è risolvibile con un'attenta ingegneria dei sistemi distribuiti.

Questo articolo descrive come noi abbiamo costruito un coordinamento multi-firma veramente decentralizzato per Lotus, e perché è importante per l'ecosistema delle criptovalute nel suo complesso.

Cos'è MuSig2 e Perché È Importante?

MuSig2 è un protocollo di multi-firma per le firme Schnorr. Più parti collaborano per produrre una singola firma aggregata che è crittograficamente indistinguibile da una transazione a firma singola.

I vantaggi in termini di privacy ed efficienza sono sostanziali. Il P2SH tradizionale per la multi-firma con tre partecipanti richiede 99 byte di chiavi pubbliche e 210 byte di firme — 309 byte totali. MuSig2 con Taproot utilizza 33 byte per la chiave pubblica e 64 byte per la firma — 97 byte, una riduzione del 69%. Ancora più importante, la transazione non rivela alcuna informazione su quante parti fossero coinvolte o quale fosse la soglia di firma.

Le proprietà di sicurezza sono rigorose. MuSig2 previene gli attacchi rogue key tramite coefficienti di aggregazione delle chiavi derivati da tutte le chiavi dei partecipanti. Previene gli attacchi di riutilizzo del nonce (che esporrebbero le chiavi private) attraverso una gestione attenta delle sessioni e la generazione deterministica dei nonce. Lo schema è dimostrabilmente sicuro sotto l'ipotesi del logaritmo discreto, la stessa ipotesi che garantisce la sicurezza delle firme Schnorr e ECDSA a firma singola.

Combinato con Taproot, MuSig2 abilita comportamenti on-chain sofisticati che appaiono come semplici pagamenti:

  • Canali di pagamento con risoluzione complessa delle controversie — il canale in stile Lightning di Alice e Bob appare come un indirizzo standard
  • DAO treasury che richiedono l'approvazione unanime del consiglio — una multi-firma 3-di-3 o 5-di-5 appare come una singola chiave
  • Vault con time lock — fondi bloccati per sei mesi a meno che tutte le parti concordino un rilascio anticipato
  • Spesa condizionale — "paga Bob se queste condizioni sono soddisfatte, altrimenti rimborsa Alice"

Tutto questo appare on-chain come semplici transazioni a firma singola, a meno che non venga utilizzato lo script path. Non si tratta di privacy di facciata. Quando le transazioni sofisticate si confondono perfettamente con l'attività quotidiana, l'analisi della blockchain diventa fondamentalmente più difficile. Tutti ne beneficiano.

Il protocollo è standardizzato come BIP-327, implementato in Bitcoin Core e verificato da crittografi. Ma ecco il punto critico: MuSig2 richiede due round di comunicazione interattiva.

Il Problema del Coordinamento Centralizzato

MuSig2 non è uno smart contract che si deploy e si dimentica. È un protocollo interattivo che richiede un'orchestrazione attenta:

Round 1: Scambio dei Nonce Ogni partecipante genera i nonce usando la generazione deterministica RFC 6979 (con entropia casuale aggiuntiva per impostazione predefinita per la sicurezza in produzione) e condivide i nonce pubblici. Tutti devono ricevere i nonce pubblici di tutti gli altri prima di procedere.

Round 2: Scambio delle Firme Parziali Ogni partecipante crea una firma parziale usando la propria chiave privata, il nonce aggregato e i dati della transazione. Queste firme parziali vengono combinate nella firma finale.

Trasmissione Qualcuno deve inviare la transazione alla rete. Chi? E se rifiuta? E se va in crash?

Questo crea un problema di coordinamento con diverse sotto-problematiche complesse:

Scoperta e Gestione delle Sessioni

Quando Alice vuole spendere da un indirizzo 3-di-3 che condivide con Bob e Charlie, come fa il suo wallet a comunicare a Bob e Charlie che una sessione di firma è iniziata? La blockchain non può aiutare — il punto è che nulla accade on-chain finché la firma non è completa. Gli approcci tradizionali:

  • Server coordinatore centralizzato: tutti si connettono a un servizio centrale che inoltra i messaggi. Funziona finché il server non è down, non censura le transazioni, non viene compromesso, o l'operatore non decide di applicare commissioni.
  • Coordinamento manuale: "Alice invia a Bob e Charlie l'hex della transazione via email. Bob risponde con la sua firma parziale. Charlie è in vacanza e non risponde per tre giorni." Questo non scala.
  • Infrastruttura self-hosted: tutti gestiscono un server con IP pubblico e si coordinano tramite connessioni dirette. Questo esclude i wallet mobili, gli utenti dietro NAT e chiunque non sia disposto a gestire infrastruttura server.

Autenticazione e Sicurezza

Come verificano i partecipanti che i messaggi provengano effettivamente dai co-firmatari previsti? In un sistema decentralizzato senza autorità centrale, ogni peer deve verificare indipendentemente l'autenticità dei messaggi. La soluzione richiede prove crittografiche: i messaggi vengono firmati con la chiave privata del mittente, e i destinatari verificano la firma rispetto alla chiave pubblica dichiarata prima di elaborarli.

Attacchi Replay e Riutilizzo del Nonce

Cosa impedisce a Eve di registrare il nonce di Alice da una sessione precedente e riprodurlo? Riutilizzare i nonce con messaggi diversi espone le chiavi private. Il protocollo deve imporre transizioni di fase rigorose: non si può inviare una firma parziale prima che i nonce siano stati raccolti, non si possono riutilizzare i nonce tra sessioni diverse e non si possono firmare transazioni differenti nella stessa sessione.

Guasti del Coordinatore e Failover

Qualcuno deve aggregare le firme parziali e trasmettere la transazione. La scelta ovvia è designare un partecipante come coordinatore. Ma cosa succede quando si disconnette? Si aspetta indefinitamente? I partecipanti si accordano manualmente su un nuovo coordinatore fuori banda?

Rate Limiting e Protezione DoS

In un sistema peer-to-peer, cosa impedisce ad attori malevoli di inondare le sessioni di firma con dati spazzatura? Servono rate limiting, tracciamento della reputazione e la capacità di bandire i peer che si comportano male — ma senza un'autorità centrale.

La Soluzione Lotusia

Il nostro approccio combina tre pattern collaudati dei sistemi distribuiti in un livello di coordinamento peer-to-peer coerente:

1. Scoperta Multi-Livello

Utilizziamo l'infrastruttura collaudata di libp2p con tre meccanismi di scoperta complementari:

DHT (Tabella Hash Distribuita): gli annunci di sessione vengono memorizzati nella DHT Kademlia (con replicazione k=20) usando un identificativo di sessione derivato dai firmatari partecipanti e dal messaggio. Quando Alice crea una sessione di firma, pubblica un annuncio sulla DHT. Bob e Charlie possono scoprirlo interrogando la DHT con l'ID della sessione. Questo fornisce un archivio persistente e decentralizzato senza server centrale — le sessioni rimangono scopribili anche quando il creatore va offline.

GossipSub: per la scoperta dei firmatari in tempo reale, i partecipanti pubblicano annunci su topic PubSub organizzati per tipo di transazione (ad es. musig2:signers:SWAP). Quando Bob annuncia la sua disponibilità per atomic swap, Alice riceve la notifica in 10-100 ms se è iscritta a quel topic. Questo fornisce una scoperta istantanea dei peer senza i ritardi del polling DHT.

Protocollo di Messaggi Diretti: una volta che i partecipanti si scoprono a vicenda, i messaggi di coordinamento (nonce, firme parziali) vengono inviati tramite il protocollo di messaggistica di libp2p con routing peer-to-peer. I messaggi sono cifrati usando il protocollo Noise di libp2p e instradati attraverso la rete verso peer specifici anziché diffusi globalmente.

L'approccio a livelli gestisce scenari diversi: DHT per l'archiviazione persistente delle sessioni e la scoperta dei partecipanti offline, GossipSub per gli annunci dei firmatari in tempo reale e messaggistica diretta tra peer per i round di firma effettivi.

2. Sicurezza Crittografica End-to-End

Ogni messaggio di protocollo è firmato crittograficamente usando firme Schnorr. Annunci di sessione, pubblicità dei firmatari, richieste di firma e adesioni dei partecipanti portano tutti firme che dimostrano che il mittente controlla la propria chiave privata dichiarata. Questo livello di autenticazione previene l'avvelenamento della DHT, gli attacchi di impersonificazione e la manomissione dei messaggi.

L'architettura di sicurezza implementa una difesa in profondità attraverso molteplici livelli indipendenti:

Rate Limiting: i peer possono inviare al massimo un annuncio ogni 60 secondi. Le violazioni innescano un'escalation automatica — 10 violazioni comportano l'inserimento permanente nella blacklist.

Resistenza Sybil: ogni peer può annunciare al massimo 10 chiavi pubbliche per impostazione predefinita (50 per identità verificate, 100 per utenti istituzionali). Questo impedisce a singoli attori di inondare la rete con partecipanti fittizi.

Tracciamento della Reputazione dei Peer: il sistema mantiene blacklist (ban permanenti) e graylist (sospensioni temporanee) basate sul comportamento. Firme invalide, violazioni del rate limiting e tentativi di spam contribuiscono tutti ai punteggi di reputazione che determinano il trattamento dei peer.

Applicazione delle Fasi del Protocollo: macchine a stati assicurano il corretto ordinamento dei messaggi. I nonce non possono essere inviati prima dell'istituzione della sessione. Le firme parziali non possono essere inviate prima del completamento dell'aggregazione dei nonce. Le transazioni non possono essere trasmesse prima della finalizzazione della firma.

Protezione Replay dei Messaggi: ogni messaggio include un numero di sequenza strettamente crescente per firmatario per sessione. Numeri di sequenza duplicati o fuori ordine innescano il rifiuto e penalità alla reputazione.

Identità basata su Burn (opzionale): i partecipanti possono ancorare la propria identità a transazioni blockchain bruciando dimostrabilmente XPI in un formato specifico con tag LOKAD. Queste identità consentono la rotazione delle chiavi senza perdita di reputazione — l'identità è legata a (txId, outputIndex), non a chiavi effimere, e richiede periodi di maturazione (144 blocchi per la registrazione, 6 blocchi per la rotazione) per prevenire attacchi temporali. In una futura implementazione, questo potrebbe diventare un componente obbligatorio per stabilire la reputazione tra peer.

3. Elezione Deterministica del Coordinatore

Questo è l'elemento che rende il failover elegante. Invece di designare manualmente un coordinatore, tutti i partecipanti eseguono lo stesso algoritmo deterministico.

Il metodo di elezione predefinito è l'ordinamento lessicografico:

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
  }
}

Tutti forniscono le stesse chiavi pubbliche, tutti le ordinano in modo identico, tutti selezionano la prima — nessuna votazione, nessuna comunicazione, nessuna ambiguità. L'ordinamento corrisponde esattamente a come l'aggregazione delle chiavi di MuSig2 ordina i partecipanti, garantendo coerenza lungo tutto il protocollo.

Quando il coordinatore va in crash o rifiuta di trasmettere? Il sistema effettua automaticamente il failover verso il partecipante successivo nell'ordine. Questo continua fino a N-1 guasti, il che significa che una multi-firma 3-di-3 diventa non responsive solo se tutti e tre i partecipanti sono offline contemporaneamente.

Il determinismo è cruciale. Nei sistemi distribuiti, il consenso è costoso. Ma quando si può prendere una decisione senza coordinarsi — perché tutti calcolano indipendentemente la stessa risposta — si eliminano intere classi di modalità di guasto. L'implementazione supporta anche metodi di elezione basati su hash, primo firmatario e ultimo firmatario per casi d'uso specifici.

Cosa Questo Abilita

Questi pattern si combinano per supportare casi d'uso che in precedenza richiedevano infrastruttura centralizzata:

Treasury Multi-Firma: dai conti condivisi 2-di-2 alle treasury di consiglio 10-di-10 (tutti n-di-n), con failover automatico del coordinatore che garantisce la possibilità di spesa anche durante interruzioni parziali.

Canali di Pagamento: canali a due parti (Alice ↔ Bob) dove entrambe le parti possono avviare aggiornamenti del canale, e il canale rimane operativo anche se il software coordinatore di una delle parti va in crash.

Atomic Swap: veri swap cross-chain peer-to-peer dove i partecipanti coordinano la firma simultanea di entrambi i lati dello swap senza terze parti.

Vault con Time Lock: fondi che richiedono la firma di tutti i partecipanti prima di un timeout, e una firma singola dopo — con il coordinamento multi-firma che avviene senza soluzione di continuità in background.

Protocollo Privacy SwapSig: il nostro equivalente di CoinJoin in cui più parti si coordinano per creare una singola transazione con input e output unificati, rompendo la tracciabilità on-chain pur mantenendo la verifica individuale delle firme. Un futuro articolo del blog farà un'analisi approfondita di SwapSig.

L'infrastruttura è general-purpose. Qualsiasi cosa richieda la firma interattiva multi-parte può utilizzarla.

Implicazioni per l'Ecosistema Crypto nel suo Complesso

Questa implementazione è agnostica rispetto alla criptovaluta. Il livello di coordinamento opera indipendentemente dal consenso della blockchain — puro networking P2P e scambio di messaggi crittografici. Bitcoin può adottarlo per la multi-firma Taproot. Ethereum può usarlo per le firme a soglia nell'account abstraction. Qualsiasi criptovaluta che supporta le firme Schnorr può integrare questa infrastruttura. Canali Lightning, atomic swap, protocolli privacy, governance DAO e operazioni DeFi richiedono tutti un coordinamento interattivo multi-parte. La stessa infrastruttura risolve tutti questi problemi.

Ancora più importante, questo dimostra che il coordinamento decentralizzato è praticabile per i sistemi di produzione. L'industria ha adottato per default coordinatori centralizzati non perché il coordinamento P2P sia impossibile, ma perché nessuno aveva rilasciato un'implementazione funzionante. Quando esiste un'infrastruttura riutilizzabile — come TCP/IP per il networking o TLS per la cifratura — gli sviluppatori smettono di trattare il problema come opzionale. Questo cambia l'aspettativa di base: il coordinamento decentralizzato diventa la norma anziché l'eccezione.

Stato dell'Implementazione e Prossimi Passi

L'implementazione è completa e funzionante. Oltre 91 test validano l'implementazione del protocollo, l'elezione del coordinatore, gli scenari di failover, l'autenticazione dei messaggi e la protezione replay. Il codice è in sviluppo attivo da settimane e gestisce i casi limite scoperti attraverso test estensivi.

La gestione delle connessioni è propriamente isolata. Il vostro wallet mantiene connessioni P2P generali alla rete Lotus, e queste sono separate dalle connessioni specifiche per le sessioni di firma. I limiti di connessione del wallet non bloccheranno le sessioni multi-firma, e l'attività multi-firma non esaurirà gli slot peer generali.

La chiave pubblica aggregata MuSig2 diventa la chiave interna Taproot. Gli alberi di script complessi (per condizioni di fallback o time lock) rimangono nascosti a meno che non si spenda tramite lo script path, rivelando solo il ramo utilizzato.

L'implementazione risiede in lotus-sdk, il nostro moderno SDK TypeScript per Lotus. Esempi funzionanti dimostrano:

  • Firma base 2-di-2 con scoperta automatica
  • Elezione del coordinatore multi-parte e failover
  • Integrazione Taproot con spesa tramite key path e script path
  • Gestione delle sessioni e protezione replay

La documentazione tecnica copre le decisioni architetturali, le considerazioni sulla sicurezza, l'utilizzo delle API e le procedure di test.

La Strada da Percorrere

MuSig2 ha risolto in modo elegante e dimostrabile il problema matematico delle firme Schnorr multi-parte, ma l'infrastruttura di coordinamento è rimasta centralizzata. Questa implementazione dimostra che il coordinamento peer-to-peer è pratico. L'infrastruttura è general-purpose e riutilizzabile — si costruisce una volta, si usa ovunque. La tecnologia dovrebbe migliorare le relazioni umane, non ostacolarle o sostituirle.

Ora viene la parte cruciale: sperimentazione e iterazione. Il software matura attraverso l'uso reale, non la speculazione. Scoprite come funziona la reputazione della comunità in pratica sui profili social di Lotusia, oppure leggete come classifichiamo i contenuti. Installate lotus-sdk, sperimentate con gli esempi, mettete alla prova il protocollo, segnalate problemi. L'uso nel mondo reale farà emergere casi limite e informerà la prossima iterazione. Lotus è sempre stato un progetto che fa le cose per bene. La Tartaruga Lotusiana si muove lentamente, ma deliberatamente, verso la vittoria; un passo attento alla volta.

Risorse:

Comunità: