Infrastructure Treasury funding

Governance
1

I’ll keep this brief as a wall of text can turbo-nuke engagement.

Problem

As an ecosystem we rely on certain infrastructure, which is historically paid for by the Treasury (or there are ongoing discussions about whether or not it should be). However, we have seen a bombardment of proposals from different providers (at least 6 so far on Polkadot Opengov), as well as bounties that aim to simplify things/ capture them under one roof - some are approved, some are rejected. It’s a bit of a roll of the dice as to whether or not the proposal will be successful, and from a non-infrastructure provider’s point of view it can be daunting wrt what should and shouldn’t be funded, who should provide it, etc.

Solution

One infrastructure bounty (or maybe even an Infrastructure Collective? :thinking:) with a budget approved through Opengov that covers any and all infrastructure needs for the entire Polkadot ecosystem.

Types of infrastructure that could be included

  • Public RPC services
  • Public indexers
  • System chain collators
  • Boot nodes (light clients)

Factors that should be considered

  • How many of each type do we need? How many providers? Factoring in:
    • User experience
    • Performance
    • Decentralisation

Once we have agreed on the above factors (and any others raised), only then can we agree what should be a suitable budget to maintain these requirements.

10 Likes
2

As a heads up we’re member of the Infrastructures Builders Program, I’m not talking for the IBP just sharing my opinion.

In my opinion the right way forward would be to provide services through the IBP or a IBP like clone.

IBP (Infrastructures Builders Program), is a collective of infrastructure providers that provide core services (RPC and bootnodes for relaychains and system-parachains) in a decentralized manner. All services are run on own hardware and own colocation/data centers. Members are distributed globally and access is handled through GeoDNS and Anycast(WIP). This means no single provider is in control and no risk of intermediaries(cloud/regulations) . Should there be ever a malicious actor or issues with a service the member can be easily removed. Provided services are payed end of month according to uptime through a bounty. There are two tracks, one professional and a hobbyist, which allows community members to learn and provide rpc services as well.

Now that the community has decided that RPC nodes for parachains should be payed for by the treasury such a setup would make sense for that as well. Maybe the IBP could be extended to parachains and updating the requirements would make it so that more service providers could participate. Members that wish to only provide services with their endpoints can do it easily by just resolving DNS to their setup. They also have the option to leverage the decentralized way through GeoDNS or Anycast to have a better global performance coverage.

This way the ecosystem would not be dependent on a single provider and the bounty/program itself can deploy RPC endpoints accordingly on locations where it sees fit.

9 Likes
3

For what it’s worth, from the client side, the medium term plan is to remove the concept of RPC nodes (they would simply be full nodes instead) and to make the handling of bootnodes automatic.

See:

This removes a lot of overall maintenance overhead (such as managing domain names and load balancers) and completely removes the possibility of attacks (apart from of course (D)DoS attacks).

Should there be ever a malicious actor or issues with a service the member can be easily removed.

This is unfortunately not a good solution, because 1) you must somehow be made aware of the fact the actor was malicious or has an issue, which is more easily said than done 2) you’re removing the malicious actor after the fact.
If an RPC provider is malicious and is technically competent, you simply won’t be able to detect it.

5 Likes
4

Whats the rough timeline on deprecating the concept of RPCs?

lightclient is great for current state but AFAIK it doesn’t work for historic data.
Is the plan to be able to also use it for historic data?

We would still need people to run full/archive nodes or is the long term plan that the lightclient connects to validators? Which almost none run in archive mode.

Agree, but we are working within the given limitations. Currently there is some kind of trust required that rpc providers act in good faith and for example do not re-sell/use access data. The removing of the member is mainly used if a member wants to do bigger maintenance or should there be a incident with the provided services.

1 Like
5

We second Tugy’s comments. As the proponent of the IBP, obviously we’re just a little bit biased but the idea was that we could all work together to provide better and more decentralized services. We could work on migrating the program to Polkadot earlier than anticipated and grow the size of the program allowing all of the existing providers to fully integrate into the program. If we were to double the size of the IBP, making plenty of room for existing providers, and expanding to cover all parachains – it would still reduce the overall expenditure for RPCs on an aggregate annual basis (Not by a lot, but enough)

The plan for IBP program milestone 3 was to request ~3M DOT as a loan from the polkadot treasury, we would stake this with 1kv validators (providing 2 more slots to the 1kv polkadot program), and use the generated rewards to cover the cost of the IBP program. It would result in a slight reduction in overall staking rewards but cost the treasury nothing in the long run while providing complete coverage to the entire ecosystem.

Unfortunately some providers are cloud based which makes their integration into the IBP non-trivial from their current business processes.

Do you have a rough time span? I’m currently operating on the assumption that we’ll likely have RPC in some form through 2025.

2 Likes
6

It’s hard to say because the decentralized nature of things means that there isn’t somebody in charge who will define a timeline. The best I/we can do as devs is give the possibility for UIs to not use RPCs. And when it comes to that, the underlying tech is completely ready, it’s just on the frontend side that not everything is ready.

However it’s in principle completely possible for UIs to continue using RPC endpoints forever even if they have the possibility not to and even though RPCs are less secure. We can’t control that.

Full nodes will never remove the possibility to turn your node into an RPC node, because the RPC endpoint is how the owner of the node interacts with their node.
The only thing we want to deprecate is the fact that Alice uses an RPC node hosted by Bob even when Alice and Bob don’t know each other.

Is the plan to be able to also use it for historic data?

Light clients can’t provide old data at the moment. You still need RPC archive nodes for that. But it seems to me that most people use indexers (subscan and similar) rather than archive RPC nodes.
In the longer term (it requires BEEFY), light clients might be able to fetch historical data from archive non-RPC nodes. There are other problems to solve, so it’s a bit hypothetical.

To be clear, the full nodes that are currently RPC nodes are still necessary. It’s not possible to just “remove the servers”. Something has to provide the bandwidth and send data to the browsers.
The only change is that the browser would automagically find the full nodes and communicate with the full nodes in a way that doesn’t require a domain name in front of them.

So everything you said about treasury proposals and a collective is still relevant.

4 Likes
7

You’ve pinpointed a key issue - managing all the different parts of our infrastructure can get complicated with so many proposals and providers.

In fact, something similar to your suggestion existed on Kusama. It was called an Infrastructure Maintenance Bounty. It wasn’t perfect, but it did help to sort out a lot of problems and support some crucial services. Unfortunately, the Bounty extension proposal was voted Nay in the OpenGov.

For example, service providers like OnFinality and Dwellir, explorers such as SubScan and DotScanner, and governance platforms like SubSquare and dotTreasury all benefited from the funding this bounty provided. This support was really important in helping these projects deliver their services and improve the Polkadot/Kusama ecosystem.

I believe that a bounty should cover all types of infrastructure, not just the core stuff. Other non-core areas, like governance platforms or block explorers are also important and need support.

So, your idea of reinstating infrastructure bounty, with a budget agreed in advance, could be a great way forward. It could make things a lot simpler for everyone involved and make sure we get the infrastructure services we need.

2 Likes
8

Who decides what is and what isn’t categorised under an infrastructure label?

Example:

9

Who decides what is and what isn’t categorised under an infrastructure label?

We do, during this discussion, formulating a framework for such funding that could then be put forward for discussion/ voting on-chain.

1 Like
10

I’ve heard a lot about the Infrastructure Builders Program (IBP) and the Infrastructure Maintenance Bounty (IMB) - it seems there are/ were some crossovers between the two (before IBM was nuked).

Can agree that one funding model that covered all of:

  • Public RPCs (whilst needed) (IBP?)
  • Indexers (Subsquid?)
  • System chain collators (IBP?)
  • Boot nodes (IBP?)
  • Governance platforms (Polkassembly & Subsquare)
  • Block explorers (Subscan)

Would pretty much wipe out the bulk of ongoing Opengov referenda.

I think an on-chain Infrastructure collective with its’ own treasury, funded by a fixed % of the inflation going to the Treasury could work as a model for this moving forward - I assume it’s perfectly feasible to also spin out different funded bounties from within that (e.g. IBP & IMB)?

1 Like
11

Yes :). There is decent progress on implementing these sub-treasuries so I hope they start rolling out in the not-too-distant future. Staged payouts and multi-asset (stablecoin) proposals should also reduce the frequency of referenda.

Not sure if infrastructure needs its own collective. Not opposed outright but there are other existing/potential collectives (Fellowship, Parachain Fellowship) that should be able to vet infrastructure proposals.

2 Likes
12

My thoughts on Infrastructure having its’ own collective is due to it being able to have its’ own budgeted treasury, because in my eyes the collectives are kind of super-bounties with their own membership logic and potentially automatically refilling budget - or are you saying that e.g. the Fellowship or another collective could have multiple treasuries, one of which could be for say infrastructure?

1 Like
13

I was still thinking each collective would have one sub-treasury (not multiple). I’m just not sure how much fragmentation makes sense. The Fellowship should have a decent idea of what kinds of services are necessary for operation/integration of the system and be able to sort out good proposals from fluff.

I definitely had in mind that for non-system chains, this type of funding would fall under the Parachain Tech Fellowship. Parachain builders know best what they need to succeed, so things like “fund a block explorer for all parachains that get a slot” would make sense as general funding that reduces the barrier of entry for new parachains (specifically the barrier of contracting and paying for a block explorer).

An Infrastructure Collective whose sole purpose is funding has a problem where they will probably say that spending on infrastructure is good, and thus spend lots, and then ask for more funding. It’s a challenge to avoid the positive feedback loop that e.g. departments in big corporations find themselves in (save money X years in a row and then ask for a bigger budget one year to invest in new equipment, and get turned down because you’ve shown you can operate on a lower budget, while departments that always spend get approved for bigger budgets).

While I agree with the “super-bounty” model, IMO that’s only a portion of a Collective’s role. Fellowship e.g. has WhitelistOrigin and the mandate of maintaining/developing the runtimes.

Again, not against an Infrastructure Collective per se, just that it should have broader objectives than to divvy up funding. Perhaps there could be something like “System Integration Collective” (grammar patrol rejoice) with expertise in all sorts of tooling (signing libraries, middleware APIs, indexers, etc.) with a mandate of making adoption easier.

14

Is there anything in writing or in video that better describes the topology of a collective? I worry that we’re going back to something akin to a gov1 model and it seems like we’ll just go back to the old issues of “if you know someone, you know someone, if you don’t, you don’t.”

If there’s a long running program like the IBP, or the newly created Assurance Legion Bounty, how would these programs ask and receive their funds?

1 Like
15
3 Likes
16

We proposed a similar solution to that mentioned by @lolmcshizz and @tom.stakeplus under the “Proposed Long Term Solution” section of our most recent proposal OnFinality Funded Polkadot RPC Services Treasury Proposal - Google Docs

From our point of view, the greatest advantage of Polkadot is the network effects and support that it brings. Funding from the Polkadot treasury will be a holistic solution that will allow us to support as many parachains as possible.

“Teams need to coordinate/negotiate with all sorts of partners (block explorers, rpc node providers, wallets, other parachains). This slows down innovation for Kusama.” - Interlay

Multiple parachains have privately and publicly affirmed that one of the biggest challenges is dealing with all the tertiary providers needed to run a production parachain (RPC nodes, block explorers, indexers, governance pages, wallets integrations and more). Parachains are expected to integrate and manage all of these vendors, taking valuable time away from protocol innovation. These providers all waste a surprising amount of time making corresponding treasury proposals and managing wallets of multiple tokens to a large number of chains. It’s bad enough that we estimate that we alone spend weeks worth of FTE on accounting, submitting treasury proposals, engaging with the community, monitoring wallets for payments, liquidating tokens in a way that minimises market impact, and then account for all of the above actions again, each and every quarter.

We propose that in the long term, we create a new “Parachain Infrastructure Bounty”, that provides basic public services for all active parachins for both ecosystems. The aim is to make the ecosystem more harmonious, unify processes and tools, speed up development progress, and will help all new teams get started.

Ideas floating around suggest that each parachain gets a certain amount of base level of funding for common good infrastructure. Some even speculate that there could be funding for each category of public good infrastructure, and they can only allocate that funding to any infra providers of their choosing that are part of the bounty. Whether we allow parachains to choose what providers to allocate this funding, or allow providers to compete for it (and on what basis), is still unclear. For example, a parachain could split the funding across multiple providers, or allocate it to a single provider. Any unused funding would likely need to be refunded back to the treasury.

But setting this bounty up and communicating with the large number of stakeholders will take a long time. At this stage, we expect at least 5 RPC providers, 4 wallets, 3 block explorers, 2 indexers, and 2 governance tools will want to be party to this bounty if it encompasses all “public good infrastructure”. We expect that the process of consulting all stakeholders, negotiating the terms of the bounty, finding curators, communicating with both communities and then submitting a proposal will take at least a quarter and will require a large amount of effort from our team and others.

Finally, we don’t have precedent yet for this kind of funding agreement, especially since the community voted to stop funding the last infrastructure bounty less than 5 months ago. There is a very real likelihood that the community will vote against this bounty, after considerable effort is made to set it up with over 10 stakeholders involved. There is a lot of risk here and it’s hard to see any single actor investing the time to set this up without a precedent or previous approval from the community.

Note that proposal succeeded so we’re about to begin the process to setup said “Parachain Infrastructure Bounty” (or whatever we call it), i’ll drop a link to a new channel that we can use to collaborate on organising this here soon.