[Feature Request]: bridge/full: prioritised serving to selected light nodes

[Bidon15]

Implementation ideas

Background

The idea was born out of the discussions around usage spikes of light nodes on a limited amount of bridge & full nodes.

Motivation

As more RaaS teams want high availability operations wise for their users' light nodes, they have the motivation to hold the stack of either bridge node or full nodes. The issue can came in once there is a huge spike of light nodes with a limited amount of bridges and fulls. Hence instead of serving their users' light node first, their bridge/full could serve others, which is not preferable.

Implementation ideas

This FR can be treated as typical rate-limiting for everyone except a selected number of peers

We already have peer Scoring implementation and the following UX should be considered as sufficient to consider this FR as complete:

celestia rpc p2p PrioritizePeer <multiaddr> <score>
celestia rpc p2p ListOfPrioritizedPeers

[musalbas]

Good idea. This will also allow for paid node providers, without needing to use a centralized RPC endpoint. Or even just make a whitelist of peers, and ban everyone else.

[Bidon15]

Or even just make a whitelist of peers, and ban everyone else.

Banning(blacklisting) peers is already available in RPC cli.

(1)My concern around banning as a go-to/only option is the abusive nature of it. Long-term it can create a negative sum game in paywalls, which is proven to be a very bad public look for web2 establishments like Reddit, Twitter, etc.

(1.1)Rate limiting for others / Prioritising for selected is a good compromise to hold the balancing out until external help kicks-in. If no help is coming to load balance in N time, we can start banning the growing amount of peers as a last resort from bridge/full nodes pov.

Point 1.1 could be implemented through external tooling

[Wondertan]

We can achieve something similar with the current stack/implementation. With connection manager trimming, the node operator(NO) can configure BN/FN to have only 0 "free" connections. Then, by calling p2p protect <maddr>(or p2p.Protect on our API), NO can add peers that are protected from trimming by the connection manager.

cc @Bidon15, @musalbas

[Olshansk]

tl;dr Sharing rough ideas (details to follow next year) on how Pocket Network could be leveraged here as well.

---

Pocket Network's utility and value proposition is incentivizing high quality-of-service when servicing RPC requests. While we are an independent L1 today servicing 500M+ relays a day across dozens of hardware operators, we're going to migrate to Celestia using Rollkit next year.

Below, I'm jotting down some ideas that are not mutually exclusive w.r.t to what others have proposed here.

Two modes of operation:

1. Gossip headers & proofs across the network (opportune side incentives)
2. Request headers & proofs directly from a full node (pay for high QoS)

Flow:

1. A Celestia full node operates normally
2. Generate a Pocket private key
3. Stake as a Supplier for the Celestia service
4. Mode 1 (opportune side incentives)
   1. Participate in Gossip normally
   2. If:
      1. The request in the network is staked as a Pocket Application AND
      2. The responder in the network is staked as a Pocket Supplier AND
      3. The Application (user) & Supplier (node operator) are in the same session
      4. Application & Supplier sign the request (forward) and response (gossiped successfully)
   3. Then:
      1. Gossip RPC req/res can be rewarded and is stored in the local Pocket session tree
5. Mode 2 (requirements for a higher QoS)
   1. Advertise public endpoint to provide proofs & headers in Pocket's registery
   2. If:
      1. Light client is staked as a Pocket Application AND
      2. Light client uses the matching advertised endpoint from the Supplier
      3. Application & Supplier sign the request (get proof/header) and response (provide header/proof)
   3. Then:
      1. Request can be rewarded and is stored in a local Pocket session tree
6. Finally, settle the session reward/utility on Pocket L2 (uses Celestia as the DA layer and Celestia business logic remains the same)

---

cc @RossiNYC for visibility

[Bidon15]

Thanks for the rough breakdown of the ideas @Olshansk.
The initial discussion is more on p2p/libp2p level rather then accustomed RPC calls, like cosmos grpc/rpc/api, eth's json-rpc

The issue is with N Bridge node might be serving other Light nodes, while not prioritising LNs that this(these) Bridge node(s) was(were) initially designed to serve to

[Wondertan]

Yes, incentivized RPCs are tangential to the problem. The p2p network should operate without tokenization when possible.

[Olshansk]

The proposal above was designed with a p2p/libp2p network in mind.

In a (open, decentralized, permissionlesss) torrent-like network, the nodes communicate via RPC requests. The term "RPC" might be overloaded because we associated it with a domain (i.e. a centralized entity), but two IPs also communicate via RPC.

The idea here is that:

1. IP1 <--> IP2 (neither IP1 nor IPR2 hold a pocket privKey)
2. IP1 <--> IP3 (only IP3 hold a pocket privKey)
3. IP4 <--> IP3 (both IP3 and IP4 hold a pocket privKey)

This creates an optional financial incentive for some (case 3 but not cases 1 & 2) requests to deliver a higher quality (e.g. latency) while being an add-on instead of part of the core protocol.

Questions:

1. Wdyt of this approach/idea?
2. Lmk if you think this requires a more extensive and proper design doc.

[Partykingdk]

Good idea, I will also belive that thy will allow paid node providers