FA2 z / do serializacji

Question

W standardzie FA2.0 nadawca i odbiorca są wysyłani jako bajty (w przeciwieństwie do wysyłania jako łańcuch znaków dla FA1.2).

Oczekiwany wynik: Podczas dekodowania adresów (ciągów) do ich reprezentacji skrótu klucza publicznego zakładam, że przestrzegany jest format P2P: https://tezos.gitlab.io/api/p2p.html#public-key-hash-21-bytes-8-bit-tag. Np. Tz1ij8gUYbMRUXa4xX3mNvKguhaWG9GGbURn to '00fd41f8dd065c16d8bfe0d6aa932b765f5b23f5c0' (21 bajtów)

Widoczny wynik: Podczas sprawdzania istniejącej transakcji bajty mają długość 22 z prefiksem „00” „0000fd41f8dd065c16d8bfe0d6aa932b765f5b23f5c0” (https://better-call.dev/carthagenet/opg/oosHQxzosTdzizkPDvaDYDjjHeRCu4uG3MnfeH6SeceDoZJLNby/contents => rawJSON)

Do czego służy dodatkowy bajt? Czy powinienem oczekiwać, że zawsze będzie to „00”?

Answer 1

W standardzie FA2.0 nadawca i odbiorca są wysyłani jako bajty (w przeciwieństwie do wysyłania jako łańcuch znaków dla FA1.2).

Oba standardy tokenów mówią, że nadawca i odbiorca są adresami Michelson. Adresy Michelsona mają dwie dozwolone reprezentacje, jako łańcuchy (czytelna reprezentacja) i jako bajty (zoptymalizowana reprezentacja).

Do czego służy dodatkowy bajt?

Dodatkowy bajt służy do odróżnienia kont niejawnych od inteligentnych kontraktów.

Czy powinienem oczekiwać, że zawsze będzie to „00”?

Nie, tylko „00” dla kont ukrytych.

Aby uzyskać szczegółowy opis schematu kodowania binarnego adresów Tezos, możesz użyć następującego polecenia:

$ tezos-codec describe alpha.contract binary schema