Skip to content

Conversation

sorpaas
Copy link
Member

@sorpaas sorpaas commented Jul 1, 2025

The TransactionSignature type was designed to always maintain the invariant for EIP-2, but this wasn't later properly done for EIP-1559, EIP-2930, etc.

odd_y_parity: false,
r: hex!("36b241b061a36a32ab7fe86c7aa9eb592dd59018cd0443adc0903590c16b02b0").into(),
s: hex!("5edcc541b4741c5cc6dd347c5ed9577ef293a62787b4510465fadbfe39ee4094").into(),
signature: eip2930::TransactionSignature::new(
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
signature: eip2930::TransactionSignature::new(
signature: eip1559::TransactionSignature::new(

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nevermind, just saw that it reuses eip2930::TransactionSignature.

Copy link

@RomarQ RomarQ Jul 1, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe it could be in a common module that shares the common types like TransactionSignature, AccessList and TransactionAction, just to avoid confusion?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The idea is to reuse unchanged struct from older hard forks to newer hard forks.

  • We have legacy -> EIP-2930 -> EIP-1559 -> EIP-7702.
  • In legacy, a TransactionSignature is defined. This becomes legacy::TransactionSignature.
  • In EIP-2930, the format of TransactionSignature is changed, so we define a eip2930::TransactionSignature.
  • The format of signature is unchanged in EIP-1559 and EIP-7702, so in eip1559 and eip-7702 mods, we pub use super::eip2930::TransactionSignature.

Copy link

@RomarQ RomarQ left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Just added a small remark

When the signature is invalid, the specification still asks that only
the item is ignored, but not that decoding fails.
@sorpaas sorpaas merged commit 2dd9d1d into master Jul 2, 2025
5 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants