FA2 de / vers la sérialisation

Question

Dans la norme FA2.0, l'expéditeur et le destinataire sont envoyés sous forme d'octets (par rapport à l'envoi sous forme de chaîne pour FA1.2).

Résultat attendu: lors du décodage des adresses (chaîne) en leur représentation de hachage de clé publique, je suppose que le format P2P est suivi: https://tezos.gitlab.io/api/p2p.html#public-key-hash-21-bytes-8-bit-tag. Par exemple, tz1ij8gUYbMRUXa4xX3mNvKguhaWG9GGbURn serait '00fd41f8dd065c16d8bfe0d6aa932b765f5b23f5c0' (21 octets)

Résultat vu: Lors de la vérification d'une transaction existante, les octets ont une longueur de 22 avec un préfixe '00' '0000fd41f8dd065c16d8bfe0d6aa932b765f5b23f5c0' (https://better-call.dev/carthagenet/opg/oosHQxzosTdzizkPDvaDYDjjHeRCu4uG3MnfeH6SeceDoZJLNby/contents => rawJSON)

À quoi sert l'octet supplémentaire? Dois-je m'attendre à ce qu'il soit toujours «00»?

Answer 1

Dans la norme FA2.0, l'expéditeur et le destinataire sont envoyés sous forme d'octets (par rapport à l'envoi sous forme de chaîne pour FA1.2).

Les deux normes de jeton indiquent que l'expéditeur et le destinataire sont des adresses de Michelson. Les adresses de Michelson ont deux représentations autorisées, sous forme de chaînes (représentation lisible) et d'octets (représentation optimisée).

À quoi sert l'octet supplémentaire?

L'octet supplémentaire est utilisé pour distinguer les comptes implicites des contrats intelligents.

Dois-je m'attendre à ce qu'il soit toujours «00»?

Non, ce n'est que «00» pour les comptes implicites.

Pour une description détaillée du schéma de codage binaire des adresses Tezos, vous pouvez utiliser la commande suivante:

$ tezos-codec describe alpha.contract binary schema