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

London JSON RPC Specification #334

Closed
timbeiko opened this issue Jun 9, 2021 · 3 comments
Closed

London JSON RPC Specification #334

timbeiko opened this issue Jun 9, 2021 · 3 comments

Comments

@timbeiko
Copy link
Collaborator

timbeiko commented Jun 9, 2021

There are a few outstanding things to figure out w.r.t. JSON RPC for London. This document details them.

Specifically, the three things we need to get a common solution for are:

  1. eth_call and how it deals with BASEFEE and GASPRICE
  2. Adding effectiveGasPrice to eth_getTransactionReceipt, see Add effectiveGasPrice to eth_getTransactionReceipt execution-specs#206
  3. eth_maxPriorityFeePerGas vs. feeHistory

It would be great if clients can share their thoughts on this here prior to the call so that we can spend the call time going over the most contentious & hard to spec things.

@fvictorio
Copy link

Somewhat minor, but it would also be great if we could agree on what to return for the baseFeePerGas fields when a pre-London block is fetched. In my opinion, it should return a block without that field, but notice that pre-Berlin legacy transactions include a type field with value 0 (at least in geth), so the behavior here is not obvious (you could argue that pre-London blocks should have a 0 baseFeePerGas instead of omitting that field).

@sunce86
Copy link

sunce86 commented Jun 11, 2021

For point 1: eth_call and how it deals with BASEFEE and GASPRICE

I'm in favor of adding additional optional field called "base fee" to the eth_call parameter list.

In my opinion, eth_call should be used (by default) to analyze what would happen "in reality". Therefore, you need to:

  1. Define gas price/maxFeePerGas&maxPriorityFeePerGas because you do that in reality also.
  2. Expect that base fee is taken from the block header specified in parameter list (or from default block header if block is not specified in eth_call parameter list).

If you want to diverge from this and analyze tx under different conditions, you need to provide those different conditions in parameter list. In case of gas_price/maxFeePerGas&maxPriorityFeePerGas, if you want them to be 0, then omit them in parameter list or set to 0 explicitly. In case of base fee, if you want to ignore the base fee from block header, then specify that in parameter list (set base fee to 0).

Adding base fee field is a clean way for users to intuitively better understand how the function works by looking only at the eth_call function signature.

@timbeiko
Copy link
Collaborator Author

On ACD115, we agreed to the following:

  1. For eth_call, follow geth's behaviour as per this PR unless anyone finds an issue with it;
  2. Have the effectiveGasPrice in the transaction receipt as per Add effectiveGasPrice to eth_getTransactionReceipt execution-specs#206
  3. Go with the feeHistory API by default, but add a cap to the amount of blocks it returns (to work better with light clients). @zsfelfoldi will modify the gist and open a PR against the JSON RPC spec once done.

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

3 participants