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

feat(op-consensus): op-alloy-consensus #4

Closed
wants to merge 10 commits into from

Conversation

clabby
Copy link
Collaborator

@clabby clabby commented Apr 13, 2024

Overview

Adds a periphery crate for alloy-consensus, op-alloy-consensus, that contains OP-specific types for the TxEnvelope (to include TxDeposit) as well as the Receipt + ReceiptEnvelope. For all unmodified types, such as the Header, consumers should use alloy-consensus.

Note

Blocked by alloy-rs/alloy#529, will update the alloy dependency after this has been merged.

@clabby clabby marked this pull request as draft April 13, 2024 02:26
@clabby clabby force-pushed the refcell/consensus-port branch 4 times, most recently from e6f9bd5 to 3c16cb7 Compare April 13, 2024 02:39
@clabby clabby marked this pull request as ready for review April 13, 2024 02:47
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.

great start,

we should reuse as much as possible from alloy-consensus

@clabby
Copy link
Collaborator Author

clabby commented Apr 13, 2024

great start,

we should reuse as much as possible from alloy-consensus

Thanks - this should be the minimal amount we need to port, without changing the upstream API of alloy-consensus. We can re-use TxLegacy, TxEip2930, TxEip1559, and TxEip4844, but would need to expose several of their private functions in alloy-consensus:

  • fields_len
  • decode_signed_fields
  • encode_with_signature

Update: alloy-rs/alloy#529

@clabby clabby force-pushed the refcell/consensus-port branch 3 times, most recently from 2fb8518 to fbe2cdd Compare April 13, 2024 20:28
@clabby clabby force-pushed the refcell/consensus-port branch 4 times, most recently from b15ea35 to aa904b4 Compare April 13, 2024 21:00
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 is great,

only have two questions re receipt stuff

crates/op-consensus/src/receipt/mod.rs Outdated Show resolved Hide resolved
///
/// [deposit]: https://specs.optimism.io/protocol/deposits.html
#[cfg_attr(feature = "serde", serde(rename = "0x7E", alias = "0x7E"))]
Deposit(OpReceiptWithBloom<T>),
Copy link
Member

Choose a reason for hiding this comment

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

hmm, only this variant needs the Op specific receipt type, right?

the others could reuse the the alloy-consensus one?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Yeah, only this variant needs it. Decided to use all OpReceiptWithBlooms to avoid type conversion within as_receipt_with_bloom + as_receipt.

Technically, all of the receipts within OP consensus do use this format, though the extra deposit_nonce + deposit_receipt_version fields are omitted from the RLP if they don't exist. Could reuse the ReceiptWithBloom<T> type for others -- would you rather have the type conversions?

#[cfg_attr(feature = "serde", derive(serde::Serialize, serde::Deserialize))]
#[cfg_attr(feature = "serde", serde(tag = "type"))]
#[non_exhaustive]
pub enum OpReceiptEnvelope<T = Log> {
Copy link
Member

Choose a reason for hiding this comment

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

PTAL at the review here w.r.t type duplication between alloy upstream and op-alloy #2

it should be possible to wrap the internal receipt type, I would think? maybe not

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.

hmm, I'd prefer if we could reuse the alloy-consensus receipt envelope type or even the entire variant and then only add an additional deposit variant

adding pub struct OpReceipt<T = Log> { doesn't make much sense to me

#[cfg_attr(feature = "serde", derive(serde::Serialize, serde::Deserialize))]
#[cfg_attr(feature = "serde", serde(tag = "type"))]
#[non_exhaustive]
pub enum OpReceiptEnvelope<T = Log> {
Copy link
Member

Choose a reason for hiding this comment

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

I think we should just reuse the regular alloy consensus types here

#[derive(Clone, Debug, PartialEq, Eq, Default)]
#[cfg_attr(feature = "serde", derive(serde::Serialize, serde::Deserialize))]
#[cfg_attr(feature = "serde", serde(rename_all = "camelCase"))]
pub struct OpReceipt<T = Log> {
Copy link
Member

Choose a reason for hiding this comment

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

this should be OpDepositReceipt
which wraps the alloy-consensus receipt and adds extra fields for deposit

@prestwich
Copy link
Member

adds a little work for you, but it's all easy:
alloy-rs/alloy#477

@refcell refcell changed the base branch from main to refcell/consensus-port May 20, 2024 17:50
@refcell refcell changed the base branch from refcell/consensus-port to main May 20, 2024 17:51
@mattsse
Copy link
Member

mattsse commented Jun 12, 2024

superseded by #8

@mattsse mattsse closed this Jun 12, 2024
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.

5 participants