Treasury Proposal - High Performance Public Infrastructure (Milestone 1)
OnFinality is a SaaS platform providing infrastructure services for the Polkadot/Substrate community. We just launched our beta version of a shared node API Service and are already listed in the Polkadot.js app. This service expands on our core mission - to support all blockchain developers in the world by providing core infrastructure so they can focus on building the next dApp.
Setting up blockchain infrastructure is difficult and time consuming, and requires a level of server development expertise that many don’t have. We're applying for funding to scale and improve our platform to provide a level of service and resiliency for production ready applications. This proposal consists of two milestones, and this application is for just the first:
- Implement more comprehensive user analytics and reporting so that each developer can report on exactly what requests are being made to their API service account, and use this data to improve their own dApps
- Geolocation routing that allows us to maximise the use of different pools of nodes across our user base, and allows us to quickly fall over to alternative pools in the case that one goes offline
More Info:
- We just served over 3.2 million requests in a single day on the 6th of January 2021 to our free API service
- We’ll maintain our free tier for users of 500,000 requests a day while funds to run these nodes remain. This is so we can maintain and ensure that Polkadot is accessible by all, from the largest and most funded development teams, to the many amateurs tinkering away.
- In the future, we may provide additional paid tiers of API Service usage above those 500,000 daily requests at different costs structures
- We’ll maintain the one click deploy dedicated node access to Polkadot for customers that need more than what our API service is intended for
- You can access our public API service by creating a free account for our admin portal, or by connecting to it using Polkadot.js
You can read more on this treasury funding proposal at https://docs.google.com/document/d/1UCH0_mriTXqs1E-o4QBDFxQCaL90bYjJEb92Wusq6J4/edit?usp=sharing
Additionally, you can talk to us on Telegram at t.me/onfinality
Comments (2)
Comments (2)
Happy to see more infrastructure projects in the community, but some descriptions about Elara need clarification.
As far as I know, Elara has significant differences in technical architecture and services compared with other similar projects:
- First of all, the most important point is that Elara's back-end architecture is not a simple node pool+load balancer. Because, although the node pool+load balancer scheme is simple, it is extremely inefficient.
Unable to bear the impact of large-scale applications and traffic, the architecture cannot be expanded.
Elara is different. The core of Elara is a complete distributed system, which requires only a small number of nodes to provides basic data sources as the basis. Elara adopts a distributed architecture design and a multi-component and multi-service approach.
It supports the access of a large number of users with extremely high performance, and also guarantees high availability. In addition, it also provides a highly scalable architecture that can easily cope with the development process of the polkadot ecosystem at different stages. - Second, Elara provides free 1,000,000 requests for every project every day for developers in the community
- Third, Elara will soon support 10+ mainnet in the next upgrade of v0.3, and v0.4 will add monitoring、automated operation and maintenance、automated expansion and deployment functions, etc.
In short, Elara is lightweight and powerful, and the service capabilities provided to developers are far greater than the capabilities provided by its own deployment nodes.
The API service provided by Elara not only includes the functions of all nodes, but also includes historical status data functions, as well as DApp request statistical dashboard analysis and other functions.
There is some detail in our proposal writeup but I'm happy to expand on it here.
To your first point, OnFinality is also designed as a distributed system from day 1. Our understanding of Elara's technical architecture shows that Elara routes different requests to different nodes via a router proxy. In the end the chain nodes are still servicing user's requests. We are proposing a similar architecture in this proposal, but by using distributed pools of nodes – we’d love to see some reasons behind your assertation that “although the node pool+load balancer scheme is simple, it is extremely inefficient. Unable to bear the impact of large-scale applications and traffic, the architecture cannot be expanded”. We have the same goal of supporting large numbers of users around the world and are also confident that we can provide highly scalable architecture for the entire polkadot/substrate ecosystem.
We've done some stress testing before we launched the beta phase (and are using this beta to confirm these numbers). We've tested that a single node can support ~250 simultaneously connected users making a total of 3,200 tps. As a result, a small pool of 3 nodes could theoretically handle 9,600 transactions per second.
Second, we provide 500,000 free requests every day. Although we are not planning on removing this tier currently, we are considering doubling it to match Elara's. A key point to note is that we are yet to see a single user even approaching this daily limit.
And to your third point, it seems strange to compare future work planned by Elara to what OnFinality already offers? We already support multiple mainnet and testnets for different networks. We have automated management APIs already published and have robust support for dedicated one-click nodes and infrastructure management services.
I think it is important to note the cost aspect of our platform compared to Elara, since the treasury will likely contribute a proportion of these costs. In a previous proposal Elara quoted $14,000/month for a cluster with 7 nodes servers, we are quoting less than a 10th of that ($1,101.60) for a slightly smaller pool size (https://polkadot.polkassembly.io/treasury/16#c36677ad-289f-4818-b405-f3503de751ea). We can run a small pool of productionised high-performance nodes (3 initially) behind a load balancer for a lower per unit cost.
In summary, we are confident we can provide a more performant and scalable solution with the expertise in blockchain infrastructure in our team and our approach to load balancing. We also have a more complete family of infrastructure management products to support the community and are focused on expanding and improving this.
Happy to see more infrastructure projects in the community, but some descriptions about Elara need clarification.
As far as I know, Elara has significant differences in technical architecture and services compared with other similar projects:
Unable to bear the impact of large-scale applications and traffic, the architecture cannot be expanded.
Elara is different. The core of Elara is a complete distributed system, which requires only a small number of nodes to provides basic data sources as the basis. Elara adopts a distributed architecture design and a multi-component and multi-service approach.
It supports the access of a large number of users with extremely high performance, and also guarantees high availability. In addition, it also provides a highly scalable architecture that can easily cope with the development process of the polkadot ecosystem at different stages.
In short, Elara is lightweight and powerful, and the service capabilities provided to developers are far greater than the capabilities provided by its own deployment nodes.
The API service provided by Elara not only includes the functions of all nodes, but also includes historical status data functions, as well as DApp request statistical dashboard analysis and other functions.
There is some detail in our proposal writeup but I'm happy to expand on it here.
To your first point, OnFinality is also designed as a distributed system from day 1. Our understanding of Elara's technical architecture shows that Elara routes different requests to different nodes via a router proxy. In the end the chain nodes are still servicing user's requests. We are proposing a similar architecture in this proposal, but by using distributed pools of nodes – we’d love to see some reasons behind your assertation that “although the node pool+load balancer scheme is simple, it is extremely inefficient. Unable to bear the impact of large-scale applications and traffic, the architecture cannot be expanded”. We have the same goal of supporting large numbers of users around the world and are also confident that we can provide highly scalable architecture for the entire polkadot/substrate ecosystem.
We've done some stress testing before we launched the beta phase (and are using this beta to confirm these numbers). We've tested that a single node can support ~250 simultaneously connected users making a total of 3,200 tps. As a result, a small pool of 3 nodes could theoretically handle 9,600 transactions per second.
Second, we provide 500,000 free requests every day. Although we are not planning on removing this tier currently, we are considering doubling it to match Elara's. A key point to note is that we are yet to see a single user even approaching this daily limit.
And to your third point, it seems strange to compare future work planned by Elara to what OnFinality already offers? We already support multiple mainnet and testnets for different networks. We have automated management APIs already published and have robust support for dedicated one-click nodes and infrastructure management services.
I think it is important to note the cost aspect of our platform compared to Elara, since the treasury will likely contribute a proportion of these costs. In a previous proposal Elara quoted $14,000/month for a cluster with 7 nodes servers, we are quoting less than a 10th of that ($1,101.60) for a slightly smaller pool size (https://polkadot.polkassembly.io/treasury/16#c36677ad-289f-4818-b405-f3503de751ea). We can run a small pool of productionised high-performance nodes (3 initially) behind a load balancer for a lower per unit cost.
In summary, we are confident we can provide a more performant and scalable solution with the expertise in blockchain infrastructure in our team and our approach to load balancing. We also have a more complete family of infrastructure management products to support the community and are focused on expanding and improving this.