Parner-chains-smart-contracts rework discussion

[kayvank]

Table of Contents

1. Overview
2. Components
3. onchain
4. offchain
5. Smart Contract deployment
6. Source of difficulty
7. Why is it difficult
8. An obvious solution
9. The obvious problems
10. Proposal
11. Offchain, Alternative approach
12. Cons and Pros of offchain rework

Overview

overview-diagram.txt

Components

• onchain
  Haskell multi-project, where the smart-contracts are authored
• offchain
  Purescript project, the front-facing application

onchain

Very similar to any other Plutus onchain Haskell projects

• Validators and Minting scripts are authored in Plutus
• Contracts compiled and serialized to Purescript embedded CBOR payload
  • This scheme creates an unnecessary coupling of offchain application to Purescript

offchain

The forward facing component providing required functionalities:

• Utility functions
• Reporting capabilities
• Smart contract deployment

Smart Contract deployment

Architectural choices made in this section are the source of much of our difficulties

• enourmous amount of time required to adapt changes in:
  • cardano ledgers
  • plutus
• potential security vulnerability

Source of difficulty

Main source of difficulty is applying runtime parameters/inputs to contracts for:

• CTL uses cardano-serialization rust-library by:
  • compiling the library to WebAssembly
  • wrapping the result in an npm package
  • publishing the package in a public repository
• Next, CTL adds a number of other features according to their needs/business model
• Release the new CTL

Why is it difficult

Adding new such npm dependency are difficult for:

• introduce the npm package to our project with the following side-effect
  • npm -> package.json, need to do npm install
  • spago -> spago.spago.dhall, need to spago2nix generate
  • nix related modules, need to nix flake lock
  • new rust code needs new npm packages
    • npm package needs to be in concert with the rust code
  • none of these are under our control
  • there is no cohesive versioning scheme among these parts, we rely on mLab to communicate with us what version of nmp package correlates a given rust serialize that we think we need. Thus far, this process has been based on trial and error to find out what version of the serializer to use
    - we have no way of getting a head of the problem, we became aware of the issue, only when things break or don't work as a result of an upgrade, update on our components
• additionally, we have to chase mLab to release the new npm package

An obvious solution

We can wrap our own npm around the rust cardano-serialization-lib which begs the question:

• what is the value gained by relying on mLab's CTL?

The obvious problems

chase mLab:

• for new npm packages
• for new CTL that used the new npm package
• to make sure we only get from CTL what we need
• the vector of attack this npm package introduces

Proposal

Liberate us from CTL through:

• liberate the offchain code from the choice of development platform
  • use CIP-0057 for standard way of publishing contracts, OpenApi on onchain haskell project
  • simplify the offchain project build dependencies

Offchain, Alternative approach

Choice of development platform effects the speed of development drastically.

• Haskell
  • use cardano-api for all our deployment needs.
  • lots of synergy through out IOI
  • we’re solving a known problem that many other teams have already solved
• Rust
  • no need for the npm indirection
  • we have a healthy number of rust exports
  • many teams in cardano are embracing rust
• Typescript and lucid
  • I lack typescript expertise, but believe our recruiters will have less of a challenge finding typescript developers

Cons and Pros of offchain rework

• cons
  • major undertaking
  • will require a non trivial amount of time
  • need to develop new platform while maintaining the old one
• pros
  • maintaining current offchain implementation is unsustainable