TxInfo for PlutusV3
lehins opened this issue · comments
Describe the feature you'd like
Here is the spec for all of the Conway related changes in the Ledger that affect TxInfo:
newtype ColdCommitteeCredential = ColdCommitteeCredential Credential
deriving (Show, Eq)
newtype HotCommitteeCredential = HotCommitteeCredential Credential
deriving (Show, Eq)
newtype DRepCredential = DRepCredential Credential
deriving (Show, Eq)
data DRep
= DRepCredential DRepCredential
| DRepAlwaysAbstain
| DRepAlwaysNoConfidence
deriving (Show, Eq)
data Delegatee
= DelegStake PubKeyHash
| DelegVote DRep
| DelegStakeVote PubKeyHash DRep
deriving (Show, Eq)
-- | There is probably no need for Plutus Scripts to even know about all this data in Anchors,
-- but it is here for completeness. So we might wanna omit them, especially since urls are a
-- bit tricky, since we can't guarantee their validity, not even that they are utf8-encoded.
data Anchor = Anchor
{ anchorUrl :: ByteString -- Arbitrary Url
, anchorDataHash :: Hash -- Blake2b_256 of some off-chain data
}
deriving (Eq, Show)
-- | Note taht it no longer is caled DCert, since certificates are no longer all about
-- delegation, they are also about governance.
--
-- Notable changes:
--
-- * Pool certificates are unchanged
-- * Addition of deposits and refunds. Those values are validated according to respectful
-- PParams. Certificates that where present before get their deposit/refund as
-- optional. This is done for graceful tarnsition, since next era after Conway will require
-- deposit/refund amount
-- * New DRep entity
-- * New Constitutional Committee entity
data TxCert
= -- | Register staking credential with an optional deposit amount
TxCertRegStaking Credential (Maybe Value)
| -- | Un-Register staking credential with an optional refund amount
TxCertUnRegStaking Credential (Maybe Value)
| -- | Delegate staking credential to a Delegatee
TxCertDelegStaking Credential Delegatee
| -- | Register and delegate staking credential to a Delegatee in one certificate. Noter that
-- deposit is mandatory.
TxCertRegDeleg Credential Delegatee Value
-- | Register a DRep with mandatory deposit value and an optional Anchor
| TxCertRegDRep DRepCredential Value (Maybe Anchor)
-- | Update DRep's optional Anchor
| TxCertUpdateDRep DRepCredential (Maybe Anchor)
-- | UnRegister a DRep with mandatory refund value
| TxCertUnRegDRep DRepCredential Value
-- | Authorize a Hot credential for a specific Committee member's cold credential
| TxCertAuthHotCommittee ColdCommitteeCredential HotCommitteeCredential
| TxCertResignColdCommittee ColdCommitteeCredential
deriving (Eq, Show)
data Voter
= CommitteeVoter !HotCommitteeCredential
| DRepVoter DRepCredential
| StakePoolVoter PubKeyHash
deriving (Eq, Show)
data Vote
= VoteNo
| VoteYes
| Abstain
deriving (Eq, Show)
-- | Similar to TxOutRef, but for GovActions
data GovernanceActionId = GovernanceActionId
{ gaidTxId :: TxId
, gaidGovActionIx :: Integer
}
deriving (Eq, Show)
data VotingProcedure = VotingProcedure
{ vpVote :: Vote
, vpAnchor :: Maybe Anchor
}
deriving (Eq, Show)
data Committee = Committee
{ committeeMembers :: Map ColdCommitteeCredential Integer
-- ^ Committee members with epoch number when each of them expires
, committeeQuorum :: Rational
-- ^ Quorum of the committee that is necessary for a successful vote
}
deriving (Eq, Show)
data Constitution = Constitution
{ constitutionHash :: Hash -- Balke2b_256 of some off-chain data
, constitutionScript :: Maybe ScriptHash
}
deriving (Eq, Show)
data GovernanceAction
= -- | Proposed updates to PParams. This is a very tricky one, since PParamsUpdate is pretty
-- big and changes from one era to another. However, it could be very important for the
-- governance scripts to be able to see the values in the PParamsUpdate, but I am not
-- sure how to go forward about this, so for now I leave it as empty.
ParameterChange -- Should contain: (PParamsUpdate era)
--
| -- | proposal to update protocol version
HardForkInitiation ProtocolVersion
| TreasuryWithdrawals (Map Credential Value)
| NoConfidence
| NewCommittee
[ColdCommitteeCredential]
-- ^ Old committee
Committee
-- ^ New Committee
| NewConstitution Constitution
| InfoAction
deriving (Eq, Show)
data ProposalProcedure = ProposalProcedure
{ ppDeposit :: Value
, ppReturnAddr :: Credential
, ppGovernanceAction :: GovernanceAction
, ppAnchor :: Anchor
}
deriving (Eq, Show)
data ScriptPurpose
= Minting CurrencySymbol
| Spending TxOutRef
| Rewarding Credential
| Certifying TxCert
| Voting Voter GovernanceActionId
| Proposing -- For now this will only be used by Constitution, thus might turned out to be
-- unused.
deriving (Show, Eq)
-- | TxInfo for PlutusV3
data TxInfo = TxInfo
{ txInfoInputs :: [TxInInfo]
-- ^ Unchanged
, txInfoReferenceInputs :: [TxInInfo]
-- ^ Unchanged
, txInfoOutputs :: [TxOut]
-- ^ Unchanged
, txInfoFee :: Value
-- ^ Unchanged
, txInfoMint :: Value
-- ^ Semantics changed:
-- In Conway for PlutusV3 translation is different from previous Plutus versions, since we no
-- longer add a zero ADA value to the mint field during translation.
-- Fixes: https://github.com/input-output-hk/plutus/issues/5039
, txInfoTxCert :: [TxCert]
-- ^ Certificate type has changed
, txInfoWdrl :: Map Credential Integer
-- ^ Unchanged
, txInfoValidRange :: POSIXTimeRange
-- ^ Unchanged
, txInfoSignatories :: [PubKeyHash]
-- ^ Unchanged
, txInfoRedeemers :: Map ScriptPurpose Redeemer
-- ^ Semantics changed
--
-- ScriptPurpose is now different in Conway
, txInfoData :: Map DatumHash Datum
-- ^ Unchanged
, txInfoId :: TxId
-- ^ Unchanged
, -- New in Conway ===========================================================
txInfoVotingProcedures :: Map Voter (Map GovernanceActionId VotingProcedure)
-- ^ This is Map with all of the votes that were included in the transaction
, txInfoProposalProcedures :: [ProposalProcedure]
-- ^ This is a list with Proposals that will be turned into GovernanceActions, that everyone
-- can vote on
, txInfoCurrentTreasuryAmount :: Maybe Value
-- ^ Optional amount for the current treasury. If included it will be checked to be equal
-- the current amount in the treasury.
, txInfoTreasuryDonation :: Maybe Value
-- ^ Optional amount for donating to the current treasury. If included, specified amount
-- will go into the treasury.
}
deriving (Show, Eq)Describe alternatives you've considered
No response
Thanks! We'll start working on it soon.
I found two things: ppReturnAddr should be a Credential (since a reward address can be locked by scripts), and the Proposing constructor of ScriptPurpose should probably include a GovernanceAction since we want to run the script once for each proposal.
@WhatisRT Thank you for double checking it.
ppReturnAddr should be a Credential
Changed. We also need to change this in ledger implementation and in the spec, both are wrong (I've messaged you about this on slack and here is a related github issue: IntersectMBO/cardano-ledger#3594)
and the Proposing constructor of ScriptPurpose should probably include a GovernanceAction since we want to run the script once for each proposal.
I am not so sure about this. We'll talk more about this later, since that is not the top priority. However, in my understanding there are no Plutus scripts in the proposal procedure, thus the only script that can run for such purpose is the constitution script.
Is the spec update nearly done also? That's also super helpful as a reference.
Is the spec update nearly done also? That's also super helpful as a reference.
@michaelpj I've updated the ticket to reflect some of the changes from the PR review.
If you were talking about the formal spec, then, yes it is nearly done and it contains almost the same types as in this ticket.
@zliu41 In the issue I said "Pool certificates are unchanged", but totally forgot to include them in the actual type, so here are the two missing constructors for PlutusV3 context:
data TxCert
= -- | A digest of the PoolParams
TxCertPoolRegister
PubKeyHash
-- ^ poolId
PubKeyHash
-- ^ pool VFR
| -- | The retirement certificate and the Epoch in which the retirement will take place
TxCertPoolRetire PubKeyHash Integer -- NB: Should be Word64 but we only have Integer on-chain