Add endpoint to enable estimation of inclusion fee

[namankumar]

What problem does your feature solve?

As a transaction-submitting developer, I need a way to estimate inclusion fee so that I can be sure my transaction will make it into the next ledger.

What would you like to see?

An endpoint that returns an inclusion fee, where the value of the fee is such that it maximizes the probability of the transaction making it into the current ledger while minimizing wasted XLM.

What alternatives are there?

N/A

[namankumar]

Notes:

• this endpoint could potentially be a field returned by simulateTransaction.transactionData as well... I'm open to both possibilities cc: @janewang
• docs should be updated to suggest best practices for using the endpoint
• the logic to compute the value of inclusion fee is TBD
  • Ethereuem geth looks 20 blocks behind and only considers the cheapest 3 transactions for each block, choosing the 60th percentile. 20 blocks is likely too long for Soroban

[namankumar]

References that may help in determining computing logic:

1. https://docs.alchemy.com/docs/how-to-build-a-gas-fee-estimator-using-eip-1559#relationship-between-gasusedratio-and-basefeepergas
2. EIP-1559 Gas API Call (Breakout #10) ethereum/pm#328 (comment)

[janewang]

We already proposed doing this from the RPC spec and I'd like to include what we actually want to build in the ticket description. Mind let me create the ticket?

[namankumar]

Feel free

[namankumar]

Another idea that came up while discussing with Jane. We can simplify the MVP even more: use the same logic as fee_stats but filter out soroban tx for the new endpoint

[janewang]

Closed in favor of #114