FA2 de / a serialización
En el estándar FA2.0, el remitente y el receptor se envían como bytes (en lugar de enviar como cadena para FA1.2).
Resultado esperado: al decodificar las direcciones (cadena) a su representación hash de clave pública, asumiría que se sigue el formato P2P: https://tezos.gitlab.io/api/p2p.html#public-key-hash-21-bytes-8-bit-tag. Por ejemplo, tz1ij8gUYbMRUXa4xX3mNvKguhaWG9GGbURn sería '00fd41f8dd065c16d8bfe0d6aa932b765f5b23f5c0' (21 bytes)
Resultado visto: Al verificar una transacción existente, los bytes tienen una longitud de 22 con un prefijo '00' '0000fd41f8dd065c16d8bfe0d6aa932b765f5b23f5c0' (https://better-call.dev/carthagenet/opg/oosHQxzosTdzizkPDvaDYDjjHeRCu4uG3MnfeH6SeceDoZJLNby/contents => rawJSON)
¿Para qué se utiliza el byte extra? ¿Debería esperar que siempre sea '00'?
Respuestas
En el estándar FA2.0, el remitente y el receptor se envían como bytes (en lugar de enviar como cadena para FA1.2).
Ambos estándares de token dicen que el remitente y el receptor son direcciones de Michelson. Las direcciones de Michelson tienen dos representaciones permitidas, como cadenas (representación legible) y como bytes (representación optimizada).
¿Para qué se utiliza el byte extra?
El byte adicional se usa para distinguir las cuentas implícitas de los contratos inteligentes.
¿Debería esperar que siempre sea '00'?
No, es solo '00' para cuentas implícitas.
Para obtener una descripción detallada del esquema de codificación binaria de las direcciones de Tezos, puede usar el siguiente comando:
$ tezos-codec describe alpha.contract binary schema