Skip to content

feat: impl Encodable / Decodable for Receipts #1752

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

Merged

Conversation

Rjected
Copy link
Contributor

@Rjected Rjected commented Dec 4, 2024

Motivation

The Deref / DerefMut derives were kind of an antipattern, giving the illusion that Encodable was implemented, when it was only due to deref coercion. Decodable was also not implemented. This is required if we ever want to use the Receipts type in reth.

Solution

This instead this removes the derived derefs, and directly implements the encodable / decodable traits.

PR Checklist

  • Added Tests
  • Added Documentation
  • Breaking changes

@Rjected Rjected force-pushed the impl-encodable-decodable-for-receipts branch from d02f88e to 6538899 Compare December 4, 2024 19:13
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.

this mimics the eth rlpx format, right?

Comment on lines +187 to +201
impl<T: Encodable> Encodable for Receipts<T> {
fn encode(&self, out: &mut dyn BufMut) {
self.receipt_vec.encode(out)
}

fn length(&self) -> usize {
self.receipt_vec.length()
}
}

impl<T: Decodable> Decodable for Receipts<T> {
fn decode(buf: &mut &[u8]) -> alloy_rlp::Result<Self> {
Ok(Self { receipt_vec: Decodable::decode(buf)? })
}
}
Copy link
Member

Choose a reason for hiding this comment

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

aren't those derivable?

Copy link
Contributor Author

@Rjected Rjected Dec 4, 2024

Choose a reason for hiding this comment

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

Yes this should mimic the rlpx format. I'm not sure how we can derive them, because it's a struct and not a newtype, we can't use RlpEncodableWrapper etc. If we derive RlpEncodable, it will insert an additional header which isn't correct.

Copy link
Member

Choose a reason for hiding this comment

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

ah because RlpEncodableWrapper only works with unnamed and can't handle a single field?

@mattsse mattsse merged commit 8a787e4 into alloy-rs:main Dec 5, 2024
26 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