Vai al contenuto
Financial Context Wiki

Rotazione dei firmatari multisig

Una procedura incentrata sulla verifica per sostituire i firmatari multisig preservando il quorum, controllando l'insieme dei proprietari e la soglia esatti on-chain e reagendo in sicurezza a una chiave compromessa.

Aggiornato

Solo a scopo educativo; non costituisce consulenza finanziaria, legale o di sicurezza. Un errore nella rotazione può trasferire il controllo, invalidare approvazioni pendenti o bloccare definitivamente un conto multisig.

Risposta diretta

La rotazione dei firmatari multisig cambia i conti autorizzati ad approvare le transazioni. Normalmente non richiede un nuovo indirizzo di portafoglio né un trasferimento di asset: una transazione privilegiata modifica l’insieme dei proprietari del conto e, talvolta, la sua soglia di approvazione. Le implementazioni sono diverse, quindi occorre verificare il contratto distribuito e lo stato on-chain corrente anziché presumere che le etichette dell’interfaccia descrivano correttamente i poteri.

Una rotazione sicura dimostra innanzitutto il controllo di ogni nuovo firmatario, mantiene per tutta la modifica un quorum eseguibile ma non concentrato, rimuove il vecchio firmatario e verifica lo stato finale on-chain. Perdere il quorum richiesto prima dell’esecuzione può rendere impossibile una normale rotazione dei proprietari; abbassare la soglia per comodità può creare una finestra di acquisizione del controllo.

La persona, il dispositivo di firma, la chiave privata e l’indirizzo del proprietario on-chain sono registri distinti. Documentare l’indirizzo esatto, il custode, il dominio di controllo indipendente, lo stato del backup e il motivo della rotazione. Nessuna rotazione legittima richiede di rivelare una frase seed o una chiave privata.

Come funziona

  1. Inventariare i poteri attuali. Da una chain e da un indirizzo di conto verificati in modo indipendente, leggere l’implementazione distribuita, l’elenco dei proprietari, la soglia, il nonce, i moduli abilitati, i guard, il fallback handler, il percorso di recupero e gli eventuali timelock. Un modulo o meccanismo di recupero può eseguire al di fuori della normale soglia dei proprietari, mentre un guard restrittivo può bloccare una rotazione altrimenti valida.
  2. Definire lo stato obiettivo prima di firmare. Registrare l’insieme esatto dei proprietari e la soglia dopo la modifica. Confermare che la soglia non superi il numero di proprietari e che almeno altrettanti firmatari indipendenti restino operativi. La separazione geografica non è indipendenza se una sola persona, un vault di password, un conto cloud o un amministratore controlla tutti i dispositivi.
  3. Registrare e autenticare il nuovo firmatario. Generare o ripristinare la nuova chiave nell’ambiente di custodia previsto, verificare l’indirizzo su un dispositivo affidabile e dimostrare il controllo con una challenge concordata o una firma di prova. Confermare l’indirizzo tramite un secondo canale autenticato; non affidarsi soltanto a testo copiato da una chat o all’interfaccia del portafoglio.
  4. Scegliere un ordine con stati intermedi sicuri. Alcuni contratti possono sostituire atomicamente un proprietario. Safe, per esempio, espone swapOwner; espone anche addOwnerWithThreshold, removeOwner e changeThreshold. Se un’implementazione richiede più transazioni, analizzare l’insieme dei proprietari e la soglia dopo ogni passaggio. Aggiungere e verificare la capacità prima di rimuoverla, a meno che una compromissione attiva renda insicuro tale ordine.
  5. Decodificare e simulare la transazione esatta. Controllare in modo indipendente chain ID, indirizzo del conto, target, selettore di funzione, vecchio e nuovo indirizzo del proprietario, soglia risultante, nonce, value e tipo di operazione. Trattare delegatecall, batching, modifiche ai moduli e modifiche ai guard come effetti ad alto rischio distinti. Ogni firmatario deve approvare lo stesso payload decodificato e lo stesso hash della transazione.
  6. Eseguire con i poteri esistenti. Il quorum valido corrente autorizza la rotazione, salvo diversa indicazione di un percorso di recupero documentato. In emergenza, coordinarsi solo tramite contatti autenticati e usare firmatari non compromessi. Se non restano disponibili né il quorum normale né un’autorità di recupero preconfigurata, una chiamata standard di gestione dei proprietari non può ripristinare l’accesso.
  7. Verificare e chiudere la modifica. Dopo la conferma, interrogare direttamente l’insieme dei proprietari e la soglia, esaminare gli eventi emessi o le trace secondo l’implementazione e confermare che il vecchio indirizzo non sia più autorizzato. Far partecipare il nuovo firmatario a una transazione approvata, a basso rischio o a valore zero, che richieda la soglia prevista. Esaminare le transazioni pendenti, revocare accessi off-chain e backup del precedente firmatario e archiviare proposta, firme, hash della transazione, blocco e stato finale.

Esempio pratico

Si supponga che un conto 3-of-5 abbia come proprietari A, B, C, D ed E e che B debba essere sostituito da F. Il team verifica prima che F controlli l’indirizzo esatto proposto e resti indipendente dagli altri proprietari. Per una distribuzione Safe compatibile prepara swapOwner(prevOwner, B, F). La chiamata è essa stessa una transazione Safe e richiede quindi 3 conferme valide dall’insieme corrente dei proprietari. Il risultato decodificato deve conservare un numero di proprietari pari a 5 e una soglia pari a 3.

Dopo la conferma della transazione, il team legge getOwners e getThreshold, verifica che B sia assente e F presente e fa eseguire a F e ad altri due proprietari un test approvato con valore 0. Esamina anche le transazioni pendenti: una firma o preapprovazione di B potrebbe non soddisfare più i controlli sui proprietari dopo la rimozione, perciò le proposte interessate devono essere annullate o ricostruite anziché considerate eseguibili.

Se B potrebbe essere compromesso, il team non gli chiede di approvare la rimozione. Altri tre proprietari non compromessi eseguono la sostituzione, quindi ispezionano moduli, permessi di recupero, allowance, session key e transazioni già eseguite, perché rimuovere B non annulla le azioni precedenti né revoca i poteri concessi tramite un’altra via. Se sono disponibili meno di 3 proprietari non compromessi, può aiutare soltanto un percorso di recupero o amministrativo configurato in precedenza; condividere frasi seed o fidarsi di un servizio di “recupero” non richiesto non sostituisce il quorum.

Rischi e controlli

  • Conto o indirizzo errato. Verificare chain ID, indirizzo multisig, implementazione e indirizzo del nuovo proprietario su dispositivi e fonti indipendenti. L’address poisoning e gli errori di copia possono cedere il controllo a un aggressore.
  • Perdita del quorum. Modellare ogni stato intermedio. Rimuovere troppo presto un proprietario, alzare la soglia oltre i firmatari disponibili o ruotare insieme più dispositivi correlati può rendere inutilizzabile il conto.
  • Concentrazione temporanea. Una soglia più bassa o un firmatario appena aggiunto può creare un periodo in cui un numero minore di parti controlla il conto. Preferire una sostituzione atomica quando supportata e non abbassare la soglia solo per semplificare la procedura.
  • Custodia correlata. Indirizzi diversi non sono indipendenti se seed, dispositivi, backup, comunicazioni o amministratori condividono lo stesso dominio di guasto. Verificare il recupero senza centralizzare i segreti.
  • Poteri nascosti. Moduli, guard, fallback handler, session key, timelock e contratti di recupero possono aggirare o bloccare il percorso dei proprietari. Inventariarli e verificarli prima e dopo la rotazione.
  • Corsa con il firmatario compromesso. Prima che la rimozione sia confermata, un firmatario sospetto può anticipare, sottrarre asset, cambiare configurazione o approvare un’altra transazione. Usare procedure di risposta agli incidenti, invio privato delle transazioni quando opportuno e monitoraggio continuo dello stato; non presumere che una transazione inviata abbia vinto la corsa.
  • Approvazioni pendenti obsolete. Le modifiche a proprietari e soglia possono invalidare le firme raccolte o cambiare quali approvazioni siano sufficienti. Rivalutare ogni transazione in coda rispetto allo stato finale e annullare le proposte obsolete.
  • Falso completamento. Una notifica di successo dell’interfaccia non prova lo stato desiderato. Attendere la politica di conferma richiesta, quindi leggere lo stato del contratto e verificare payload della transazione, eventi e risultato di esecuzione.
  • Offboarding incompleto. Rimuovere un proprietario on-chain non cancella chiavi copiate, accessi organizzativi, credenziali del relayer, voci del vault di password o poteri in altri contratti e chain. Revocare ciascun elemento separatamente e conservare una traccia di audit.

Errori comuni

  • “La rotazione significa spostare tutti gli asset in un nuovo portafoglio.” Molti multisig basati su smart account aggiornano i proprietari allo stesso indirizzo del conto. La migrazione è un’operazione diversa e può essere richiesta solo da una particolare implementazione o piano d’incidente.
  • “Aggiungere prima il nuovo firmatario è sempre sicuro.” Protegge la disponibilità, ma può ampliare temporaneamente l’insieme autorizzato. Durante una compromissione attiva, una sostituzione atomica o un’altra sequenza di emergenza può essere più sicura.
  • “Una soglia 3-of-5 significa che sono disponibili tre persone nominate qualsiasi.” Il contratto conta i conti proprietari validi, non persone, reparti o dispositivi. La custodia condivisa e le chiavi inaccessibili riducono l’indipendenza e la disponibilità effettive.
  • “Rimuovere un proprietario compromesso annulla il danno.” Dopo la conferma, la rimozione impedisce l’uso futuro di quel percorso del proprietario; non annulla le transazioni eseguite né revoca i permessi creati altrove.
  • “L’interfaccia del portafoglio è una prova sufficiente.” Interfacce e servizi di indicizzazione possono essere obsoleti, configurati male o dannosi. Decodificare la transazione e leggere lo stato finale del contratto da un endpoint verificato in modo indipendente.
  • “Senza quorum, l’assistenza può reimpostare il portafoglio.” Un multisig in autocustodia dispone solo dei percorsi di autorità codificati o preconfigurati on-chain. Senza un quorum valido o un percorso di recupero, l’accesso può andare perso definitivamente.

Argomenti correlati

Fonti

Navigazione

Cerca nella wiki...