[Suggestion] Add method to get current fee rate data

[phroi]

As per title, I'm wondering: within a DApp that relies on a CKB Light Client as back-end, what's the most idiomatic way to choose a mining fee rate?

With a full node there is a variety to methods to chose from, here I'm not really sure how to even get that information about other transactions 🤔

As usual I'm asking here since GitHub issues are SEO friendly and very likely in the future there will be other L1 developers wondering the same 😉

Keep up the great work 💪
Phroi

[quake]

The light client doesn't provide this functionality, you may get it through a third party full node or service.

[phroi]

Hey @quake, thank you for taking your time for giving realistic alternative solutions, very appreciated!! 🙏

The issue I see with both your solutions is that they seem inconsistent with Light Client goal. On one side both your suggestions rely on centralized API services, while I was under the impression that the Light Client purpose is to move away from such centralized services 🤔

Is there any good reason not to include such an endpoint in the Light Client?

[quake]

If you want to provide a similar rpc, the light client needs to synchronize all blocks for fee analysis, which is in conflict with the design goals of the light client, so light client based wallets can only use the fixed fee rate option, or use a third-party service.

[phroi]

Use a fixed fee rate

Last time I checked Nervos L1 fee rates, anything between 3000 and 5000 was working nicely. Heck, even the minimum 1000 fee rate usually get included pretty quick. Then again there are days in which the fee rate spikes dramatically (say for example when ".bit" deploys). In those days I wouldn't really want to be the user of a DApp that uses a fixed fee rate...

If you want to provide a similar rpc, the light client needs to synchronize all blocks for fee analysis, which is in conflict with the design goals of the light client.

Let's talk a bit about this, for example let's assume that:

• We want to implement get_fee_rate_statistics.
• We request this statistic for N blocks.
• We have P peers.

When the user makes the request we would have N * P requests with your approach, correct? That's way too many, I agree with you @quake.

Let's take a different approach then. What if we could get away with only P requests?

The idea is simple:

• To each peer we ask the already computed get_fee_rate_statistics(N).
• The responses are: (mean_0, median_0), ... , (mean_p, median_p).
• Light Client returns to the user: median(mean_0, ... , mean_p), median(median_0, ... , median_p).

Due to the median properties, even if P/2 - 1 clients return a wrong or out of date response, the Light Client still reports the correct answer. In extreme conditions we could also get degraded responses, but it would always be better than trusting 100% the response of a single node.

Also in general, fee rate statistics shouldn't be used as they are, but they should be used by the DApp to make an informed decision, so that if for example a fee rate statistic is absolutely too high or too low, the DApp takes an adequate response.

What's your take on this @quake?

[quake]

The hardest part of doing fee rate statistics calculation or estimation on a light client is the lack of information. Full node knows everything about the latest N blocks and txpool, such as the fee rate of every transaction it contains, but light client does not.

If we trust the statistics data returned by the full node without verification (which requires data), assuming that most of the full nodes connected are owned by miners, the miners can return fake data to the light client in order to earn more tx fee.

[phroi]

Fair point @quake! Right now no miner has the incentive to modify a node to increase the fees returned by these methods as most of the RPC traffic is handled by trusted nodes (such the ones you advised earlier or Ankr), but in a future where my proposal was to be implemented in the Light Client, they would actually have such an incentive.

For that reason, such a simplistic implementation cannot be included in the Light Client, then again I don't really see any other good alternative that transparently works out-of-the-box for mainnet, testnet and devnet.. so I'll just implement this functionality in my little library by using Light Client's get_peers and then using the full node RPC of the peers.

I'll leave this issue open as in my opinion there is request for such a feature in Light Client 🤗