So i had a brief discussion with @tomaka about the neccessity of a light client data incentivization protocol for parachain teams. The reasoning is light clients are essentially parasites on the full nodes of the network and so the request/response protocol that serves light clients can also be a DDOS vector for adversarial parties of the network.
In order to make the network resilient against these kinds of attacks, we must introduce a light client data incentivization protocol.
Tomaka suggested instead of making light clients pay ahead of time in order to access some data, we could instead discard non-paying clients when there’s an unusual amount of load on the full nodes. This imo, makes a lot of sense and i think is a great solution to our DDOS problem.
In this protocol, light clients would stake some tokens on-chain and register their request key, a special key which they’ll use to sign p2p requests that get sent to full nodes. Full nodes can then give priority access to requests signed by these staked light clients.
Creating this topic to collect thoughts and feedback so we can draft an implementation plan.
The reasoning is light clients are essentially parasites on the full nodes of the network and so the request/response protocol that serves light clients can also be a DDOS vector for adverserial parties of the network.
I think that many people will have the impression that the risk is that allowing light clients to connect means that they can flood the node and thus slow it down and thus that there’s a risk for the peer-to-peer network.
I just want to clarify this, and also because nobody on the Internet seems to understand what a “DoS attack” is.
DoS just means denial of service. As its name says, you’re denying service to legitimate users. It doesn’t necessarily mean crashing the software. It doesn’t necessarily mean overloading the software. It just means preventing legitimate users from using the service, which can mean the service doesn’t work at all or is so slow as to be unusable.
In case of HTTP servers (the usual DoS attack target), connections between clients and servers are typically short-lived, so if you manage to prevent servers from accepting new connections, you’re essentially preventing everyone from accessing the servers. This is typically done by flooding the server with incoming connections and requests, such that the server accepts the fact that it doesn’t have enough CPU/memory to serve everyone.
In case of a peer-to-peer network, the nodes stay connected to each other. If the node is flooded with incoming connections and requests, it can simply deny new incoming connections and back-pressure the requests, and the nodes that are already connected to it don’t suffer at all (unless the node’s implementation was badly written). Service isn’t denied.
The only thing that a DoS attack can cause is prevent new full nodes and new light clients from reaching the peer-to-peer network (in an acceptable time). Once you’re connected, you’re connected for good.
I also want to add that the reason why nobody is really covering this topic is that it’s incredibly complex.
Which creates a chicken and egg problem, because you can’t stake tokens and registering your key without accessing the chain, and you can’t access the chain without having staked your token and registered the key.
A centralized RPC server is normally degrees of magnitude more easy to DoS than the peer-to-peer network. After all, an RPC server is nothing more than a node. Instead of having to attack the entire network, you just have to attack one node (or a certain number of nodes if there is a load balancer).
I really want to highlight that RPC servers are worse in every way possible than the peer-to-peer network, except for the fact that the WebSocket protocol that it uses is more familiar to people.
Unlike the p2p swarm you can run cloudflare’s ddos protection service in front of your RPC servers to deny DDOS attacks. So i still think centralized RPC servers can serve as an accessible entry point.
I believe that CloudFlare also provides a service that secures against IP-level DoS attacks. Also, CloudFlare doesn’t work magically. Because we use exclusively WebSocket, they can’t act as a cache and can’t filter undesirable requests, unless they added code specific to Substrate/Polkadot, which I doubt they will.
Many teams already use cloudflare for ddos protection on their RPC servers, composable included. Kinda non-negotiable when you have RPC providers ddos-ing your own RPC servers so they can sell you their RPC plans.
All in all, do you have any wishlists for this incentivization protocol? I’m looking to get a grant for polytope labs to implement this.
IMO that sounds like a bad solution to the problem. First needing to use some RPC will be a really shitty UX.
As @tomaka already said this is a chickend egg problem and also not that easy to solve. I think we should incentivize people for running full nodes that can be used by light clients. This would probably be the easiest solution. This could also be put on chain with some offchain workers testing that these nodes are reachable etc.
There is yet another issue with the request key approach that I’m not sure you guys have thought about yet, which is the fact that light clients are meant to run completely client side, which can be fine if you are embedding them on precompiled native binaries, but the moment you introduce them in a web app, which is where most developers want to embed them, you hit a roadblock: how do you protect this secret request code in a client side web app without relying on a centralized server?
The idea here is every user of your app will need their own request keys, Ideally your front end handles this automatically.
The reason for request keys is to prioritize requests from already paying light clients in the event of a DDOS attack on your network. Sure you can run these nodes without a light client incentivization protocol, but as the users of your network grows, your infrastructure costs will grow in tandem to the point where it’s no longer economically feasible to support all the light clients for free.
This light client protocol will also help rate limit light client requests, which as i’ve described can be a DDOS vector for adversarial parties.
As I’ve already mentioned, this is an incredibly complicated topic. Nobody is really talking about this, not because it’s not an interesting problem, but because it’s so overwhelmingly complicated.
You can’t “just” make light clients pay the full nodes. It raises tons of questions.
How much do you actually pay? Through pre-calculated fees? But then we need a reference machine and a reference implementation to determine how much each request costs, kind of like weights in the runtime but insanely more complicated. Through auctions? But then how do you prevent a full node from charging 50€ just to connect? How do you make sure that the light clients are aware of the almost-empty full node that charges only 0.0001€? How do you prevent full nodes from acting badly against each other so that they eliminate the full nodes that propose a lower price? Do you make the light clients automatically make the payment? If yes, the user might have a nasty bill at the end of the month. If no, you have a bad UI.
How do you prevent full nodes from simply being dummies that actually redirect the request to a different full node (that is not theirs), so that their operational cost is almost 0?
How do you prevent full nodes from doing the bare minimum (e.g. limiting the bandwidth as much as possible) just to get the payments, even though the light clients will suffer from this?
How do you prevent an attacker from charging less money than everyone else just so that every light clients connects to it, and then eclipse attack them?
Also, how do you manage the request key? Will I need to plug my hardware wallet just to access a UI?
How do you prevent the full nodes from tracking users through their request key, just like cookies on the web?
I’m stopping here, but you get the idea. “Just” incentivizing full nodes is way too naive.
It makes more sense that the fees are pre-calculated and fixed.
This is out of scope for the protocol.
Nodes acumulate signed requests and use them to collect payments on-chain where they’ve been escrowed.
Basti’s suggestion of node behaviour checking via off-chain workers can mitigate all of this.
The request key doesn’t control funds, it’s only for signing requests, so it can be stored in a hot wallet. No hardware wallet needed.
Not going with an auction model solves this, also i should clarify that this protocol is for state data, no light client should have to pay to access consensus data.
Sirs, I get that this is a very complicated problem, but it makes sense to put our heads together and try to solve it before it becomes a pressing issue.