[Peras 25.5] Introduce Bytes32RealPoint

[agustinmista]

This PR introduces a specialization of RealPoint for blocks where the header hash is always 32 bytes long.

[jasagredo]

I am not sure this is how it should be. I think this is unsafe as assertions are not checked in production

[agustinmista]

I would have expected this to be an invariant for any blk such that:

type instance HeaderHash blk = ShortByteString

But if that's not the case I guess we will need to deal with the partial conversion more explicitly.

Would you prefer this to be discharged with a Maybe or with an error?

[tbagrel1]

IIRC:

• For any blk of a concrete era (OneEra x); or the HardForkBlock xs, HeaderHash blk is semantically isomorphic to a 32-byte bytestring, but it can take slightly more compact forms (e.g. 4 Word64 zipped together for some eras)
• For other blks (e.g. TestBlock), we can't make any assumption on the shape of HeaderHash blk

[agustinmista]

Thanks @tbagrel1 for the extra context.

FTR: we still need to decide how to discharge errors when coercing from a (potentially) non-32bytes-long ShortByteString into Bytes32RealPoint, as this is not captured at the type level.

What we need to address concretely here is whether we:

1. Capture this with a Maybe and let the client code (likely the HFC?) handle it.
2. Assume it can't happen and put an error for the impossible case.
3. Assume it can't happen and wrap the expression with an assertion.
4. Something else?

Then (1) and (2) will come with some minor performance penalty (length check and optionally wrapping on Maybe) that we can avoid if we already know that forall blk. Coercible (HeaderHash blk) ShortByteString implies len(header_hash) == 32 in any production context where this function could be invoked. On the other hand (3) should have no performance penalty in production, while still being able to detect issues in testing.

I'm OK with any of these approaches, but I would like to hear back from @jasagredo before making any change :)

[tbagrel1]

@jasagredo

Hey we just discussed this with @agustinmista, and here's a more refined context/question:

1. We will only convert from (Real)Point blk to Bytes32RealPoint in contexts in which it's morally safe to do it; that is, for blk of a concrete era or the HardForkBlock. So ideally the conversion functions should probably NOT return a Maybe (to avoid having to deal with impossible cases at call site). Do you agree?
2. Is it ok to assume that OneEra blk or AllEra blks (For HardForkBlock blks) are the right classes that carry the moral invariant that a header hash carries 32 bytes of information? If not, what would be the right class?
3. If the previous one is correct, would it be ok to create a conversion class from (Real)Point blk to Bytes32RealPoint and add it as a superclass constraint for OneEra blk ? This way I think it would be easier to implement the converter for the different concrete shape of 32-bytes headerhash (e.g. Bytestring, 4 Word64s, etc)

[agustinmista]

Hey @jasagredo! ✋

Do you think you could take a look at the remaining comment on this PR? This is currently blocking Peras 26 from being merged 😅

Thanks in advance!

CC @dnadales in case you have time to chime in instead.