GraphQL API should contain EIP-1559 London Hardfork methods

[amyodov]

Rationale

GraphQL API should contain everything necessary to create the transactions - such as, a GraphQL analog/endpoint to eth_feeHistory, but also probably other methods.

Why should this feature exist?
Without this, the GraphQL API is not feature-complete and does not let you to create the transactions in post-EIP-1559 way. No way to get the real estimate what gas to use.

What are the use-cases?
Using Geth through GraphQL only, without resorting to JSON-RPC.

Implementation

Do you have ideas regarding the implementation of this feature?
No.

Are you willing to implement this feature?
No, but will happily test it out.

[s1na]

I was looking a bit into eth_feeHistory and it seems to me that this query already has almost all of the "raw data" necessary:

query feeHistory($from: Long!, $to: Long!) {
  blocks(from: $from, to: $to) {
    number
    baseFeePerGas
    gasUsed,
    gasLimit,
    transactions {
    	maxFeePerGas
        maxPriorityFeePerGas
    }
  }
}

We have the list of base fees for the block range itself, gasUsedRatio can be computed by block.gasUsed / block.gasLimit. Now, short of adding a feeHistory field to the Query schema we have several options for facilitating the client to compute the rest of the data itself:

• Add nextBaseFeePerGas to Block since feeHistory also returns the computed base fee for one future block
• Add reward/effectiveTip to Transaction. This can be computed by min(tx.priorityFee, tx.maxFee-baseFee) but it's a EVM-related logic and it's fair to provide it

IMO the percentile logic for rewards can be left for clients to handle.

[fjl]

I sort-of agree with these ideas.

[s1na]

@amyodov can you try the script provided with #24452 to see if that fits your need?

[amyodov]

@s1na , I am not that much of a Gopher :( And our infrastructure (where geth GraphQL is used, and which helps me to notice various GraphQL inconsistencies and shortages) uses the geth releases only, not the self-built prereleases; so I have to wait till any next geth release to try any new GraphQL changes, unfortunately.
But I will definitely have a look at them and try to use them as soon as they are added.