LambdaBuffers for Rust

[bladyjoker]

LambdaBuffers got funded by the Catalyst Fund10 round (as announced in #101) and our proposal lists Rust support as one of its first milestones.

Achieving this will enable us to seamlessly share types and their values between Rust and other supported languages. Whether it's to store and exchange JSON based configuration or Cardano dApp 'datums', the effort to do so will be effectively reduced to your devops automation and configuration (we provide Nix API to do exactly that). We don't want to spend time manually implementing various encodings in the 21st century, and we want to save you the trouble of doing that as well.

I want to briefly touch on the plans and known challenges that we are tackling to get Rust support.

Code generation

Two basic challenges we tackle here are:

1. Mapping LambdaBuffers type definitions into Rust equivalent
   • Rust supports sum, product and record types, so this should be pretty straightforward. If there's any 'translation principle' that is less than obvious, we'll make sure to highlight it in our documentation.
2. Mapping LambdaBuffers derived implementations into Rust equivalent
   • LambdaBuffers Codegen module uses a thing called LamVal which is used to encode functions in an 'abstract' manner. This enables us to have a single specification for how implementations are derived (ie. how json (de)serialization works for a given LB type), and then have a separate LamVal to target language translation step for each of the supported languages.
3. Implement the testsuite that guarantees derived implementation mappings are correct
   • LB's golden files are the basic assurance we provide as to the correctness of the derived implementations mapping.

LambdaBuffers Prelude for Rust

The LambdaBuffers Prelude package defines some basic types that could considered to be a common denominator between different programming languages. It also specifies a Json type class, which is a principal encoding method that each of opaque types listed in this module support.

So, in order to have Rust support LB's Prelude, we need to:

1. Decide on the existing types to map into
   • Rust is pretty similar to Haskell and Purescript, so types like Maybe and Either, are ubiquitous and part of the standard library (Option and Result),
2. Implement the runtime library that implements the promised json encodings (aka. lbr-prelude)
   • This library is then distributed to LambdaBuffer users as it's a necessary dependency to work with LB Prelude.
3. Implement the testsuite (aka. lbt-prelude)
   • The most basic assurances we provide is that all the runtime libraries handle golden files correctly.

@szg251 is already tackling this #103.

LambdaBuffers Plutus for Rust

Supporting LambdaBuffers Plutus package is integral to this project, as the gracious Catalyst funding we received is contingent to facilitating Cardano dApp development.

The development process here is basically the same as for the LB Prelude package, we'll just need to do a preliminary investigation to understand which library is best to use when mapping opaque types that denote the foundational plutus-ledger-api types, the choice is roughly between:

1. https://github.com/dcSpark/cardano-multiplatform-lib
2. https://github.com/Emurgo/cardano-serialization-lib
3. https://github.com/aiken-lang/aiken
   • uplc crate

The central LB type class in the Plutus package is PlutusData which denotes the, so called, 'Data' encoding which is the foundational value representation used in Cardano's Plutus application platform.
Unlike the lbr-prelude runtime library for the LB Prelude package, these encodings are already set in stone by Cardano specs and a reference implementations used is located in the Haskell library plutus-ledger-api. This means we don't have to provide PlutusData encoding implementations for all the 'opaque' types in the LB Plutus package, they're already available in the target language ecosystems and we can just (re)use that!

We do however need to provide the lbt-plutus testsuite to make sure our implementation derivation is sane!

[bladyjoker]

Please follow our project board for this milestone at https://github.com/orgs/mlabs-haskell/projects/35/views/4