fix: use correct encoding for L1 data fee of EIP2718 transactions #793
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.
1. Purpose or design rationale of this PR
EIP2718 defines the byte encoding as
Type || Payload
, butEncodeRLP
returns an actual RLP array, i.e. it prepends the marshaled result with one or more bytes. We should useMarshalBinary
instead. Note: The behavior ofEncodeRLP
andMarshalBinary
is identical for legacy transactions, so this is not a breaking change.This PR also adds an upper bound on
L1DataFee
to ensure these values don't overflow in the tracing/circuit code. Technically, this is a breaking change, but in practice such high data fee values never occur on Scroll.2. PR title
Your PR title must follow conventional commits (as we are doing squash merge for each PR), so it must start with one of the following types:
3. Deployment tag versioning
Has the version in
params/version.go
been updated?4. Breaking change label
Does this PR have the
breaking-change
label?