Wiki ZooBC
Les bases de ZooBC

La ZooBC Foundation

La ZooBC Foundation est l’organisation à l’origine de ZooBC. Sur chaque chaîne, elle détient les 11 sièges de genèse du registre des nœuds, et elle publie les outils publics en ligne de commande. Elle n’a aucun pouvoir particulier sur les transactions ou les soldes : le protocole confie à chaque clé une seule tâche, et certaines choses ne sont possibles pour aucune clé.

Les sièges de genèse

Chaque chaîne démarre avec 11 nœuds enregistrés inscrits dans son bloc de genèse : les sièges de genèse, détenus par la Foundation. Tout autre opérateur rejoint le registre des nœuds par la file d’attente (file d’attente). Personne ne choisit les nouveaux venus ; ils sont admis un par un, au rythme fixé par le protocole. Sur le mainnet, le premier nouveau venu est admis 7 jours après la genèse, puis un par cycle de 600 jours divisés par le nombre de sièges comptés, borné entre 7 et 90 jours : environ 54,5 jours tant que 11 sièges sont comptés (rythme d’admission). Dans ce décompte, les sièges de genèse pèsent au plus 11.

Une fois admis, chaque siège actif a la même chance d’être tiré pour produire un bloc. Les sièges de genèse suivent les mêmes règles que les autres, et démarrent avec le même score de participation de 20 % que tout nouveau nœud.

Chaque chaîne démarre avec 11 sièges de genèse détenus par la ZooBC Foundation ; les autres nœuds attendent dans une file et passent un tourniquet, une admission par cycle, vers de nouveaux sièges. Chaque siège actif a la même chance de produire des blocs.
Chaque chaîne démarre avec 11 sièges de genèse détenus par la ZooBC Foundation ; les autres nœuds attendent dans une file et passent un tourniquet, une admission par cycle, vers de nouveaux sièges. Chaque siège actif a la même chance de produire des blocs.

Les outils

La Foundation publie les outils publics en ligne de commande sur github.com/zoobc/tools, sous licence MIT, en dix langages : C++, TypeScript, JavaScript, Python, Go, Rust, Kotlin, Swift, PHP et Perl. Ils dialoguent avec un nœud uniquement par son API publique, comme n’importe quelle application (outils en ligne de commande).

Les clés et leurs tâches

ZooBC confie à chaque clé une seule tâche :

CléCe qu’elle fait
autorité de publicationenregistre les versions du logiciel par le hachage de leurs fichiers, et peut les révoquer
trésorerieun compte ordinaire : elle dépense ce qu’elle détient
teneur de marchéun compte ordinaire
autorité des pagesaucune règle de la chaîne ne la lit
propriétaire de siègeenregistre, met à jour, change la clé et retire son propre nœud, et perçoit les gains du nœud
clé de nœudproduit les blocs et signe les reçus, les attestations et les votes

À partir de la version 0.5.8, les quatre clés de rôle (autorité de publication, autorité des pages, trésorerie et teneur de marché) ont quatre adresses distinctes sur les trois chaînes, chacune conservée sur son propre appareil. Le constructeur de genèse vérifie qu’elles diffèrent. Des quatre, seule l’autorité de publication a un pouvoir sur la chaîne, et elle peut détenir jusqu’à 1 000 ZBC à la genèse pour payer ses frais. Les sièges exercent un contrôle sur elle : les deux tiers d’entre eux peuvent opposer leur veto à une version, et les deux tiers maintenant leur vote pendant une semaine peuvent remplacer l’autorité (versions et mises à jour).

Les propriétaires de sièges et les clés de nœud sont expliqués dans l’article clés d’un nœud.

Quatre clés, une tâche chacune : l’autorité de publication enregistre ou révoque le hachage d’une version, la trésorerie dépense son propre solde, le propriétaire de siège enregistre, modifie ou retire son nœud, la clé de nœud produit les blocs et signe les reçus ; il n’y a pas de clé d’administration.
Quatre clés, une tâche chacune : l’autorité de publication enregistre ou révoque le hachage d’une version, la trésorerie dépense son propre solde, le propriétaire de siège enregistre, modifie ou retire son nœud, la clé de nœud produit les blocs et signe les reçus ; il n’y a pas de clé d’administration.

Ce qu’aucune clé ne peut faire

  • Il n’y a pas de clé d’administration dans le consensus. Une règle, un paramètre ou un solde ne change que par des transactions que chaque nœud valide, ou par les votes de prix bornés des sièges (votes de prix) ; jamais par un message signé.
  • La genèse est figée. Ses comptes, ses sièges, ses paramètres et ses hauteurs de règles font partie de l’identité de la chaîne.
  • L’activation des règles ne peut être ni votée ni signée. Un binaire de nœud en désaccord avec les hauteurs de règles enregistrées pour sa chaîne refuse de fonctionner.
  • La trésorerie ne peut pas frapper de pièces. Les nouveaux ZBC ne proviennent que du calendrier de la coinbase (offre et l’émission).
  • L’enregistrement d’une version est indicatif. Il ne guide que les nœuds qui ont choisi de se mettre à jour eux-mêmes, et ceux-ci vérifient le hachage par rapport à la chaîne. Un nœud qui exécute un binaire choisi par son opérateur n’est pas affecté.
  • Personne n’approuve les transactions. Chaque nœud valide chaque transaction et chaque bloc selon les mêmes règles : la Foundation ne peut donc ni approuver, ni annuler, ni bloquer un paiement.

Ces garanties tiennent grâce au code que chaque nœud exécute, pas grâce à la promesse de qui que ce soit. Les nouveaux ZBC ne sont pas non plus minés ni vendus par qui que ce soit : ils suivent un calendrier fixe et sont versés par loterie aux nœuds enregistrés en proportion de leur score (loterie coinbase).

Voir aussi