Synchronously check all transactions
to have non-zero length
#3885
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
As part of
newPayload
block hash verification, thetransactionsRoot
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 withtransactions
containing one or more zero-length transactions, that such transactions will effectively be skipped when computing thetransactionsRoot
. Note thattransactions
are opaque to the CL and zero-length transactions are not filtered out beforenewPayload
.In any case, the
blockHash
validation may still succeed, resulting in a potentialSYNCING/ACCEPTED
result tonewPayload
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 sametransactionsRoot
(andblockHash
) 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. BecauseforkchoiceUpdated
refers to blocks byblockHash
, outcome may be nondeterministic and implementation dependent. IfforkchoiceUpdated
deems theblockHash
to refer to aVALID
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 itsExecutionPayload
, risking finalizing it.The problem can be avoided by returning
INVALID
innewPayload
if there are any zero-lengthtransactions
entries, preventing optimistic import of such blocks by the CL.