Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Blueprint support (CIP-57) with auto-generation of Elm code #59

Open
mpizenberg opened this issue Sep 29, 2024 · 0 comments
Open

Blueprint support (CIP-57) with auto-generation of Elm code #59

mpizenberg opened this issue Sep 29, 2024 · 0 comments
Labels
good first issue Good for newcomers help wanted Extra attention is needed

Comments

@mpizenberg
Copy link
Owner

At compilation, most onchain languages like Aiken generate a plutus.json file, containing a specification of the Plutus contract interface. This file called a blueprint, is specified by CIP-57, and contains information such as:

  • the list of existing validators
  • the compiled code and hash of each validator
  • the names and types of the redeemer and the datum for each contract

It looks like this:

{
  ...
  "validators": [{
      "title": "hello_world.hello_world.spend",
      "datum": {
        "title": "datum",
        "schema": { "$ref": "#/definitions/hello_world~1Datum" }
      },
      "redeemer": {
        "title": "redeemer",
        "schema": { "$ref": "#/definitions/hello_world~1Redeemer" }
      },
      "compiledCode": "590103...",
      "hash": "fdd6640d1c9a4392dd7e829f0cc4e26766539c48b2cf594959e33559"
  }],
  "definitions": {
    ...
    "ByteArray": { "dataType": "bytes" },
    "hello_world/Redeemer": {
      "title": "Redeemer",
      "anyOf": [{
          "title": "Redeemer",
          "dataType": "constructor",
          "index": 0,
          "fields": [{
              "title": "msg",
              "$ref": "#/definitions/ByteArray"
          }]
      }]
}}}

Looking at that blueprint enables anyone to interact with these contracts relatively easily. But what would make it extra nice, would be a way to auto-generate an Elm module defining types and encoding/decoding for all of this.

One issue commonly faced when crafting the redeemer and the datum in the offchain code is to not encode them to the correct Data shape. Such a failure will crash the contract execution immediatly. If instead, the encoders/decoders and typed representations of these are auto-generated in an Elm module, any mistake on the user side will be catched directly at compile time, making it much more dev-friendly.

There is a great tool to auto-generate Elm code, called Elm CodeGen, initiated by Matthew Griffith. I’d highly suggest anyone taking this one, to use elm-codegen for that task.

@mpizenberg mpizenberg added help wanted Extra attention is needed good first issue Good for newcomers labels Sep 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Good for newcomers help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

1 participant