Update EIP-4844: Specify precompile input's z and y to be encoded as big endian

[g11tech]

Following a discussion ACD on may 11, it was decided to specify z and y in pre-compile input to be big endian so that there is minimal confusion on EL which primarily encodes bytes as big endian.

Ref: https://discord.com/channels/595666850260713488/745077610685661265/1106250714415648849

Corresponding PR in the consensus specs detailing polynomial commitments:

• Update the endianness of the polynomial commitments to be big endian consensus-specs#3354

[eth-bot]

✅ All reviewers have approved.

[lightclient]

So it turns out that the blake2 (EIP-152) precompile accepts little endian encoding, so maybe we're being too pedantic?

[arnetheduck]

the way forward here would be the same as any other BLS data: treat it as a black-boxed array of bytes and specify the serialization elsewhere (rather than bending the ssz interpretation etc)

[g11tech]

fair point, actually its uint256 list/array so so talking about big endian encoding is irrelevant.

and with now the rlp serialization, it will anyway serialize it big endian for EL layer

have remove the extra meta text

[arnetheduck]

well, BLSFieldElement in that world needs to be Bytes32 - uint256 would imply a SSZ "number" which is little endian.

[asn-d6]

That's indeed how it's defined in consensus-specs: https://github.com/ethereum/consensus-specs/blob/dev/specs/deneb/polynomial-commitments.md#custom-types

This might be one of the desync issues between EIP and consensus-specs.

Am I right that the Blob struct is currently unused in the EIP?

[g11tech]

Blob right now in EIP (mostly an EL specification) is only used for network tx format correctness verification via kzg libs and so is the case in CL.

even for DAS underlying libs could take an input and give erasure code blobs as output
for Custody game, i don't see why CLs need to interpret blob data as BlsFieldElements for generating merkle proofs, so again their its just blob data

[g11tech]

well, BLSFieldElement in that world needs to be Bytes32 - uint256 would imply a SSZ "number" which is little endian.

Well Uint256 does imply a number which is the intend as its a point on the BLS curve, but i don't think it implies encoding format case in point the below lines from the EIP which were anyway previously the part of EIP.

    # Return FIELD_ELEMENTS_PER_BLOB and BLS_MODULUS as padded 32 bytes big endian values
    return Bytes(U256(FIELD_ELEMENTS_PER_BLOB).to_be_bytes32() + U256(BLS_MODULUS).to_be_bytes32())

But anyway I think this extra clarification I added in a separate PR takes care of any confusion:
https://github.com/ethereum/EIPs/pull/7038/files#diff-c72ce77807acfea9e9693b7999f247841df938c9645be37013903805fa8b0c09R283

[arnetheduck]

but i don't think it implies encoding format

https://github.com/ethereum/consensus-specs/blob/dev/ssz/simple-serialize.md#uintn

[hwwhww]

Probably not in this PR, but can we use CL format ByteVector[BYTES_PER_FIELD_ELEMENT * FIELD_ELEMENTS_PER_BLOB] for Blob here? ByteVector (just bytes) allows you not to go deep into SSZ in EL than Vector.

[asn-d6]

LGTM. Thanks!

[eth-bot]

All Reviewers Have Approved; Performing Automatic Merge...