Mismatch in SafeHash Computation for Transactions with Empty Redeemers in Conway Env (PPViewHashesDontMatch)

[chris-r-99]

I am currently building transactions on the PreProd testnet using the new cost model and the latest version of the serialization library. The transactions involve attaching a datum to the witness set, even though no script is spent. This is necessary as many major DApps require the datum to be included for reference when the datum hash is used in the transaction. This approach allows tools like Blockfrost to look up the datum for DApp batchers.

To achieve this, I utilize the following functionalities:

• add_extra_witness_datum(): Adds the datum to the witness set.
• calc_script_data_hash(costmdls): Computes the safe hash, where costmdls is the respective cost model.

This method worked well before the Conway era. However, when trying this on the PreProd testnet, I encounter the following error upon submitting the transaction:

{
    "code": 2,
    "info": "Wallet could not send the tx.",
    "message": "{\"contents\":{\"contents\":{\"contents\":{\"era\":\"ShelleyBasedEraConway\",\"error\":[\"ConwayUtxowFailure (PPViewHashesDontMatch (SJust (SafeHash \\\"169b169c7b6e0d3a2623f15c77caaa92ed4e67965384e157e6a996bced7428d2\\\")) (SJust (SafeHash \\\"4ab25d04ac3f84498e5bbf174f7c4935293a5e6457fbfb1610ccccc491845b8d\\\")))\"],\"kind\":\"ShelleyTxValidationError\"},\"tag\":\"TxValidationErrorInCardanoMode\"},\"tag\":\"TxCmdTxSubmitValidationError\"},\"tag\":\"TxSubmitFail\"}"
}

Context:

• Pre-Conway Era: The workflow described above (adding extra witness data, calculating the script data hash) worked as expected, with no issues when interacting with transactions containing empty redeemers.
• Post-Conway on PreProd Testnet: The error occurs when trying to submit transactions where redeemers are empty. Specifically, the error message points to a mismatch in the SafeHash (PPViewHashesDontMatch).

Observations:

• Transactions involving redeemers and script interactions (non-empty redeemers) work correctly, indicating that I am not using the wrong cost model.
• The issue seems isolated to transactions where redeemers are empty, suggesting a possible change in how the safe hash is computed in this edge case in the Conway era.

Request for Help:

Has anyone encountered a similar issue, or is there any insight into why this mismatch in SafeHash might be occurring when not spending any scripts (empty redeemers) in the Conway era? Are there any known workarounds for this issue?

Any assistance or suggestions would be greatly appreciated.

Let me know if you’d like any further adjustments or additions!

[lisicky]

Thanks @chris-r-99! Seems it's related to this IntersectMBO/cardano-ledger#4554
I have released 12.0.2-beta.1, it should help till we make official 12.0.2, since today is weekend : )

[chris-r-99]

Thank you for the support! Can confirm this fixes the issue