Hey, I wanted to open this topic about community bootnodes and snapshot providers. I know that treasury is already paying for some of these infrastructure providers and I think this is important.
In some internal Parity discussion @tomaka raised the request that we should also request bootnode providers to install a certificate. This certificate is required for lights clients to be able to connect from the browser through websocket to a node. In the future with WebRTC this will maybe not be required anymore. However, for the moment this is required for light clients to being able to being able to talk to the chain. So, we should require this from community bootnodes as well to have this certificate installed. I don’t have any guide at hand that explains the setup, but I expect that someone will post a comment linking to a writeup/howto
The snapshot providers are currently fulfilling the job of helping validators to speedup the time to set up a new node. While this works, it should not be the preferred way for the future. In the future these snapshots should disappear. Polkadot supports warp syncing and this should be highlighted as the preferred way of setting up a new node. When we will have warp syncing first class support (Requires: Light sync state needs a proper format · Issue #11184 · paritytech/substrate · GitHub, Support Warp sync from non genesis · Issue #12249 · paritytech/substrate · GitHub & Make Warp Sync the default Sync mode · Issue #12250 · paritytech/substrate · GitHub), the snapshot providers should switch to providing checkpoints. These checkpoints are essentially the chain spec augmented with some “information”. These extra “information” will be used by warp sync to sync from some point in the chain history that is much closer to the tip than genesis. This has some security aspects and also it will be much faster. To generate these checkpoints a running node will be required and then it is about calling a RPC endpoint. While every Polkadot release will contain a new chain spec with the latest checkpoint, it is useful to have this decentralized as well to not have a central identity (Parity) that provides them.
I hope this post is useful on how the community can help Polkadot and on what the council/individual curators should take care of when approving funding.
Thank you for sharing this, @bkchr! I will flag this to the curators of the Kusama maintenance bounty as this is the place for service providers to apply for maintenance funds, so we request this as a condition for funding once we have the specifics of the certificate (@tomaka@erin your input here is appreciated).
The same condition should apply for any Polkadot maintenance proposals: although for this we need council members to be aware until the community decides on opening a maintenance bounty on Polkadot.
To be more precise, the idea is that the bootnode listens for (non-secure) WebSocket connections (with --listen-addr /ip4/0.0.0.0/tcp/30333/ws or similar), and sets up some kind of HTTP reverse proxy (e.g. nginx) in front of the node. This reverse proxy accepts TLS connections.
This setup requires passing the --public-addr /dns/example.com/tcp/443/wss (replace the domain name and port by the ones that are appropriate, of course) CLI flag to the node, so that the node knows its external address.
Adding an HTTP reverse proxy is a pretty common devops operation, so I don’t know how much we should explain it ourselves.
For context on this. We tried earlier to place substrate bootnodes behind a haproxy (reverse-proxy with ssl-termination) but at that point in time, substrate based nodes didn’t support this for a few reasons yet.
Perhaps this has been remedied in later version of substrate nodes? @Maharacha has more information from Dwellir team on this topic…
If there is more, please post on this issue or create a new one!
I’m not that familiar with the exact setup you need for having a proxy in front of the node to support wss etc. We should probably also have a proper tutorial in the Polkadot wiki, so that for the future it is easier to do.
