[FR] - Extra `ScriptData` for reference inputs with hashed datums

[mmontin]

Internal/External
External

Area
Plutus

Describe the feature you'd like

In july 2024 I posted an issue to report that cardano-api was not providing a way to add extra script data to a transaction body that does not correspond to an output being paid with a datum hash.

Later on, this feature was implemented in this PR.

However, it was very quickly removed in this commit.

Recently, I dove deeper into the ledger rules and realized that my original feature request was only half relevant. It turns out that the ledger rules forbid to add a resolved datum for a PK input with a datum hash, which I was not aware off (and which I don't know the reason for). I am assuming this is the reason why this new feature was quickly removed after being introduced following my issue.

However, I say half relevant, because the ledger does allow to provide extra resolved datums for reference inputs with hashed datums, which, following the removal of this feature, is still not possible to achieve from within cardano-api, as far as I can see. Feel free to let me know if either this feature is already present elsewhere, or if it is a deliberate choice not to provide it.

I wish this feature would be brought back, even if solely dedicated to reference inputs. Whenever a reference input would be defined in a transaction body, users could be given the opportunity to bind a ScriptData to that reference input, similarly to how they can be attached to outputs. It does not necessarily need to be a full new field within a body, which, I agree, was a reasonable solution if those extra datums could come from different places.

Describe alternatives you've considered

I am currently relying on the hack I described in my original issue, where i have to manually deconstruct the generated ShelleyTxBody, add the script data and re-bundle it after recomputing the script integrity hash. In case anybody is interested, this hack is performed here.

[Jimbo4350]

It turns out that the ledger rules forbid to add a resolved datum for a PK input with a datum hash, which I was not aware off (and which I don't know the reason for). I am assuming this is the reason why this new feature was quickly removed after being introduced following my issue.

Yes you are correct. I should have explained in the PR description.

However, I say half relevant, because the ledger does allow to provide extra resolved datums for reference inputs with hashed datums, which, following the removal of this feature, is still not possible to achieve from within cardano-api, as far as I can see.

I'm not opposed to this but we would need to investigate.

[mmontin]

I understand that you'd want to investigate, considering that my original assumption about hashed datums from PK inputs was incorrect (if you happen to know why the ledger prevents that, please let me know, this actually baffles me).

About reference inputs however, I conducted my own investigation and hopefully this will convince you:

1. We once had a client that explicitly required a specific reference input to exist, have a datum hash, and for which the validator was expecting the full datum in the supplemental datums.
2. My hack in cooked-validators did work for this project and for further testing, thus the ledger seems to indeed accept such transactions. Here is our test that explicitly makes use of the pre-image datum of a hashed datum in a ref input in case you want to check it out.
3. I found a post on github somewhere, when I realized that it was forbidden to add datums corresponding to PK inputs, that says that only datums corresponding to outputs and reference inputs were allowed. However, I was unsuccessful in finding this resources again tonight.
4. I did find an explicit mention in CIP-31 that, in addition to outputs, reference inputs were now allowed to be provided with a pre-image datum in the transaction body. This mention can be found in section called Extra datums on this page and I will also attach a screenshot of this short paragraph.

The solution here might simply be to allow to optionally add such datums whenever attaching a reference input, and collecting them similarly to those of outputs. On the other hand, reviving your original feature to have a dedicated field in the TxBody might be more resilient to possible updates in the future. Who knows, we might be allowed to add more datums in later updates. Let me know what your thoughts are. I'm still open to making this contribution if need be, although my last attempt was unsuccessful at the time and it might be much quicker to implement for somebody who is more familiar with this codebase !

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 120 days.