-
Notifications
You must be signed in to change notification settings - Fork 148
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
refactor: use simple boolean for parity in signature #776
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I personally much prefer this over the enum approach.
another option would be just an integer but given that we need parity as bool, this makes more sense.
I wonder if we should remove the rlp trait impls for this entirely to avoid footguns, because en/decoding is tx specific?
regarding rollout, this will require a few changes downstream, so I wonder if we should instead introduce this a new type first, transition everything, then remove the old Signature type?
/// Decode an RLP-encoded VRS signature. | ||
pub fn decode_rlp_vrs(buf: &mut &[u8]) -> Result<Self, alloy_rlp::Error> { | ||
pub fn decode_rlp_vrs( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this needs more context on the parity decoding closure
6c1f0e0
to
85b4ab3
Compare
85b4ab3
to
5b01993
Compare
Extracted new signature type to |
Motivation
Right now we use
Parity
enum for parity value in signature:core/crates/primitives/src/signature/parity.rs
Lines 10 to 17 in 9c53778
Because of it containing EIP-155 related variants it basically captures transaction-related logic which does not belong to primitives and results in inconsistencies and need for dynamic checks. e.g alloy-rs/alloy#1305 #705 alloy-rs/alloy#1510
Primitive signature representation in context of Ethereum is
(U256,U256,bool)
, this PR changesSignature
to have this structure and leaving specialized parity encoding to types holding signatures and having enough context to perform correct encoding.At this point in any context we know how parity should be encoded and storing a simple boolean is enough to figure this out. i.e legacy transaction knows its chain_id and can adjust parity accordingly.
API changes in this PR:
"yParity": "0x{0,1}"
write_rlp_vrs
now accepts encodablev
value as a parameter, allowing callers to provide arbitrary encoding for paritydecode_rlp_vrs
now accepts adecode_parity
closure allowing callers to provide arbitrary decoding for parity, possibly capturing additional context (e.g legacy chain_id)This PR is accompanied with PR in alloy to demonstrate/discuss needed API changes alloy-rs/alloy#1540 alloy-rs/eips#12
PR Checklist