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

Nethermind as rbuilder state provider #1

Open
4 of 6 tasks
mralj opened this issue Dec 19, 2024 · 4 comments
Open
4 of 6 tasks

Nethermind as rbuilder state provider #1

mralj opened this issue Dec 19, 2024 · 4 comments
Assignees

Comments

@mralj
Copy link
Collaborator

mralj commented Dec 19, 2024

Goal

Nethermind client should work as a state provider for rbuilder.
Firstly, the state will be provided via IPC RPC, and then we'll optimize (e.g., Rust <> C# FFI).

TODOs

Here is the list of the Traits we'll have to implement:

Column Already supported by NM? indicates that the:

  1. RPC call already exists in the NM client
  2. NM client supports both arg and return types (they are either "the same" or there is a small amount of work to be done to support the requirements fully)

If the args or return data needs to be adapted from/to NM-specific types, I propose adapters to be implemented on the rbuilder side where possible since this is specific to rbuilder and not the NM client.

StateProviderFactory

Trait Done? Already supported by NM?
latest
history_by_block_hash
last_block_number

StateProvider

Trait Done? Already supported by NM?
storage
bytecode_by_hash
block_hash
basic_account

HeaderProvider

Trait Done? Already supported by NM?
header
@mralj
Copy link
Collaborator Author

mralj commented Dec 27, 2024

@asdacap, can you please look into the following (by look into, I mean either let me know RPC methods if they already exist or implement new ones)

1. bytecode_by_hash

I'm not sure what the RPC call is for this one (or if NM supports it), here is how I implemented it (following Ferran's PR), but I don't think this is the correct implementation:

fn bytecode_by_hash(&self, code_hash: B256) -> ProviderResult<Option<Bytecode>> {
        let address = Address::from_word(code_hash);
        let block_id = BlockId::hash(self.hash);

        let res = futures::executor::block_on(async {
            self.provider.get_code_at(address).block_id(block_id).await
        })
        .unwrap();

        Ok(Some(Bytecode::new_raw(res)))
    }

This doesn't look correct because the get_code_at RPC call expects Address, and the bytecode_by_hash trait provides code_hash (the hash of the code we are fetching).
So my questions are:

  1. Is this code indeed incorrect? If it is incorrect,
  2. Does NM already support this call out of the box, and if not, can it be implemented on the NM side?

2. calculate_state_root

We'll need an RPC call to calculate the state root (if one doesn't already exist) on the NM side. The rbuilder provides:

  1. parent_hash (so we can get the previous state_root by reading the parent block via the provided hash)
  2. ExecutionOutcome which has BundleState containing the state diff (from BundleState struct I think we only need the state and the contracts.

If I'm not mistaken, this should be enough to calculate state_root. I
If NM doesn't already have an RPC call which supports this, can you implement one and let me know the API spec?

@asdacap
Copy link

asdacap commented Dec 29, 2024

So for 1, I think it probably mean that you'll need to get the account for the address first, which contains the codehash.
For 2, its not available. I'll think of an API spec.

@mralj
Copy link
Collaborator Author

mralj commented Dec 30, 2024

So for 1, I think it probably mean that you'll need to get the account for the address first, which contains the codehash.

Yeah, but the issue is that the bytecode_by_hash trait doesn't have (access to) the address, it only receives the code_hash.
I'd have to somehow find the account by code_hash, is this already possible in NM via RPC? If not we'll have to add support for this as well.

@asdacap
Copy link

asdacap commented Dec 31, 2024

Ow, thats fine. I thought it only pass in Address as some kind of optimization. We can get code by hash directly.

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

No branches or pull requests

2 participants