EIP-1559 Gas API Call (Breakout #10)

[tvanepps]

Date and Time

Date/Time: Friday, June 4 at 14:00 UTC (10:00 ET)
Duration: 60 mins
Recording: https://youtu.be/SpU6WACP2cM

Agenda

• Presentation by Gas API providers
• JSON RPC endpoint for gas price
  • Addition of eth_maxPriorityFeePerGas Add eth_maxPriorityFeePerGas execution-specs#201
  • Need to agree on return value
• JSON RPC endpoint for next block baseFeePerGas Proposal: add eth_baseFeePerGas method execution-specs#207
• Open Discussion

⭐ Cheatsheet: 1559 for Wallets and Users ⭐

↓ Leave a comment to add anything else ↓

[timbeiko]

One thing to discuss is how to update eth_gasPrice, quoting from the R&D discord:

Per the 1559 wallet call, there was a desire for eth_gasPrice to be backwards compatible so initial thought is to add a new optional parameter that signals the caller would like to receive a 1559-style estimate. The alternative is we could add new endpoints eth_maxPriorityFeePerGas and eth_maxFeePerGas that clients can call to get the new info.

[timbeiko]

Quick update: as per ethereum/execution-specs#201 (comment), we are likely to add a separate API for the priority fee. It would be good to use the call to discuss what value the API should provide.

[GregTheGreek]

@timbeiko do we have a list of different options that it can be calculated so folks can come a bit more prepared? I'm very concerned over the implementations of the GPO so would love to help wallet devs understand what they're getting as a return value!

[karalabe]

Geth's implementation currently:

• eth_gasPrice before London uses the current algorithm (deliberately won't say)
• eth_gasPrice after London will return the exact same number based on the total fees paid (tip + base)
• eth_maxPriorityFeePerGas after London will effectively return eth_gasPrice - baseFee

Auto-fill details:

• If the user doesn't specify either gasPrice or 1559 gas fields, we default to 1559 style transactions
• If the user doesn't specify maxPriorityFeePerGas, we default to the above estimation
• If the user doesn't specify maxFeePerGas, we default to maxPriorityFeePerGas + 2*baseFee

The rationale's behind this thought:

• Users continuing to rely on legacy transactions and eth_gasPrice should not observe any behavioral change. (Hence why I didn't detail how the GPO works, it works the same way as until now).
• Users stuffing eth_gasPrice into a 1559 tx for the priorityFee or maxFee will be handled gracefully as if they just did a legacy transaction, no shooting yourself in the foot.
• Advanced users who know 1559 is different and how can rely on the new endpoint eth_maxPriorityFeePerGas which returns a value for the tip only (thus it won't be mined if used as is without a baseFee + slack on top).

---

Edit: Geth's gas price oracle retrieves the cheapest 3 transactions from the past X blocks, and uses the 60th percentile as the suggestion for the price. The 60th percentile ensures we're aiming for inclusion in 2-3 blocks, whereas looking at the minimums ensures we're trying to push prices downward instead of up.

Edit2: X = 20 for full nodes and 2 for light clients (they need to retrieve the entire blocks to suggest a price)

[barnabemonnot]

Hi! Yes some thoughts on the proposed oracle:
(edits after the following was made clear: there is an oracle ('GPO') that tracks the 60th percentile of the minimum tip paid over the last 20 blocks, looking at the 3 transactions with the smallest tip for each block. eth_maxPriorityFeePerGas returns GPO while eth_gasPrice returns GPO + current basefee)

• 20 blocks seems too long, it takes 6 blocks for basefee to double, so 20 blocks is 4 minutes 20 worth of blocks (average) which in worst case leads to basefee 10x'ing. The intuition here is that when basefee stabilises around the current correct market value, instead of catching up to it during spikes, in a way it "cleanses" the environment, you shouldn't need to rely on what happened in the past to determine what you should be doing now. The only periods where you want to use past information to determine your tip would be during spikes, but it's unlikely that we'd ever see a period with 20 full blocks in a row, for reference 6 full blocks means that prices doubled in about 1min20sec. I checked the worst spikes once and even then it wasn't that sudden (lost that analysis to a bad computer crash.... but happy to run it again!). There is also a strong dependency between the length of your look back period and the percentile you choose which we could exploit. You could say "let's keep 20 blocks but up the percentile to 80th" or "let's keep the percentile to 60th and only lookahead 10 blocks", that would probably have about the same effect. But if I had to pick I'd be more inclined to choose the latter because 20 blocks in the past is ancient history in 1559, basefee would have caught up to something by this point.

• In the Discord messages it was discussed that the congestion rate is the important metric, not congestion level. I do think that any 1559-adapted gas price oracles must look at the gas used one way or another. This is the objective source of truth that prices alone cannot capture. If you see a block that is less than full, your oracle should stop advertising higher premiums than necessary. Right now it doesn't take advantage of the fact that block fullness provides the correct measure of congestion rate. I understand the need to not break everything at once and it's something again we could simulate to convince ourselves, but it seems inescapable to me that we cannot be looking only at prices to design a good 1559 oracle. Although after being more clear on what the current proposal does it's probably safe, if suboptimal.

[karalabe]

I tried to explain conceptually the mechanism, but I guess it got misunderstood somewhere along the way.

Our gas price oracle internally calculates the priority fees actually paid by the transactions. For the eth_gasPrice call, we will return the estimated priority fee + 1 basefee (which will essentially be the "current" full gasPrice that we estimate pre-London). For eth_maxPriorityFeePerGas, we return the estimated priority fee. The user needs to set the maxFeePerGas either manually based on the tip, or Geth defaults to the priority fee + 2x baseFee.

[fvictorio]

@karalabe when you say "1 basefee", what value do you use? The base fee of the latest block, the next base fee, or something else?

[karalabe]

The current baseFee.

[danjm]

Will the call be recorded, or will notes be taken, and made publicly available?

[zsfelfoldi]

I wrote a short proposal for a fee suggestion API:
https://gist.github.com/zsfelfoldi/9ca596996f5a556c58dae3aa4f4d0049

[timbeiko]

@danjm I don't think we'll have notes, but I'll upload a recording to Youtube.

[timbeiko]

Link for the 1559 API wishlist: https://hackmd.io/@timbeiko/1559-api-wishlist

[Santhosh1692]

@timbeiko Please notify me once the recording has been uploaded to YouTube. I'll get started by adding the notes.

[timbeiko]

Recording available here: https://www.youtube.com/watch?v=SpU6WACP2cM&feature=youtu.be cc: @Santhosh1692