Dalla chiave pubblica all’indirizzo: formati nelle diverse reti

Un indirizzo è una rappresentazione definita dal protocollo, non un identificativo universale

Un indirizzo blockchain è un modo specifico di una rete per indicare un account, una destinazione o un insieme di condizioni di spesa. Molti indirizzi sono in ultima analisi collegati alla crittografia a chiave pubblica, ma il percorso da una chiave pubblica a un indirizzo visualizzato non è universale. Alcune reti applicano un hash alla chiave pubblica, altre codificano direttamente la chiave pubblica e altre ancora consentono destinazioni derivate dalla logica di un programma o da condizioni multiple. Di conseguenza, l’affermazione «un indirizzo è solo una chiave pubblica» è troppo generica. Allo stesso modo, gli indirizzi non contengono un nome personale verificato e una stessa stringa che sembra un indirizzo può avere significati diversi su reti diverse.

Una codifica definisce come i byte diventano caratteri leggibili. Base58 usa un alfabeto scelto per evitare alcuni caratteri visivamente confondibili. La notazione esadecimale usa la base 16, con cifre da 0 a 9 e lettere da a a f. Bech32 usa un alfabeto diverso e include un meccanismo di checksum per rilevare molti errori di trascrizione. Un prefisso può aiutare a indicare una rete o una famiglia di indirizzi, ma non è una verifica indipendente della titolarità. È opportuno riconoscere i formati, lasciando la validazione definitiva a software che conosce la rete specifica e le sue regole.

Bitcoin: diversi modi per descrivere le condizioni di spesa

Gli indirizzi Bitcoin rappresentano generalmente destinazioni di output: le condizioni alle quali i coin associati a un determinato output potranno essere spesi in seguito. In un modello più datato, il pay-to-public-key-hash (P2PKH), la destinazione codifica un hash associato a una chiave pubblica ed è comunemente visualizzata usando Base58Check; sulla mainnet Bitcoin inizia spesso con «1». Gli indirizzi pay-to-script-hash (P2SH) iniziano comunemente con «3» sulla mainnet e rappresentano l’hash di uno script di riscatto, anziché semplicemente la chiave pubblica di una persona. Uno script P2SH può contenere condizioni non visibili dal solo indirizzo.

Gli output nativi Segregated Witness (SegWit) di versione 0 usano la codifica di indirizzo Bech32 prevista dalla Bitcoin Improvement Proposal (BIP) 173 e sulla mainnet iniziano spesso con «bc1q». Gli output nativi witness di versione 1 e successive usano Bech32m secondo la BIP 350; gli indirizzi Taproot iniziano comunemente con «bc1p». Le regole di spesa esatte dipendono dal witness program e dal tipo di script. Queste stringhe sono esempi di famiglie di indirizzi, non regole di validazione esaustive. Non si dovrebbe dedurre che una stringa arbitraria che inizia con «bc1p» sia quindi valida. Il software deve verificare la lunghezza, l’alfabeto, il checksum, la versione witness e gli altri vincoli descritti dalla specifica applicabile.

Perché coesistono formati più datati e più recenti

Un formato di indirizzo fa parte di un ecosistema di protocolli e applicazioni. Nuove tecniche di codifica possono migliorare il rilevamento degli errori o supportare nuovi tipi di spesa, mentre i tipi di destinazione precedenti restano presenti nei dati storici e spesso continuano a essere utilizzabili. Questa coesistenza non implica che un formato visualizzato rappresenti un asset diverso. Né significa che un utente possa convertire in sicurezza una destinazione in un altro formato modificandone il prefisso. La conversione non è un’operazione di modifica del testo: devono essere preservate le condizioni di spesa sottostanti e le regole del protocollo. Quando un analista rileva più formati, dovrebbe innanzitutto stabilire se appartengono alla stessa rete e quali informazioni comunica ciascuno.

Ethereum: indirizzi di account di 20 byte

Gli indirizzi degli account esterni di Ethereum si formano convenzionalmente a partire dagli ultimi 20 byte di un hash Keccak-256 di una chiave pubblica rappresentata in modo appropriato. Sono comunemente mostrati con il prefisso «0x» seguito da 40 caratteri esadecimali. Ethereum ha anche account di contratto, i cui indirizzi identificano codice distribuito e non sono derivati da una corrispondente chiave privata convenzionale nello stesso modo. Ethereum Improvement Proposal 55 (EIP-55), Mixed-case checksum address encoding, usa le maiuscole e le minuscole delle lettere nella stringa esadecimale come meccanismo facoltativo per rilevare errori di digitazione. Si possono comunque usare rappresentazioni tutte in minuscolo; la validazione del checksum con maiuscole e minuscole miste aiuta a rilevare alcuni errori, ma non può stabilire l’identità del destinatario.

Numerose reti compatibili con l’Ethereum Virtual Machine usano una sintassi di indirizzo che inizia anch’essa con «0x». Una sequenza identica di 20 byte su due reti non significa che le due reti condividano saldi o cronologie delle transazioni. Un token su una rete di questo tipo può essere associato a un indirizzo di smart contract, mentre il saldo dell’utente è registrato nello stato del contratto. L’indirizzo del contratto, l’indirizzo dell’account dell’utente, un identificativo di transazione e il simbolo leggibile di un asset si riferiscono a elementi diversi. Confonderli può portare a rendicontazioni errate anche quando ogni carattere copiato è corretto.

Solana: indirizzi basati su valori di 32 byte

Un indirizzo di account Solana è un valore di 32 byte visualizzato in Base58. Un tipo di indirizzo è una chiave pubblica associata a una coppia di chiavi Ed25519; un altro è un indirizzo derivato da un programma (PDA), calcolato a partire da un identificativo di programma e da seed secondo le regole di indirizzamento di Solana. Un PDA non ha una corrispondente chiave privata capace di firmare secondo le modalità ordinarie. Un programma autorizzato può invece agire per quell’indirizzo tramite regole di esecuzione definite. Questo esempio mostra perché non si può descrivere ogni indirizzo come un hash abbreviato di una chiave pubblica. Nel modello degli account di Solana, l’indirizzo dell’account identifica lo stato, mentre il campo proprietario dell’account determina quale programma può modificare quei dati secondo le regole della rete.

Riconoscere, convalidare e attribuire

Un indirizzo può sembrare plausibile pur appartenendo alla rete sbagliata. Un checksum può rilevare molti errori di digitazione accidentali, ma un indirizzo ben formato può comunque identificare un destinatario non intenzionale o un programma dal comportamento inatteso. Anche le schermate che nascondono i caratteri centrali possono celare delle sostituzioni. Prima di interpretare un registro di pagamento, occorre distinguere la validità sintattica dalla compatibilità con la rete, ed entrambe dall’identificazione del titolare. Un’etichetta di un explorer come «wallet di servizio» è un’affermazione fornita da un operatore o da una fonte di dati, non qualcosa che nella maggior parte dei casi è incorporato matematicamente nelle stringhe degli indirizzi.

1. Identificare la rete esatta e, se pertinente, l’ambiente di rete, ad esempio mainnet o una rete di test.
2. Determinare se la stringa è un indirizzo di account, un indirizzo di contratto, una destinazione di output, un identificativo di transazione o un altro oggetto.
3. Convalidare il valore completo con un parser appropriato alla rete, anziché basarsi solo sul prefisso.
4. Per l’attribuzione, raccogliere prove indipendenti; non equiparare la corrispondenza del checksum all’identificazione verificata di una persona o di un ente.

I formati degli indirizzi sono ottimizzati intenzionalmente affinché le macchine li interpretino con precisione, non perché le persone li memorizzino. In un rapporto del settore pubblico, una formulazione corretta è «questa transazione fa riferimento alla destinazione X sulla rete Y», non «la persona Z ha ricevuto i fondi», a meno che altre prove non giustifichino tale attribuzione. La prossima lezione mostra come queste distinzioni tra indirizzi e identificativi compaiono nei dati messi a disposizione dagli explorer blockchain. Il modulo successivo del corso tratterà la gestione pratica di chiavi, frasi seed e rapporti di custodia.

Focus d’esame: Confrontare le famiglie di indirizzi Bitcoin Base58Check, Bech32 e Bech32m; gli indirizzi esadecimali Ethereum e l’EIP-55; e gli account Solana in Base58, compresi gli indirizzi derivati da programmi. Spiegare perché un indirizzo non è universalmente una chiave pubblica o un’identità verificata e perché una stringa identica su reti diverse non implica uno stato identico.