Start assembling Alonzo transactions and witnesses. #2022
Conversation
nc6
force-pushed
the
nc/alonzo
branch
8 times, most recently
from
f1c02f2 to
d9c9324
Compare
| import Shelley.Spec.Ledger.Hashing (HashAnnotated (..)) | ||
|
|
||
| -- | TODO this should be isomorphic to the plutus type | ||
| data Data era |
There was a problem hiding this comment.
Should it be imported from the Plutus library? Did we ever conclude the discussion on how close this is going to be to plain CBOR?
There was a problem hiding this comment.
I think Plutus will have or already has a particular single module that (re?)-exports everything that should be accessible to the ledger (this type, the interpreter calling function, etc.).
I guess things there will also have to become era-parametrized? Or do we maybe want to make this a type family so that only the family is parametrized by era, but not the specific types to which the family is instantiated for each era
| exUnitsSteps :: !Word64 | ||
| } | ||
| deriving (Eq, Show, Ord) | ||
|
|
There was a problem hiding this comment.
we need to have a discussion about how we actually handle this execution units tracking. What is in the spec now (ie this structure) is kind of middle ground between two approaches not finalized and needs to change. @WhatisRT we should schedule a meeting for some time in the next week or two
|
|
||
| data ScriptDataRaw era = ScriptDataRaw | ||
| { _scriptDataScripts :: Map (ScriptHash era) (Core.Script era), | ||
| _scriptDataData :: Set (Data era), |
There was a problem hiding this comment.
Using the correct plural of Datum here seems slightly more confusing than using the wrong one to make it clear that this is a collection of Datum objects (Datums) heeehee
There was a problem hiding this comment.
also, should we make the scriptDataData and scriptDataScripts consistent with each other - as in, either have them both be a map from hash to the preimage, or have them both be just the preimage? And if so, which way do you prefer?
There was a problem hiding this comment.
I'm fine with either. The spec currently has them just being the preimage, but the existing Shelley code has them as the map. As yet I haven't grokked the usage patterns well enough to proffer an opinion on what would be best for Data. If we want them consistent, then I can happily change this to a Map.
nc6
force-pushed
the
nc/alonzo
branch
4 times, most recently
from
779ed35 to
c6efcaa
Compare
|
|
||
| -- | Marker indicating the part of a transaction for which this script is acting | ||
| -- as a validator. | ||
| data Tag | ||
| = -- | Validates spending a script-locked UTxO | ||
| Input | ||
| | -- | Validates minting new tokens | ||
| Mint | ||
| | -- | Validates certificate transactions | ||
| Cert | ||
| | -- | Validates withdrawl from a reward account | ||
| Wdrl | ||
| deriving (Eq, Generic, Ord, Show) |
There was a problem hiding this comment.
Lets put a comment here about how we intend to use this. Is it as a index to some type constructor (using Data.Kinds) or as a field to some record type.
| TxWitnessConstr | ||
| ( Memo | ||
| ( TxWitnessRaw | ||
| witsVKey | ||
| witsBoot | ||
| ( ScriptDataConstr | ||
| ( Memo | ||
| ( ScriptDataRaw | ||
| witsScript | ||
| witsData | ||
| witsRdmr | ||
| ) | ||
| _ | ||
| ) | ||
| ) | ||
| ) | ||
| _ | ||
| ) |
There was a problem hiding this comment.
Shouldn't we use the constructor patterns for ScriptData, rather than building it from whole cloth here?
| ) => | ||
| FromCBOR (TxBodyRaw era) | ||
| where | ||
| fromCBOR = decode $ SparseKeyed "TxBodyRaw" init bodyFields [] |
There was a problem hiding this comment.
The final argument to SparseKeyed here is the set of required fields, such that an error will be raised if they're not present. So should set it here to the same set as in shelley-ma
nc6
force-pushed
the
nc/alonzo
branch
2 times, most recently
from
2e7512e to
2d99233
Compare
There was a problem hiding this comment.
I didn't realize I hadn't approved this already, sorry. Thanks @nc6 !
- transaction inputs and outputs - witnesses - scripts and data
Start establishing the framework for Alonzo tests, so far just including roundtrip tests. We include a roundtrip CBOR test for TxWitness.
This is needed to work around a bug with cabal-to-nix. See this thread (https://input-output-rnd.slack.com/archives/CG386Q1NE/p1607468183215300) for further details.
Early work setting up Alonzo types: