Add support for CIP-57: Plutus Contract Blueprint #1927
Description
Introduction
Hey there! My name is Kylix and I'm a software engineer at Liqwid Labs, the team behind Liqwid Finance and Agora.
Summary
This issue intends to start discussion on supporting a CIP-57 ledger data enrichment layer directly in Cardano DB Sync.
Feature examples
Some examples of useful features that could be built into Cardano DB Sync using CIP-57 I can think of include:
- Decoding output datum directly in DB Sync, moving a considerable amount of the computational work, that is currently being ran on middleware services and applications, to the SQL server while also settling on a single source-of-truth for this "enriched"/higher-level data.
- Adding metadata fields to Plutus script describing tables, like for example name and description, allowing users of Cardano DB Sync to join on relations based on this metadata instead of forcing those users to join on those same relations based on script hashes and PostgreSQL auto-generated IDs.
There's a very good chance I haven't covered all use-cases of this integration in the items described above. I tried to stick the scope of the examples to some of our known use cases.
Suggested implementation
Allow passing a flag or environment variable to DB Sync with the file-path of one or more plutus.json files containing the data required for encrichment. Add (retro-compatible) nullable metadata fields to the already existing tables.
Context
At Liqwid Labs, we aim to expose a considerable amount of metrics and analytics about Liqwid Finance and its' deployment of Agora that require computation based on historical ledger data (namely based on output datum fields). Since our first iteration (Liqwid V1: https://v1.liqwid.finance/) we've struggled with building systems that reliably provide this data without requiring a large amount of service deployments and maintenance. With this issue we aim to solve this problem by moving the workload to a service we already work with on a day-to-day (Cardano DB Sync being the service) while also making the solution generic enough as to where it can benefit others (namely dApps and DeFi protocols building on top of Cardano DB Sync in the Cardano ecosystem).
Conclusion
First off all, I want to thank you, the reader, for reading this issue. I'm eager to hear back from developers maintaining and introducing features/improvements to Cardano DB Sync and from community members / entities who could be impacted by the implementation of a solution to the problem stated above.