Update EIP-8142: Various blob encoding-decoding fixes

[Thegaram]

This PR addresses various issues and inconsistencies in the blob encoding/decoding logic in EIP-8142:

• Fix field element encoding. Ethereum interprets blob bytes as big-endian-encoded field elements (see execution-specs, also blob encoding in ethrex and scroll). So chunk_to_blob should set the first byte of each field element to 0, instead of setting the last byte.
• Consistent endianness. Use big-endian encoding for bal_length and txs_length in the 8-byte blob payload header.
• Stricter blob decoding. Cover two error cases in blobs_to_execution_payload_data (array overindexing and malleable trailing data). Though engine_newPayload re-encodes using the canonical zero-padding, so this was not a correctness issue.

[eth-bot]

File EIPS/eip-8142.md

Requires 1 more review from Authors: @frisitano, @jsign, @kevaundray, @nerolation, @soispoke

[frisitano]

Looks good - left a comment inline

[frisitano]

I understand that field elements are represented as big-endian - does that mean that we should have all encodings use the same standard? What's the rationale/decision space here and implications?

[Thegaram]

does that mean that we should have all encodings use the same standard?

No, that's not necessary, this change is optional.

I see value in consistently using big-endian encoding. It is already used for the blob field elements, and for RLP encoding, we might as well use it for these two integers.

I did a quick search in https://github.com/ethereum/execution-specs. It seems that the EL tends to use big-endian in most cases, though there are a few exception.

[frisitano]

Thanks for the explanation - sounds good to me.