Cardano-db-sync: Aktualisieren Sie die in CIP5 angegebenen Bezeichner mit vorangestellter bech32-Codierung

db-sync verwendet das Adress-Rendering von cardano-api das sich im cardano-node Repository befindet. Übertragen dieses Tickets in dieses Repo.

@erikd Sind diese nicht bereits in der API-Bibliothek implementiert?

• Schwimmbad
• pool_vk
• vrf_vk

@rhyslbw : Ja, die API unterstützt bereits die in CIP5 angegebenen Bech32-Präfixe (einschließlich der von Ihnen aufgeführten).

Wir haben kürzlich das cardano-api auf die Einhaltung von CIP5 geprüft.

Danke @intricate und @dcoutts. Bitte übertragen Sie dieses Problem zurück an cardano-db-sync da ich keine Betreuerfähigkeiten habe, um es selbst zu tun

~Angenommen, cardano-api tut das Richtige, sollte das jetzt einfach funktionieren ( 5.0.0 Tag).~

@erikd

SELECT * from pool_hash LIMIT 5

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

Oh, hier geht es nicht nur um Adressen! Ok, ja, sie müssen möglicherweise sowohl als Hex als auch als Bech32 gespeichert werden.

Bei den anderen habe ich block.vrf_key und pool_update.vrf_key . Sind das die?

Ich habe block.vrf_key und pool_update.vrf_key gefunden. Sind das die?

Ja, das sind die Präfixe und deren Zuweisungen gemäß CIP

• pool_vk Bestätigungsschlüssel für den Poolbetreiber
• vrf_vk VRF-Bestätigungsschlüssel

Mir sind derzeit keine Abfragen bekannt, die die rohe ByteString-Version dieser Felder verwenden, daher könnte ich dann einfach zur Verwendung der Bech32-Codierung wechseln, anstatt sie zu duplizieren. Ist das sinnvoll?

Ok, block.vrk_key hat ein Bech32-Präfix und damit eine Kodierung.

pool_update.vrf_key hat kein Bech32-Präfix.