search

Emurgo / cardano-serialization-lib

This is a library, written in Rust, for serialization & deserialization of data structures used in Cardano's Haskell implementation of Alonzo along with useful utility functions.
Other
230 stars 124 forks source link

Allow explicitly setting TransactionOutput serialization format #639

Closed refi93 closed 10 months ago

refi93 commented 10 months ago

We (NuFI wallet) are facing issues with Dapp(s) that use the Post-Alonzo era outputs in the transaction bodies sent to be signed via the CIP30 dapp connector because we are unable to properly serialize them with cardano-serialization-lib, because as mentioned in https://github.com/spacebudz/lucid/issues/180, this lib automatically serializes outputs without Datum to alonzo-era outputs, which saves bytes, but doesn't play well with out architecture that relies on trying to rebuild the transaction from the parsed entries to ensure our tx parsing didn't miss any field of the raw tx which could otherwise result in signing a different tx than shown to the user (user sees parsed tx and its effects in a user friendly way) which is a security measure. So currently, due to this limitation of CSL, we are unable to securely (without resorting to blind-signing the raw tx from the dapp) process external txs with Post-alonzo outputs without datums.

I see a similar issue being raised earlier where this choice of serialization format for tx output has been discussed but it was closed with no change to the current approach: https://github.com/Emurgo/cardano-serialization-lib/issues/609#issuecomment-1503769984 - given the use-case of reserialization of the tx to ensure integrity of data shown to the user vs the real tx body, would you be open to re-consider the option to be able to specify the serialization_format in the TransactionOutput class (https://github.com/Emurgo/cardano-serialization-lib/blob/23caa65c57ea5f88fe3e9c84303bee239d71d5e1/rust/src/lib.rs#L674)?

lisicky commented 10 months ago

Hi @refi93 ! Thanks for your issue : ) Unfortunately we don't have priority to add this feature, but CSL is open source project and you can contribute to it. Also I wanna warn you that "reconstructing" a tx by yourself it is a not the best idea because cbor is very wordy standard, I mean there are plenty ways how the same data can be serialized into cbor and all of them will be valid. Small example: array or map can have definite and indefinite length. If you wanna to show a tx before signing you can use FixedTransaction type, it preserves a transaction body unchangeable and you can easily add a new vkey witness to a tx without any concerns about changes in tx body original bytes.

refi93 commented 10 months ago

thanks for the quick reply - yeah, we ended up using FixedTransaction for signing and to ensure that the raw tx doesn't contain any field we didn't parse (and show to the user in a user-friendly way/mindfully omit) we try to at least serialize our parsed transaction data (custom structure different from CSL, containing additional details about derivation paths/serialization format) back with CSL and compare it with the re-serialized result of what CSL parsed from the raw transaction body. This seems to be a good enough solution for us for now, closing the issue