Lava Public RPC: Boosting UX & DevX

Proposals
1

Overview:
Public RPC is often a source of frustration for users and developers alike. It’s fragmented, unreliable and under-maintained - many times degrading the UX on wallets and dapps, creating a bad reputation for chains as being slow or hard to build on.

Lava’s Incentivized Public PRC (ipRPC) initiative offers a completely new approach to public RPC - empowering users & devs with super reliable & performant access to data, while making it easy for teams & communities to monitor, manage, and save on infra costs.

How it works
Archway will deploy an on-chain $ARCH pool on Lava’s chain, which will be used to aggregate, rank, and incentivize RPC providers, based on the volume and quality of their service.

Very similarly to how liquidity pools work, RPC pools create a permissionless market for data that’s driven by supply and demand. It’s highly flexible and can be easily monitored, optimized, and scaled by adjusting incentives and on-chain parameters.

Main benefits

  1. Simplicity: one united RPC endpoint
  2. Reliability: automatic retry and fallback
  3. Performance: optimized performance for every user/dapp
  4. Scalability: easily scale when traffic increases
  5. :bow_and_arrow: Reduce costs and pay in ARCH :bow_and_arrow:

Goals
We’ve seen a lot of community discussions around Archway RPCs recently, and based on our previous success working with other ecosystems, we’re very positive that Lava can significantly improve some of the issues users are experiencing. Our goals for this initiative are:

  1. Maximize user and developer experience
  2. Simplify infra management
    • Easily track and monitor each providers’ performance
    • No need to negotiate and contract with every provider individually
    • Providers get paid according to actual volume & quality of service, not a fixed quota
  3. Attract and engage new professional node runners and contributors

Experience
Our RPC Pool partners include NEAR, Axelar, Evmos, Cosmos, Union, Stargaze, Starknet and Filecoin (More TBA). Our live deployments on NEAR, Evmos and Axelar have significantly improved the reliability and performance for users.

Milestones

  1. Integration & Setup
    • Archway “Spec” integration + maintenance
    • Provider onboarding
    • Provider stats dashboard
  2. Endpoint launch - setup, monitoring & maintenance of RPC endpoints for Archway Mainnet & Testnet
  3. Growth
    • Onboarding users
    • Monitoring and optimizing performance

Budget
We’re asking for 65,000$ in $ARCH to deploy Archway on Lava’s Mainnet. The majority of funding (70%) will be deployed on-chain and distributed to providers over 6 months, based on performance. 30% will be used to cover Lava’s costs for setup, maintenance, support, marketing, bookkeeping and compliance.

We’re looking forward to receiving your questions and feedback!

Our old proposal: Fast, reliable & scalable public RPC - Powered by Lava - #14 by aelesbao

4 Likes
2

Your last post and ask was in February, and to my knowledge got shut down due to a view of high expenses. Astrovault had seen some infrastructure issues, but things were mostly ok.

6 months later things have gotten significantly worse, not better. As primary clients of the Archway network, Astrovault needs better and more scalable RPC solutions. It’s an easy yes from us, and thank you for coming back and trying a 2nd round.

I’d encourage other validators and network participants who were opposed previously to thoroughly test out existing solutions before voting No. Astrovault is averaging nearly 300 RPC errors per day over the last several weeks. Any solution is an absolute need.

5 Likes
3

Hello everyone!
This is Grint, the Product Lead at All That Node, an RPC Node Provider service.

We are currently working with the LAVA Network to expand RPC infrastructure across multiple protocols. So far, we’ve teamed up on projects like NEAR, Axelar, and Evmos, where our collaboration with LAVA has helped lower entry barriers and improve the overall user experience within these ecosystems. Our aim is to continue being a trusted partner and contributing to these important initiatives.

We believe that by bringing the benefits of the LAVA Network to Archway, users can experience similar improvements and help drive the network’s growth and success.

5 Likes
4

Hey Eric, thanks for your feedback. Our previous proposal received almost unanimous support from the community during the on-chain vote. It was pulled because we missed a step in the governance process, and we intend to follow all the steps correctly this time.

As for RPC failures, Lava has proven experience in solving such issues for users in other ecosystems, and we aim to do the same for Archway :handshake:

5 Likes
5

Ideally, core network access should be trusted to be secure, reliable, and fast.

It’s reassuring that Lava typically have 20-30 participants per network chain for redundancy, and some of these have multiple servers that are load balanced.

Key to this solution is the balancing distribution system that rewards high Quality of Service.

Network access is assured from their existing uptime stats of over 99% since April on both NEAR and Evmos chains.

Lava’s Service Level Agreement will provide the community with quick responses and solutions.

This solution is supplied via the unified access point, therefore, the Everyone eXperience (EX) is not compromised; this should be a win for users, devs, validators, the network, blockspace sales, and growth.

6 Likes
6

I support anything and everything that can be done to fix the utter nightmare of RPC issues we’ve been dealing with. The chain has been virtually unusable, any improvement in this regard is absolutely essential. I wholeheartedly support Lava in their proposal.

5 Likes
7

Will Lava be offering relayer support as well? seems like all the relayers keep having issues too.

4 Likes
8

This solution is only for RPC services

2 Likes
9

I appreciate the thoughts in the reply, BEngEE, but is there any concern in your eyes around the amount of liquid ARCH incentives that will likely be offloaded by the providers? The ask is for $65k for 6 months of incentives or $130k annually.

2 Likes
10

This isn’t needed and a waste of treasury funds.

Here is a full list of current RPC providers : chain-registry/archway/chain.json at master · cosmos/chain-registry · GitHub

As you can see, there are a ton of providers.

1 Like
11

Seconded. Couldn’t agree more. As a regular Archway Network participant and Astrovault user, the lack of reliable RPCs has been a recurring issue for weeks, and it impacts a DEX’s ability to carry out trades when the back-end infrastructure it depends on is having issues. We really need this support, and I will vote in favor of this Proposal.

2 Likes
12

If this was such an easy solution, why was it not shared on the Forum a week ago?

This is the public space for discourse regarding Archway Governance. Having all the information in front of us to make our decisions is a vital component of this being a transparent process.

1 Like
13

Archway is already paying and offloading ARCH for RPCs via delegations. The difference is that with Lava it will be much easier to track & manage and a lot more optimized:

  1. Providers get paid according to volume and performance
  2. Provider stats are openly available
  3. Users benefit from better reliability & performance:
    • Performance and geolocation-based optimization
    • Automatic retries and fallback
    • Sophisticated caching and more

The proposed budget will be distributed monthly over 6 months to dozens of data providers who have skin in the game

3 Likes
14

I’m not sure if you’re aware; this solution already unites some of the RPC providers on the list that you linked.

When you say “this isn’t needed”, perhaps compare this solution to the last months where the official public RPC has often been down, by our recent very conservative testing, approximately 300 failed RPC access attempts per day.

The official public RPC is a singular entity and sadly, the existing result is that users are inconvenienced, worse, sometimes to a point of total dispair - this cannot be acceptable.

A solution like this is needed.

3 Likes
15

More RPC providers won’t solve Astrovault rpc issues.

I appreciate the discussion, but I think treasury funds will be better spent somewhere else.

16

Ok, so if more RPCs won’t solve the problem, and you won’t provide them either, what do you propose?

All you’re doing is deflecting blame, you’re not proposing a solution to the recurring RPC issues.

This hurts Archway in the view of traders and investors who seek a return on their capital. They won’t want to use Astrovault if the RPCs keep having problems. This is a valid use of Treasury Funds, whether you agree with my perspective or not. The Archway Treasury serves Archway. RPCs are part of Archway’s infrastructure it needs to properly support its DApps and the new, upcoming DApps that we are all eager to see.

2 Likes
17

Voting is live: https://archway.explorers.guru/proposal/52

18

It seems like this proposal is mainly being considered because Astrovault is in need of an RPC cluster.

If needed they can get a super reliable RPC endpoint from 10+ providers for the traffic they have for under 2000USD a month.

I see no need to create an additional (aggregated) endpoint for archway from community pool funds without any direct indication of benefit of usage on this chain. In our opinion the chain is not responsible for providing anything beyond development grade RPCs and would highly encourage dApps to find and pay their own providers so that App performance is isolated from each other and can be enhanced individually.

Sorry for the late comment but we will be voting no on this proposal.

best,
Ertemann
Lavender.Five Nodes

19

More RPC providers won’t solve Astrovault rpc issues

We are not the only team to find this, Philabs have tried to fix the issues, sadly, nothing has worked.

We sent Philabs a standalone script to demonstrate Archway RPC errors by simply querying a balance. Each day a few hundred failures are recorded, for example, yesterday saw 350, the day before 490 (2024-Sep-15), these errors occur every hour of every day.

[1] Most other “public RPCs” are either heavily rate limited, suffer degraded performance, or do not offer what Archway/Philabs provide. Still, we invested in a fall-back to other RPCs when one errors out, however, each have issues, none have proven reliably stable without errors.

The Lava RPC distribution solution pools together many providers, it handles errors and rewards successful traffic flows, therefore, incentivises pool participants to maintain high service level.

Provider 1 ---\
Provider 2 -P-| --> Lava RPC distribution => dApp
Archway    -O-|
Lavender 5 -O-|
...        -L-|
...        ---|
Provider n ---/

See that Archway and Lavender 5 can be part of the pool.

dApps would not be beholden to one provider, important for robust reliability with a far lower error rate.

We have been told that validators (not Astrovault) receive delegations to provide public use RPC endpoints. Some validators also get rewards to provide IBC relays. In trying to make relay services reliable, Philabs created alerts for when services fail, Lavender 5 did not want such alerts without payment. Charging $24,000 per year per dApp shows that this proposal is in direct conflict to their interests, it’s clear to expect a vote No from Lavender 5. However, what about fulfilling the requirement to provide RPC in return for Philabs delegation rewards (see [1]).

It’s not unreasonable that an entity funded to launch and maintain a network, be expected to manage public RPC access to the same level that a far less funded validator like Lavender 5 claim that they can.

For any dApp building on Archway, an RPC solution that allows all dApps to properly scale up is key for network support and growth. Imagine if Youtube network started buffering out because it is “development grade”.

2 Likes
20

Sorry for chiming in late, but I want to respond from my perspective of ArchID. We too had some issues with the official public RPC, including rate limiting, and errors. Some time ago we switched to another public RPC provider (and set yet another RPC as fallback). Since that change we’ve had zero issues.

I’ve had a decent experience generally with the Archway public RPCs and find it comparable to public RPC on other networks I’ve deployed on. I think for high volume low latency environments, public infra usually isn’t going to suit that use case, but with that kind of traffic paying for dedicated server costs shouldn’t be an issue. It’s actually pretty insane what people pay for overpriced RPC services on Ethereum like Infura and Alchemy.

Anyway, I think this is a good proposal, and I could see myself voting yes if it weren’t for the high price tag. Sorry to say I will be voting no.