[FR] - Provide comprehensive CDDL grammar for local tx-submission protocol

[ashisherc]

External

Area

Other Local tx submit mini protocol.

Describe the feature you'd like
We are using Local Tx submit mini protocol to submit transactions to the Cardano node, the mini protocol spec does not define the response CDDL as it is understood to be polymorphic. We want to parse the rejection message returned from the Cardano node, for which a CDDL spec would suffice.

[ashisherc]

@JaredCorduan

[JaredCorduan]

It might make sense to transfer this to https://github.com/input-output-hk/ouroboros-network. what do you think, @coot ?

[ashisherc]

here's one for the Ouroboros Network repo, IntersectMBO/ouroboros-network#4521

[coot]

The problem is that it's indeed polymorphic, and the concrete type is implemented by the consensus team if I am not mistaken. But they don't use CDDL. @dnadales should be able to point to the right place where it's defined. This is a chase since the rejection reason type itself is polymorphic over blk type (it's a type family: ApplyTxErr), and thus might depend on the era.

[ashisherc]

@JaredCorduan @coot in that case, should this issue be moved to the ledger repo? Also, is there a way I can see the specs somehow currently so that I can decode the rejection message (very imp for me at this time)? I also want to emphasise on the importance of documenting this because many teams are now building their own tools in different languages (which is what Cardano needs the most) and we need a way to know the specs.

PS, the Ouroboros network library I am building is in javascript which has gone through multiple iterations and I want to open source it soon.

[coot]

@JaredCorduan @coot in that case, should this issue be moved to the ledger repo?

Ledger has nothing to do with it, it's consensus (which now lives in ouroboros-network repo as well). I am aware this is important, let's give consensus a chance to answer.

PS, the Ouroboros network library I am building is in javascript which has gone through multiple iterations and I want to open source it soon.

Nice, I am happy to hear that.

I am not sure this is really consensus specific. Seems to me that what this issue is about is somewhat broader in scope than a mere documentation if we want to do it properly, but it would rather be specifying and exposing the mini-protocols as the node's interface in a more formal way. This would imply:

1. Write, publish, and version the CDDLs somewhere, eg. as a package that implementors could use tool with
2. Write the proper tests to ensure our implementation is compliant with its specification and backward compatible (golden tests, roundtrip properties, version migration tests...)
3. (optional) Publish test vectors or generators that implementors could use to check their implementation against real data

It would be great if we could consolidate the CDDLs we have in, say, a cardano-cddl-api package

[ashisherc]

@abailly-iohk thanks for the response. I am not sure about another Haskell package for this purpose. (Maybe I misunderstood your message) The sole purpose of my request is so that devs can build tools easily in different languages which just requires us to know the CDDLs.

Just like we have CDDLs documented for Cardano-ledger and ouroboros-network, we would like to have access to all sorts of CDDLs eg. We also do not have CDDLs for local state query protocol.

I can understand this might be a bigger fish to fry, so at this time I am very much looking for CDDLs for the tx submit rejection message

@ashisherc I meant package in the broader sense and I fully sympathise with the goal you describe. In my mind, package was intended to mean "something that's published in a well-known location that people can download and use within their environment". It could be as simple as a tarball or just a schema document. the important point is that this "package" would be versioned and could be used within some toolchain to produce, eg. language-dependent artifacts able to serialise/deserialise packets

The CDDL for the rejection messages simply do not exist at this stage so we would need to write them and put them somewhere for you to retrieve. It's therefore does not seem illogical for me to walk the extra mile and integrate the various CDDLs we have into something more comprehensive. If we were in 2003 we would probably write a XML schema :)

[ashisherc]

Perfect!

FWIW the reject reason is an ApplyTxError whose encoding is defined here: https://github.com/input-output-hk/cardano-ledger/blob/master/eras/shelley/impl/src/Cardano/Ledger/Shelley/API/Mempool.hs#L214
Seems to me it would make to include a CDDL file describing those in the ledger itself, alongside the transaction.cddl which are defined per era.