Scaling Down of Parity’s Public Infrastructure

Hello all,

Quick intro: I’m Erin, the technical lead of Parity’s infrastructure teams, who are astounding engineers and run a wide variety of services, including our public nodes which you may be familiar with, including rpc.polkadot.io and kusama-rpc.polkadot.io.

Given Parity’s initiative to assist in building a strong ecosystem and decentralize further, we would like to scale down what we as Parity are running and help strengthen the offerings of infrastructure available within the ecosystem in order to both maintain and improve upon the already high quality and breadth of service. What this means in absolute terms is:

  • Parity will reduce the number of RPC nodes we are running, but rpc.polkadot.io will continue to be maintained, although response times for requests will increase.
  • We already have rate-limiting on our nodes, but further rate-limiting will be introduced.
  • rpc.polkadot.io and kusama-rpc.polkadot.io should not be used by or linked to within any dapps, as we cannot guarantee response times or service level.
  • We will remove these RPC endpoints from the selection of nodes in the polkadot.js frontend.
  • Parity will reduce the number of bootnodes we operate to 2 nodes per network, including the Polkadot and Kusama relay chains and their system parachains.
  • We will continue running our public substrate-api-sidecar nodes short term, but there is interest from the community for decentralizing these as well which we appreciate, and are willing to collaborate on any other ideas anyone has about the future of infrastructure in Polkadot.

Scale-down timelines for different services:

  • RPC nodes will be scaled down at the end of this month, November 2023.
  • Bootnodes will be scaled down 2 days after the next Polkadot release.

Services we will likely scale down in the future which don’t have a timeline yet:

  • Light client bootnodes
  • substrate-api-sidecar

We believe that these services can be better taken care of by the community as there are many extremely skilled individuals and teams in the infrastructure field here :heart:.

In addition to this, Parity’s Success team has been involved in advising the formation of a working group which unites various infrastructure providers under an entity which would offer standardized delivery of public RPC and bootnodes, so we’d like to express continuous support of such programs in the journey for community-first, decentralized collectives to be at the forefront of not just providing infrastructure, but innovate on more public good ecosystem services.

We’d also like to be transparent about how much these services were costing us (raw infrastructure cost), since we believe the community can be more efficient on a cost basis than we have been:

  • RPC nodes: USD$7.50 per 1 million requests.
  • Bootnodes: USD$125 per node per month.
  • substrate-api-sidecar: USD$1.74 per 1000 requests.

In terms of scale, we are currently servicing:

  • Average request rate (last 15 days): 388 calls/sec
  • Total requests (last 30 days): 1005696000 calls

These figures are for rpc.polkadot.io.

With your help we can continue to innovate on how to provide the most decentralized as possible infrastructure services and would like to help lay the groundwork for an unstoppable light client future. If anyone has further questions, please feel free to ask them here!

16 Likes

Thanks Erin,

OnFinality has been preparing for this change for some time and offer a generous free tier, with paid plans for Polkadot and Kusama RPCs to suit every developer and budget

We’re here to help

Daniel

2 Likes

Put Subway in front of the RPC nodes and then it can handle at least 10x more requests for free. GitHub - AcalaNetwork/subway

6 Likes

Zondax would like to help too.
Happy to provide some free infra and get a bit more involved in the infra working group.

5 Likes

Thanks @erin on the detailed brief and a detailed plan on the future plans on the infra side from Parity.

Per mentioned, Success team is currently working on organising infra working groups with different teams that would be unified under standardised provision of these services.

If someone wants to drop a suggestion or intent on being a part of these groups - please let me know, per my responsibility as an Infra/Tooling lead. My tg is @alexdimes

2 Likes

In terms of substrate-api-sidecar, we have taken some proactive steps to identify some key endpoints that are causing bottlenecks, and increase performance internally, but also try and provide some documentation and ways to decrease infra cost via external tools.

Our tracking issue for this progress can be seen here: [Meta] Performance · Issue #1361 · paritytech/substrate-api-sidecar · GitHub

2 Likes