Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Datum and redeemer insertion order #130

Merged
merged 3 commits into from
Sep 27, 2022

Conversation

MicroProofs
Copy link
Contributor

Ensure datum and redeemer order is maintained when building a transaction.

@SebastienGllmt
Copy link
Contributor

FYI this is #86 . I'm not sure about using LinkedHashMap vs a Vec since LinkedHashMap has led to some issues in the past. @rooooooooob can you sign off on this if this is okay?

Copy link
Contributor

@rooooooooob rooooooooob left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@SebastienGllmt this won't address #86 fully though as PlutusMap is still a BTreeMap. Although I guess that is more for deserialization and such. This wouldn't cause an issue with the order conflicting in the built txs right? Since those are used as lists? Does this address the reason why in #86 they had changed it? Was it for building txs?

Could you refresh my mind on what issues LinkedHashMap caused? (bug-wise). I can only remember it causing issues due to BTreeMap automatically being canonical form so if we needed to serialize canonically (e.g. tx hashes) switching this out would break it. Or maybe traits not being implemented for it e.g. the JSON schema ones or CBOR ones which is why we have a wrapper around it in the latest version of codegen to implement those. Neither of those should be relevant here so I think it's okay, assuming this addresses the root reason why in the fork they changed it.

@@ -337,7 +342,9 @@ impl TransactionWitnessSetBuilder {
}

pub fn get_redeemer(&self) -> Redeemers {
Redeemers(self.redeemers.clone().into_values().collect())
Redeemers(self.redeemers.clone().iter().map(|i|{
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this clone is necessary anymore since iter() should give you refs to iterate over which you are cloning in that map anyway. Same with the one above in get_plutus_datum.

@SebastienGllmt
Copy link
Contributor

Yeah, I think the issues with LinkedHashMap were:

  • issues preserving encodings
  • requires manual conversion to canonical form
  • requires manual to/from json implementations

@rooooooooob
Copy link
Contributor

It should fix the preserving encodings though, not cause it. That's why we've been using it in places. BTreeMap didn't since it just orders lexicographically. (which may or may not be canonical order everywhere, since canonical order is canonical order of the serialized bytes but should be fine for most simple keys).

If this covers the root reason why the fork changed it I'm fine with this change, although the minor nit would be those clones are unnecessary afaik. A full replacement to LinkedHashMap to maintain order in PlutusMap should happen anyway after the regeneration. I thought we had already changed it, but it looks like I just stored the original bytes of the entire datum instead to cover all encoding issues in Emurgo/cardano-serialization-lib#317

@MicroProofs
Copy link
Contributor Author

Cool I'll change the clones

Copy link
Contributor

@rooooooooob rooooooooob left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@SebastienGllmt SebastienGllmt merged commit fbc858b into develop Sep 27, 2022
@SebastienGllmt SebastienGllmt deleted the datum_and_redeemer_insertion_order branch September 27, 2022 09:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants