Notice: Polkadot has migrated to AssetHub. Balances, data, referenda, and other on-chain activity has moved to AssetHub.Learn more
Proposal for Monitoring of public RPC/WSS Endpoints & Node Database Analytics
Dear community,
I present to you a proposal which aims to develop a technical solution to:
- Monitor and report on the uptime, performance and integrity of public WSS (RPC) relay-chain endpoints. The data could be used to guide funding of said services, to encourage a service standard or to provide existing providers with a second take on key metrics from a third-party.
- Monitor and trend database growth rates for twenty-four database configurations. This is something that I started and self-funded > 16 months ago. Upon launch it gained interest by technical parties and is now referenced within the Polkadot Wiki. I would like to expand on the project to include growth charts and offer a wider range of database configurations. Further to this, I intend to monitor the restoration times of some of the more popular database configurations.
Additional: Providing that the original scope is met, I'll consider monitoring of database bloat, trend average RAM or CPU usage as well as monitor availability and integrity of bootnodes.
Both major items are not found within any existing public resources and are in my opinion well aligned to Kusama's experimental nature. Full details including budget details can be found in the proposal document. This document was circulated to members of the 1KV/IBP for a week and was open for public discussion for > 2 weeks.
Disclosure: As it relates to WSS monitoring, I am presently employed by LuckyFriday which as of last week is now listed as a public RPC provider. I also share good professional relationships with most of the RPC providers. The proposed solution is open sourced such that anyone can operate in-tandem and compare/challenge results. Once up and running these `audits` will be operated and presented without any human intervention.
Kind Regards,
Will | Paradox
Comments (5)
Requested
Proposal Failed
Summary
0%
Aye
0%
Nay
Aye (230)0.0 DOT
Support0.0 DOT
Nay (77)0.0 DOT
Public RPCs are centralized and should only be considered as a last resort way to access a blockchain. Instead, light client or self-hosted node should be preferred. In terms of decentralization there is no point in such services as described in the proposal.
Public RPCs are centralized and should only be considered as a last resort way to access a blockchain. Instead, light client or self-hosted node should be preferred. In terms of decentralization there is no point in such services as described in the proposal.
Hi Liberty, I respect your perspective on the matter. Personally, I think public RPC nodes are required for ease of adoption and use with the ecosystem's present stage development. It is an idealistic thought to believe that everyone who wishes to interact with the chain should sync and maintain a node themselves. If a technically capable individual intends to do this then the second aspect of the proposal should lend them some support. Light-nodes are a good future option and I look forward to its maturity. To my knowledge light nodes also rely on specified boot nodes which to your argument remains a point of centralization. Light nodes as used by browser extensions (at least Chrome) also require exposed and secured P2P traffic which atm is provided by said RPC providers. RPC providers also providing reliable boot node services. With that said I don't think we'll see public RPC endpoints points becoming redundant in the near future but I welcome and support continued progress with other options.