FA2 da / a serializzazione

Aug 24 2020

Nello standard FA2.0 il mittente e il destinatario vengono inviati come byte (anziché inviare come stringa per FA1.2).

Risultato previsto: durante la decodifica degli indirizzi (stringa) nella loro rappresentazione hash della chiave pubblica, presumo che venga seguito il formato P2P: https://tezos.gitlab.io/api/p2p.html#public-key-hash-21-bytes-8-bit-tag. Ad esempio, tz1ij8gUYbMRUXa4xX3mNvKguhaWG9GGbURn sarebbe '00fd41f8dd065c16d8bfe0d6aa932b765f5b23f5c0' (21 byte)

Risultato visualizzato: quando si verifica una transazione esistente, i byte sono di lunghezza 22 con un prefisso '00' '0000fd41f8dd065c16d8bfe0d6aa932b765f5b23f5c0' (https://better-call.dev/carthagenet/opg/oosHQxzosTdzizkPDvaDYDjjHeRCu4uG3MnfeH6SeceDoZJLNby/contents => rawJSON)

A cosa serve il byte extra? Dovrei aspettarmi che sia sempre "00"?

Risposte

5 RaphaëlCauderlier Aug 24 2020 at 19:30

Nello standard FA2.0 il mittente e il destinatario vengono inviati come byte (anziché inviare come stringa per FA1.2).

Entrambi gli standard di token dicono che mittente e destinatario sono indirizzi di Michelson. Gli indirizzi di Michelson hanno due rappresentazioni consentite, come stringhe (rappresentazione leggibile) e come byte (rappresentazione ottimizzata).

A cosa serve il byte extra?

Il byte aggiuntivo viene utilizzato per distinguere gli account impliciti dagli smart contract.

Dovrei aspettarmi che sia sempre "00"?

No, è solo "00" per gli account impliciti.

Per una descrizione dettagliata dello schema di codifica binaria degli indirizzi Tezos, è possibile utilizzare il seguente comando:

$ tezos-codec describe alpha.contract binary schema