Vai al contenuto
Financial Context Wiki

Portafoglio gerarchico deterministico (HD)

Scopri come un portafoglio HD deriva un albero di chiavi da un unico seed, come differiscono la derivazione rafforzata e quella normale e cosa deve conservare un backup completo e verificabile.

Aggiornato

Solo a scopo educativo; non costituisce consulenza finanziaria. Gli investimenti possono comportare perdite.

Risposta diretta

Un portafoglio gerarchico deterministico (HD) deriva da un unico seed radice un albero riproducibile di coppie di chiavi crittografiche. BIP-32 definisce il meccanismo dell’albero delle chiavi: ogni nodo è una chiave estesa contenente una chiave e un codice di catena di 32-byte, mentre ogni chiave figlia è selezionata da un indice. Lo stesso materiale radice, le stesse regole di derivazione e lo stesso percorso riproducono le stesse chiavi figlie.

Il carattere “deterministico” rende pratico il backup, ma non rende intercambiabili tutti i portafogli. Una frase mnemonica è un possibile modo per codificare entropia e produrre un seed; un percorso di derivazione seleziona invece un nodo, mentre una regola di indirizzo o di script trasforma la relativa chiave pubblica in qualcosa che una blockchain riconosce. Ripristinare soltanto le parole può mostrare un portafoglio vuoto se la passphrase, il percorso, la rete, il tipo di script o le regole di individuazione degli account sono diversi.

“Gerarchico” significa che l’autorità può essere suddivisa in sottoalberi. Una chiave pubblica estesa a livello di account può consentire a un servizio di sola osservazione di derivare le normali chiavi pubbliche discendenti senza possedere le chiavi di spesa. Una chiave privata estesa può derivare il corrispondente sottoalbero privato e deve essere protetta come una raccolta di chiavi private, non come un singolo indirizzo.

Un portafoglio HD è un sistema di gestione delle chiavi, non un oggetto portafoglio on-chain. La blockchain non memorizza la frase mnemonica, il seed, il percorso, le etichette o il backup. Si tratta di dati off-chain gestiti dal software del portafoglio e dall’utente.

Come funziona

1. Dall’entropia alla radice

BIP-39 viene comunemente usato prima di BIP-32, ma i due standard sono distinti. BIP-39 codifica 128-256 bits di entropia con una somma di controllo in 12-24 words, quindi applica PBKDF2-HMAC-SHA512 con 2048 iterazioni alla frase mnemonica normalizzata e alla passphrase facoltativa per produrre un seed di 512-bit. Ogni passphrase produce un seed valido ma diverso, quindi una passphrase mancante o digitata in modo errato non viene individuata in modo affidabile da un messaggio di “password non valida”.

BIP-32 usa HMAC-SHA512 con la chiave Bitcoin seed per trasformare i byte del seed in una chiave privata master e in un codice di catena master. Questa chiave privata estesa radice è l’origine dell’albero BIP-32. Non tutti i portafogli deterministici usano BIP-39 o BIP-32: il ripristino deve quindi identificare lo schema effettivo invece di dedurlo dalla presenza di parole di recupero.

2. Chiavi estese e derivazione delle chiavi figlie

Una chiave privata estesa BIP-32 combina una chiave privata con un codice di catena; la sua chiave pubblica estesa neutralizzata combina la chiave pubblica corrispondente con lo stesso codice di catena. La derivazione normale di una chiave figlia usa la chiave pubblica del nodo padre, il codice di catena e l’indice della figlia, quindi una chiave pubblica estesa può derivare normali chiavi pubbliche figlie. Non può derivare chiavi private figlie.

Le chiavi figlie rafforzate usano indici da 2^31 a 2^32 - 1 e incorporano materiale della chiave privata del nodo padre. Non possono essere derivate dalla chiave pubblica estesa del padre. Nei percorsi sono generalmente contrassegnate da un apostrofo, come in m/84'/0'/0'. Il rafforzamento limita i danni causati da uno specifico problema di BIP-32: una chiave pubblica estesa padre, insieme a una corrispondente chiave privata figlia non rafforzata, può rivelare la chiave privata estesa padre.

3. I percorsi danno significato all’albero

BIP-44 definisce m / purpose' / coin_type' / account' / change / address_index. I primi 3 livelli sono rafforzati; change e address_index sono normali, così le chiavi pubbliche dell’account possono generare indirizzi di ricezione e di resto. Per convenzione, il ramo 0 è esterno e il ramo 1 è quello interno per il resto. L’individuazione BIP-44 esamina la cronologia delle transazioni e usa un gap limit di 20 indirizzi esterni consecutivi non utilizzati.

Il percorso è un metadato, non un segreto né una garanzia universale. BIP-84 assegna lo scopo 84' agli account P2WPKH SegWit nativi, mentre altri scopi o strutture specifiche del portafoglio producono altri sottoalberi. Il tipo di moneta è una convenzione di namespace, non una regola imposta da una blockchain.

4. Le chiavi non costituiscono l’intero portafoglio

Una chiave pubblica richiede comunque regole relative alla rete e all’indirizzo o allo script. In Bitcoin, la stessa chiave può essere usata in script di output diversi; un portafoglio multifirma richiede inoltre la soglia, le chiavi dei cofirmatari, l’ordine delle chiavi e le origini di derivazione. I descrittori di output BIP-380 associano chiavi e origini a espressioni di script esplicite e possono includere una somma di controllo. Per questo, un backup del solo seed può non bastare a ricreare ciò che il portafoglio originale monitorava o poteva spendere.

Le etichette del portafoglio, i contatti, le note sulle transazioni, le chiavi importate, i nomi degli account e alcune impostazioni di recupero di contratti o smart account non sono generalmente derivati in modo deterministico. Richiedono un’esportazione o una documentazione separata.

5. Backup e ripristino sono processi sottoposti a verifica

Registra l’implementazione del portafoglio, il formato della frase mnemonica o del seed, l’eventuale presenza di una passphrase, l’impronta digitale master, i percorsi pertinenti, le reti, gli indici degli account e i descrittori Bitcoin o dati equivalenti sulle regole. Conserva i segreti radice offline e, ove possibile, separati dai metadati pubblici di ripristino. Un xpub non può spendere autonomamente, ma può rivelare saldi, relazioni tra indirizzi e futuri discendenti normali.

Verifica il ripristino in un ambiente affidabile prima di fare affidamento sul backup. Confronta innanzitutto indirizzi o descrittori noti senza trasferire fondi; controlla poi sia i rami di ricezione sia quelli del resto, gli account successivi, la cronologia delle transazioni e la firma mediante una piccola transazione controllata. Non inserire mai una frase mnemonica, una passphrase o un xprv in un sito web o in una chat di assistenza non affidabili.

Esempio

Considera un account Bitcoin SegWit nativo in m/84'/0'/0'. Lo scopo 84' seleziona la convenzione BIP-84, 0' seleziona il namespace del tipo di moneta Bitcoin e l’ultimo 0' seleziona il primo account. Un sistema di sola osservazione può ricevere la chiave pubblica estesa dell’account e derivare rami normali senza ricevere la chiave privata dell’account.

La prima chiave esterna di ricezione si trova in m/84'/0'/0'/0/0, la successiva in m/84'/0'/0'/0/1. La prima chiave interna per il resto si trova in m/84'/0'/0'/1/0. Tutte discendono dallo stesso account, ma il ramo e l’indice selezionano chiavi diverse. Riutilizzare il seed con m/44'/0'/0'/0/0 seleziona un altro sottoalbero e un’altra convenzione di output; un risultato vuoto non dimostra che il seed sia errato.

Per un registro completo di ripristino Bitcoin, conserva il backup del segreto radice separatamente dal descrittore o dai metadati equivalenti che identificano l’impronta digitale, il percorso, la chiave pubblica estesa, il tipo di script e la somma di controllo. Verifica diversi indirizzi usati in precedenza su entrambi i rami. Trovare soltanto il primo indirizzo di ricezione dimostra la correttezza di una foglia, non che siano stati recuperati ogni account, ogni output di resto o tutte le regole del portafoglio.

Rischi

  • Concentrazione in un’unica radice: la compromissione di un seed radice o di una chiave privata estesa di livello sufficientemente alto può esporre tutti i discendenti nel suo ambito.
  • Perdita del backup: perdere l’unico backup del seed, o perdere separatamente una passphrase BIP-39 non documentata, può rendere irrecuperabili tutte le chiavi derivate.
  • Falsa sicurezza della passphrase: una passphrase BIP-39 errata crea un portafoglio diverso ma valido, che può sembrare un ripristino riuscito ma vuoto.
  • Percorso o script errato: il seed corretto usato con scopo, account, ramo, rete o tipo di output sbagliato genera indirizzi validi ma non correlati.
  • Backup incompleto delle regole: seed e percorso da soli potrebbero non ricostruire condizioni di spesa multifirma, basate su descrittori, di smart account o specifiche del portafoglio.
  • Fuga di informazioni dalla chiave pubblica estesa: un xpub può rivelare un gruppo di indirizzi e consentire il monitoraggio continuo dei discendenti normali.
  • Compromissione del padre in BIP-32: un xpub padre insieme a una corrispondente chiave privata figlia non rafforzata compromessa può rivelare il sottoalbero privato del padre.
  • Strumenti di recupero non affidabili: siti web, estensioni, dispositivi contraffatti, strumenti per gli appunti o la condivisione dello schermo possono acquisire l’intero segreto radice.
  • Supporti non verificati: carta, metallo, file cifrati o backup hardware possono fallire a causa di errori di trascrizione, corrosione, password dimenticate o formati non supportati.
  • Migrazione incompleta: trasferire le monete visibili lasciando token, output di resto, ruoli nei contratti, approvazioni o account successivi sotto la vecchia radice mantiene l’esposizione.

Idee sbagliate comuni

Una frase di backup include tutti i dettagli del portafoglio?

No. Può riprodurre il materiale della chiave radice, ma non necessariamente la passphrase, la convenzione di derivazione, la rete, gli script, le regole multifirma, le etichette, le chiavi importate o la cronologia di individuazione degli account. Conserva i metadati richiesti dal portafoglio effettivo.

È sicuro pubblicare un xpub perché non può spendere?

No. Normalmente non può firmare, ma può rivelare gli indirizzi discendenti normali passati e futuri e la loro cronologia complessiva. Nel problema BIP-32 descritto sopra, associarlo a una corrispondente chiave privata figlia non rafforzata può anche compromettere il sottoalbero padre.

Gli indirizzi nuovi creano backup indipendenti?

No. Gli indirizzi nuovi riducono il riutilizzo degli indirizzi e migliorano la privacy, ma i discendenti deterministici restano controllati dallo stesso antenato. La compromissione della radice colpisce il sottoalbero anche quando ogni pagamento ha usato un indirizzo nuovo.

Il ripristino di un indirizzo noto dimostra che il portafoglio è completo?

No. Convalida una combinazione di materiale radice, percorso e costruzione dell’indirizzo. Il ripristino deve comunque coprire i rami di ricezione e del resto, tutti gli account utilizzati, gli script o le regole e le reti pertinenti.

Argomenti correlati

Fonti

Navigazione

Cerca nella wiki...