WIP #1
WIP #1
Conversation
LedgerCBOR instance — allows to generate CanonicalCBOR instance from the ledger one MempackCBOR instance - allow to generate CanonicalCBOR instance from the mempack one
| import Cardano.Ledger.Alonzo.TxOut (DataHash32, Addr28Extra) | ||
|
|
||
| -- | Helper that allows us to deriving instances via internal CBOR representation | ||
| newtype LedgerCBOR a = LedgerCBOR { unLedgerCBOR :: a } |
There was a problem hiding this comment.
Maybe integrate the version as a parameter to LedgerCBOR, then we can derive for specific versions rather than hard-coding to V1?
There was a problem hiding this comment.
Let's try! Not sure how it would work with presence of the new versions, but it will likely to simplify current version
UPD: done
| deriving (Eq, Show) | ||
|
|
||
| instance (MemPack a) => ToCanonicalCBOR V1 (MemPackCBOR a) where | ||
| toCanonicalCBOR _v (MemPackCBOR a) = toPlainEncoding shelleyProtVer (encodeMemPack a) |
There was a problem hiding this comment.
Do we want to go via the ledger encodings specifically for MemPack? I would have thought we would just encode the ByteArray directly
There was a problem hiding this comment.
This approach creates CBOR bytes, and stores MemPack there, so basically it stores to ByteArray in the encoder. It should be compatible with current implementation and reuse optimal approach from the ledger,
This approach should be compatible with CBOR for SCLS files and reuse all functionality from ledger.
However in this approach we will have to write specification for the binary form in CIP.
Maybe I miss something still.
| fromCanonicalCBOR = Versioned . MemPackCBOR <$> toPlainDecoder Nothing shelleyProtVer decodeMemPack | ||
|
|
||
| -- | Input wrapper for the keys that are used in utxo namespace | ||
| data UtxoIn = UtxoIn { utxoInAddress :: DataHash32, utxoInIndex :: Word16 } |
There was a problem hiding this comment.
Maybe call this 'UtxoKey' rather than 'UtxoIn', which is a little confusing. Or just re-use the TxIn datatype
There was a problem hiding this comment.
Reusing TxIn would be nice. Though IIUC there is no mapping from TxIn to script data, so should I use two variants for TxIn and for Purpose and Hash (for scripts)?
Description
Checklist
CHANGELOG.mdfiles updated for packages with externally visible changes.NOTE: New section is never added with the code changes. (See RELEASING.md).
.cabalandCHANGELOG.mdfiles when necessary, according to theversioning process.
.cabalfiles updated when necessary.NOTE: If bounds change in a cabal file, that package itself must have a version increase. (See RELEASING.md).
scripts/fourmolize.sh).scripts/cabal-format.sh).scripts/gen-cddl.sh)hie.yamlupdated (usescripts/gen-hie.sh).