Power multi-language micro-services architecture Cardano DApp - SIDAN Lab

Developers Cardano Integration
1

About half year in since the first article on medium about SIDAN Lab’s early story & our open source strategy, we have continued to maintain and upgrade the open source libraries in SIDAN Lab. Here we give a quick pulse check, how these libraries have powered DeltaDeFi to the public testnet we launched in previous weeks, and how everyone can get started to make use of these public good!

What’s now, what’s next

Funding Status Feature Coming Soon
whisky Completed - F11, F12; Proposing - F14 Unified types support; Transaction building; Wallet Pallas integration
vodka Proposing - F14 Onchain utility functions; Transaction building for unit testing Revamp, performance optimization, and auditing of onchain utility functions; Feature-complete transaction building for unit testing
cardano-bar Proposing - F14 Typescript (Mesh) blueprint parser; Aiken validator code snippet Rust (whisky) blueprint parser; Mesh code snippet; Whisky code snippet
rum N/A Unified types support Wallet Transaction building
gin N/A Unified types support Wallet Transaction building

How we use these tools to build DeltaDeFi

DeltaDeFi is a multi-language micro-services architecture Cardano DApp, we have 10+ services connected with 3 core big components handling Cardano-related logics:

  • Frontend in TypeScript - The frontend of testnet is built with NextJS in TypeScript. We use MeshJS to handle wallet connection and UTxOs fetching here.
  • Core API services in Golang - We have the core of our backend in Golang. In the Golang micro-services, we conduct heavy Cardano value operations and prepare the necessary Cardano types like UTxOs and Value passing to other services to further process.
  • Transaction building in Rust - The core transaction building is built with whisky. It receives information from Golang microservices and returns full transactions.
  • Merkle computation in TypeScript - In the current version, we do not reimplement the off-chain of Aiken’s merkle-patricia-forestry in Rust. So for transactions like deposit, withdrawal, Hydra open and close, which require computation of Merkle root, we handle in a TypeScript server built with Mesh

This is where the type alignments amongst libraries are powerful. We centralized the development work into checking field names exactly once in the library level, then we can be hassle-free by the time of develop DeltaDeFi - all the types can be casted into each others without further conversion.

Public-facing SDKs

In DeltaDeFi, we have built SDKs in 4 languages to support traders in programmatic trading. However, we faced one problem before we implemented transaction signing in rum and gin.

Due to the unstandardized CBOR serialization in Cardano (why we don’t have a CIP for it yet!), the transaction body changed after signing with serialization logics from py-cardano and apollo, due to for example turning empty array into null. Eventually, it breaks the state tracing in DeltaDeFi backend since we index transactions with hashes.

Rather than working on a CIP (we wish! but it might take months or years to process), we solve by relying on one serialization core (whisky), exporting into multiple languages for signing:

  • TypeScript: whisky → wasm → mesh
  • Golang: whisky → cardano-golang-signing-module → rum
  • Python: whisky → cardano-python-signing-module → gin

With that, we can support all clients signing transactions built by DeltaDeFi backend without augmenting the transaction body, empowering true programmatic trading.

Getting Started

Best way of getting started is to check the official documentation and examples

We will continue building in the community, give it a try and we’d love to have your feedback!

1 Like
2

@hinsonsidan I have some great news for you: if your innovative approach to DeFi and its reference implementations were laid out in documentation that could be easily understood & followed by both collaborators and competitors — with your motivation and design choices separated from the specification itself — your resulting CIP could take about a month to process.

CIPs for such interoperability have only been delayed when there’s been no apparent interest by other agencies in following the work of an individual or single agency. It doesn’t sound at all like this would be a problem for your very generally useful framework above.

If there are common & extensible standards for your SDKs or your computational back-end, it would serve the community well if they could be started as CIP drafts sooner rather than later. You’d be welcome to post any preliminary ideas about this in the CIP repository Discussions area (as well as continuing discussion here) to build up ideas & collaboration for such an eventual standard:

1 Like