Firme a soglia
Le firme a soglia consentono a un numero richiesto di partecipanti di cooperare per produrre una firma digitale usando quote di una chiave di firma comune. Nella custodia di criptovalute, ciò può distribuire il potere di firma tra sistemi o organizzazioni. Una soluzione a soglia dipende dal protocollo crittografico e dalla gestione delle chiavi; la denominazione MPC wallet non ne specifica i dettagli.[1]
Soglie e multifirme
In uno schema a soglia, un sottoinsieme sufficiente dei partecipanti può firmare. FROST è un protocollo di firma Schnorr a soglia in due round, con ipotesi di sicurezza sulla generazione delle quote della chiave e sul numero di partecipanti compromessi. RFC 9591 è una pubblicazione informativa del Crypto Forum Research Group, non una specifica Internet Standards Track.[1]
La firma di più parti non equivale sempre a una firma a soglia. MuSig2, specificato nel BIP 327, aggrega le chiavi pubbliche dei partecipanti e produce una firma Schnorr compatibile con il BIP 340, ma richiede tutti i firmatari coinvolti nell’aggregazione delle chiavi. È uno schema multifirma n-di-n, anziché uno schema a soglia t-di-n.[2]
Ipotesi di sicurezza e condizioni operative
Distribuire le quote cambia il modello di fiducia, ma non elimina la necessità di sistemi sicuri. FROST presuppone una generazione e distribuzione sicure delle quote e limiti al numero di partecipanti che un avversario può compromettere. Le considerazioni di sicurezza trattano il riutilizzo dei nonce, i canali laterali e i guasti del protocollo. La disponibilità a firmare e la protezione dalle falsificazioni sono proprietà distinte.[1]
Servizi di custodia
La documentazione di Multi-party Compute di Google Cloud, consultata nell’ottobre 2026, descrive una piattaforma di custodia che combina firme a soglia e controlli organizzativi. La documentazione indica che il servizio è in Preview e descrive un’API v1beta. Elenca ECDSA su secp256k1 per Bitcoin e applicazioni compatibili con EVM; ciò non implica il supporto per ogni formato di firma blockchain.[3]
L’autorizzazione crittografica è inoltre distinta dall’automazione delle politiche sulle transazioni. La documentazione di Google afferma che un numero sufficiente di firmatari può autorizzare una transazione rifiutata dalle politiche automatiche. L’esito di una politica va quindi interpretato nel modello di firmatari e di governance del servizio.[4]
Riferimenti
- ↑ 1,0 1,1 1,2 RFC 9591: The Flexible Round-Optimized Schnorr Threshold (FROST) Protocol, June 2024, introduction and security considerations.
- ↑ BIP 327: MuSig2 for BIP340-compatible Multi-Signatures, motivation and general signing flow, checked 29 October 2026.
- ↑ Google Cloud: Multi-party Compute overview, checked 29 October 2026.
- ↑ Google Cloud: Transaction policy evaluation, checked 29 October 2026.