Cardano-db-sync: Atualizar identificadores especificados em CIP5 com codificação bech32 prefixada

db-sync usa a renderização de endereço de cardano-api que está no repositório cardano-node . Transferindo este tíquete para esse repo.

@erikd Eles ainda não estão implementados na biblioteca de API?

• piscina
• pool_vk
• vrf_vk

@rhyslbw : Sim, a API já tem suporte para os prefixos Bech32 especificados em CIP5 (incluindo os que você listou).

Recentemente, auditamos cardano-api quanto à conformidade com CIP5.

Obrigado @intricate e @dcoutts. Por favor, transfira este problema de volta para cardano-db-sync porque eu não tenho recursos de mantenedor para fazer isso sozinho

~ Supondo que cardano-api esteja fazendo a coisa certa, isso deve funcionar agora (tag 5.0.0 ). ~

@erikd

SELECT * from pool_hash LIMIT 5

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

Oh, não se trata apenas de endereços! Ok, sim, eles podem precisar ser armazenados como hexadecimal e como Bech32.

Quanto aos outros, encontrei block.vrf_key e pool_update.vrf_key . São esses?

Encontrei block.vrf_key e pool_update.vrf_key. São esses?

Sim, estes são os prefixos e suas atribuições de acordo com o CIP

• pool_vk Chave de verificação do operador do pool
• vrf_vk chave de verificação VRF

No momento, não estou ciente de quaisquer consultas que usem a versão bruta ByteString desses campos, então eu poderia apenas alternar para o uso da codificação Bech32 em vez de duplicá-los. Isso faz sentido?

Ok, block.vrk_key tem um prefixo Bech32 e, portanto, uma codificação.

pool_update.vrf_key não tem um prefixo Bech32.