Outstanding Questions About the Infrastructure Builders Program (IBP) Bounty

After reviewing the Infrastructure Builders Program (IBP) Bounty #50 in more detail, several questions have arisen.

1 - Pricing model (AWS / Google vs actual providers)

According to the last top-up proposal, the nodes pricing appears to be based on AWS and Google Cloud benchmarks.

However, according to the IBP dashboard, in practice, some services are delivered by Hetzner or even by operators without a clearly identifiable entity.

Why is the base pricing calculated using premium cloud providers if the services are ultimately delivered by significantly cheaper operators? This approach seems problematic, as it enables certain providers to capture the price difference without clear justification.

2 - Large price discrepancies for the same service

Tender #3 spreadsheet of Public RPCs for Relay and System Chains (Bounty #31) shows offers from node providers to run a Polkadot Relay Chain node at an average cost of approximately $2,200 per month.

Why, then, is the IBP Bounty paying between $4,000 - $5,000 per month for what appears to be the same service?

Doesn’t this indicate that the IBP base pricing model may be inflated, as previously suggested, given that providers are demonstrably able to deliver the same service for significantly less, as shown by the tenders under Bounty #31?

3 - Parachain RPCs

The IBP Bounty, and ultimately the Polkadot Treasury, is currently funding RPC services for parachains such as Hydration, Moonbeam, Bifrost, Nexus, Ajuna, Unique, and Xcavate.

Why are RPC nodes funded for some parachains but not others? Who makes this determination? Shouldn’t this responsibility rest with the projects themselves and their token holders?

4 - System chain RPCs

Do we really need 7 or 8 RPC providers per system chain?

5 - Potential double payments (LuckyFriday)

LuckyFriday is currently being compensated by the IBP Bounty for 23 services, including:

  • Polkadot Relay
  • Polkadot Asset Hub
  • Polkadot Bridge Hub
  • Polkadot People

However, these same services appear to already be funded under Public RPCs for Relay and System Chains (Bounty 31). How is this potential overlap being addressed?

Spreadsheet Bounty 31
LuckyFriday payment - Bounty 31

6 - Curator paid $3400 per month
Finally, there is also the matter of Coinstudio receiving $3,400 per month as a curator, without it being clear what specific work is being performed in exchange for this compensation.

Given the significant amount of funds involved, I would appreciate some clarification to better assess whether this bounty is being managed properly.

  1. Those are the ASNs of those making DNS queries in order to utilize the service. :joy:

  2. IaaS pricing is based on utilization and utilization is dynamic. Utilization is updated regularly here and base pricing is here

  3. This was defined in the last top-up on pokadot #1516

  4. Yes, it’s for latency optimization to increase quality of service globally. This was discussed extensively in KSM #35, on AAG, and in other places.

  5. Lucky friday provides RPC services from their location in Arizona I believe and their services for the public bounty in their location in washington d.c

  6. This was resolved in another thread

With such basic errors I have to assume that you’re rage bait trolling and not actually challenged in any way. With that said, good one :rofl:

Sorry, but I still don’t fully understand why there are DNS queries going through Hetzner. Which providers are these services actually hosted with? Can someone verify this?

It’s also still unclear to me how the potential double payments involving LuckyFriday across different bounties are being handled. Likewise, I don’t understand how the same Polkadot RPC service can be paid $5,000 under one bounty and $2,200 under another.

Perhaps another member of the community can provide more information on this.

Thank you.

Those are the USERS of the service, not the PROVIDERS. We would never record ip addresses of actual rpc users however DNS presents an opportunity for data collection from a 3rd party. The DNS server isn’t technically the RPC client because of the way DNS works. Since we’ve implemented this custom DNS system it allows us to use the DNS query as a proxy for the user to get a general sense of location. (Metadata-esque) This is useful to get a sense of global load and how that changes over time so we can track load from countries / regions and determine how best to update things in the future. It’s also used by the DNS system to globally manage load and members. It’s important to note that these are dns queries not rpc queries. Our RPC query handling is into the billions a day. These are DNS lookups that are done prior to connecting to the rpc server and a single DNS query could represent 10s, 100s, 1000s or 10s of 1000s or even millions of rpc queries.

I mean, on the dashboard there’s a map that gives you the exact latitude and longitude of the datacenter for each member. You can verify it by looking up that member’s corresponding ip address. Not sure what else you could want…

Lucky friday has multiple datacenter locations as do many other providers. Stake Plus has servers located in Washington DC and Cincinnati OH. Dwellir has locations in Sweden, 2 in Africa, and some others that I can’t recall right now. Lucy friday is providing IBP services from one location and providing the public bounty rpc services from another location. 2 sets of hardware, different physical location, etc. Curators have been provided necessary documentation to verify contracts, locations, hardware deployments, etc. Again, it’s all in the proposals for how the program will be run going back to KSM #35.

Thank you very much for the clarifications — I genuinely appreciate them.

It is clear to me that LuckyFriday operates data centers in multiple locations. However, I still don’t fully understand why the same service, for example a Polkadot Relay Chain RPC node, is being provided under two different bounties.

Isn’t this a form of duplication? Why aren’t other operators doing the same?

I also don’t understand the price difference between the two bounties for what appears to be an identical service. Even accounting for operator margins, why is the same service provided for $2,200 under one bounty and $4,000–$5,000 under another?

Finally, isn’t there a certain overlap between Bounty #31 and Bounty #50?

Which services are you referring to? I’m not familiar with how bounty #31 operates, costs, structure, or anything. But my general understanding is that it’s individual providers, providing single sets of services from a single location. Meaning, they do not work together in a unified way to optimize for global coverage.

The IBP is focused on global latency optimization in a decentralized way which essentially means regional slots and people being able to apply for regional slots. As the slots fill up we end up with different wholly owned providers in each region and where if any one provider goes down others in near by regions can cover the load. However, all providers are required to work together in a unified way that provides standardization to endpoints which allows us to use services like geodns, anycast, etc to automatically route an end user to their closest rpc server. This is really important for any end-user facing application because many rpc calls are synchronous. This means that, you make one call and the output of that call is used as input for another call. If it takes you 200 milliseconds round-trip per request from the rpc server and your longest string of synchronous calls is say 20 that means your application will take 4 seconds to populate and become usable. If it takes you 30 milliseconds round-trip per request from the rpc server and you have 20 calls your application becomes usable in 0.6 seconds.

It’s really not rocket science, faster = better.

In addition to all this, the providers own their own hardware, operate their own networks, own hypervisor clusters, etc. No one is hosting on google cloud, hetzner, etc. There are rules regarding redundancy, performance, etc.

I can’t speak for anyone else, but I was focused on building out this DNS system as well as trying and failing to deliver on 601. We even passed on a few system chain collator seats because I didn’t want to deal with it. Everyone kind of has their own thing in addition to the IBP. Every IBP member has been involved in the ecosystem on other levels beyond simply providing RPC services. We each have our own interests, desires, and paths, it’s not that strange.

Edit:

I should add, global latency optimization will be important in the future as we move to light clients because of how it’s possible to do the same latency optimization through decentralized networks of nodes by utilizing laws of physics to determine distance between 2 nodes on a network (or the internet) and the network as a whole coming together with consensus as to nodes physical proximity to other nodes.

It’s then possible to have automatically generated sets of nodes where when a new light client comes on to the network it can announce its location and quickly find out the nearest set of nodes to pull data from. By having this global network bootstrapped it will allow light clients to be a success and not just light clients but native storage and every other requisite and end user facing service that will be deployed in the future. (We’re also the logical service providers for any computationally verified services that will be offered in any future market places).

Thank you very much for your input, but I still don’t understand why LuckFriday can run a Polkadot RPC node in a bounty at a price they offered in a tender for $2,200 (supposedly including their profit), and then offer the same service in another bounty for $4,000–$5,000.

I must be missing something, but it doesn’t make sense to me.

It seems that the base pricing using AWS and Google Cloud in IBP Bounty is inflated, and in my opinion, not all operators actually provide these services using those providers or at those prices.

I imagine someone with the right expertise could verify this.