Les clés et les types de comptes

Un compte ZooBC est contrôlé par une signature, jamais par un nom d’utilisateur, un mot de passe ou une clé API. La signature attendue dépend du type du compte. Outre ses comptes Ed25519 natifs, ZooBC accepte des comptes dont les adresses s’écrivent comme Bitcoin, Ethereum, Solana, Polkadot, Cardano, Ripple, Tron et Tezos les écrivent, et vérifie leurs signatures avec le schéma propre à chaque chaîne. Une clé Bitcoin ou Ethereum peut donc contrôler un compte ZooBC à la même adresse que celle qu’elle a sur sa chaîne d’origine. Ce compte est distinct, tenu sur le grand livre propre à ZooBC, et détient des ZBC.

Une adresse, c’est un type et une charge utile

Une adresse est un numéro de type sur 4 octets (little-endian) suivi d’une charge utile dont le type détermine le sens et la longueur (comptes et adresses). Pour un compte natif, la charge utile est la clé publique Ed25519 elle-même ; pour un compte Ethereum, ce sont les 20 derniers octets du hachage Keccak-256 de la clé ; pour un compte Bitcoin P2PKH, c’est le HASH160 de la clé.

Les adresses sans clé ne peuvent pas signer non plus : les fonds du protocole, les groupes de comptes et les comptes multisignature n’ont pas de clé, si bien que leurs avoirs ne bougent que selon les règles du protocole.

La forme textuelle native est ZBC_ suivi de 56 caractères base32 en sept groupes de huit : la clé de 32 octets plus une somme de contrôle SHA3-256 de 3 octets qui couvre aussi le préfixe. Les séparateurs, les espaces et la casse des lettres sont ignorés à la lecture. La même clé de 32 octets peut aussi s’écrire comme clé de nœud (ZNK_), clé de relais (ZBR_) ou clé de passerelle (ZBG_).

Un seul condensé pour tous les schémas

Chaque type de compte signe le même condensé lié à la chaîne :

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

Seul ce condensé est accepté ; une signature sur les octets bruts est refusée. Le hachage de genèse lie chaque signature à une seule chaîne (signatures liées à la chaîne). Certains schémas hachent le condensé une fois de plus, comme l’exige leur chaîne d’origine.

Les schémas

• Ed25519 sur le condensé de 32 octets, pour ZooBC (type 0) et Solana (11). Cardano (13) et Tezos (16) signent aussi avec Ed25519, mais leurs adresses sont des hachages : le champ de signature porte donc aussi la clé, soit 98 octets composés d’une longueur sur 2 octets, de la clé et de la signature. La clé est liée à l’adresse par BLAKE2b-28 (Cardano) ou BLAKE2b-20 (Tezos).
• ECDSA secp256k1, style Bitcoin, pour les types 1, 5, 6 et 7 et pour Ripple (14). Le champ de signature porte la clé : une longueur sur 2 octets, une clé de 33 ou 65 octets, puis la signature de 64 octets (r et s). Le HASH160 de la clé doit être égal à l’adresse, le message signé est le double SHA-256 du condensé, et seules les signatures à s faible (low-s) sont acceptées.
• ECDSA secp256k1, style Ethereum, pour Ethereum (4) et Tron (15) : une signature de 65 octets (r, s et v) sur le hachage Keccak-256 du condensé. La clé est récupérée à partir de la signature et son adresse comparée ; les signatures à s élevé (high-s) sont refusées.
• Schnorr BIP-340 pour Taproot (9), avec la clé de sortie x-only ; le portefeuille applique l’ajustement (tweak) Taproot.
• sr25519 pour Polkadot (12), dans le contexte de signature «  substrate  ».

Les comptes Taproot peuvent aussi recevoir des ZBC par SendZBC sur chaque chaîne, dès la genèse.

Vérifier une clé qui n’est pas stockée

Une adresse de style Ethereum n’est qu’un hachage de 20 octets ; la clé publique n’est stockée nulle part sur la chaîne. Les signatures Ethereum sont récupérables : à partir du message signé et de la signature de 65 octets, n’importe qui peut calculer l’unique clé publique qui l’a produite. Le nœud fait exactement cela, prend les 20 derniers octets du hachage Keccak-256 de la clé récupérée, et n’accepte la signature que s’ils sont égaux à l’adresse. Comme les signatures à s élevé sont refusées, une signature ne peut pas être transformée en une seconde forme valide. Aucune étape d’enregistrement ni aucune consultation externe n’est nécessaire, et les comptes 0x peuvent envoyer aussi librement qu’ils reçoivent.

Des transactions étrangères transportées à l’intérieur

Un expéditeur doté d’un compte étranger peut aussi placer une transaction native de sa chaîne d’origine dans le champ message d’une transaction ZooBC. Sur ce chemin, le nœud vérifie la transaction étrangère et sa signature au lieu du condensé ZooBC :

• Ethereum (type 4) : une transaction EIP-1559, EIP-2930 ou legacy (EIP-155) avec une liste d’accès vide. Son signataire récupéré doit être l’expéditeur, son to le destinataire, et sa valeur en wei divisée par 10^10 le montant (MetaMask et l’accès de style Ethereum).
• Solana (type 11) : un transfert System dont les lamports sont égaux au montant.
• Bitcoin (types 7 et 5) : une entrée, une ou deux sorties et des frais de mineur nuls ; la sortie 0 paie le destinataire et la sortie 1, s’il y en a une, rend la monnaie à l’expéditeur.

Un tel message porteur peut atteindre 4 096 octets, et la transaction ne peut pas porter de paiement de survie (enveloppe de la transaction).

Dériver les clés natives

Une clé native est dérivée d’une phrase de récupération BIP-39 : PBKDF2-HMAC-SHA512 avec 2 048 itérations, puis SLIP-0010 Ed25519 selon m/44'/883'/n', chaque étape étant durcie (hardened). 883 est le type de monnaie de ZooBC.

Voir aussi

• Comptes et adresses
• Signatures liées à la chaîne
• Signer une transaction
• MetaMask et l’accès de style Ethereum
• Le portefeuille web