Implement eth_simulateV1

[mattsse]

Describe the feature

ref ethereum/execution-apis#484

this should be similar to eth_callMany

reth/crates/rpc/rpc/src/eth/api/call.rs

Lines 81 to 83 in 79d505a

	/// Simulate arbitrary number of transactions at an arbitrary blockchain index, with the
	/// optionality of state overrides
	pub async fn call_many(

and/or trace_callMany

reth/crates/rpc/rpc/src/trace.rs

Lines 127 to 131 in 79d505a

	/// Performs multiple call traces on top of the same block. i.e. transaction n will be executed
	/// on top of a pending block with all n-1 transactions applied (traced) first.
	///
	/// Note: Allows tracing dependent transactions, hence all transactions are traced in sequence
	pub async fn trace_call_many(

Additional context

No response

[dhruvmalik007]

Hey, I am interested to try my luck creating PR on this issue . I wanted to understand various things :

• in terms of the specification regarding the transaction batching and merging the arbitrary blocks : do we need to maintain the sliding window in order to manage the state of the n blocks which are parsed .

• also the use of the ExEx executors for composing the transactions as the offchain hooks is required in this case ?

Thanks

[mattsse]

great!

this doesn't require any offchain components, I think we can start with type bindings for the endpoint, then the trait function and then try to implement the described logic.
the pr has a few test cases, we can use the objects to generate bindings: https://transform.tools/json-to-rust-serde

[rupam-04]

great!

this doesn't require any offchain components, I think we can start with type bindings for the endpoint, then the trait function and then try to implement the described logic. the pr has a few test cases, we can use the objects to generate bindings: https://transform.tools/json-to-rust-serde

So do we end up with the following somewhere?

use serde_derive::Deserialize;
use serde_derive::Serialize;

#[derive(Default, Debug, Clone, PartialEq, Serialize, Deserialize)]
#[serde(rename_all = "camelCase")]
pub struct Root {
    pub jsonrpc: String,
    pub id: i64,
    pub method: String,
    pub params: (Params, String),
}

#[derive(Default, Debug, Clone, PartialEq, Serialize, Deserialize)]
#[serde(rename_all = "camelCase")]
pub struct Params {
    pub block_state_calls: Vec<BlockStateCall>,
    pub trace_transfers: bool,
}

#[derive(Default, Debug, Clone, PartialEq, Serialize, Deserialize)]
#[serde(rename_all = "camelCase")]
pub struct BlockStateCall {
    pub state_overrides: StateOverrides,
    pub calls: Vec<Call>,
}

#[derive(Default, Debug, Clone, PartialEq, Serialize, Deserialize)]
#[serde(rename_all = "camelCase")]
pub struct StateOverrides {
    #[serde(rename = "0xc000000000000000000000000000000000000000")]
    pub n0xc000000000000000000000000000000000000000: n0xc000000000000000000000000000000000000000,
}

#[derive(Default, Debug, Clone, PartialEq, Serialize, Deserialize)]
#[serde(rename_all = "camelCase")]
pub struct n0xc000000000000000000000000000000000000000 {
    pub balance: String,
}

#[derive(Default, Debug, Clone, PartialEq, Serialize, Deserialize)]
#[serde(rename_all = "camelCase")]
pub struct Call {
    pub from: String,
    pub to: String,
    pub value: String,
}

[dhruvmalik007]

Apologies for delay as I had issues running reth on limited specs laptop and thanks @rupam-04 for reaching out.

This is a correct description of traits although what I also added is to develop the traits while taking also the pre implemented types (i.e reth_trie::StateRoot , so as to have consistent API ). if possible we can have a joint PR for this one and I will work on the side of writing the structures for the parameters along with the API method.

[rupam-04]

Apologies for delay and thanks @rupam-04 for reaching out.

This is a correct description of traits although what I also added is to develop the traits while taking also the pre implemented types (i.e reth_trie::StateRoot , so as to have consistent API ). if possible we can have a joint PR for this one and I will work on the side of writing the structures for the parameters along with the API method.

feel free to continue your work on this, I just subscribed to this issue as it looked interesting to me. I am looking forward to how you implement the whole thing.

[KillariDev]

hey, If you are interested in joining eth_simulatev1:s implementers call, we have a meeting every Monday. You can find the meeting in the Ethereum Protocol Calls calendar

[dhruvmalik007]

Thanks @KillariDev I will be there to resolve my queries.