Make HeadId usable on-chain

[uhbif19]

Why

We use HeadId as part of out on-chain terms.
Now we need to convert it to CurrencySymbol, what makes is less type-safe.

https://github.com/mlabs-haskell/hydra-auction/blob/07740fb9cd832f934bab61dab23b4369e96d0c9c/src/HydraAuction/Types.hs#L78

What

Make HeadId serializable to on-chain Data.

How

I think HeadId may just use BuiltinByteString instead of ByteString.

[ch1bo]

So, you would like to have a HeadId type in the hydra-plutus package to refer to Hydra Head on-chain and the knowledge that this is in fact just a policy id / CurrencySymbol should be hidden? How would your code acquire such a HeadId and expect it to be used?

I see some usage of it here in your code base.

The type you are using right now is the one from Hydra.Chain which is used in the HeadLogic and on the API of the hydra-node and deliberately not cardano-specific! Making this a newtype around the plutus-tx specific BuiltinByteString is thus not desirable.

What we can do, however is to define such a type in the hydra-plutus package along with some conversion functions like headIdToCurrencySymbol if that helps you.

[uhbif19]

How would your code acquire such a HeadId and expect it to be used?

It is used as param of AuctionTerms. On chain script check that correct Head is used, and not any other head.

But it is also used on delegate servers and clients, to ensure that correct head is used.
So it requires bunch of back-and-forth type conversions that way.

Making this a newtype around the plutus-tx specific BuiltinByteString is thus not desirable.

Why? Anyway ToData/FromData are just as good, I believe. Actually we could do it ourself.
But I only see headIdToCurrencySymbol, no other side conversion. But probably it could be crafted too.

[ch1bo]

Making this a newtype around the plutus-tx specific BuiltinByteString is thus not desirable.

Why?

Because HeadId is not cardano-specific. We don't want to wrap a cardano/plutus specific type in it. Conversion will always be needed.

I'd we do the following to address this item:

• Document the existing HeadId to make it clear it is a generic identifier for a hydra head. As this is used on the API, this will eventually also move into an api package. Let's call this Hydra.API.HeadId.

• Introduce a new type in hydra-plutus, also named HeadId (?) and make that a type alias around CurrencySymbol (or a newtype if it does not add overhead via plutus-tx). Let's call this Hydra.Plutus.HeadId

• Provide conversion functions to convert between the to forms, similar as we do for the ContestationPeriod and Party types. Question only is.. where? This converts from a generic head id into a cardano-specific head-id. So naturally hydra-plutus would be better suited, but that would make hydra-plutus depend on hydra-api (which does not yet exist).

[uhbif19]

@ch1bo

Introduce a new type in hydra-plutus, also named HeadId

I proposed single type cuz it seems simple solution to me. If not single type, than I think that conversion functions are good enough, and child packages may do onchain newtype themselves, cuz this type is not used by hydra so there is no need for interoperability.