Tracking: Improve reth-trie-db state traits

[Rjected]

Currently we have the following for the DatabaseProof, DatabaseStateRoot, etc. traits:

reth/crates/trie/db/src/proof.rs

Lines 17 to 36 in fe53ec5

	/// Extends [`Proof`] with operations specific for working with a database transaction.
	pub trait DatabaseProof<'a, TX> {
	/// Create a new [Proof] from database transaction.
	fn from_tx(tx: &'a TX) -> Self;
	/// Generates the state proof for target account based on [`TrieInput`].
	fn overlay_account_proof(
	tx: &'a TX,
	input: TrieInput,
	address: Address,
	slots: &[B256],
	) -> Result<AccountProof, StateProofError>;
	/// Generates the state [`MultiProof`] for target hashed account and storage keys.
	fn overlay_multiproof(
	tx: &'a TX,
	input: TrieInput,
	targets: HashMap<B256, HashSet<B256>>,
	) -> Result<MultiProof, StateProofError>;
	}

This can likely be rewritten as:

pub trait StatefulProof {
    /// Generates the state proof for target account based on [`TrieInput`].
    fn overlay_account_proof(
        &self,
        input: TrieInput,
        address: Address,
        slots: &[B256],
    ) -> Result<AccountProof, StateProofError>;

    /// Generates the state [`MultiProof`] for target hashed account and storage keys.
    fn overlay_multiproof(
        &self,
        input: TrieInput,
        targets: HashMap<B256, HashSet<B256>>,
    ) -> Result<MultiProof, StateProofError>;
}

Where the caller can have a from_tx method on the struct itself, instead of having one on the trait. The trait implementer is responsible for owning or managing a tx / tx ref.

Tasks

Beta Give feedback

1. Improve DatabaseProof trait
2. Improve DatabaseStorageProof trait
3. Improve DatabaseStateRoot trait
4. Improve DatabaseStorageRoot trait
5. Improve DatabaseTrieWitness trait

[frisitano]

One thing to be mindful of here is that the Database* traits may need to be modified / extended as part of our ambitions with #11830 so it would be wise to take that into account when scheduling/planning this work. I think it makes sense to do this refactor after we complete #11830.

[Rjected]

One thing to be mindful of here is that the Database* traits may need to be modified / extended as part of our ambitions with #11830 so it would be wise to take that into account when scheduling/planning this work. I think it makes sense to do this refactor after we complete #11830.

Yep agreed, just noting this here to make sure we remember to do it after

[github-actions]

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