Account e indirizzi

Su ZooBC la tua chiave è il tuo account. Un account nativo è identificato dalla sua chiave pubblica Ed25519, scritta come un indirizzo di 66 caratteri che inizia con ZBC_. Nessuno emette gli indirizzi: un wallet ricava il tuo dalla tua chiave, e può farlo offline. Ogni indirizzo porta un checksum, quindi una copia digitata male viene rifiutata prima che venga inviato qualsiasi cosa.

Com'è fatto un indirizzo

Un indirizzo nativo è formato dal prefisso ZBC, un trattino basso e 56 caratteri in sette gruppi di otto:

ZBC_57J5D5QV_OPO4JILA_RQW2JC77_OOIDM4VM_BHFCLTKB_2DOFOR4L_Z24K7SFR

Questo esempio è stato ricavato da un hash per il quiz di zoobc.how. Nessuno ne detiene la chiave, quindi non inviarvi mai monete.

I 56 caratteri sono 35 byte scritti in base32, un alfabeto formato dalle lettere maiuscole dalla A alla Z e dalle cifre da 2 a 7: i 32 byte che identificano l'account, seguiti da un checksum di 3 byte.

I 32 byte sono la chiave

All'interno della catena un account non è testo. È un numero di tipo di 4 byte seguito da un contenuto la cui lunghezza dipende dal tipo. Il tipo 0 è l'account nativo ZooBC, e il suo contenuto è la chiave pubblica Ed25519 dell'account stessa, non un suo hash. Chiunque può quindi leggere la chiave direttamente dall'indirizzo: dalla versione 0.5.8 l'API del nodo risponde a /api/v1/accounts/<address>/pubkey per un account nativo a partire dal solo indirizzo.

Altre catene fanno diversamente, e ZooBC le segue quando usa i loro indirizzi. Il contenuto di un account Ethereum sono gli ultimi 20 byte di un hash Keccak-256 della chiave, e quello di un account Bitcoin classico (P2PKH) è l'HASH160 di 20 byte della chiave. ZooBC accetta account di Bitcoin, Ethereum, Solana, Polkadot, Cardano, Ripple, Tron e Tezos, ciascuno scritto come lo scrive la sua catena d'origine e verificato con lo schema di firma della sua catena d'origine (chiavi e tipi di account).

Il checksum intercetta gli errori di battitura

Il checksum è formato dai primi 3 byte dello SHA3-256 calcolato sul contenuto di 32 byte seguito dalle tre lettere del prefisso. Qualunque cosa decodifichi un indirizzo, che sia il wallet, gli strumenti da riga di comando o l'API del nodo, lo ricalcola e rifiuta l'indirizzo se non corrisponde. Un errore di battitura casuale produce un altro indirizzo valido solo circa una volta su 2^24, cioè 16,7 milioni, tentativi. Come verifica per il quiz, sono state provate tutte le 1.736 modifiche di un singolo carattere dell'indirizzo di esempio qui sopra, e ognuna è stata rifiutata.

Il rifiuto avviene prima che venga costruita una transazione, quindi non viene inviato nulla. Il consenso stesso non decodifica mai testo: le transazioni portano gli indirizzi come byte, e il checksum viene verificato dagli strumenti che trasformano il testo in byte. Non esiste una ricerca dell'«account più vicino», e le monete inviate a un indirizzo sbagliato ma valido non tornerebbero indietro da sole.

Scrivere un indirizzo

La decodifica segue una regola dei caratteri significativi: ogni trattino basso, trattino e carattere di spaziatura viene scartato, a capo compresi, e ciò che resta viene convertito in maiuscolo. Così ZBC_57J5D5QV_…, zbc-57j5d5qv-…, un indirizzo senza alcun separatore e uno andato a capo su due righe di un'email decodificano tutti gli stessi 32 byte, e il checksum viene poi verificato come al solito. Separatori e maiuscole esistono solo per aiutare le persone a leggere e copiare.

Prefissi

Le tre lettere del prefisso dicono a che cosa serve una chiave:

L'API accetta anche una forma ZTX_ per gli id delle transazioni.

Poiché il checksum copre il prefisso, gli stessi 32 byte sotto due prefissi hanno in comune i primi 51 caratteri dopo il prefisso e differiscono solo negli ultimi cinque. La chiave dell'esempio scritta come chiave del nodo termina in …_2DOFOR4L_Z24FR5JM invece che in …_2DOFOR4L_Z24K7SFR. Cambiare il prefisso a mano, senza ricalcolare la parte finale, rompe il checksum, quindi la modifica viene intercettata. L'account proprio di un nodo è la forma ZBC_ della sua chiave del nodo.

Indirizzi senza chiave

Alcuni indirizzi nativi non sono affatto chiavi. Nessuna chiave privata corrisponde a essi, quindi nessuna firma può spendere da essi, e le loro monete si muovono solo secondo le regole del protocollo stesso:

• i pool del protocollo: il pool di longevità ZBCLONGV, il pool di archiviazione ZBCSTORE e il pool delle app ZBCAPPS, ciascuno un nome ASCII completato con zeri fino a 32 byte (pool);
• un gruppo di account, indicato da un hash della transazione che lo ha fondato (gruppi di account);
• un account multifirma, un hash della sua soglia e dei suoi partecipanti (multifirma);
• un oggetto dataset, l'hash della transazione che lo ha creato (dataset).

Tutto è pubblico

Ogni nodo detiene lo stato completo, e la sua API risponde a chiunque, senza account, senza chiave e senza chiave API. GET /api/v1/accounts/<address> restituisce il saldo, e le route /history, /transactions e /movements sotto di essa elencano ciò che l'account ha fatto e ogni variazione del suo saldo con la relativa causa, compresi i canoni pagati e le ricompense vinte. Gli explorer mostrano gli stessi dati come pagine web (explorer e i nodi di archivio).

Ciò che la catena non registra è chi sei. Un indirizzo è una chiave, non un nome, e nulla sulla catena lo collega a una persona a meno che qualcuno non stabilisca quel collegamento. La privacy su ZooBC deriva quindi da come usi gli indirizzi, non da saldi nascosti. Serve una chiave per agire, mai per guardare.

Un account che detiene ZBC paga un piccolo canone, e un account il cui saldo non riesce a coprirlo viene eliminato (canone degli account e pruning).

Vedi anche

• Procurarsi un wallet e custodirlo al sicuro
• Chiavi e tipi di account
• Firmare una transazione
• Canone degli account e pruning
• Glossario