Wiki ZooBC
Sécurité et architecture

Signatures liées à la chaîne

Une signature ZooBC n’est valide que sur une seule chaîne. Avant de signer une transaction, un portefeuille calcule un condensé qui inclut le hachage de genèse de la chaîne, de sorte qu’un paiement signé sur le testnet ne se vérifie ni sur le mainnet ni sur le devnet, alors même que la même clé donne la même adresse sur chaque chaîne. La même liaison protège les connexions entre nœuds et les messages signés hors chaîne.

Le condensé

Le signataire ne signe jamais les octets bruts de la transaction. Il signe ce condensé :

digest           = SHA3-256("ZBC-TX" ‖ genesis hash ‖ unsigned transaction bytes)
transaction hash = SHA3-256(unsigned transaction bytes ‖ signature)
transaction id   = the first 8 bytes of the transaction hash, little-endian

L’étiquette « ZBC-TX » marque le condensé comme celui d’une transaction ; d’autres actions signées utilisent d’autres étiquettes (voir plus bas). Le hachage de genèse lie la signature à une seule chaîne. Seul ce condensé lié à la chaîne est accepté : une signature portant sur les octets nus, sans chaîne liée, est refusée sur toutes les chaînes. Voir signer une transaction pour la procédure de signature complète.

Un condensé construit à partir de ZBC-TX, du hachage de genèse (l’identité de la chaîne) et des octets de la transaction passe par SHA3-256 puis est signé. Avec la genèse du testnet, la signature correspond ; avec celle du mainnet, le condensé diffère et la transaction est refusée.
Un condensé construit à partir de ZBC-TX, du hachage de genèse (l’identité de la chaîne) et des octets de la transaction passe par SHA3-256 puis est signé. Avec la genèse du testnet, la signature correspond ; avec celle du mainnet, le condensé diffère et la transaction est refusée.

Le hachage de genèse est l’identité de la chaîne

Le hachage de genèse est le hachage du tout premier bloc d’une chaîne. Il est dérivé de la configuration de genèse de la chaîne, si bien que modifier n’importe laquelle des valeurs engagées dans cette configuration donne un nouveau hachage, c’est-à-dire une autre chaîne (voir bloc de genèse). Il n’existe nulle part dans ZooBC d’octet distinct d’identifiant de réseau : le hachage de genèse est la seule identité de la chaîne. Devnet, testnet et mainnet ont chacun le leur (voir devnet, testnet et mainnet), et un réseau de test relancé en reçoit un nouveau.

Un nœud indique le genesis_hash de sa chaîne et sa signing_version sur sa route d’information, /api/v1/node/info (voir API du nœud), de sorte qu’un portefeuille ou un outil peut savoir pour quelle chaîne il signe.

Le rejeu d’une chaîne à l’autre

Supposons qu’un paiement soit signé sur le testnet et que quelqu’un le copie sur le mainnet. Le nœud du mainnet calcule le condensé avec le hachage de genèse du mainnet, obtient une valeur différente, et la signature ne se vérifie pas : la transaction est refusée comme « non signée pour cette chaîne ». Le montant ne joue aucun rôle, et le portefeuille n’a rien à ajouter.

La même clé donne la même adresse sur chaque chaîne ZooBC, et une adresse approvisionnée sur une chaîne affiche simplement un solde nul sur une autre. C’est précisément pour cela que la liaison compte : sans elle, un paiement effectué sur une chaîne pourrait être copié sur une autre et y déplacer des pièces.

Chaque type de compte, chaque signataire

Les comptes ZooBC peuvent être contrôlés par de nombreux types de clés : les clés Ed25519 propres à ZooBC, des clés Bitcoin et Ethereum, et d’autres encore (voir clés et les types de comptes). Chaque type de compte signe le même condensé lié à la chaîne ; certains le hachent d’abord une nouvelle fois, comme l’exige le schéma de signature de leur chaîne d’origine (les clés de type Ethereum, par exemple, signent son hachage Keccak-256). Les participants d’un compte multisignature signent le condensé lié à la chaîne de la transaction interne.

D’autres actions signées utilisent leurs propres condensés, eux aussi liés à la chaîne : les consentements qui lient ou contrôlent des groupes de comptes (« ZBC-GROUP-LINK », « ZBC-GROUP-CONTROL »), la cosignature d’un séquestre à plusieurs parties, et la demande qui annule une transaction en attente dans le pool d’un nœud (« ZBC-CANCEL »).

Nœuds et messages

La liaison à la chaîne ne s’arrête pas aux transactions :

  • La poignée de main entre pairs. Lorsque deux nœuds se connectent, la poignée de main est signée par la clé de nœud et porte le hachage de genèse. Un pair d’une autre chaîne est refusé avec « Genesis hash mismatch », de sorte qu’un nœud d’une chaîne ne s’apparie jamais avec un nœud d’une autre.
  • Les messages signés. Les messages signés hors chaîne avec les outils utilisent le condensé SHA3-256("ZBC-MSG-v2" ‖ hachage de genèse ‖ message), de sorte qu’un message signé sur le devnet ne se vérifie jamais sur le testnet ni sur le mainnet (voir messages signés et chiffrés).

Les reçus sont l’exception au sein du protocole : un reçu ne nomme aucune chaîne et ne porte donc aucune liaison à la chaîne qui lui soit propre. Il nomme en revanche un bloc de référence par sa hauteur et son hachage, que les validateurs vérifient.

Voir aussi