-
Notifications
You must be signed in to change notification settings - Fork 244
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RPC Redundancy/Failover Configuration #733
Comments
I believe our strategy for the decentralization of RPC Servers is a bit different, but some of these ideas can be implemented. On |
@volovyk-s What is on your mind in terms of a different strategy? I feel near-api-js is the right abstraction layer to deal with the pool of RPC servers to enable true decentralization. |
@frol there are two separate problems. The first one is a stability of a single RPC Server. The second one is the ability to switch to another server when the first one is down (decentralization). As far as I know, our current strategy was to work on stability first (API Keys). For the second one, I agree, usage of multiple RPC Servers with fallbacks on a clientside is the best option. But we will need to design it carefully, simple fallback on each call can be slow. And we will need to support API Keys for each such server. I will prioritize this issue. |
@volovyk-s Ah, well, those are indeed two completely different efforts, but they came somewhat together, and we need both solutions: (1) extended RPC connection configuration, (2) failover configuration. This issue is about the second point. |
(and @volovyk-s) I apologize on the side discussion on decentralization here... It was just to mention the addition context and reasons. The goal of this issue is to add support for multiple RPC configurations, allowing retries against a prioritized list of RPC nodes. This at least mitigates single RPC provider failures/outages. |
@frol @volovyk-s any movement on this? Another downtime/major latency issue on mainnet, with many apps unusable because of the dependency of a single RPC provider. |
Seems like the ideal solution here will be the creation of The problem here is the increased load on RPC Servers, something that we are trying to avoid. In our case, we will need to refactor the existing Also, we can refactor |
Enable configuring multiple RPC nodes also helps to resolve the feature request of switching RPC URLs in NEAR wallet: near/near-wallet-roadmap#36, if wallet could set fallback RPC URLs by default. |
I tried to add a new property Trying to only modify the implementation of |
When executing |
@frol @volovyk-s Yet another downtime/major latency issues on primarily on testnet, because of the dependency of a single RPC provider. |
Dear Team, We have a library named fallback-falooda which helps us get the reliable node in the list of nodes in our cosmos environment. We are also using it in our node selector in our near specific use cases. I have made a few changes in the code to make it work with fallback falooda. here - master...leapsamvel:near-api-js:master We can, either
Could you let me know, and I will raise the PR accordingly with the test cases and documentation? TIA. |
Resolved by #1334 |
Is your feature request related to a problem? Please describe.
Current RPC providers can have downtime, temporary connectivity issues, or rate limits that make clients transactions fail. Over the past year we have observed several windows of RPC failure, which could have been mitigated if near-api-js had configurations for multiple RPC providers.
Describe the solution you'd like
Similar to issues #703 and #717, the core JSON RPC provider should be refactored to not only have retries, but allow for retries against multiple Providers. The default provider list can configure both near foundation and openshards RPC services. Provider list can be a single node string for backward compatibility OR an array of node strings.
Up for discussion but needed: Create a failover threshold of retries for each provider, and a threshold for provider failures before defaulting to a different priority.
Configuration Example:
NOTE: Because near-api-js is used in many dapps and repos, this functionality is very key toward providing the easiest way to allow clients to decentralize their RPC access. This is critical for community attacks against public resources.
Describe alternatives you've considered
Users must create multiple instances of the Near module with different providers configured and detect TXN failures. Not idea at all.
Additional context
There is an ongoing effort to create a decentralized RPC for mainnet & guildnet using many of the openshards.io nodes with a redundant load-balancer.
The text was updated successfully, but these errors were encountered: