-
Notifications
You must be signed in to change notification settings - Fork 157
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
update plutus to alonzo/rc-2 #2425
Conversation
148a0f0
to
b7e5068
Compare
@@ -264,7 +264,7 @@ plutus_data = ; New | |||
/ { * plutus_data => plutus_data } | |||
/ [ * plutus_data ] | |||
/ big_int |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
big_int
can be any big int now for the same reason.
6d3e033
to
5af208b
Compare
71cc4d7
to
9c5cb98
Compare
9c5cb98
to
b17905d
Compare
Left e -> fail e | ||
Right cm -> pure cm | ||
|
||
decodeArrayAsMap :: Ord a => Set a -> Decoder s b -> Decoder s (Map a b) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, so we gave you the cost model as Map Text Integer
to make it very homogenous, and so you could work with it somewhat independently of the API we give you. But if we're using defaultCostModelParams
during deserialization, then that's kind of gone out the window.
In which case: it seems like this would be easier if it was Map ModelKey Integer
where ModelKey
has a Enum
/Bounded
instances? It also would make for a nicer, more generic function:
decodeArrayAsMap :: (Enum k, Bounded k, Ord k) => Decoder s v -> Decoder s (Map k v)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, I agree, that would probably be nicer to work with and maintain.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @michaelpj ! The enumeration will have to match what we are currently doing (ascending order by key) if we want to make this change sometime before the next hardfork after alonzo (since the cost model is a part of the script integrity hash).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point!
As of IntersectMBO/cardano-ledger#2425, the ledger serialises only the values of a CostModel, rather than the keys. This is to allow for far more compact serialisation (the string names were taking a lot of space!) However, it means that we reassemble the names from the Plutus default cost model parameters, and hence generators must match these names. This commit alters the cost model generator to simply set values over the Plutus `defaultCostModelParams`.
This PR ended up being less trivial than I expected, so I will leave some notes here for posterity.
Data
to 64 bytes, so our tests and CDDL have been adapted accordingly.102
is now serialized as#6.102([uint, [* a]])
instead of#6.102([uint, * a])
.