Update primitive.yaml: Add Bytes primitive

[ryanschneider]

This came up in ethereum/builder-specs#107 (comment) (/cc @lucassaldanha). I agree with Lucas that Bitvector is probably wrong, and that currently we don't have a good primitive to express this.

I'm also not terribly familiar with the beacon API types though, so am open to other options, both in naming and format.

Some points of discussion:

• Alternative names: ByteVector?
• I'm honestly not sure if the regex should be {2,} (which I started with) or {0,} since before the latest changes to EIP-7865 the empty requests were encoded as "0x" which {2,} doesn't allow.
• I could instead refactor the build spec since really the requests are bounded to sizeof(largest request type) * max_request_count_per_block + 1 but that seemed to get really deep in the weeds for a field thats meany to be opaque for most purposes.

[mcdee]

I'd rather see the regex as ^0x([0-9a-fA-F][0-9a-fA-F])+$ to ensure that we don't end up with odd-length hex strings.

[ryanschneider]

I'd rather see the regex as ^0x([0-9a-fA-F][0-9a-fA-F])+$ to ensure that we don't end up with odd-length hex strings.

Good call @mcdee I made that change. We can always change the + to a * if we feel that "0x" should be allowed to represent an empty byte sequence.

[nflaig]

arbitrary-length / unbounded values are not SSZ compatible, you always have to define a maximum bound

[ryanschneider]

I'll go ahead and close since ethereum/builder-specs#107 was closed as well. I guess better wording if we ever want to revisit this would be "An sequence of bytes with unspecified maximum length"

[nflaig]

"An sequence of bytes with unspecified maximum length"

You have to specify a maximum length, there is no unbounded type in ssz. That being said, it would still be possible for the execution requests list use case as you can just update the max length each hard fork if new request types are added

[ryanschneider]

Closing since ethereum/builder-specs#107 which required this was closed as well.