As part of `newPayload` block hash verification, the `transactionsRoot`
is computed by the EL. Because Merkle-Patricia Tries cannot contain `[]`
entries, MPT implementations typically treat setting a key to `[]` as
deleting the entry for the key. This means that if a CL receives a block
with `transactions` containing one or more zero-length transactions,
that such transactions will effectively be skipped when computing the
`transactionsRoot`. Note that `transactions` are opaque to the CL and
zero-length transactions are not filtered out before `newPayload`.
```python
# https://eips.ethereum.org/EIPS/eip-2718
def compute_trie_root_from_indexed_data(data):
"""
Computes the root hash of `patriciaTrie(rlp(Index) => Data)` for a data array.
"""
t = HexaryTrie(db={})
for i, obj in enumerate(data):
k = encode(i, big_endian_int)
t.set(k, obj) # Implicitly skipped if `obj == b''` (invalid RLP)
return t.root_hash
```
In any case, the `blockHash` validation may still succeed, resulting in
a potential `SYNCING/ACCEPTED` result to `newPayload` by spec.
Note, however, that there is an effective hash collision if a payload is
modified by appending one or more zero-length transactions to the end of
`transactions` list: In the trivial case, a block with zero transactions
has the same `transactionsRoot` (and `blockHash`) as one of a block with
one `[]` transaction (as that one is skipped).
This means that the same `blockHash` can refer to a valid block (without
extra `[]` transactions added), but also can refer to an invalid block.
Because `forkchoiceUpdated` refers to blocks by `blockHash`, outcome may
be nondeterministic and implementation dependent. If `forkchoiceUpdated`
deems the `blockHash` to refer to a `VALID` object (obtained from a src
that does not have the extra `[]` transactions, e.g., devp2p), then this
could result in honest attestations to a CL beacon block with invalid
`[]` transactions in its `ExecutionPayload`, risking finalizing it.
The problem can be avoided by returning `INVALID` in `newPayload` if
there are any zero-length `transactions` entries, preventing optimistic
import of such blocks by the CL.
Currently, documentation does not state what determines the `ForkDigest`
for `BlobSidecar`. It makes most sense to use the corresponding slot as
that one determines the `ForkDigest` of the corresponding beacon block.
Furthermore, add "and later" remarks so that `ELECTRA_FORK_VERSION` is
also associated with the `deneb.BlobSidecar` type.
This is in line with how `light-client/p2p-interface.md` is done.
Electra introduces two changes that affect light client data handling:
1. The `ExecutionPayloadHeader` is extended with new fields.
This is handled similarly as before with the Deneb fork.
2. The `BeaconState` generalized indices change due to lack of EIP-6493.
This is handled by making the generalized index be fork dependent via
a helper function that computes it dynamically. Furthermore, the case
where pre-Electra light client data is consumed by an Electra based
`LightClientStore` requires normalizing the shorter proof of the
pre-Electra data to fit into the Electra data structure by prepending
a zero hash.
