Skip to content
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

fix: make a sensible encoding api #1496

Merged
merged 28 commits into from
Oct 28, 2024
Merged

fix: make a sensible encoding api #1496

merged 28 commits into from
Oct 28, 2024

Conversation

prestwich
Copy link
Member

@prestwich prestwich commented Oct 16, 2024

Spawned from the depths of #1485

Motivation

Fix transaction coding APIs to be usable and clear

  • [Bug] encode_with_signature_fields encodes an invalid transaction when the signature Parity is unexpected #1510 output for encode_with_signature
  • Codebase generally confuses the 2 uses of RLP encoding (tx payload and network format)
  • The docs for encode_with_signature are wrong
  • encode_with_signature produces 2718 output when with_header is false, and RLP in network format when with_header is true. All other encode_ methods produce RLP output in non-network format
  • decode_with_signature is missing entirely
  • EncodableSignature seems to now be redundant as reth migrated to alloy-primitives::Signature

Solution

create a simple API in which encoding and decoding function names specify which format they produce/accept

PR Checklist

  • Added Tests
  • Added Documentation
  • Breaking changes

@prestwich
Copy link
Member Author

prestwich commented Oct 16, 2024

cc @mattsse @klkvr. I'd like feedback on the new API before applying it to the other tx types

Copy link
Member

@mattsse mattsse left a comment

Choose a reason for hiding this comment

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

only looked briefly because rlp gives me headaches

wdyt @Rjected

crates/consensus/src/transaction/rlp.rs Show resolved Hide resolved
@prestwich prestwich marked this pull request as draft October 17, 2024 01:12
@prestwich prestwich marked this pull request as ready for review October 17, 2024 15:53
@prestwich
Copy link
Member Author

prestwich commented Oct 17, 2024

this is rebased and ready for review

The main thing it does is make an INTERNAL trait RlpEcdsaTx that captures common encoding behavior across existing tx types. This trait is not intended to cover all future behavior, just to unify codepaths across the 5 current tx types, and make sure that encoding schemes are correct, simple to use, and impossible to confuse

@prestwich prestwich self-assigned this Oct 17, 2024
@prestwich
Copy link
Member Author

now closes #1510 as well

@prestwich
Copy link
Member Author

this has been rebased onto main after #1528 and is ready for review. Note that 1528 included a version of this API in the blob sidecar rlp impl. I'm also prepping a followup PR to move other RLP impls to this style

@prestwich
Copy link
Member Author

Could we get a patch release of alloy-rlp? alloy-rs/rlp#28 would let us reduce code complexity

@onbjerg
Copy link
Member

onbjerg commented Oct 23, 2024

@prestwich alloy-rlp 0.3.9 is now released with alloy-rs/rlp#28

@prestwich
Copy link
Member Author

@prestwich alloy-rlp 0.3.9 is now released with alloy-rs/rlp#28

Thank you, this PR is updated, rebased, and ready for review 👍

Copy link
Member

@mattsse mattsse left a comment

Choose a reason for hiding this comment

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

cool,
I think this a lot cleaner now.

would like one more sanity rlp review from @klkvr

Copy link
Contributor

@Rjected Rjected left a comment

Choose a reason for hiding this comment

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

I really like the API, one concern about the header type when this is implemented on legacy txs - I'm thinking legacy txs should probably override all of the default impls for network_ fns

I think we should also specify the type of RLP header when possible (list v string)

crates/consensus/src/transaction/rlp.rs Outdated Show resolved Hide resolved
crates/consensus/src/transaction/rlp.rs Outdated Show resolved Hide resolved
crates/consensus/src/transaction/rlp.rs Outdated Show resolved Hide resolved
crates/consensus/src/transaction/legacy.rs Show resolved Hide resolved
crates/consensus/src/transaction/eip2930.rs Outdated Show resolved Hide resolved
crates/consensus/src/transaction/eip4844.rs Show resolved Hide resolved
crates/consensus/src/transaction/eip4844.rs Outdated Show resolved Hide resolved
crates/consensus/src/transaction/eip4844.rs Outdated Show resolved Hide resolved
@prestwich
Copy link
Member Author

fixes up and ready for re-review

Copy link
Member

@klkvr klkvr 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 a nit

crates/consensus/src/transaction/eip4844.rs Outdated Show resolved Hide resolved
@mattsse mattsse merged commit f34a2dd into main Oct 28, 2024
26 checks passed
@mattsse mattsse deleted the prestwich/improve-enc-api branch October 28, 2024 13:23
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
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.

[Bug] encode_with_signature_fields encodes an invalid transaction when the signature Parity is unexpected
5 participants