FA2 от / до сериализации
В стандарте FA2.0 отправитель и получатель отправляются как байты (вместо отправки как строка для FA1.2).
Ожидаемый результат: при декодировании адресов (строки) в их хеш-представление открытого ключа я предполагаю, что соблюдается формат P2P: https://tezos.gitlab.io/api/p2p.html#public-key-hash-21-bytes-8-bit-tag. Например, tz1ij8gUYbMRUXa4xX3mNvKguhaWG9GGbURn будет '00fd41f8dd065c16d8bfe0d6aa932b765f5b23f5c0' (21 байт).
Видимый результат: при проверке существующей транзакции байты имеют длину 22 с префиксом '00' 0000fd41f8dd065c16d8bfe0d6aa932b765f5b23f5c0 '(https://better-call.dev/carthagenet/opg/oosHQxzosTdzizkPDvaDYDjjHeRCu4uG3MnfeH6SeceDoZJLNby/contents => rawJSON)
Для чего используется дополнительный байт? Должен ли я ожидать, что он всегда будет «00»?
Ответы
В стандарте FA2.0 отправитель и получатель отправляются как байты (вместо отправки как строка для FA1.2).
Оба стандарта токенов говорят, что отправитель и получатель являются адресами Майкельсона. Адреса Майкельсона имеют два допустимых представления: строки (читаемое представление) и байты (оптимизированное представление).
Для чего используется дополнительный байт?
Дополнительный байт используется для отличия неявных учетных записей от смарт-контрактов.
Стоит ли ожидать, что всегда будет 00?
Нет, это только «00» для неявных учетных записей.
Для подробного описания схемы двоичного кодирования адресов Tezos вы можете использовать следующую команду:
$ tezos-codec describe alpha.contract binary schema