Safe Haskell | Safe-Inferred |
---|---|
Language | Haskell2010 |
PlutusLedgerApi.Common.ProtocolVersions
Contents
Synopsis
- newtype MajorProtocolVersion = MajorProtocolVersion {}
- shelleyPV ∷ MajorProtocolVersion
- allegraPV ∷ MajorProtocolVersion
- maryPV ∷ MajorProtocolVersion
- alonzoPV ∷ MajorProtocolVersion
- vasilPV ∷ MajorProtocolVersion
- valentinePV ∷ MajorProtocolVersion
- conwayPV ∷ MajorProtocolVersion
- conwayPlus1PV ∷ MajorProtocolVersion
- knownPVs ∷ Set MajorProtocolVersion
- futurePV ∷ MajorProtocolVersion
Documentation
newtype MajorProtocolVersion Source #
This represents the major component of the Cardano protocol version. The ledger can only supply the major component of the protocol version, not the minor component, and Plutus should only need to care about the major component anyway. This relies on careful understanding between us and the ledger as to what this means.
Constructors
MajorProtocolVersion | |
Fields |
Instances
Protocol Version aliases
shelleyPV ∷ MajorProtocolVersion Source #
Shelley era was introduced in protocol version 2.0
allegraPV ∷ MajorProtocolVersion Source #
Allegra era was introduced in protocol version 3.0
maryPV ∷ MajorProtocolVersion Source #
Mary era was introduced in protocol version 4.0
alonzoPV ∷ MajorProtocolVersion Source #
Alonzo era was introduced in protocol version 5.0
vasilPV ∷ MajorProtocolVersion Source #
Vasil era was introduced in protocol version 7.0
valentinePV ∷ MajorProtocolVersion Source #
Protocol version 8.0 was the Valentine intra-era HF
conwayPV ∷ MajorProtocolVersion Source #
Conway era was introduced in protocol version 9.0
conwayPlus1PV ∷ MajorProtocolVersion Source #
The next HF after Conway. It doesn't yet have a name, and it's not yet known whether it will be an intra-era HF or introduce a new era.
knownPVs ∷ Set MajorProtocolVersion Source #
The set of protocol versions that are "known", i.e. that have been released and have actual differences associated with them.
futurePV ∷ MajorProtocolVersion Source #
This is a placeholder for when we don't yet know what protocol version will be used for something. It's a very high protocol version that should never appear in reality. New builtins should always be given this protocol version until they've been finalised.
We should not assign names to future protocol versions until it's confirmed that they are correct, otherwise we could accidentally associate something with the wrong protocol version.