[Proposal: MB5/MR1] Dwellir - RPC Infrastructure Q3 Moonbeam

Governance Treasury Proposals
, ,
1

RPC Infrastructure Q3 Moonbeam

Abstract - Dwellir is a leading IaaS (infrastructure as a service) team providing RPC infrastructure to more than 25 projects in the Dotsama ecosystem. We are proposing to receive payment for a geographically distributed public Moonbeam RPC API Service.

This service is currently available via:

wss://Moonbeam-rpc.dwellir.com
https://moonbeam-rpc.dwellir.com/

Motivation - a statement on why the Moonbeam Community via the Treasury Council should support the MBTP.

Project Overview and Team Experience -

Team

The Dwellir crew has over a decade of experience in the crypto domain and aims to expedite the development of web 3.0. We are experienced computer scientists, entrepreneurs, and crypto enthusiasts that share the ideas and philosophies around a free and decentralized web.

Gustav Nipe - CEO

Entrepreneur and political activist. Worked several years for the Swedish Pirate Party on privacy issues. Previous CTO at ImpactVision Inc (Acquired by Apeel Science 2020) a startup spawned from the Google Singularity University.

Erik Lönroth - DevOps lead

Technology Lead for High Performance Computing at Scania, past CIO ImpactVision Inc. Board member of Open Source Sweden.

Joakim Nyman - Solutions Architect

DevOps engineer at Imint AB, past lead developer at ImpactVision Inc.

Christian Ander - Institutional Partnership

President and founder of Goobit Group, a publicly traded crypto exchange in Sweden, BTCX.

Ankan Anurag - Senior Engineer

Senior engineer at Dwellir, past senior engineer at P.F.C. and Klarna.

Ben Chatwin - Operations Has worked for several high-tech startups in drones, machine learning and more recently for deFi projects across multiple blockchain ecosystems.

Dwellir is an infrastructure provider for the decentralized web. We run RPC services for Kusama and Polkadot and more than 26 other projects. Currently, we are processing 60 million JSON RPC requests per day.

We also provide validator/collator services for the networks [Kusama], [Polkadot and KILT and participated in the Thousand Validator Programme for Polkadot & Kusama.

We own and operate our own bare metal which has two important effects. The first is that we directly contribute to the real decentralization of the network away from public cloud providers. The second is that we can deliver an often better functioning service at a fair price.

Lastly, we are builders. We are working on a suite of tools associated with our infrastructure that aim to give insights to the community. An example of this work is a report produced for Parity. See the attached document for a link to the project.

Rationale -

Milestone 1 - Providing RPC services for Moonbeam

Setting up blockchain infrastructure is difficult, time-consuming, and expensive:

  • It requires a level of DevOps skills that many do not have. A Moonbeam node, for example, requires knowledge of SSL certificate handling, WebSocket management, HTTPS management, firewall configuration, security measures, monitoring, reporting, upgrades etc.
  • It’s extremely costly to run a node. Since we own and operate our infrastructure our cost structures are fair and more sustainable than cloud providers where one can expect huge increases in price.
  • Running production-level infrastructure is not trivial. You need to autoscale quickly to handle sudden increases in traffic which is very common when new projects launch. Our infrastructure uses a smart cluster stack whereby sudden increases in traffic are expertly scaled up and down as needed without the need for intervention.
  • It requires time. Time is the most valuable resource for projects. Most projects simply do not have the time to spend on DevOps, especially in crunch moments.

Key Terms (optional) - definitions of any terms within the proposal that are unique to the MBTP.

Overall Cost -

USD : $7,072.20
GLMR : 14,557.84 @ token price ( $0.4858)

More details in the attached document:

Use of Treasury Funds -

Scope

We are builders first and want to ensure that we provide infrastructure and additional services that meet the community’s needs for the next decade!

This grant will enable us to continue the service we currently provide which entails:

  • Hosting of the Moonbeam node(s)
  • 24/7 Monitoring of core functions including scaling mechanism
  • Continuous security improvements
  • Continuous updates, upgrades, and optimisations
  • Communication with development teams (where necessary)
  • Currently we operate three clusters in Northern Europe.

Outcomes

There are three main outcomes:

  1. Improve the decentralization of the polkadot ecosystem by providing our own bare-metal infrastructure
  2. Improve the user experience within the Moonbeam ecosystem by ensuring the reliable availability of the network.
  3. Strengthen the team’s ability to work on core business problems as a result of reducing the strain on DevOps. We believe it’s important that parachain teams innovate on their core technology rather than spend time and resources on DevOps where we are clearly positioned to take the load.

Specifications -

We own and operate our own bare metal which has two important effects. The first is that we directly contribute to the real decentralization of the network away from public cloud providers.

This is a combination of world-class hardware, open-source scalable software for managing complex infrastructure and our own custom monitoring stack.

Steps to Implement -

We have already implemented this technology and have been running the chain successfully for more than 6 months. In the last 30 days, we processed more than 300 million requests for the users of Moonbeam and we’re looking forward to processing another 10 billion!

1 Like
2

Hey, Ben! Thank you for your proposal! I was very glad to get acquainted with it.

Following the official Moonbeam docs, I see that there are four Endpoints providers available right now that our users can use. Unfortunately, I don’t see Dwellir in this list.
I also didn’t see on your website that you support the Moonbeam network.

Based on this, I have a few questions, it is interesting to know your vision:

  1. Is there any reason why you are not added to Moonbeam docs as one of the available RPC providers?
  2. How do users find your endpoints if there is no information that you support the Moonbeam network?
  3. As you can see, there are already four public RPC providers that our users can use, why do you think there is a need to continue expanding this list?
  4. Do you have any additional advantages?
  5. If the number of requests increases dramatically, is your infrastructure ready to cope with the high load?

btw, I noticed that you need to make some adjustments, namely:

I think it would be nice to remove it.

it looks like you missed this link:
https://moonbeam-rpc.dwellir.com

this probably needs to be removed too at this stage.

3

Thank you for your questions. They’re very relevant and thankfully quite easy for us to answer as we have been a long time supporter of the project.

1. Is there any reason why you are not added to Moonbeam docs as one of the available RPC providers?

We have previously been in the documentation. We removed ourselves recently because we were going to close down the service as a result of being unable to fund our services.

2. How do users find your endpoints if there is no information that you support the Moonbeam network?

We have every intention of adding our endpoints back assuming we’re successful with this application.

Also, our endpoints have previously been available via polkadot.js.org. We will also make a PR to make our endpoints available there.

3. As you can see, there are already four public RPC providers that our users can use, why do you think there is a need to continue expanding this list?

Due to the fact that our endpoints are being used to such a large extent it seems evident by the traffic that we are indeed a relevant service already.

4. Do you have any additional advantages?

Our infrastructure is owned and operated. We don’t use public clouds such as AWS, Google. Therefore supporting Dwellir is supporting decentralisation.

5. If the number of requests increases dramatically, is your infrastructure ready to cope with the high load?

Yes, our infrastructure is highly scalable. In the case of Moonbeam we have done 20x since last month with no downtime.

I believe I have addressed your other adjustments to the formatting of the proposal.

1 Like
4

Crystal clear. Thank you so much for answering all my questions, Ben. I really appreciate it!
Good luck to your team, I will be glad to see your endpoints again in Moonbeam docs!

1 Like
5

Hi Benn,

Maybe I missed it, but is this request to cover which period of time for the service provided?

6

This proposal is for Q3. The service is still up and running and if successful we plan to apply for Q4 in January.

The nodes have previously been available via polkadot.js.org since February. Here is the PR.

We recently removed them from polkadot.js.org due to failure to procure funding. We’re still receiving high volumes of traffic because developers in the ecosystem have already onboarded us as providers.

7

Hey sir, the services provided and for which to request the tip, involve only the Moonbeam network? or also moonriver?

8

This application is for Moonbeam only. Should we add Moonriver here or make an application to the Moonriver team for this?

I noticed OnFinality added Moonriver to their proposal. We are happy to do the same if you think it is appropriate.

9

It seems to me that when you provide a service for Moonriver, it makes sense to create a separate proposal for Moonriver, where you will request a MOVR token as payment for your services. but I’m not a member of the council, so you should probably wait for their feedback :slight_smile:

10

It would be better for the discussion to include the information related to the Moonriver service in the same proposal.

given that in this case the Council is made up of the same people

with its distinction in $ of how much would be the tip requested by that moonriver service

and how much is it for moonbean

11

I have updated the embedded proposal with the costs for Moonriver also. I have quoted them in GLMR.

12

Thanks u, will check it when i have time :+1:

1 Like
13

Hey Ben, i think the amount requested for the service for Moonriver should be in MOVR.

14

If the council wants to pay for both here. Then just let me which currency, it’s just a simple math calculation at the end of the day. Ideally, we’d like to reduce the amount of work for the teams involved.

Are there any other major outstanding questions apart from this?

15

@turrizt - are you able to update this template with our proposal submissions?

Moonriver : https://moonriver.polkassembly.network/treasury/1

Moonbeam proposal: https://moonbeam.polkassembly.network/treasury/5

16

Hey, Ben. I changed the title, I think you can edit your post by adding a links to on-chain proposals

17

hey @Benn , first of all I would like to thank you for the service provided to the networks

Now, if you could answer the following questions, the community and the Treasury Council can have a better idea of everything that the proposal and its services represent, thank you

  1. Do you offer decentralized hosting? Describe this in detail
  2. Provide metrics around the volume of the Moonbeam ecosystem traffic you are currently handling
  3. What plans (if any) are in place to convince dApps and end-users to switch to your RPC solution
  4. Describe any future cost saving plans
  5. Describe monetization and revenue model
18

Thanks for the questions:

  1. Do you offer decentralized hosting? Describe this in detail

We currently do not offer decentralised hosting. We host all of our own servers and infrastructure. This is the most optimal and safest way to provide a high-quality service. Our experience and dialogues with other projects in the Polkadot ecosystem and others suggest that decentralised hosting is a risk in delivering high-quality uptime, a security risk and quite frankly a legal risk. Who is to determine the persons/organisations behind these nodes?

  1. Provide metrics around the volume of the Moonbeam ecosystem traffic you are currently handling.

For the current proposal, we processed 220 million requests over the three-month period. We are on track to triple this (costs will NOT triple).

In the last 30 days, we have processed roughly 300 million requests - https://stats.dwellir.app/ (currently being updated with new chains so there are delays in statistics)

  1. What plans (if any) are in place to convince dApps and end-users to switch to your RPC solution

We plan to relist our RPC endpoints in your documentation and on polkadot.js.org. Your community is already well aware of our nodes and uses them regularly. We only expect this to continue. This is with consistent marketing of our services via Twitter, discord and other Polkadot developer communities in which we are active.

  1. Describe any future cost-saving plans

Due to the fact that we run our own infrastructure and have an autoscaling software stack, our cost structure scales much better than public cloud providers such as AWS and Google. You can expect costs not to rise significantly. We can certainly say that our cost structure will be significantly better than some of our competitors.

Assuming that there are minimal memory leaks in the chain software (which has been an issue in the past), RAM usage should not increase dramatically which is the major cost centre. Data transfer is a cost that does not increase prices significantly.

Should there be a need for an extra geographic node this could increase costs though we would ensure to have this discussion with the team prior.

  1. Describe monetization and revenue model

We’ve included operating and hardware costs in the pricing structure presented in the application.

19

@jose.crypto do you have any more questions at this stage?

20

Thanks for all the answers

Personally, the use of these points does not seem high enough to benefit a large part of the community and thus be able to opt for the treasury payment

In addition, removing and adding points every X time from polkadot.js does not help to stabilize its use either.

Even though I am in favor of having different options, if they are not used it really is useless and these resources are not used.

maybe apply a better pattern to attract clients and request, for future proposals?