Haskell Support in UTxO RPC

dmayhew Post 1: Development Model
January 10, 2024

Project Introduction

Problem

UTxO RPC lacks developer support for Haskell implementations which creates a barrier to its adoption by Cardano industry partners and products—specifically, the `cardano-node` product which is a primary target for UTxO RPC.

Background

Cardano is a UTxO-based blockchain technology. UTxO stands for “Unspent Transaction Output” and is a popular model for blockchain technologies. UTxO RPC is a language- and platform-independent gRPC specification for interacting with UTxO-based blockchains. It is open-source and still under development, primarily by TxPipe, the client of this project.

UTxO RPC aims to provide SDKs and generated code to support use and implementation of UTxO RPC in a variety of languages. Work is already underway in Rust, Go, Python and Node.js. However, many Cardano products are written in Haskell and lack of support for Haskell in UTxO RPC makes it challenging for those products to adopt the standard. The goal of this project is to alleviate this barrier by providing Haskell Cardano developers with the code and tools necessary to support UTxO RPC client and server implementations.

Solution

I will add Haskell support to UTxO RPC in the following ways:

  1. Add Haskell code generation to the existing code generation systems in use by UTxO RPC. The result will be Haskell code generated from the gRPC specification and contained in the same repository as the specification and generated code for other languages.
  2. Create a Haskell SDK that contains additional code required to support Haskell implementation of the specification. Namely, client code used to call gRPC methods on a server that implements UTxO RPC and example server code that serves mocked or stubbed data that can be adapted to create a real implementation.

“Would be nice” goal

If time allows, I will also complete the following:

  1. Create a proxy server that implements UTxO RPC by translating gRPC service methods into API calls to existing Cardano products that serve proprietary APIs. The proxy server will not implement any methods itself and is not intended to be a permanent solution but rather a bridge to enable development of client applications that use UTxO RPC before a proper server implementation has been created.

Stretch goal

  1. Begin development of an in-process server thread in an existing Haskell Cardano product (`marconi-sidechain`) that implements UTxO RPC. This will be the beginning of the more permanent solution mentioned above. Although completion of this implementation is beyond the scope of this project, demonstrating its feasibility will reduce the barriers to implementation by industry partners.

Software Development Model

I will follow an Agile/Incremental development model for this project.

The Process

  1. Agree to rough requirements. Requirements should be detailed enough to enable the client and myself to agree to work together.
  2. Requirements elaboration and elucidation for goals 1-3.
  3. For each deliverable (1-3):
    1. Analyze requirements.
    2. Design a solution.
    3. Implement the solution.
    4. Test the implementation.
    5. Review the deliverable with the client.
  4. Requirements elaboration and elucidation for goal 4.
  5. Repeat step 3 for goal 4.

Communication with the client will be ongoing throughout the project in the following ways:

  1. Weekly zoom meetings with a client representative.
  2. Discord messages with the client and/or the community for asynchronous communication.
  3. All work is open source, so work will go through an open pull-request process subject to public discussion.

Justification

This project involves four distinct deliverables, which lends itself well to an incremental model. Each deliverable can be treated as its own “increment”, following its own development lifecycle. Work on each deliverable should happen mostly in serial, but adoption of Agile methodologies will allow me to work on some of them in parallel if necessary.

A rough initial requirement gathering phase is required to ensure all parties have understood clearly what the project is that they are agreeing to. This project involves one primary client (TxPipe, the recipient of goals 1-3) and one secondary client (IOHG, recipient of goal 4 if it is accomplished). Therefore, it is important to ensure all parties are communicating clearly about the work to be completed. A more in-depth requirements elaboration and elucidation phase is required once work begins. Initially, only goals 1-3 will be elaborated, and if I am able to reach goal 4 I will undergo another elaboration phase with the secondary client.

This software development model is a mixture of an incremental model, due to working on each deliverable as an increment, and an agile model, due to constant involvement of the client, embracing change, and the delivery of working software frequently through splitting the work into increments.