Minting policy (Full or Limited)

[ffakenz]

Currently, on master, there is a gap with the spec in regards to the minting policy approach.

The spec describes somewhat the minting policy to follow "The limited approach":

• here in the on-chain (Section 5.1):

• and here in the off-chain (Section 6.4.1 and Figure 10):

In summary, this means:

u_head does not need to check for minted quantities or PT distribution when minting tokens:
- Actors need to check off-chain whether an `initTx` is well-formed.
- Minted quantities and whether PTs are paid to v_initial should be determined off-chain.

There is some progress on filling this gap for "The limited approach" as part of #452 (PR #712), but it was stopped in favor to explore "The full approach".

Both approaches have been documented by researchers in the following google doc

Some notes taken during Weekly Engineering with researched regarding "The full approach":

• we do this to know less when reasoning about the head
• we could incorporate this into general specification and actually implement it
  • when we mint - we ensure consumation of out ref also present in head params/datum.
  • tx that mints tokens takes the first (head) output and makes sure this output is spent. Outref in datum matches the head script parameter.
• check distribution of PT's - do not check the token name
• recipe for the full policy implementation:
  take the txout ref from the datum, apply to the minting policy and compare the hashes + make sure the head tokens are there
• It makes it simpler to identify a correct head

Concerns:

• only ada and head tokens being in the Value (so adversary cannot pack some garbage tokens to increase the tx size)
• "It makes it simpler" is only a "feeling" and we would need to write down what it actually means to identify a head.

[ch1bo]

Thanks for opening this and providing some context. Let's try to structure this for creating a feature item off it:

Why

• the minting policy ensures uniqueness of a Head, by providing a HeadId
• helps in identifying a "sound Head", i.e. one that follows the rules
• able to tell a proper Head from a faked one apart
• want to limit necessary knowledge required by users/implementations off-chain

What

• In any case our minting policy mu_head should be parameterized by an out-ref, which is ensured to be unique by checking that out-ref is actually spent on minting -> makes any token minted unique and the hash of the script is hence also unique -> unique HeadId

• To know whether a token was indeed minted by a parameterized minting policy:

  • we need the minting policy mu_head itself
  • we need to the parameter out-ref
  • we need to be able to apply a parameter to a script and take it's hash
  • the result of hash(mu_head(out-ref)) then is the policy id / currency symbol of a token. In our case this is also the "HeadId"

• It's helpful to keep the out-ref parameter around, for example in the datum of an output.

• It's not practical (not possible?) to apply parameters to scripts and serialize them on-chain. Hence, we would also keep the resulting policy id next to the parameter, for example in the datum. Consequently this check needs to be done off-chain.

• To ensure that we have a "proper Head" at hand, e.g. when observing transactions on-chain, more checks need to be done. Depending on the nature of the minting policy, these checks are either

  • off-chain for limited policy
  • on-chain for a full policy

• In our case "proper" means:

  • There is unique, single state token that is paid into a specific contract (the head validator v_head), which ensures continuity
  • The PTs are also paid into a specific contract (the initial validator v_initial), to ensure they are available for aborting the Head (= cannot be spent arbitrarily)
  • The datum communicated on Head transactions is consistent with the tokens that were minted:
    • number of participants = number of PTs
    • (if in the datum) the pub key hashes of all participants = the token names of PTs

[ch1bo]

Implemented in #742