Firme Schnorr e aggregazione multisig

·9 min di lettura·Di SSP Editorial Team
Copertina blu navy di SSP con icone di chiave, scudo, CPU e fulmine su gradiente scuro, capitolo Schnorr della serie Multisig Deep Dive

Nell'articolo precedente abbiamo percorso come SSP costruisce davvero un wallet multisig on-chain: percorsi BIP48, due xpub in ordine lessicografico, un redeem script contro cui la chain controlla. Tutto quel meccanismo è costruito sopra uno schema di firma particolare — ECDSA sulla curva secp256k1, lo stesso schema con cui Bitcoin è uscito nel 2009 e che la maggior parte delle chain ha ereditato.

Questo articolo è sull'altro schema di firma — Schnorr — e su cosa cambia quando ci costruisci multisig sopra. Il titolo principale è che Schnorr supporta l'aggregazione: sotto il protocollo giusto, n firme di n cosigner possono essere combinate in una singola firma che, on-chain, sembra una firma normale di una sola chiave. Il wallet si comporta come un wallet multisig, ma la chain non vede mai la multi-ità. Questo ha conseguenze reali per fee, privacy e per quali tipi di multisig diventano economicamente sostenibili.

TL;DR

  • ECDSA è ciò con cui la maggior parte del multisig attuale (incluso SSP oggi) firma. Ogni cosigner produce una firma separata; la chain le controlla tutte. Costo e impronta scalano con n.
  • Schnorr è uno schema di firma diverso, abilitato su Bitcoin tramite l'upgrade Taproot del 2021. Ha una proprietà matematica — la linearità — che ECDSA non ha. La linearità permette a più firme Schnorr di essere sommate in una singola firma valida per una chiave combinata.
  • MuSig2 è il protocollo moderno e pratico che trasforma quella proprietà matematica in un protocollo multisig usabile. n cosigner eseguono un breve protocollo interattivo, ciascuno contribuendo con un giro di nonce e una firma parziale; il risultato è una singola firma Schnorr indistinguibile da una di chiave singola.
  • È una vittoria netta sul lato verifica — fee, gonfiore della blockchain e privacy ne traggono tutti beneficio. Non è una vittoria gratis sul lato firma: l'aggregazione richiede una gestione attenta dei nonce, e un'implementazione bacata può far trapelare chiavi private.
  • SSP oggi usa multisig BIP48 + ECDSA sulle chain che supporta. La roadmap è aggiungere percorsi Schnorr/MuSig2 dove la chain li supporta, senza rompere il modello 2-of-2 esistente che gli utenti hanno già.

Un rapido richiamo su cosa fa una firma

Una firma digitale dimostra due cose al verificatore: questo esatto messaggio è stato firmato da qualcuno che detiene la chiave privata corrispondente a questa chiave pubblica. On-chain, il "messaggio" è un hash di transazione, la "chiave pubblica" è l'indirizzo (o ciò che lo deriva), e il "verificatore" è ogni nodo della rete. Se la firma torna, la transazione è valida; altrimenti viene rifiutata.

ECDSA — lo schema che Bitcoin e la maggior parte delle chain EVM usano — è ben compreso, conservativo, e funziona bene per il caso di un singolo firmatario. Il problema è cosa succede quando vuoi più firmatari ad autorizzare la stessa transazione. ECDSA non ha modo di combinare firme. Se vuoi two-of-two, la chain deve memorizzare entrambe le firme e controllarle entrambe. Three-of-five, cinque firme. La transazione cresce con il numero di cosigner.

What is multisig descrive la parte di protocollom di n chiavi, regole di redeem, la chain che impone la soglia. Quello che quel pezzo precedente non si sofferma a spiegare è il costo: sotto ECDSA, tutte quelle firme vivono nella transazione. Una transazione P2WSH 2-of-2 è genuinamente più grande e più costosa da trasmettere di una transazione single-sig con lo stesso effetto.

Cosa cambia Schnorr

Le firme Schnorr, originariamente proposte alla fine degli anni '80, furono evitate nel design originario di Bitcoin per incertezza brevettuale all'epoca. Sono matematicamente più pulite di ECDSA in un aspetto specifico: sono lineari. Se s1 è una firma valida su un messaggio sotto la chiave P1, e s2 è una firma valida sullo stesso messaggio sotto la chiave P2, allora s1 + s2 è una firma valida su quel messaggio sotto P1 + P2. Sia le chiavi che le firme sommano.

Perché conta: diventa improvvisamente possibile combinare le firme prima che tocchino la chain. Invece di memorizzare due firme nella transazione, ne memorizzi una — la somma. Il verificatore controlla l'unica firma contro la somma delle due chiavi pubbliche, che entrambi i firmatari possono calcolare in anticipo. Dalla prospettiva della chain, la transazione risultante sembra indistinguibile da una transazione firmata da una sola chiave.

ECDSA non può farlo. La matematica di ECDSA coinvolge un inverso moltiplicativo che rompe la linearità; le somme di firme ECDSA non sono firme valide. Per questo il multisig basato su ECDSA deve spedire tutte le firme individuali on-chain. La chain ispeziona ciascuna separatamente.

Bitcoin ha rilasciato le firme Schnorr (tramite BIP340) come parte del soft fork Taproot del 2021. Le firme di per sé sono leggermente più piccole delle firme ECDSA (64 byte contro ~71), ma il fatto molto più grande è ciò che quella linearità abilita quando la combini con il multisig.

MuSig2 — multisig che sembra una sola firma on-chain

La versione onesta di "puoi sommare firme Schnorr" è che lo devi fare con cura. L'approccio ingenuo — lasciare che ogni cosigner scelga un nonce, condividere la propria firma parziale, sommare tutto — fa trapelare materiale di chiave sotto firma ripetuta ed è vulnerabile a una classe di attacchi "rogue key". Un protocollo di aggregazione pratico deve difendersi da entrambi.

MuSig2 è il risultato di circa un decennio di raffinamento su questo problema. È lo standard de facto per il multisig Schnorr n-of-n: al momento della firma, i cosigner si scambiano due giri di nonce, ciascuno produce una firma parziale, e uno di loro somma le parziali in una firma aggregata finale. Il risultato è una singola firma Schnorr, valida contro una singola chiave pubblica aggregata, indistinguibile on-chain da una firma di chiave singola.

Alcuni punti importanti su MuSig2:

  • Attualmente è n-of-n. Per ottenere un vero m-of-n (es. 2-of-3) sotto aggregazione serve macchinario aggiuntivo — FROST è la proposta capofila — e si sta ancora produzionalizzando. Quindi nel 2026, ciò che SSP aggregherebbe in modo pulito è il default 2-of-2. Le configurazioni 2-of-3 e superiori dell'articolo selettore ancora in gran parte usano visibilità on-chain in stile ECDSA.
  • Richiede ancora entrambi i cosigner online per firmare. L'aggregazione non riduce il numero di firmatari necessari; comprime solo l'output finale. La UX è la stessa di oggi — due dispositivi firmano la stessa transazione — ma l'impronta on-chain del risultato è più piccola.
  • Un'implementazione MuSig2 bacata può far trapelare chiavi. La gestione dei nonce è sottile. Le distribuzioni in produzione si appoggiano a librerie ben auditate (il modulo MuSig2 di libsecp256k1, lo stack rust-bitcoin, ecc.) per questa ragione.

Cosa significa questo per SSP oggi

SSP oggi, su ogni chain che supporta, usa multisig ECDSA derivato da BIP48. Due dispositivi, due chiavi private, due firme separate on-chain. È corretto, è auditato (da Halborn — vedi il riferimento inside-ssp-2025-halborn-audits nel pezzo 2-of-2 esistente), ed è interoperabile con qualsiasi altro wallet conforme BIP48. Lo svantaggio è che paghi il costo on-chain pieno del 2-of-2.

La roadmap da qui, in italiano semplice: aggiungere un percorso di codice Schnorr/MuSig2 per Bitcoin (dove Taproot è attivo e stabile) che firma lo stesso wallet 2-of-2 usando aggregazione al suo posto. La semantica di soglia del wallet non cambia — entrambi i dispositivi devono ancora firmare. I byte on-chain si riducono, e la transazione risultante sembra una spesa single-sig.

Per l'utente, questo si tradurrebbe principalmente in:

  • Fee Bitcoin leggermente più basse per transazione.
  • Privacy migliorata — il wallet smette di gridare "sono un wallet multisig" all'analitica della chain.
  • Riconciliazione più veloce per la UI del wallet (un po' meno dati da scaricare e parsare per indirizzo).

Non è — e vale la pena dirlo chiaro — un upgrade di sicurezza. La crittografia è comparabilmente dura, solo strutturata in modo diverso. Il motivo per adottarla è efficienza e privacy, non sicurezza grezza.

Cosa significa questo per costo, privacy e UX

Tre posti dove questo atterra una volta che l'aggregazione è ampiamente distribuita su una chain:

Costo. Bitcoin addebita le fee approssimativamente per dimensione di transazione in vbyte. Una transazione ECDSA P2WSH 2-of-2 è significativamente più grande della transazione Taproot-MuSig2 equivalente. Per wallet a basso saldo che inviano piccoli importi, il risparmio relativo di fee può essere del 20–30%. Per business ad alto throughput, il risparmio assoluto sulle fee annuali è denaro vero.

Privacy. Oggi, quando un wallet trasmette una spesa P2WSH 2-of-2, quel fatto è visibile a chiunque guardi un block explorer. Le società di chain analytics sofisticate raggruppano gli indirizzi per pattern di spesa, e "questo indirizzo è multisig" è un forte segnale di cluster. Una spesa Schnorr-aggregata sembra identica a una spesa single-sig. Il segnale di cluster sparisce.

UX. La UX di firma in SSP — firma sul browser, poi conferma sul telefono — non cambia. Entrambi i dispositivi continuano a produrre firme parziali; il wallet semplicemente le combina prima di trasmettere invece di trasmetterle entrambe. Dalla prospettiva dell'utente l'unico cambiamento visibile è "il wallet sembra più economico da usare".

C'è una vittoria UX più profonda all'orizzonte, anche. Una volta che l'aggregazione m-of-n (tramite FROST o simile) sarà pronta per la produzione, potresti immaginare un wallet SSP 2-of-3 — come il setup solo di recovery che l'articolo precedente descrive — che on-chain sembra un normale wallet single-sig. La terza chiave "di recovery" è genuinamente una terza chiave di firma, ma la chain non deve mai saperlo.

Cosa significa questo per te

Tre conclusioni:

  1. Non devi pensare a Schnorr per usare SSP correttamente. Il setup 2-of-2 che hai oggi è costruito su multisig ECDSA ben auditato, e rimane così indipendentemente da come atterra l'aggregazione. Il prossimo articolo della serie (social recovery vs multisig) ignora deliberatamente l'aggregazione perché la domanda di chi può spendere è indipendente da come appare la firma on-chain.
  2. L'aggregazione è un upgrade di "fee e privacy", non di "sicurezza". Se mai vedrai un wallet vendere "MuSig2 = più sicuro", diffida. La sicurezza crittografica di un MuSig2 ben implementato è paragonabile al multisig ECDSA ben implementato; le vittorie stanno altrove.
  3. Tieni d'occhio il supporto chain, non il marketing del wallet. Schnorr è attivo su Bitcoin ed è in adozione nel mondo EVM tramite account abstraction. Le chain che lo supportano bene sono dove SSP lancerà per prime il multisig aggregato; altrove, BIP48 + ECDSA rimane il default corretto e sicuro.

Il prossimo articolo di questa serie, Social recovery vs multisig, sposta il focus dalla crittografia alle operazioni: quando opti per il multisig e quando il social recovery lo batte? Entrambi proteggono dal perdere chiavi; rispondono a domande diverse. Per un ripasso veloce di quali dispositivi SSP usa oggi e perché, Meet SSP Wallet resta il punto di partenza.

Condividi questo articolo

Articoli correlati