Signer une transaction
Une signature prouve que le détenteur de la clé d’un compte a approuvé une transaction, octet par octet. Sur ZooBC, le signataire ne signe jamais la transaction brute : il signe un condensé qui couvre aussi l’identité de la chaîne, si bien que la signature n’est valide que sur une seule chaîne. Des comptes de nombreux types de clés peuvent signer, chacun avec le schéma de sa chaîne d’origine, ce qui permet à une clé Bitcoin, Ethereum ou Solana de contrôler directement un compte ZooBC.
Ce qui est signé
Le signataire prend l’enveloppe non signée, c’est-à-dire tous les champs sauf la signature, et signe ce condensé :
digest = SHA3-256( "ZBC-TX" ‖ genesis block hash ‖ unsigned bytes )« ZBC-TX » est une étiquette ASCII, et ‖ signifie « suivi de ». Seul ce condensé lié à la chaîne est accepté. Dans une transaction de version 3, les 4 octets d’expiration font partie des octets non signés : ils sont donc signés comme tous les autres champs.
Le hachage du bloc de genèse est l’identité de la chaîne. ZooBC n’a pas de champ d’identifiant de réseau : le devnet, le testnet et le mainnet ont chacun leur propre hachage de genèse, si bien qu’une signature faite pour le mainnet ne se vérifie ni sur le devnet ni sur le testnet, même lorsque la même clé détient des fonds sur les trois. Les nœuds comparent aussi leurs hachages de genèse avant de se connecter les uns aux autres. Cela ferme la porte au rejeu inter-chaînes, où quelqu’un copie votre transaction d’une chaîne vers une autre ; voir les signatures liées à la chaîne.
Le hachage et l’identifiant
Une fois signée, une transaction est identifiée par son hachage et son identifiant :
hash = SHA3-256( unsigned bytes ‖ signature )
id = the first 8 bytes of the hash, read as a little-endian signed 64-bit integerUn nœud refuse un identifiant déjà confirmé, ce qui empêche un rejeu sur la même chaîne. L’identifiant d’une transaction IssueToken est aussi l’identifiant du jeton qu’elle crée (voir l’émission d’un jeton).
Les types de clés qui peuvent signer
Une adresse commence par un numéro de type, et ce type décide de la façon dont sa signature est vérifiée :
| Type de clé (numéro) | Schéma de signature |
|---|---|
| ZooBC (0), Solana (11) | Ed25519 |
| Cardano (13), Tezos (16) | Ed25519, la clé publique étant portée dans un champ de signature de 98 octets |
| Bitcoin legacy (1), P2PKH (5), P2WPKH encapsulé dans P2SH (6), P2WPKH (7), Ripple (14) | ECDSA secp256k1 sur un double SHA-256 du condensé, la clé publique étant jointe |
| Ethereum (4), Tron (15) | secp256k1 sur le Keccak-256 du condensé ; la clé est retrouvée à partir d’une signature r‖s‖v de 65 octets |
| Bitcoin Taproot (9) | Schnorr BIP-340 |
| Polkadot (12) | sr25519 |
Les signatures ECDSA doivent utiliser la forme low-s. Quel que soit le schéma, chaque clé signe le même condensé lié à la chaîne.
Certains types d’adresses ne peuvent jamais signer : Empty (2), l’eID estonien (3, qui n’a pas de vérificateur), les scripts Bitcoin P2WSH (8) et les jeux de données (10). Une adresse P2WSH représente un script plutôt qu’une clé unique, et une adresse de jeu de données désigne des données, pas un signataire. Les comptes sans clé, comme les fonds du système, les groupes de comptes et les comptes multisignature, n’ont aucune clé et ne dépensent que selon leurs propres règles.
Signer avec un portefeuille étranger
Un portefeuille étranger peut aussi signer une transaction de sa propre chaîne et la faire transporter, comme message, à l’intérieur de la transaction ZooBC correspondante :
- Ethereum : une transaction legacy, EIP-2930 ou EIP-1559 avec une liste d’accès vide ;
- Solana : un transfert du programme System ;
- Bitcoin : une entrée, une ou deux sorties, et des frais nuls.
Le nœud vérifie que l’expéditeur, le destinataire et le montant concordent avec la transaction ZooBC, et une même charge utile étrangère ne peut être dépensée qu’une seule fois. Un tel message peut contenir jusqu’à 4 096 octets. Pour un accès à la manière d’Ethereum, voir MetaMask.
Autres condensés signés
Le même schéma lié à la chaîne, chaque fois avec sa propre étiquette, couvre d’autres consentements :
- le rattachement d’une adresse à un groupe et la cession du contrôle d’un groupe (« ZBC-GROUP-LINK » et « ZBC-GROUP-CONTROL ») ;
- la demande faite à un nœud d’annuler une transaction en attente dans son pool (« ZBC-CANCEL ») ;
- la cosignature d’un séquestre à plusieurs parties.
Les messages hors chaîne, qui ne sont pas des transactions, sont signés sous la forme SHA3-256("ZBC-MSG-v2" ‖ genesis hash ‖ message) avec une clé Ed25519 ; voir les messages signés et chiffrés.