use alloy transaction types

[mattsse]

the core tx types are quivalent to alloy's:

reth/crates/primitives/src/transaction/eip1559.rs

Line 13 in 67f6176

pub struct TxEip1559 {

the only difference is the codec impl

reth/crates/primitives/src/transaction/eip1559.rs

Line 11 in 67f6176

#[main_codec]

we can implement codec by doing the same as for

reth/crates/storage/codecs/src/alloy/withdrawal.rs

Lines 6 to 11 in 67f6176

	/// Withdrawal acts as bridge which simplifies Compact implementation for AlloyWithdrawal.
	///
	/// Notice: Make sure this struct is 1:1 with `alloy_eips::eip4895::Withdrawal`
	#[main_codec]
	#[derive(Debug, Clone, PartialEq, Eq, Default)]
	struct Withdrawal {

TODO

• feat: migrate to alloy TxLegacy #9593
• feat: migrate to alloy TxEip1559 #10262
• eip2930: use alloy TxEip2930 #10623
• eip4844: use alloy TxEip4844 #10624
• eip7702: use alloy TxEip7702 #10617
• optimism deposit

This should be done in separate prs and involves

• move existing struct def to https://github.com/paradigmxyz/reth/blob/67f617646ce4b68a5096239238aa9209636ff500/crates/storage/codecs/src/alloy/transaction.rs#L1-L1 impl codec for alloy types via into/from
• phase out primitive transaction defs

there are likely missing/renamed functions in alloy, so we need to surface those and add to alloy if appropriate

[leruaa]

I can take this on.

[mattsse]

cool, this will likely be a bit painful, see #9485 for ref
we likely need to do some work on rlp for this

[leruaa]

@mattsse Looking into this, it seems I will have to convert from reth Signature to alloy one at many places. Do you think I should work on migrating reth Signature to alloy as a prerequisite to this issue, or converting is ok for now?

For instance in the code below, I would like to call encoded_len_with_signature() on alloy TxLegacy that takes an alloy signature as a parameter:

reth/crates/primitives/src/transaction/pooled.rs

Lines 303 to 306 in cbe9a7c

	Self::Legacy { transaction, signature, .. } => {
	// method computes the payload len with a RLP header
	transaction.payload_len_with_signature(signature)
	}

[emhane]

is the end goal to replace reth_primitives::PooledTransactionsElement with alloy_consensus::TypedTransaction ? if so we'd be more efficient if we tackle this by making types that use reth_primitives::PooledTransactionElement generic over a type T: alloy_consensus::Transaction. do we have a complete list of types we want to replace with its alloy equivalent?

[emhane]

T: alloy_consensus::Transaction + <the codec trait>, and impl the codec trait for alloy types where we define the codec trait

[github-actions]

This issue is stale because it has been open for 21 days with no activity.

[hannahredler]

I am applying to this issue via OnlyDust platform.

My background and how it can be leveraged

Hello! I am a software engineer with approx 8 years experience in Python, Java and Typescript. I have recently been learning rust and studying the core program with the Privacy and Scaling Explorations team to learn more about applied ZK.

Whilst new to rust, I have a lot of experience in writing maintainable, tested and clean code and know I can contribute positively to your code base!

How I plan on tackling this issue

Since it seems like a fairly straightforward migration, I would check the examples that have been given and ensure that I replicate the methodology.

[klkvr]

@tcoratger thank you for working on all PRs from here! would you like to work on TxDeposit migration to close this?

[tcoratger]

@tcoratger thank you for working on all PRs from here! would you like to work on TxDeposit migration to close this?

Mhh not sure we have all the required methods in alloy TxDeposit no? like stuffs to do encoded_len_with_signature or payload_len_for_signature as SignableTransaction is not implemented for TxDeposit at the moment or did I miss something? (I'm not familiar with the op-alloy codebase so maybe I'm missing something here)

[klkvr]

@tcoratger thank you for working on all PRs from here! would you like to work on TxDeposit migration to close this?

Mhh not sure we have all the required methods in alloy TxDeposit no? like stuffs to do encoded_len_with_signature or payload_len_for_signature as SignableTransaction is not implemented for TxDeposit at the moment or did I miss something? (I'm not familiar with the op-alloy codebase so maybe I'm missing something here)

deposit transactions can't be signed, so we won't need those

[tcoratger]

@tcoratger thank you for working on all PRs from here! would you like to work on TxDeposit migration to close this?

Mhh not sure we have all the required methods in alloy TxDeposit no? like stuffs to do encoded_len_with_signature or payload_len_for_signature as SignableTransaction is not implemented for TxDeposit at the moment or did I miss something? (I'm not familiar with the op-alloy codebase so maybe I'm missing something here)

deposit transactions can't be signed, so we won't need those

And we need to merge this right? alloy-rs/op-alloy#68

[klkvr]

@tcoratger thank you for working on all PRs from here! would you like to work on TxDeposit migration to close this?

Mhh not sure we have all the required methods in alloy TxDeposit no? like stuffs to do encoded_len_with_signature or payload_len_for_signature as SignableTransaction is not implemented for TxDeposit at the moment or did I miss something? (I'm not familiar with the op-alloy codebase so maybe I'm missing something here)

deposit transactions can't be signed, so we won't need those

And we need to merge this right? alloy-rs/op-alloy#68

yep

[tcoratger]

@klkvr Also previously we had a method like:

pub(crate) fn payload_len_without_header(&self) -> usize {
    let payload_length = self.fields_len();
    // 'transaction type byte length' + 'header length' + 'payload length'
    1 + length_of_length(payload_length) + payload_length
}

which calculates basically 'transaction type byte length' + 'header length' + 'payload length' but in op alloy we only have:

fn length(&self) -> usize {
    let payload_length = self.fields_len();
    Header { list: true, payload_length }.length() + payload_length
}

but we lack the 'transaction type byte length' so this is also a method to add in op alloy right?

[klkvr]

yeah, I think we can add encoded_len(&self, with_header: bool) and encode(&self, &mut dyn BufMut, with_header: bool)

[hai-rise]

Thank you for the awesome work!

I wonder if we have the same plan for Header types? For instance, these two are very similar:

• reth/crates/primitives-traits/src/header/mod.rs

  Lines 26 to 102 in d659cd3

  	pub struct Header {
  	/// The Keccak 256-bit hash of the parent
  	/// block’s header, in its entirety; formally Hp.
  	pub parent_hash: B256,
  	/// The Keccak 256-bit hash of the ommers list portion of this block; formally Ho.
  	pub ommers_hash: B256,
  	/// The 160-bit address to which all fees collected from the successful mining of this block
  	/// be transferred; formally Hc.
  	pub beneficiary: Address,
  	/// The Keccak 256-bit hash of the root node of the state trie, after all transactions are
  	/// executed and finalisations applied; formally Hr.
  	pub state_root: B256,
  	/// The Keccak 256-bit hash of the root node of the trie structure populated with each
  	/// transaction in the transactions list portion of the block; formally Ht.
  	pub transactions_root: B256,
  	/// The Keccak 256-bit hash of the root node of the trie structure populated with the receipts
  	/// of each transaction in the transactions list portion of the block; formally He.
  	pub receipts_root: B256,
  	/// The Keccak 256-bit hash of the withdrawals list portion of this block.
  	///
  	/// See [EIP-4895](https://eips.ethereum.org/EIPS/eip-4895).
  	pub withdrawals_root: Option<B256>,
  	/// The Bloom filter composed from indexable information (logger address and log topics)
  	/// contained in each log entry from the receipt of each transaction in the transactions list;
  	/// formally Hb.
  	pub logs_bloom: Bloom,
  	/// A scalar value corresponding to the difficulty level of this block. This can be calculated
  	/// from the previous block’s difficulty level and the timestamp; formally Hd.
  	pub difficulty: U256,
  	/// A scalar value equal to the number of ancestor blocks. The genesis block has a number of
  	/// zero; formally Hi.
  	pub number: BlockNumber,
  	/// A scalar value equal to the current limit of gas expenditure per block; formally Hl.
  	pub gas_limit: u64,
  	/// A scalar value equal to the total gas used in transactions in this block; formally Hg.
  	pub gas_used: u64,
  	/// A scalar value equal to the reasonable output of Unix’s time() at this block’s inception;
  	/// formally Hs.
  	pub timestamp: u64,
  	/// A 256-bit hash which, combined with the
  	/// nonce, proves that a sufficient amount of computation has been carried out on this block;
  	/// formally Hm.
  	pub mix_hash: B256,
  	/// A 64-bit value which, combined with the mixhash, proves that a sufficient amount of
  	/// computation has been carried out on this block; formally Hn.
  	pub nonce: u64,
  	/// A scalar representing EIP1559 base fee which can move up or down each block according
  	/// to a formula which is a function of gas used in parent block and gas target
  	/// (block gas limit divided by elasticity multiplier) of parent block.
  	/// The algorithm results in the base fee per gas increasing when blocks are
  	/// above the gas target, and decreasing when blocks are below the gas target. The base fee per
  	/// gas is burned.
  	pub base_fee_per_gas: Option<u64>,
  	/// The total amount of blob gas consumed by the transactions within the block, added in
  	/// EIP-4844.
  	pub blob_gas_used: Option<u64>,
  	/// A running total of blob gas consumed in excess of the target, prior to the block. Blocks
  	/// with above-target blob gas consumption increase this value, blocks with below-target blob
  	/// gas consumption decrease it (bounded at 0). This was added in EIP-4844.
  	pub excess_blob_gas: Option<u64>,
  	/// The hash of the parent beacon block's root is included in execution blocks, as proposed by
  	/// EIP-4788.
  	///
  	/// This enables trust-minimized access to consensus state, supporting staking pools, bridges,
  	/// and more.
  	///
  	/// The beacon roots contract handles root storage, enhancing Ethereum's functionalities.
  	pub parent_beacon_block_root: Option<B256>,
  	/// The Keccak 256-bit hash of the root node of the trie structure populated with each
  	/// [EIP-7685] request in the block body.
  	///
  	/// [EIP-7685]: https://eips.ethereum.org/EIPS/eip-7685
  	pub requests_root: Option<B256>,
  	/// An arbitrary byte array containing data relevant to this block. This must be 32 bytes or
  	/// fewer; formally Hx.
  	pub extra_data: Bytes,
  	}

• https://github.com/alloy-rs/alloy/blob/68065370137088b414f4796e2b3b018e36031e01/crates/consensus/src/header.rs#L28-L134

[mattsse]

yes, will track

[tcoratger]

yes, will track

@mattsse If you open an issue please tag me. If I've time, will have a look

[mattsse]

#10687