Provide getFeeStats as a new endpoint on RPC

[janewang]

What problem does your feature solve?

getFeeStats: An endpoint for inclusion fee should be made available to help developers understand how to set inclusion fee.
We propose a separate endpoint as the inclusion fee below is provided over a set of transactions instead of uniquely tied to a specific transaction, as in simulateTransaction. Furthermore, we want to avoid providing a single number, but provide a percentile distribution of fees such that the developer could have a sense of the current fees distribution and choose a bid that’s most appropriate for this transaction.

Types of transaction:

For Soroban transactions and Stellar transactions, they each have their own inclusion fees and own surge pricing. For example, classic transactions can be at base fee of 100, while Soroban fee goes through surge pricing. Thus we need one data set for Soroban transactions and one data set for Stellar transactions in the lookback period. It doesn’t make sense to mix these two types of transactions.

Lookback period:

We propose a lookback period of 50 ledgers for Soroban transactions and keep the same 5 ledger lookback period for Stellar transactions. Both of these variables should be configurable, but the values here are the default values. On a lower time scale, Soroban inclusion fees are highly volatile and cannot provide a predictive basis for analytics. We propose to reevaluate the lookback period as Soroban capacity increases and fees become less bumpy ledger to ledger.

What would you like to see?

Example response for soroban inclusion fees and stellar inclusion fees:

{
  "soroban_inclusion_fee": {
    "max": "1009",
    "min": "101",
    "mode": "101",
    "p10": "101",
    "p20": "101",
    "p30": "101",
    "p40": "101",
    "p50": "600",
    "p60": "600",
    "p70": "1009",
    "p80": "1009",
    "p90": "1009",
    "p95": "1009",
    "p99": "1009"
  },
  "inclusion_fee": {
    "max": "100",
    "min": "100",
    "mode": "100",
    "p10": "100",
    "p20": "100",
    "p30": "100",
    "p40": "100",
    "p50": "100",
    "p60": "100",
    "p70": "100",
    "p80": "100",
    "p90": "100",
    "p95": "100",
    "p99": "100"
  }
}

We should update public documentation to include usage of this endpoint.

What alternatives are there?

[2opremio]

@janewang do you want to take into account ExtendFootprintTtl and RestoreFootprint operations into the soroban_inclusion_fee? or just InvokeHostFunction?

[janewang]

@2opremio The ExtendFootprintTtl and RestoreFootprint are also soroban operations right? In theory they need to include inclusion fee and bid inclusion fee just like others. If my understanding is correct, and they compete for the same inclusion into a ledger, they should be included.