Chiavi e tipi di account

Un account ZooBC è controllato da una firma, mai da un nome utente, una password o una chiave API. Quale firma dipende dal tipo dell'account. Oltre ai suoi account nativi Ed25519, ZooBC accetta account i cui indirizzi sono scritti come li scrivono Bitcoin, Ethereum, Solana, Polkadot, Cardano, Ripple, Tron e Tezos, e ne verifica le firme con lo schema proprio di ciascuna catena. Una chiave Bitcoin o Ethereum può quindi controllare un account ZooBC allo stesso indirizzo che ha sulla sua catena d'origine. Quell'account è separato, nel registro contabile di ZooBC, e detiene ZBC.

Un indirizzo è un tipo più un contenuto

Un indirizzo è un numero di tipo di 4 byte (little-endian) seguito da un contenuto il cui significato e la cui lunghezza dipendono dal tipo (account e indirizzi). Per un account nativo il contenuto è la chiave pubblica Ed25519 stessa; per un account Ethereum sono gli ultimi 20 byte dell'hash Keccak-256 della chiave; per un account Bitcoin P2PKH è l'HASH160 della chiave.

Nemmeno gli indirizzi senza chiave possono firmare: i pool del protocollo, i gruppi di account e gli account multifirma non hanno una chiave, quindi i loro fondi si muovono solo secondo le regole del protocollo.

La forma testuale nativa è ZBC_ seguito da 56 caratteri base32 in sette gruppi di otto: la chiave di 32 byte più un checksum SHA3-256 di 3 byte che copre anche il prefisso. Separatori, spazi e maiuscole o minuscole vengono ignorati in lettura. La stessa chiave di 32 byte può essere scritta anche come chiave del nodo (ZNK_), chiave di relay (ZBR_) o chiave di gateway (ZBG_).

Un solo digest per ogni schema

Ogni tipo di account firma lo stesso digest legato alla catena:

digest = SHA3-256("ZBC-TX" ‖ genesis hash ‖ unsigned transaction bytes)

Viene accettato solo questo digest; una firma sui byte nudi viene rifiutata. L'hash genesi lega ogni firma a una sola catena (firme legate alla catena). Alcuni schemi calcolano un'altra volta l'hash del digest, come richiede la loro catena d'origine.

Gli schemi

• Ed25519 sul digest di 32 byte, per ZooBC (tipo 0) e Solana (11). Anche Cardano (13) e Tezos (16) firmano con Ed25519, ma i loro indirizzi sono hash, quindi il campo firma contiene anche la chiave: 98 byte formati da una lunghezza di 2 byte, la chiave e la firma. La chiave è legata all'indirizzo da BLAKE2b-28 (Cardano) o BLAKE2b-20 (Tezos).
• ECDSA secp256k1, stile Bitcoin, per i tipi 1, 5, 6 e 7 e per Ripple (14). Il campo firma contiene la chiave: una lunghezza di 2 byte, una chiave di 33 o 65 byte, poi la firma di 64 byte (r e s). L'HASH160 della chiave deve essere uguale all'indirizzo, il messaggio firmato è il doppio SHA-256 del digest, e sono accettate solo firme low-s.
• ECDSA secp256k1, stile Ethereum, per Ethereum (4) e Tron (15): una firma di 65 byte (r, s e v) sull'hash Keccak-256 del digest. La chiave viene recuperata dalla firma e se ne confronta l'indirizzo; le firme high-s vengono rifiutate.
• Schnorr BIP-340 per Taproot (9), con la chiave di output x-only; il wallet applica il tweak Taproot.
• sr25519 per Polkadot (12), con il contesto di firma «substrate».

Gli account Taproot possono anche ricevere ZBC tramite SendZBC su ogni catena fin dalla genesi.

Verificare una chiave che non è memorizzata

Un indirizzo in stile Ethereum è solo un hash di 20 byte; la chiave pubblica non è memorizzata da nessuna parte sulla catena. Le firme Ethereum sono recuperabili: dal messaggio firmato e dalla firma di 65 byte, chiunque può calcolare l'unica chiave pubblica che l'ha prodotta. Il nodo fa esattamente questo, prende gli ultimi 20 byte dell'hash Keccak-256 della chiave recuperata e accetta la firma solo se sono uguali all'indirizzo. Poiché le firme high-s vengono rifiutate, una firma non può essere alterata in una seconda forma valida. Non serve alcun passo di registrazione né alcuna consultazione esterna, e gli account 0x possono inviare con la stessa libertà con cui ricevono.

Transazioni esterne trasportate all'interno

Un mittente con un account di un'altra catena può anche mettere una transazione nativa della sua catena d'origine nel campo messaggio di una transazione ZooBC. Su questo percorso il nodo verifica la transazione esterna e la sua firma al posto del digest ZooBC:

• Ethereum (tipo 4): una transazione EIP-1559, EIP-2930 o legacy (EIP-155) con una access list vuota. Il suo firmatario recuperato deve essere il mittente, il suo to il destinatario, e il suo valore in wei diviso per 10^10 l'importo (MetaMask e accesso in stile Ethereum).
• Solana (tipo 11): un trasferimento System i cui lamport corrispondono all'importo.
• Bitcoin (tipi 7 e 5): un input, uno o due output e una commissione per i miner pari a zero; l'output 0 paga il destinatario e l'output 1, se presente, restituisce il resto al mittente.

Un messaggio vettore di questo tipo può essere di fino a 4.096 byte, e la transazione non può contenere un pagamento di sopravvivenza (involucro della transazione).

Derivare le chiavi native

Una chiave nativa viene derivata da una frase di recupero BIP-39: PBKDF2-HMAC-SHA512 con 2.048 iterazioni, poi SLIP-0010 Ed25519 lungo m/44'/883'/n', con ogni passo hardened. 883 è il coin type di ZooBC.

Vedi anche

• Account e indirizzi
• Firme legate alla catena
• Firmare una transazione
• MetaMask e accesso in stile Ethereum
• Il wallet web