conway.cddl costmdls clarification

[rooooooooob]

Slightly pedantic but as of #4284 the definition was changed to:

costmdls =
  { ? 0 : [ int64 ] ; Plutus v1
  , ? 1 : [ int64 ] ; Plutus v2
  , ? 2 : [ int64 ] ; Plutus v3
  , ? 3 : [ int64 ] ; Any 8-bit unsigned number can be used as a key.
  }

Is this meant to be [ * int64]? Or [ 166* int64] (etc)? Currently it's saying there are exactly 1 element per array as per the CDDL RFC but that's obviously not the intention.

Is that 3 key meant to just be a comment or suggestion for all others keys being allowed with zero restrictions e.g. * uint => [* int64]?

I'm mostly wanting to know about that old comment (e.g. ? 0 : [ 166* int ] ; Plutus v1, only 166 integers are used, but more are accepted (and ignored)) holds true and we need to accept but ignore elements after or not, but that those minimums still need to be checked. And if that ignoring has any bearing on costmodel's language view encoding computation since that hashes cost models' cost array inside a serialized CBOR structure. As far as I understand this is canonical CBOR (besides the plutus v1 difference) so not directly taking it out of the cost models on-chain serialization.

The previous eras' .cddl specs still maintain their bounds (babbage.cddl/alonzo.cddl)

    ? 0 : [ 166*166 int64 ] ; Plutus v1
  , ? 1 : [ 175*175 int64 ] ; Plutus v2

[teodanciu]

@rooooooooob, thank you for pointing out the error. I have now fixed the cddl to be:

costmdls =
  { ? 0 : [ * int64 ] ; Plutus v1
  , ? 1 : [ * int64 ] ; Plutus v2
  , ? 2 : [ * int64 ] ; Plutus v3
  , * 3 .. maxWord8 => [ * int64 ] ; Any 8-bit unsigned number can be used as a key
  }

which is correct and more precise than what we had before.

With regards to your last question, I don't understand everything you are asking (particularly towards the end), but I can start by saying that the Conway deserialization of costmodels does not check the number of values in the list, because the Plutus function that we are passing this list to (namely mkEvaluationContext) no longer expects the exact number of values for each language.
So there is no checking, ignoring or otherwise modification of the list based on these numbers.
If this does not answer everything you wanted to know, could you please explain more about what is unclear?
Thanks!