refactor: use simple boolean for parity in signature #776
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This was referenced Oct 20, 2024
mattsse
reviewed
Oct 24, 2024
There was a problem hiding this comment.
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?
Comment on lines
90
to
91
| /// 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.
this needs more context on the parity decoding closure
klkvr
force-pushed
the
klkvr/signature-parity-bool
branch
from
6c1f0e0 to
85b4ab3
Compare
klkvr
force-pushed
the
klkvr/signature-parity-bool
branch
from
85b4ab3 to
5b01993
Compare
|
Extracted new signature type to |
2 tasks
3 tasks
This was referenced Oct 30, 2024
github-merge-queue bot
pushed a commit
to alloy-rs/op-alloy
that referenced
this pull request
Nov 6, 2024
<!-- Thank you for your Pull Request. Please provide a description above and review the requirements below. Bug fixes and new features should include tests. Contributors guide: https://github.com/alloy-rs/core/blob/main/CONTRIBUTING.md The contributors guide includes instructions for running rustfmt and building the documentation. --> <!-- ** Please select "Allow edits from maintainers" in the PR Options ** --> ## Motivation Bumps alloy, alloy-core and alloy-eip7702. Code changes: - alloy-rs/alloy#1496 changed transaction encoding API, encoding functions are now prefixed with `rlp`,`eip2718` or `network`. I've updated `TxDeposit` to have methods following this pattern - alloy-rs/core#776 updated signature type to avoid using `Parity` generic and instead just keep a boolean for parity byte. The motivation is to have more correctness in encoding and data structure. Before that it was possible to construct `Signed<TxLegacy>` where transaction chain_id is `Some`, but the parity would not follow EIP-155. This required a few changes to `SpanBatchTransactions` type: - `encode_y_parity_bits` and `encode_tx_sigs_rs` are merged into single `encode_tx_sigs` which firstly encodes parity bits and then `rs` values. Same was done for decoding methods - `recover_v` method is removed. instead, we now pass the `is_protected` flag down to `SpanBatchLegacyTransactionData` and only set `chain_id` to `Some` when `is_protected` is true Blocked by minor releases for alloy, core and revm ## Solution <!-- Summarize the solution and provide any necessary context needed to understand the code change. --> ## PR Checklist - [ ] Added Tests - [ ] Added Documentation - [ ] Breaking changes
ZelionD
pushed a commit
to ZelionD/core
that referenced
this pull request
Nov 11, 2024
* wip * fix doc * fmt
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Motivation
Right now we use
Parityenum 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 changesSignatureto 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_vrsnow accepts encodablevvalue as a parameter, allowing callers to provide arbitrary encoding for paritydecode_rlp_vrsnow accepts adecode_parityclosure 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