Vai al contenuto
Financial Context Wiki

Portafoglio multifirma

Scopri come un portafoglio multifirma M-of-N distribuisce l'autorità sulle transazioni, come differiscono le multifirme basate su script e smart contract e quali rischi restano per firmatari, esecuzione, moduli e recupero.

Aggiornato

Solo a scopo educativo; non costituisce consulenza in materia di investimenti, custodia, diritto o sicurezza. Un multisig può comunque perdere fondi o diventare inutilizzabile per firmatari compromessi, transazioni dannose, moduli non sicuri, difetti del contratto o perdita del quorum. Le transazioni in asset digitali possono essere irreversibili.

Risposta diretta

Un portafoglio multifirma, o multisig, controlla un conto o un output spendibile con una regola che richiede almeno M approvazioni da N chiavi pubbliche o conti proprietari autorizzati. Una regola 2-of-3, per esempio, accetta due autorità valide qualsiasi di un insieme di tre. Si elimina così una singola chiave privata come unico punto di controllo, ma non si rende sicura ogni transazione approvata.

Il multisig convenzionale non divide una chiave privata tra i firmatari. Di norma ciascuno controlla una chiave o un conto separato, mentre lo script o il contratto verifica più approvazioni. I sistemi di firma a soglia o MPC possono invece produrre una firma da quote di chiave distribuite; hanno un aspetto on-chain e un modello di fiducia differenti.

L’implementazione conta. Bitcoin può imporre condizioni di spesa multifirma negli script delle transazioni. Su Ethereum e reti programmabili simili, un multisig comune è un conto contrattuale il cui codice definisce proprietari, soglia, regole di esecuzione ed estensioni opzionali. A differenza di un conto esterno, un conto contrattuale è controllato dal codice e non da una sola chiave privata.

La soglia M-of-N esprime limiti sia di compromissione sia di disponibilità. Un sistema 3-of-5 continua a funzionare con due autorità indisponibili, ma tre autorità valide qualsiasi possono approvare una spesa. Indirizzi diversi non sono indipendenti se una persona, un amministratore di dispositivi, un conto cloud, una sede di backup o un custode ne controlla abbastanza.

Come funziona

  1. Verificare l’autorità prima della proposta. Confermare rete e conto o output, quindi esaminare script o contratto distribuito, proprietari, soglia, regole di nonce o sequenza e ogni modulo, guard, fallback handler, percorso di recupero e autorità di aggiornamento capace di eseguire o bloccare transazioni.
  2. Costruire e decodificare la richiesta esatta. Controllare destinazione, asset, valore, calldata o script, tipo di operazione, nonce, commissioni e contenuto di ogni batch. Simulare chiamate complesse con strumenti affidabili e far verificare a ogni firmatario ciò che la firma autorizza davvero, non un’etichetta dell’interfaccia.
  3. Raccogliere approvazioni in domini di controllo indipendenti. I firmatari verificano lo stesso digest su dispositivi fidati e comunicano tramite canali autenticati. Nessun processo legittimo richiede di rivelare una seed phrase o una chiave privata.
  4. Eseguire la richiesta approvata. Raggiungere la soglia può solo rendere eseguibile la proposta. Un esecutore deve ancora trasmetterla o inviarla e potrebbe pagare una commissione di rete. Nonce obsoleto, proposta concorrente, stato mutato, commissione insufficiente o chiamata fallita possono impedirne l’esecuzione.
  5. Verificare il completamento dallo stato della blockchain. Attendere le conferme richieste, esaminare payload eseguito e risultato e controllare saldi, configurazione proprietari ed eventi quando opportuno. Rivalutare le proposte pendenti dopo ogni modifica a proprietari, soglia, moduli o politiche.

Esempio

Una tesoreria usa un multisig smart account 3-of-5 con proprietari A, B, C, D ed E in domini di controllo separati. Per un pagamento di 10,000 USDC, la proposta registra rete, conto, destinatario, contratto del token, importo, calldata, nonce e politica delle commissioni corretti. A, C ed E decodificano indipendentemente la stessa richiesta prima di approvarla.

Le approvazioni da sole non spostano i fondi. Un esecutore invia la transazione; dopo la conferma il team controlla risultato e saldo della tesoreria invece di affidarsi a una notifica dell’interfaccia. Proposta, approvazioni, hash e prove della revisione sono conservati per la traccia di audit.

Se in seguito la chiave di B è sospettata di compromissione, il quorum non compromesso restante segue la procedura di rotazione dei proprietari del conto distribuito e verifica on-chain l’insieme finale. Controlla anche proposte pendenti, moduli, allowance, permessi di recupero e altre blockchain, perché rimuovere B non annulla operazioni passate né revoca autorità concesse altrove.

Rischi e controlli

  • Custodia correlata. Più chiavi possono fallire insieme se condividono persona, dispositivo, cassaforte password, amministratore, luogo, fornitore o segreto di recupero. Mappare i domini e testare il recupero senza centralizzare autorità sufficiente per la soglia.
  • Payload dannosi o fraintesi. Un quorum valido può approvare fedelmente un indirizzo dell’attaccante, un’approvazione token illimitata, una delegate call o un batch pericoloso. Decodificare e verificare indipendentemente l’intera richiesta; usare la simulazione come prova di supporto, non garanzia.
  • Perdita e ritardo del quorum. Chiavi perse, persone indisponibili, controversie, interruzioni di rete o soglia troppo alta possono bloccare azioni urgenti o congelare gli asset. Mantenere contatti autenticati, successione documentata, backup testati e un progetto di recupero esplicito.
  • Autorità nascosta o alternativa. Moduli, guard, fallback handler, session key, relayer, contratti di recupero e amministratori di aggiornamento possono aggirare la soglia ordinaria o impedirne l’esecuzione. Inventariare questi percorsi e trattare ogni cambio di permessi come transazione ad alto rischio.
  • Rischio di contratto e distribuzione. Bug, inizializzazione insicura, errori di proxy o aggiornamento e distribuzione sulla rete sbagliata possono vanificare la politica prevista. Verificare indirizzi e codice, valutare gli audit nel contesto, ridurre le estensioni e monitorare le configurazioni.
  • Corsa dopo la compromissione e uscita incompleta. Un firmatario compromesso può agire prima che la rimozione sia confermata, e rimuovere un proprietario non annulla azioni o permessi esterni. Usare un piano d’incidente, monitorare continuamente e revocare separatamente accessi organizzativi e on-chain.

Errori comuni

  • «Più firmatari significano sempre più sicurezza». Un insieme maggiore può ridurre la concentrazione, ma aumenta rischi di coordinamento, phishing e disponibilità. Scegliere proprietari e soglia in base al modello di minaccia e alla capacità operativa.
  • «Un portafoglio 3-of-5 è controllato da cinque persone indipendenti». La blockchain conta chiavi o conti proprietari validi, non persone. Dispositivi, backup, amministratori o custodi condivisi possono rendere un solo dominio proprietari nominalmente separati.
  • «Multisig equivale all’autenticazione a due fattori o a MPC». Tutti possono distribuire il controllo, ma differiscono per credenziali, percorsi di verifica, prove on-chain e ipotesi di recupero.
  • «Quando la soglia approva, il trasferimento è completo». Approvazione, eseguibilità, invio, inclusione e conferma sono stati distinti. La richiesta può restare pendente o fallire.
  • «Multisig impedisce furti ed exploit dei contratti». Limita solo i percorsi di autorità codificati nell’implementazione. Un quorum valido, un modulo privilegiato, un contratto vulnerabile o un recupero insicuro possono ancora causare perdite irreversibili.

Argomenti correlati

Fonti

Navigazione

Cerca nella wiki...