Wiki ZooBC
Les bases de ZooBC

Comptes et adresses

Sur ZooBC, votre clé est votre compte. Un compte natif est identifié par sa clé publique Ed25519, écrite sous la forme d’une adresse de 66 caractères qui commence par ZBC_. Personne ne délivre d’adresses : un portefeuille dérive la vôtre de votre clé, et il peut le faire hors ligne. Chaque adresse porte une somme de contrôle, si bien qu’une copie mal saisie est refusée avant tout envoi.

À quoi ressemble une adresse

Une adresse native se compose du préfixe ZBC, d’un tiret bas et de 56 caractères en sept groupes de huit :

ZBC_57J5D5QV_OPO4JILA_RQW2JC77_OOIDM4VM_BHFCLTKB_2DOFOR4L_Z24K7SFR

Cet exemple a été fabriqué à partir d’un hachage pour le quiz zoobc.how. Personne n’en détient la clé : n’y envoyez donc jamais de pièces.

Les 56 caractères sont 35 octets écrits en base32, un alphabet composé des lettres majuscules de A à Z et des chiffres de 2 à 7 : les 32 octets qui identifient le compte, suivis d’une somme de contrôle de 3 octets.

Une clé publique de 32 octets plus une somme de contrôle de 3 octets font 35 octets ; le base32 (A-Z, 2-7) les transforme en 56 caractères ; l’ajout de ZBC_ et le regroupement par 8 donnent l’adresse finale.
Une clé publique de 32 octets plus une somme de contrôle de 3 octets font 35 octets ; le base32 (A-Z, 2-7) les transforme en 56 caractères ; l’ajout de ZBC_ et le regroupement par 8 donnent l’adresse finale.

Les 32 octets sont la clé

À l’intérieur de la chaîne, un compte n’est pas du texte. C’est un numéro de type de 4 octets suivi d’une charge utile dont la longueur dépend du type. Le type 0 est le compte ZooBC natif, et sa charge utile est la clé publique Ed25519 du compte elle-même, pas un hachage de celle-ci. N’importe qui peut donc lire la clé directement dans l’adresse : à partir de la version 0.5.8, l’API du nœud répond à /api/v1/accounts/<address>/pubkey pour un compte natif à partir de la seule adresse.

D’autres chaînes procèdent autrement, et ZooBC suit leur façon de faire lorsqu’il utilise leurs adresses. La charge utile d’un compte Ethereum est constituée des 20 derniers octets d’un hachage Keccak-256 de la clé, et celle d’un compte Bitcoin classique (P2PKH) est le HASH160 de 20 octets de la clé. ZooBC accepte des comptes Bitcoin, Ethereum, Solana, Polkadot, Cardano, Ripple, Tron et Tezos, chacun écrit comme l’écrit sa chaîne d’origine et vérifié avec le schéma de signature de celle-ci (clés et les types de comptes).

La somme de contrôle détecte les fautes de frappe

La somme de contrôle est formée des 3 premiers octets du SHA3-256 calculé sur la charge utile de 32 octets suivie des trois lettres du préfixe. Tout ce qui décode une adresse, que ce soit le portefeuille, les outils en ligne de commande ou l’API du nœud, la recalcule et refuse l’adresse lorsqu’elle ne correspond pas. Une faute de frappe au hasard ne produit une autre adresse valide qu’environ une fois sur 2^24, soit 16,7 millions, d’essais. À titre de vérification pour le quiz, les 1 736 modifications d’un seul caractère de l’adresse d’exemple ci-dessus ont toutes été essayées, et chacune a été refusée.

Le refus intervient avant la construction de la transaction : rien n’est donc envoyé. Le consensus lui-même ne décode jamais de texte : les transactions portent les adresses sous forme d’octets, et la somme de contrôle est vérifiée par les outils qui transforment le texte en octets. Il n’existe pas de recherche du «  compte le plus proche  », et des pièces envoyées à une adresse erronée mais valide ne reviendraient pas d’elles-mêmes.

Écrire une adresse

Le décodage suit une règle des caractères significatifs : chaque tiret bas, trait d’union et caractère d’espacement est supprimé, sauts de ligne compris, et ce qui reste est mis en majuscules. Ainsi, ZBC_57J5D5QV_…, zbc-57j5d5qv-…, une adresse sans aucun séparateur et une adresse coupée sur deux lignes d’un e-mail se décodent toutes en les mêmes 32 octets, et la somme de contrôle est ensuite vérifiée comme d’habitude. Les séparateurs et les majuscules n’existent que pour aider les personnes à lire et à recopier.

Les préfixes

Les trois lettres du préfixe indiquent à quoi sert une clé :

PréfixeSignification
ZBC_un compte (type 0)
ZNK_une clé de nœud (clés d’un nœud)
ZBR_une clé de relais (relais)
ZBG_une clé de passerelle (passerelles)
ZBS_un objet de jeu de données (type 10, jeux de données)

L’API accepte aussi une forme ZTX_ pour les identifiants de transaction.

Comme la somme de contrôle couvre le préfixe, les mêmes 32 octets sous deux préfixes partagent les 51 premiers caractères après le préfixe et ne diffèrent que par les cinq derniers. La clé d’exemple écrite comme clé de nœud se termine par …_2DOFOR4L_Z24FR5JM au lieu de …_2DOFOR4L_Z24K7SFR. Changer le préfixe à la main, sans recalculer la fin, rompt la somme de contrôle : la modification est donc détectée. Le propre compte d’un nœud est la forme ZBC_ de sa clé de nœud.

La même clé en ZBC_ et en ZNK_ : les 51 caractères après le préfixe sont identiques (la clé), les cinq derniers diffèrent parce que la somme de contrôle couvre le préfixe.
La même clé en ZBC_ et en ZNK_ : les 51 caractères après le préfixe sont identiques (la clé), les cinq derniers diffèrent parce que la somme de contrôle couvre le préfixe.

Les adresses sans clé

Certaines adresses natives ne sont pas du tout des clés. Aucune clé privée ne leur correspond, donc aucune signature ne peut dépenser depuis elles, et leurs pièces ne bougent que selon les règles propres au protocole :

  • les fonds du protocole : le fonds de longévité ZBCLONGV, le fonds de stockage ZBCSTORE et le pool des apps ZBCAPPS, chacun étant un nom ASCII complété par des zéros jusqu’à 32 octets (fonds) ;
  • un groupe de comptes, nommé par un hachage de la transaction qui l’a fondé (groupes de comptes) ;
  • un compte multisignature, un hachage de son seuil et de ses participants (multisignature) ;
  • un objet de jeu de données, le hachage de la transaction qui l’a créé (jeux de données).

Tout est public

Chaque nœud détient l’état complet, et son API répond à tout le monde, sans compte, sans clé et sans clé d’API. GET /api/v1/accounts/<address> renvoie le solde, et les routes /history, /transactions et /movements situées en dessous listent ce que le compte a fait et chaque modification de son solde avec sa cause, y compris les loyers payés et les récompenses gagnées. Les explorateurs affichent les mêmes données sous forme de pages web (explorateur et les nœuds d’archivage).

Ce que la chaîne n’enregistre pas, c’est qui vous êtes. Une adresse est une clé, pas un nom, et rien sur la chaîne ne la relie à une personne à moins que quelqu’un n’établisse ce lien. Sur ZooBC, la confidentialité vient donc de la façon dont vous utilisez les adresses, pas de soldes cachés. Il faut une clé pour agir, jamais pour consulter.

Un compte qui détient des ZBC paie un petit loyer, et un compte dont le solde ne peut pas le couvrir est élagué (loyer de compte et l’élagage).

Voir aussi