Cardano-db-sync: Update identifiers specified in CIP5 with prefixed bech32 encoding

db-sync uses the address rendering from cardano-api which is in the cardano-node repository. Transferring this ticket to that repo.

@erikd Are these not already implemented in the API library?

• pool
• pool_vk
• vrf_vk

@rhyslbw: Yes, the API already has support for the Bech32 prefixes specified in CIP5 (including the ones you've listed).

We recently audited the cardano-api for compliance with CIP5.

Thanks @intricate and @dcoutts. Please transfer this issue back to cardano-db-sync as I don't have maintainer capabilities to do it myself

~Assuming cardano-api is doing the right thing, this should just work now (5.0.0 tag).~

@erikd

SELECT * from pool_hash LIMIT 5

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

Oh, this is not just about addresses! Ok, yes, they might need to be stored both as hex and as Bech32.

As for the others, I have found block.vrf_key and pool_update.vrf_key . Is that the ones?

I have found block.vrf_key and pool_update.vrf_key . Is that the ones?

Yes, these are the prefixes and their allocations as per the CIP

• pool_vk Pool operator verification key
• vrf_vk VRF verification key

I am not currently aware of any queries that use the raw ByteString version of these fields, so I could just switch then to using the Bech32 encoding rather than duplicating them. Does that make sense?

Ok, block.vrk_key has a Bech32 prefix and hence an encoding.

pool_update.vrf_key does not have a Bech32 prefix.