funded

Marlowe Runtime SDKs

₳141,117.00 Received
₳154,286.00 Requested
Ideascale logo View on ideascale
Community Review Results (1 reviewers)
Feasibility
Value for money
Impact / Alignment
Solution

Create idiomatic SDKs in Rust, Python, Go and Javascript to easily interact with Marlowe Runtime. This will facilitate adoption of the framework by developers in the ecosystem.

Problem:

Marlowe is a brand new framework for building and running financial contracts. Marlowe Runtime is the backend for interacting with the blockchain. We need SDKs to easily interact with the backend.

Yes Votes:
₳ 346,771,258
No Votes:
₳ 125,925,245
Votes Cast:
475

This proposal was approved and funded by the Cardano Community via Project F10: Developer Ecosystem - The Evolution Catalyst funding round.

[IMPACT] Please describe your proposed solution.

Context

  • Marlowe is a brand new language and runtime for developing financial smart contracts.
  • Marlowe contracts are built by combining a small number of building blocks that describe making a payment, waiting for a certain condition and other similar types of concepts.
  • The Marlowe Runtime is the backend component of the Marlowe framework that handles interaction with the blockchain. It exposes a REST API that provides operations such as: get-contracts, create-contracts, etc.
  • To interact with the backend, developers need to manually craft the REST API Requests, which involves a lot of boilerplate code with little specific value to their particular use-case.

Technical Plan

We’ll build a set of idiomatic SDKs (software development kits) in common programming languages with the goal of reducing the boilerplate required to interact with the Marlowe Runtime API.

The selected languages are:

  • Rust
  • Go
  • Python
  • Javascript (Typescript)
  • .NET (written in C#)

The rationale for selecting the above languages is the following: they are the subset of popular languages in the Cardano ecosystem that overlap with the technical expertise of our team. Meaning, these are the languages we know how to implement and that we believe will provide value in the ecosystem.

Each SDK will present the following features:

  • All data structures defined by they core Marlowe spec will have their types represented as part of the SDK. We'll explore how to abstract this types into it's module for potential reutilization in other contexts.
  • For the Marlowe Runtime operations, each API methods will be represented as callable functions, making use of whatever asynchronous IO mechanic is provided by the language. This is will also be abstracted into its own module to decouple it from the core types (previous bullet)
  • Naming of structures and functions will respect the naming conventions of the corresponding language (eg: use camelCase for Javascript and snake_case for Python).
  • Client-side validations will be executed by the SDK to avoid errors due to invalid requests.
  • Appropriate logging will be added in relevant functions to facilitate debugging.
  • Code-generation from the OpenAPI spec will be leveraged whenever possible to streamline SDK updates on future changes of the API.
  • DocStrings will be available whenever possible to improve integration with IDEs and documentation sites.
  • Public packages will be published to the corresponding package manager of the language, if any (eg: NPM package, Crates.io package, PyPi package).

There's an existing effort for a Typescript SDK being done by IOHK. Our plan is to reach to the specific devs behind the project and seek a plan for integrating both projects into a unified effort that covers all of the languages mentioned.

[IMPACT] How does your proposed solution address the challenge and what benefits will this bring to the Cardano ecosystem?

Our proposal accelerates the development of dApps that integrate with the Marlowe framework by removing much of the boilerplate required to interact with the backend API.

[IMPACT] How do you intend to measure the success of your project?

We’ll measure the success of the project by level of engagement and usage of our new integration mechanism:

  • Common activity metrics in the open-source Github repository, such as: number of issues, contributors, traffic, etc;

  • Package manager activity metrics, such as downloads per unit of time.

  • Level of engagement from developers through TxPipe existing communication channels, such as: our Discord server, our Twitter announcements and tech support ticketing system.

    [IMPACT] Please describe your plans to share the outputs and results of your project?

Being an open-source project, the outputs will be available to any developer in the ecosystem at every step of the development process:

  • Latest version of the source-code will be available in the Github repository.
  • Source code changes will be applied through a pull-request process.
  • Alpha and Beta versions will be released at every milestone.

Upon reaching the end of the development process, we’ll provide:

  • Links to the latest published versions of the SDKs in their corresponding package managers.
  • A documentation website with instructions for usage and deployment
  • A collection of examples showcasing the usage of the SDKs
  • A tutorial video showing a walkthrough of how to use some of the SDKs

After a reasonable (1-3 months) period after the end of development, we’ll provide:

  • A report describing package manager activity

  • A report describing dev community engagement with the project

    [CAPABILITY/ FEASIBILITY] What is your capability to deliver your project with high levels of trust and accountability?

TxPipe is very proud of their past and current contributions to the ecosystem. Just to mention a few:

  • We have developed “Pallas”, a Rust library for Cardano which is used by several high-profile project in the community (such as: cncli and Aiken)
  • Through Catalyst, we have developed and delivered “Oura”, an off-chain data integration tool for Cardano used by many projects in the community (such as: Pool.io and dcSpark’s Carp, etc).
  • Through Catalyst, we have developed “Dolos”, a minimalistic version of the Cardano node which is being slowly rolled out to the community as a beta version.
  • We have developed “Demeter”, a cloud hosting platform for Cardano infrastructure with several high-profile clients (such as: JPG.store, SummonPlatform and others).

The above are examples of our accountability because:

  • It shows our commitment to evolving the open source community and the Cardano ecosystem.

  • It shows the technical expertise required to develop and maintain Cardano infrastructure.

  • It shows our commitment to the Catalyst program and its required procedures.

    [CAPABILITY/ FEASIBILITY] What are the main goals for the project and how will you validate if your approach is feasible?

By providing SDKs in popular programming languages, we intend to improve the developer experience in the following areas:

  • Faster prototyping during early-development phase

  • Faster time-to-market when building dApps

  • Less code means lower probability of bugs and issues

  • Less code to maintain an update over time

    [CAPABILITY/ FEASIBILITY] Please provide a detailed breakdown of your project’s milestones and each of the main tasks or activities to reach the milestone plus the expected timeline for the delivery.

Milestone #1: Code generation (1 month)

  • Create project scaffold for all SDKs
  • Configure code generation tooling from OpenAPI specs
  • Setup CI pipeline for automated code generation

Milestone #2: Idiomatic wrappers (2 month)

  • Create idiomatic wrappers on top of auto-generated code
  • Add required docstrings
  • Add integration tests

Milestone #3: Packaging and release (1 month)

  • Setup required accounts in package managers
  • Publish initial versions of each package

Milestone #4: Final report (3 months)

  • Gather package manager metrics

  • Gather Github repository metrics

  • Prepare and share final report

    [CAPABILITY/ FEASIBILITY] Please describe the deliverables, outputs and intended outcomes of each milestone.

Milestone #1: Code generation (1 month)

  • Output: a publicly available source-code repository
  • Outcome: a CI pipeline capable of generating required code from OpenAPI specs

Milestone #2: Idiomatic wrappers (2 month)

  • Output: a publicly available source-code repository
  • Outcome: idiomatic client libraries for each of the involved languages

Milestone #3: Packaging and release (1 month)

  • Output: publicly available packages in the corresponding package managers
  • Outcome: SDKs for each involved language with all required features

Milestone #4: Final report (3 months)

  • Output: a publicly available report

  • Outcome: larger community is aware of project results

    [RESOURCES & VALUE FOR MONEY] Please provide a detailed budget breakdown of the proposed work and resources.

FTE = full-time equivalent

Values expressed in ADA (₳)

Breakdown by resource type:

  • Backend developer: 1 FTE x 4 months = ₳ 128,571
  • Technical writer: 1 FTE x 1 months = ₳ 15,000
  • Project manager: 1/4 FTE x 6 months = ₳ 10,714

Breakdown by milestone

  • Milestone #1: ₳ 34,286

  • Milestone #2: ₳ 68,571

  • Milestone #3: ₳ 34,286

  • Milestone #4: ₳ 17,143

    [RESOURCES & VALUE FOR MONEY] Who is in the project team and what are their roles?

This project will be coordinated by the TxPipe team. In particular, the following people will be involved in the development:

As explained in the solution section, a new hire will take care of the role of Rust developer for the actual contributions.

[RESOURCES & VALUE FOR MONEY] How does the cost of the project represent value for money for the Cardano ecosystem?

The resources associated with the development process will result in open-source code that can be leveraged by any team or member of the Cardano ecosystem.

Simplifying the development and integration of Marlowe contracts will promote adoption by developers and, in consequence, promote chain activity.

Community Reviews (1)

Comments

Monthly Reports

close

Playlist

  • EP2: epoch_length

    Authored by: Darlington Kofa

    3m 24s
    Darlington Kofa
  • EP1: 'd' parameter

    Authored by: Darlington Kofa

    4m 3s
    Darlington Kofa
  • EP3: key_deposit

    Authored by: Darlington Kofa

    3m 48s
    Darlington Kofa
  • EP4: epoch_no

    Authored by: Darlington Kofa

    2m 16s
    Darlington Kofa
  • EP5: max_block_size

    Authored by: Darlington Kofa

    3m 14s
    Darlington Kofa
  • EP6: pool_deposit

    Authored by: Darlington Kofa

    3m 19s
    Darlington Kofa
  • EP7: max_tx_size

    Authored by: Darlington Kofa

    4m 59s
    Darlington Kofa
0:00
/
~0:00