Thanks for sharing the reports and being transparent.
It seems to give us more insights in regard to where the query are coming the most and stability of the RPCs, etc. Looks very nice!
I was curious and would like to understand more about the reports, it’d be great if I can know the following three points further:
What is the column 429 for?
It seems there is no failed query (or request) from RadiumBlock team, which looks very stable. Perhaps, this report would also help the Blast API team to look into the error message also shared in the report?
Kudos, RadiumBlock! Impressive RPC services, transparent operations, and a forward-looking Astar-Shiden RPC proposal. Your commitment to performance and decentralization is valued. Excited for a successful Q2 and Q3 collaboration!
Hello all glad to hear the comments from you all !
We are excited for our collaboration and look forward to expanding our service to Shiden soon.
@Gaius_sama we are unable to edit the original post so posting updated ASTAR token count here(based on EMA30). We have also updated the original google docs proposal.
EMA30 on November 16, 2023 = US$0.06
Requested Allocation 143966.67 ASTR
@pithecus our understanding is that 429 refers to the HTTP error code for too many requests.
We would like to make it clear that comparenodes is a third party service. We were also not trying to pick on Blast API or any other provider rather just looking to demonstrate the quality of our service. Anyone can use comparenodes’ services to measure as well as analyze endpoints, so yes it may be useful to Blast API team.
Thanks for the detailed response.
I am also fully aware that you did not pick up a specific RPC for comparison. What I meant was also the same as your opinion that any RPC provider can check the performance based on the report and make use of it for maintenance or so
It’s very important to have a reliable RPC node with good uptime and low latency. I think you guys are doing a great job, and thank you for being very transparent and generating some benchmarks so the community can understand the importance of this.
I voted no for this because Astar Network already has more than enough RPC providers for public users. What’s the extra value having Radium beside having:
Blast
OnFinality
Dwellir
Astar Foundation RPC services
That also use Treasury for their services (except Astar Foundation RPC services, this is paid with our runway)
I prefer treasury being used on projects or infra projects that fill in a missing gap than using treasury for your own business. I see more value in providing RPC services from project demand that you acquire to the Astar ecosystem.
I am happy to support this proposal on my side, as RadiumBlock has provided a high quality service with a very limited cost.
But this may be the last time I do, not only to RadiumBlock but to all external RPC providers: the community needs guidance rather than competition between providers.
We need RPC providers to work together and agree on a sustainable infra cost and unified metrics so the community members can understand the point of it.
At Astar team, we have been working very hard on reducing our own infra costs to make it sustainable and fit to the need of users.
If RPC providers can’t collaborate together and propose something common and understandable to the whole community, I will vote no to each next proposals.
