Remember this nonsense -- that we have to generate TxBodyContents with explicit data for fee calculation, but without explicit data for final validation? It seems the reason is our own legacy and stupidity: In both contexts, the actual transaction is not only generated from the TxBodyContent, but also the set of currently known UTxOs (obviously, in hindsight). If you trim the UTxO index at the stage of final transaction validation so that it only includes what is actually needed, things start to make much more sense, and you can always include all the data on the TxBodyContent.
I'll make this a draft pull request, so that this insight is documented and we can discuss it. I intend to incorporate it into the branch ch/inline-datums, where I work on adding inline datums to cooked. In particular, the implementation I chose in this PR should make it so that inline datums are never used.
Remember this nonsense -- that we have to generate
TxBodyContents with explicit data for fee calculation, but without explicit data for final validation? It seems the reason is our own legacy and stupidity: In both contexts, the actual transaction is not only generated from theTxBodyContent, but also the set of currently known UTxOs (obviously, in hindsight). If you trim the UTxO index at the stage of final transaction validation so that it only includes what is actually needed, things start to make much more sense, and you can always include all the data on theTxBodyContent.I'll make this a draft pull request, so that this insight is documented and we can discuss it. I intend to incorporate it into the branch ch/inline-datums, where I work on adding inline datums to cooked. In particular, the implementation I chose in this PR should make it so that inline datums are never used.