Cardano-db-sync: Actualizar identificadores especificados en CIP5 con codificación bech32 prefijada

db-sync usa la representación de direcciones de cardano-api que está en el repositorio cardano-node . Transfiriendo este ticket a ese repositorio.

@erikd ¿No están ya implementados en la biblioteca de API?

• piscina
• pool_vk
• vrf_vk

@rhyslbw : Sí, la API ya es compatible con los prefijos Bech32 especificados en CIP5 (incluidos los que ha enumerado).

Recientemente auditamos el cardano-api para verificar el cumplimiento de CIP5.

Gracias @intricate y @dcoutts. Vuelva a transferir este problema a cardano-db-sync ya que no tengo las capacidades de mantenimiento para hacerlo yo mismo.

~ Suponiendo que cardano-api está haciendo lo correcto, esto debería funcionar ahora ( 5.0.0 etiqueta). ~

@erikd

SELECT * from pool_hash LIMIT 5

1   \x153806dbcd134ddee69a8c5204e38ac80448f62342f8c23cfe4b7edf
2   \x0f292fcaa02b8b2f9b3c8f9fd8e0bb21abedb692a6d5058df3ef2735
3   \xc1ede3cc9133209466774d4826044e408db13d6fe6df751a73500f16
4   \x01df29429173d263c7533a22742dae19f16a08798b7a57873c34cf58
5   \x6b6164af70861c5537cc9c8e50fdae35139ca2c8c6fbb42e8b7e6bfb

¡Oh, esto no se trata solo de direcciones! Ok, sí, es posible que deban almacenarse tanto como hexadecimal como Bech32.

En cuanto a los demás, he encontrado block.vrf_key y pool_update.vrf_key . ¿Son esos?

He encontrado block.vrf_key y pool_update.vrf_key. ¿Son esos?

Sí, estos son los prefijos y sus asignaciones según el CIP

• pool_vk Clave de verificación del operador de la piscina
• vrf_vk clave de verificación VRF

Actualmente no tengo conocimiento de ninguna consulta que use la versión ByteString sin procesar de estos campos, por lo que podría cambiar a usar la codificación Bech32 en lugar de duplicarlos. ¿Tiene sentido?

Ok, block.vrk_key tiene un prefijo Bech32 y, por lo tanto, una codificación.

pool_update.vrf_key no tiene prefijo Bech32.