[Proposal: XX] Blast support for Moonbeam, Moonriver, and Moonbase alpha (Q2 & Q3 2024)

Governance Treasury Proposals
, ,
1

Abstract - Ongoing costs for supporting Moonbeam, Moonriver, and Moonbase alpha networks in BlastAPI (https://blastapi.io). These costs are ongoing for as long as the Moonbeam, Moonriver, Moonbase alpha ecosystems need this service and are requested on a quarterly basis. The costs requested are for Q2 & Q3 2024 (from April 1 to September 30, 2024).

Motivation - Easy, fast, and reliable access to high-performance HTTP and WSS APIs for all Moonbeam, Moonriver, and Moonbase alpha networks through https://blastapi.io in just a few clicks. Moonbeam, Moonriver, and Moonbase alpha builders can focus on developing their applications without worrying about running and maintaining infrastructure.

Project Overview and Team Experience - Blast is Bware Labs’ API provider platform that aims to solve Web 3 infrastructure issues related to reliability and latency, by employing geographically distributed third-party nodes.

Blast offers a multi-region architecture that, along with a series of clustering and geo-location mechanisms, ensures optimal routing of user requests to the closest point of presence relative to where a call is generated.

The development and maintenance of the Blast platform are provided by a highly technical team of engineers with proven experience in both Web3 and Web2 projects.

Rationale - We support Moonbeam, Moonriver, and Moonbase alpha networks in Blast API platform (https://blastapi.io ) so blockchain developers that are building their dApp on can bypass all the hurdles involved in running their own infrastructure thus reducing both their outage risks and infrastructure costs.

Overall Cost - The total cost, including three regions’ support for Moonbeam, Moonriver plus Moonbase alpha (EU, US, and APAC), is $4500 per month, meaning $27000 for Q2 & Q3 2024 payable 60% in Moonbeam Network (GLMR) and 40% in Moonriver (MOVR), tokens that are calculated at an average USD price over the last 30 days. The costs for Q2 & Q3 of 2024 (from April 1 to September 30, 2024) are 40041.89 GLMR and 476.24 MOVR.

Use of Treasury Funds - The funds will be used to pay for the infrastructure and maintenance of the Moonbeam, Moonriver, and Moonbase alpha nodes between April 1 to September 30, 2024.

These funds will be directed to cover the costs from the infrastructure providers that are used for the Blast backend like Amazon Web Services, Google Cloud, Hetzner, OVH, Servers.com and Digital Ocean and our internal resource cost for the support provided by our engineering team to have high quality infrastructure services for Moonbeam, Moonriver, and Moonbase alpha networks.

Specifications - On our decentralized, multichain, subscription-based, API platform, Blast we support Moonbeam, Moonriver, and Moonbase alpha networks with the following services and specifications:

  • Expose RPC and Websockets APIs for Moonbeam, Moonriver, and Moonbase alpha;
  • The Service availability is at least 99.9%;
  • 24/7 Monitoring and alerting for reduced downtime.
  • 24/7 On-call engineering support.
  • Developer support on Bware Labs Discord Channels.
  • The incoming traffic is Geo-load balanced over three regions: North America, Europe, and the Asia Pacific, with automated traffic routing for optimal response times.
  • The Clients that use the Public API free version of Blast are limited to 100 API Calls/second.
  • 12 Million API calls/month with a throughput of 40 API calls/second offered for free to Moonbeam, Moonriver, and Moonbase alpha users on each dedicated Blast account
  • Total traffic supported on all subscription plans and Public API: 3700 calls/second per region per network.
  • Multi-region node hosting: Moonbeam (EU, US, and APAC), Moonriver (EU, US and APAC), Moonbase alpha (EU, US and APAC)
  • Support for Debug and Trace methods
  • Support for eth_getLogs RPC method
  • Security ensured through continuous integrity monitoring coupled with a smart routing mechanism significantly reduce the risk of malicious behavior from bad actors within the ecosystem

Through Blast API decentralization third party nodes can join the protocol for Moonbeam, Moonriver, and Moonbase alpha networks, and earn rewards for their contribution. More details about this can be found here: Blast protocol - Blast Documentation 1

Public APIs:
https://moonbeam.public.blastapi.io

wss://moonbeam.public.blastapi.io

https://moonriver.public.blastapi.io

wss://moonriver.public.blastapi.io

https://moonbase-alpha.public.blastapi.io

wss://moonbase-alpha.public.blastapi.io

Dedicated APIs:

https://blastapi.io

Blast API Usage Report for January & February 2024:

Steps to Implement:

We’ve been supporting Moonbase alpha and Moonriver networks since June 2021 and Moonbeam network since January 2022. We will continue our support as long as the Moonbeam, Moonriver, Moonbase alpha ecosystems need this service.

2 Likes
2

Dear @Mihai_BwareLabs,

The @TreasuryCouncil would like to thank you for submitting the above RPC service provisioning proposal!
Methods and regions provided are great, as are the overall number of calls. No objections from a technical point of view and we appreciate Blast as a proven, reliable RPC service provider.
However, compared to other high quality RPC service provider proposals submitted, price-wise yours is still simply not competitive. Despite differences to your RPC services proposed, looking at your regular pricing offers at https://blastapi.io/pricing the overall costs proposed feel out of range as well, especially with regards to the price/scale ratio as this is an economy of scale.
While we are considering your proposal, would you be willing to put a more competitive price tag to your RPC service proposal for the upcoming six month period?

To stay on schedule we’d appreciate a reply in a timely manner, ideally by next Wednesday, March 13th.

Thanks & kind regards :sparkles:
Yaron

1 Like
3

Hey @_yrn , thank you for your input!

Regarding your feedback, we’d like to clarify that the current proposal is covering the infrastructure and maintenance costs related to the Public API and the free dedicated Blast account support for Moonbeam networks.
However, it’s important to note that the proposal does not cover the infrastructure and maintenance costs for the Blast paid subscription plans (Pricing - Blast API), as it’s tailored and scaled according to the needs of our customers.

We would like to emphasize that, in contrast to proposals from other RPC providers, our proposal includes support for three regions: North America, Europe, and the Asia Pacific and a Public API limit of 100 API calls/second.
The previously mentioned limit of 25 API calls/second for the Public API free version of Blast was inaccurately stated in our proposal and has been corrected. We would like to clarify that we have supported the Moonbeam networks on the Public API with an increased limit of 100 API calls/second since 2022.

Given the high-quality infrastructure services we offer and have consistently provided for Moonbeam, Moonriver, and Moonbase Alpha ecosystems, we kindly ask the Treasury Council to appreciate that maintaining the current level of quality while reducing the requested funds would present challenges.

4

Can you break down this $4,500 monthly costs?

Working at Dwellir I have a very good understanding of the costs involved and this doesn’t add up.

5

@micheleicebergnodes @dev0_sik @_yrn - Any other feedback here? :pray:

6

Hey @AlbertoV19 :space_invader:

The @TreasuryCouncil had decided not to move forward with Blast’s funding proposal as their asking price was just not competitive by a large margin.
This I had pointed out above and no competitive offer with a slightly more reasonable asking price was made.
In the end competition is a good thing, but you can’t always win :sparkles:

2 Likes
7

Hey @TreasuryCouncil ,

We understand your position and respect your decision.

We understand your direction of creating an competitive environment between the RPC providers from your network, we usually don’t compete by comparing ourselves with the other infrastructure teams, but we feel that the following analysis might be helpful for the future references.

Let me start with a principle, that states that the infrastructure costs are growing with the number of users and the number of requests.

Going from there, we can analyse the number of requests fulfilled that all the other providers shared in their proposals with the grant proposal attached:

  • UnitedBloc - 1.7B reqests/quarter, $10800/quarter, (status - accepted)
  • Dwellir - 2.3B requests/quarter, $4600/quarter, (status- accepted)
  • OnFinality - 3B requests/quarter, $9,600/quarter, (status - accepted)
  • Blast API - 6.2B requests/quarter, $13500 /quarter (status - rejected)

Based on that, you can also see the market share each provider has:

  • UnitedBloc - 12.8%
  • Dwellir - 17.4%
  • OnFinality - 22.7%
  • BlastApi - 46.9%

If you calculate the costs per billion request per each provider, you can see that you have a relative cost to the numbers of users:

  • UnitedBloc - $6.3k / 1B request;
  • Dwellir - $2k / 1B request;
  • OnFinality - $3.2k / 1B request;
  • BlastAPI - $2.1k / 1B request;

To @benn_69 's point, from his perspective, our costs didn’t add up, but compared with the actual usage, we are at similar pricing as Dwellir, when looking on the actual usage of the service.

This is an exception of our rule of not comparing with our colleagues in the industry, but the truth is that these proposals are always subjective. From our perspective, the dApps from the ecosystem should have a say on who they would want to support, based on the quality of the service and how happy they are with each provider.

8

Hi @flavianbware & welcome to the forum :wave:

We understand your unhappiness about not receiving funding from the treasury after going through the time and effort of entering a proposal.

we usually don’t compete by comparing ourselves with the other infrastructure teams, but […]

This is an exception of our rule of not comparing with our colleagues in the industry, but […]

We would like to emphasize that, in contrast to proposals from other RPC providers […]

Comparing is fine and necessary to stay competitive & I recommend embracing competing in general.

From our perspective, the dApps from the ecosystem should have a say on who they would want to support, based on the quality of the service and how happy they are with each provider.

The ecosystem does have a say and dApps are a part of that.

Exclusively taking into account the total requests served as in your spreadsheet comparison above is insufficient and misleading.
Serving high calls/second rates along with multi-continental low latency for instance is a much greater value proposition compared to the total request served.
Especially as RPC requests are considered “sticky” in general, particularly with more well known brands.
This one number of self-reported, unfiltered total number of RPC requests alone is not equal to the quality of service experienced.
How would a new RPC kid on the block that can deliver the highest quality of services ever get any funding any time soon if it was just for total requests served in the past?

Besides these there are many other factors which came into play here and rest assured the @TreasuryCouncil evaluated all proposals very carefully.
One of these factors is the not insignificant annualized request of $54,000 for one single RPC service provider which ideally there should be more than one but at least three+ of.
Again, as pointed out previously the Treasury Council had neither objections nor doubts towards Blast’s proposal from a technical point of view and all council members would have loved to support it at more reasonable price point. This was expressed clearly and no change to the proposed funding request was made.
Other high quality RPC service providers had proposed their high quality services at a reasonable and much more competitive price tag to the treasury.

Swapping a “hardcoded” RPC node address is work for a dApp dev but at times this transition of PRC service providers may become necessary as in this current scenario where one requested fundings get a bit out of line – from the deciding entity point of view and not the funding requesting party that is.

We are convinced that the now funded, high quality RPC service providers will take on their rising share of RPC requests in our ecosystem and encourage Blast to keep competing and proposing in the future as delivering high quality is half the battle! :sparkling_heart::muscle:

1 Like
9

Hey @_yrn ,

Thank you for taking the time to provide this response. Since it’s a long message, I’ve quoated some parts, added some questions and shared some analysis in the following lines.

May I ask how is the ecosystem involved in this process and how they are encouraged to participated?

Total number of requests is a sign of the quality of the service. If people are happy with the service, they keep on using it, when it doesn’t - they move to another provider. That’s a natural filtering that’s being done by the users.

Getting back to your point that multi-continental low latency is important, one question that comes into mind, is to ask if the Treasury Council did any benchmark by themselves, or if you rely solely on the data that is provided in the proposals?

I’ve took the liberty of running a performance banchmark, using a third-party publicly availalbe tool ( https://www.comparenodes.com/) and this is a summary of the results over all networks:

  • UnitedBloc - Global Average Latency Not Available ( UnitedBloc is not responding to requests made from ASIA region - Connection timeout)
  • Dwellir - 161ms (Global Averarage Latency)
  • OnFinality - 160ms (Global Average Latency)
  • BlastAPI - 143ms (Global Average Latency)

You can find all the reports here.

At the same time, it’s worth mentioning the limits each provider has for Public API offering:

  • UnitedBloc - 32 req/sec
  • Dwellir - 20 req/sec
  • OnFinality - 40 req/sec
  • Blast API - 80 req/sec

If you take all the variables into account (Global Latency, Reqests/s limits and total number of RPC requests served) you get a good overview of the actual costs each provider has, and the value proposition. By simply looking over the numbers, you can see that Blast API is leading at each aspect.

This doesn’t has anything to do with the new RPC kid, the main point is to look at costs from a usage perspective. As an example:
A Provider that serves 1B reqests has to maintain lower infrastructure components and has lower costs compared with one provider that servers 10B requests, while both are maintainng the same level of service. Curios to learn if you agree on this?

The Treasury Council should be a bit more transparrent about the decisions that are being made at the level of all Providers. For us the reason was: “We asked you to come with a more competitive offer, you didn’t and we have declined” It doesn’t sound like many factors were taken into consideration, or at least they have not been communicated clearly and transparently.

We are curious to learn what comparable industry metrics were used to come to this conclusion? We can understand if there are constraints at Treasury level, and there are needed limits for the sustainability of the Treasury -but everything outside of that is dictated by how the industry operates and their parameters.

From our perspective, this is an easy way of seeing it. Putting everyone in the bucket of high quality RPC and high quality services is clearly an overstatement. As we are all different, at a product level and offerings and quality of service. For starters, you can see the discrepancies at the Global Average Latency level shared earlier. It’s clear that we are not at the same level of technology and quality of services.

cc @TreasuryCouncil

10

Hey @_yrn @TreasuryCouncil ,

Just wanted to ping to make sure this doesn’t get lost.

Waiting for an answer from the Council.

11

Hey @flavianbware appreciated. It did not get lost.

While you are waiting, feel free to jump in on @benn_69 from Dwellir’s post above as it seems to have gotten lost. Thank you.

12

Hey @_yrn ,

For an average 2B reqests per month, at a average market price of 2.5$ per million request, the costs are $5000.

13

Hi @flavianbware ,
Thank you for your patience as the Committee synched a response to the many aspects in your post.

Before I move on to answer your questions, I’d like to emphasize that the Treasury Council is dedicated to acting in the best interest for the ecosystem & as such the GLMR and MOVR token holders. For that matter value-add must always be considered greater than the loss through treasury funds spent which at times does include rejecting proposals.

The ecosystem’s GLMR token holders are involved in the process of decision making for Treasury expenditure as they can cast their vote and elect three non-Foundation Council Members to join the Treasury Council via snapshot voting. Aside from that, we are in touch with many of the larger dApp teams and always have an open ear for feedback, wishes and aspects to consider from anyone. The entire treasury proposal process is open and this Forum is a place for exchange and feedback - any dApp team member may chime at any time if there is a RPC SP they would really want to see funded.

To your point on the number of requests being a sign of the quality of service: total number is indeed a sign, but of course isn’t the only factor. There is a certain amount of stickiness when it comes to RPC providers: once a Dapp or other client configures a specific RPC provider URL, it tends to stay configured that way unless there is severe performance degradation. Thus, one can see how an RPC provider that’s been around longer may accumulate more overall requests than newer ones.

As to your question whether the Treasury Council had done any benchmark by themselves: yes, we do benchmark testing ourselves. In one instance, we reached out to one RPC service provider to suggest improving their quality of service based on results we had observed in our testing. Also, our benchmarking internally over a period of time with averaged results are deviating from the results you reported in the Google Sheet above.

.

We absolutely agree that Blast provides excellent service and appreciate the support the team has provided to the Moonbeam community over several years. And while Blast certainly does well when compared to their peers in some aspects, there are always trade offs to consider. For example, it doesn’t seem as though the Blast public endpoints supported eth_getLogs when the council last checked. And of course, it is universally the case for performance metrics that there comes a point where there are diminishing returns for improvements.

The Treasury Council exists to serve the community and values decentralization and transparency. We’re always looking to improve our processes and welcome feedback. Going forward, data summary reports will be published for any decisions made with regards to future proposal votings. As for this particular case, I’d like to reiterate that many technical aspects have been evaluated and measured against alternative RPC service provider proposals and their overall price tag. Not only is the treasury limited in size but funding every proposal would likely neither be in the best interest of the ecosystem nor the token holders.

We appreciate your valuable and long-lasting support of the Moonbeam ecosystem these past years and we look forward to your proposal in the next round of proposals which will occur in July.

3 Likes
14

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.