-
Notifications
You must be signed in to change notification settings - Fork 724
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 Cardano.Api.ProtocolParameters to ease integration with Alonzo #2634
Conversation
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.
TODO: Break up Cardano.Api.ProtocolParameters module
@@ -200,3 +213,7 @@ constraints: | |||
|
|||
package comonad | |||
flags: -test-doctests | |||
|
|||
allow-newer: | |||
monoidal-containers:aeson, |
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.
You may not need monoidal-containers:aeson
anymore as of now.
d46dc08
to
0cd5588
Compare
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.
Looking good!
@@ -101,7 +115,7 @@ import Cardano.Api.Value | |||
-- | |||
-- There are also paramaters fixed in the Genesis file. See 'GenesisParameters'. | |||
-- | |||
data ProtocolParameters = | |||
data ProtocolParameters era = |
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.
Why did we need the era
type param? We don't seem to use it below.
If we really don't need it to be era-parameterised, then it should simplify things elsewhere (e.g. in the cli code).
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.
This appears to be leftover, I'll remove it We need it for the JSON instances https://github.com/input-output-hk/cardano-node/pull/2634/files?file-filters%5B%5D=.hs#diff-6d43cdca78f34a488eb77b4b8597a6b02f173b078695ca5f6a2b9371bcb30531R595
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.
Hmm. I've had a look and I don't think that's the case. You're using it to restrict the fields we render to those from a specific era, but I don't see any need to do that. We can just render them all.
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.
Yes, I think the strategy we're following here with the ProtocolParameters
is that we just have all of them, taking the union of them from all eras, and in some eras we just done use them all. I've not yet seen any reason that that strategy will not work out ok.
In which case to follow the strategy we really should not have an era param at all, since nothing inside it needs it. And other functions like JSON serialisation also do not need to know the era because the strategy we're following is to take the collection of all params, from all eras.
If you think that's not going to work out for some reason then lets review it and we might need to change strategy and have a fully era-typed style where we enforce that only the params that are available are those that exist for each specific era. But let's not do a hybrid strategy. Typed or untyped, but not a mish-mash.
0bd64ea
to
afa4b9a
Compare
The hydra error will go away once the node's deps are updated and I rebase on |
@Jimbo4350 I assume maxValSize is the maximum size of the utxo "value" field in the serialized transaction in bytes - do we know what the value of maxValSize in Alonzo era will be? In Mary it was 4000 bytes if I understood correctly: https://github.com/input-output-hk/cardano-ledger-specs/pull/2099/files#diff-1dbf0b3dcad4b1ddcdf86e9df16469b461f3e9f906cf42d925d6fb3a386dd6c2R258 |
We haven't decided on any of the new protocol parameters introduced in the Alonzo era as yet. This will happen closer to the fork. |
56cdaba
to
2cf08e4
Compare
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's obviously some overlap to make this PR and #2657. That's fine for the moment so they both pass CI independently.
Given that #2657 seems nearly ready and this one will need a bit more work, I think it probably makes most sense for this one to be rebased after that PR goes in (or rebased on that one's branch in the mean time).
-- | Cost models for non-native script languages. | ||
protocolUpdateCostModels :: Map AnyScriptLanguage CostModel, | ||
|
||
-- | Map AnyScriptLanguage ExecutionUnitPrices of execution units (for non-native script languages). |
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.
These are the other uses of the "native" script language terminology.
@@ -101,7 +115,7 @@ import Cardano.Api.Value | |||
-- | |||
-- There are also paramaters fixed in the Genesis file. See 'GenesisParameters'. | |||
-- | |||
data ProtocolParameters = | |||
data ProtocolParameters era = |
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.
Yes, I think the strategy we're following here with the ProtocolParameters
is that we just have all of them, taking the union of them from all eras, and in some eras we just done use them all. I've not yet seen any reason that that strategy will not work out ok.
In which case to follow the strategy we really should not have an era param at all, since nothing inside it needs it. And other functions like JSON serialisation also do not need to know the era because the strategy we're following is to take the collection of all params, from all eras.
If you think that's not going to work out for some reason then lets review it and we might need to change strategy and have a fully era-typed style where we enforce that only the params that are available are those that exist for each specific era. But let's not do a hybrid strategy. Typed or untyped, but not a mish-mash.
instance HasTextEnvelope UpdateProposal where | ||
textEnvelopeType _ = "UpdateProposalShelley" | ||
|
||
--TODO: Jordan UpdateProposal needs to be parameterized by era or have access to the era |
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.
If we think we might need the era just for this purpose, then we can either:
- Drop CBOR serialisation for these types. Do we really need separate serialisation for them?
- Do independent CBOR serialisation that does not involve converting to the underlying ledger type. This will not work in future precisely because we're taking the simple untyped approach of taking the union of all params for all eras.
--TODO decide how to handle parameter validation | ||
UpdateProposal (Map.fromList [ (kh, params) | kh <- genesisKeyHashes ]) | ||
|
||
newtype CostModel = CostModel (Map.Map Text Integer) |
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.
Oops, looks like we've duplicated these types from the ProtocolParameters
module. A good reason to unsplit the modules (once we make the original less enormous again) :-)
-- ---------------------------------------------------------------------------- | ||
-- Conversion functions | ||
-- |
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.
I can't tell what we've changed here since we've split the module. Can I suggest that's another good reason to not split them in this PR, or at least not split them and change them in a single commit.
|
||
|
||
instance Aeson.FromJSONKey AnyScriptLanguage where | ||
fromJSONKey = Aeson.FromJSONKeyValue parseJSON |
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.
I don't understand how this is supposed to work. A JSON key must be just a JSON string but this reuses the FromJSON
above right? But that uses a JSON object not a JSON string. Am I missing something?
@@ -835,6 +871,7 @@ fromAllegraTimelock timelocks = go | |||
|
|||
instance ToJSON (Script lang) where | |||
toJSON (SimpleScript _ script) = toJSON script | |||
toJSON (PlutusScript _ _) = Aeson.Null |
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.
Perhaps better to leave this as an error "TODO ..."
rather than Null
. The latter is too easy to forget or miss in a grep TODO
.
In the Alonzo era we introduce 6 new protocol parameters and remove 1 protocol parameter. In anticipation of the Alonzo era, we make some modifications to the ProtocolParameters type. minUTxOValue becomes a Maybe (This parameter gets deprecated in Alonzo) We introduce the following but note they are currently ignored: - adaPerUTxoByte - Cost in ada per byte of UTxO storage (replaces minUTxOValue) - costmdls - The cost models for plutus scripts - prices - The prices of execution units for plutus scripts - maxTxExUnits - Max total script execution resource units allowed per tx - maxBlockExUnits - Max total script execution resource units allowed per block - maxValSize - Max size of a Value in a tx output We introduce an era parameter in the ProtocolParameters type in order to reduce boilerplate. We have avoided the typical GADT pattern in cardano-api to prevent an explosion of types.
2cf08e4
to
32a1c83
Compare
Closed in favour of #2699 |
Prepare Cardano.Api.ProtocolParameters for Alonzo era.
In the Alonzo era we introduce 6 new protocol parameters and remove 1
protocol parameter. In anticipation of the Alonzo era, we make some
modifications to the ProtocolParameters type.
minUTxOValue becomes a Maybe (This parameter gets deprecated in Alonzo)
We introduce the following but note that they are currently ignored:
minUTxOValue)
We introduce an era parameter in the ProtocolParameters type in order to
reduce boilerplate. We have avoided the typical GADT pattern in
cardano-api to prevent an explosion of types.