Support L2 / Hydra / devnets

[matiwinnetou]

As part of our hydra-voting-poc workstream we realised we need evaluate endpoint returning ExUnits compatible with L2 / Hydra / devnets solutions.

Problem statement: Current evaluate endpoint assumes L1 parameters.

Request: Allow a user / developer to pass SlotConfig and Initial Budget via parameters to the existing evaluate endpoint.

SlotConfig {
    slot_length, // rust i32
    zero_slot, // rust i64
    zero_time // rust i64
}

InitialBudget {
   mem, // rust: i64
   cpu // rust: i64
}

These parameters can be provided via GET or POST request, the response should be compatible with existing evaluate endpoint.

Delivery of this will unblock number of L2 usecases, in cases where smart contracts need to be used.

@mmahut

I had a chat @satran004 and probably it would make more sense to have a completely new endpoint (network agnostic endpoint).

[mmahut]

As we're using Ogmios for evaluation at this moment, I'm not sure this is possible as Ogmios just uses the local mini-protocols to have the node evaluate this.

We could use Aiken for this, if it supports such feature. Tagging @KtorZ for more insight.

[matiwinnetou]

I was hoping you could use Haskell code via Ogmios directly. In terms of Aiken, our initial investigation shows that most likely pallas requires work to support changing parameters. Aiken transaction evaluation depends on pallas.

I will be doing today more tests in this area but initial investigation shows that at least changing minFeeA and minFeeB, pallas doesn't really know how to handle such transactions. In terms of keeping minFeeA and minFeeB untouched as in shelley-genesis and changing only params mentioned above could be a good idea as actually we only what ExUnits calc, the rest is handled by off-chain code. From what it seems in Aiken / pallas these things are coupled together.

[matiwinnetou]

Pallas / Aiken workstream will have to happen anyway but I was hoping when writing this request is that we / your team / somebody could bypass all Aiken / pallas and directly talk to the code to get those ExUnits from Haskell's code (somehow), e.g. Web Assembly or Ogmios.

[KtorZ]

This should be relatively easy to do, working from era summaries and a (partial) protocol parameters object. Era summaries are what can be obtained already from querying eraSummaries in Ogmios. For example on mainnet:

[
  ...
  {
    "start": {
      "time": 125280000,
      "slot": 39916800,
      "epoch": 290
    },
    "end": {
      "time": 157680000,
      "slot": 72316800,
      "epoch": 365
    },
    "parameters": {
      "epochLength": 432000,
      "slotLength": 1,
      "safeZone": 129600
    }
  },
  {
    "start": {
      "time": 157680000,
      "slot": 72316800,
      "epoch": 365
    },
    "end": {
      "time": 173664000,
      "slot": 88300800,
      "epoch": 402
    },
    "parameters": {
      "epochLength": 432000,
      "slotLength": 1,
      "safeZone": 129600
    }
  }
]

Given that L2 are most likely going to be single-eras only, it would only be about providing a single start and parameters (as end can be null).

Now a big question is whether I want to do that as a patch or, wait until V6 is finalized. I have quite many changes stashed for V6 already and it is becoming difficult/annoying to maintain two rather different versions. It is doable however. So I might give a big focus on V6 next week and see if I can wrap it up. If not, I'll get that implemented on top of v5.x.x

[matiwinnetou]

I would say this question is more to @mmahut since either they stay on V5 or they have to perform migration to V6. I don't know how costly this migration will be.

Generally for us this is not super burning, we are experiencing problems with Aiken-uplc doing similar things right now but we will want to fix those issues before.

In general both Aiken and blockfrost solution should be supported in the long term, there will always be some exotic language that will not have aiken binding and blockfrost can be used then.