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: implement eth_coinbase/anvil_setCoinbase API endpoints #452

Open
itegulov opened this issue Nov 29, 2024 · 2 comments
Open

feat: implement eth_coinbase/anvil_setCoinbase API endpoints #452

itegulov opened this issue Nov 29, 2024 · 2 comments

Comments

@itegulov
Copy link
Contributor

Two methods to get/set coinbase (aka author/beneficiary/miner):

#[rpc(name = "anvil_setCoinbase")]
fn set_coinbase(&self, address: Address) -> RpcResult<()>;

#[rpc(name = "eth_coinbase")]
fn coinbase(&self) -> RpcResult<Address>;

I feel like this is of very limited usefulness due to the following reasons:

  1. The handler for eth_coinbase is usually disabled for base ETH. I tried 15 different providers and only one of them returned 0x00..00, all others responded with either "unimplemented" or "etherbase must be explicitly specified" (Geth default when --etherbase param is missing).
  2. There is a good reason for the above: coinbase is a consensus layer thing now and it does not make sense for it to be present on the execution layer.
  3. Neither reth nor anvil support eth_coinbase (weirdly enough latter supports anvil_setCoinbase, maybe to manually replicate EVM executions that depend on COINBASE opcode?)

At the same time cost of "faking" support for it is negligible.

@itegulov
Copy link
Contributor Author

@dutterbutter @popzxc What do you guys think would make the most amount of sense here? I am leaning toward adding a very simple implementation (Arc<RwLock<Address>> that is only used in these two methods) and printing something in the logs about coinbase having no impact on anything in ZKsync.

Also fine with marking them as intentionally unsupported with a similar message.

@popzxc
Copy link
Member

popzxc commented Dec 5, 2024

Let's mark them unsupported and wait until someone needs them. Otherwise we're risking adding unneeded functionality.

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