Web3 Developer RPC Woes
Common RPC-related problems for Web3 developers
tl;dr — Developers using RPC frequently encounter unreliable/unavailable endpoints, stale data, stale node lists, rate limits, missing and messy documentation, and are expected to self-host. Web3 must be liberated from this travesty.
Lo and behold! As the world of blockchain technology and decentralized applications (dApps) continues to grow, new and intermediate Web3 devs are facing a variety of unprecedented web-based challenges. Indeed there are a slew of issues which plague us as we strive towards building the most cutting edge and awesome tech around. In this article, we will discuss the most common issues faced by web3 devs — which you may or may not know are related to RPC.
Unreliability & Unavailability ☠️
RPC endpoints go down during high traffic moments, and there is little accountability for centralized providers
A downed node is, well, a downed node 😐. At your moment of greatest need, you may find that your RPC endpoint suddenly ceases to function. In which case, you are likely in the middle of your first NFT mint or your big Airdrop to your loyal community following, who now thinks you’ve deceived them. The solution would be reliable and available RPC, alas, your once reliable and available endpoint has collapsed under the tremendous new demand generated by your landmark event 😭. This is the tragedy of the commons at warp speed! You want available, free, and fast RPC — and then you want to use it abundantly. But, in today’s web3, it’s difficult to get all of these.
Self-Hosting a.k.a. Operation Overnight DevOps 🤳🏿
Developers have to host their own nodes when required nodes are unreliable, unavailable, or insecure.
Welcome to Web3 where all the infrastructure is decentralized! Translation: you will have to run all of your own infrastructure if you care about decentralization and there is no obvious alternative! Many common chains have public RPC available for free for testing, but if you’re interested in creating a production grade application — you’re going to need reliable RPC endpoints. See The Web3 RPC Problem for an in depth evaluation of this issue.
Most developers have the tenacity to learn new skills and are willing to become skilled in deploying and maintaining a node — as one of many necessary evils required for sovereignty. Unfortunately, the process takes time away from coding, involves recurring expenses, requires a separate technical skillset than programming, and requires proper planning for future scaling. In short, Operation Overnight Devops 😝.
Stale URL Lists⏳
RPC URL lists are not always up-to-date and often contain old and dead links to down RPC endpoints.
Most commonly, RPC lists are stored in Discord server channels, on github repositories, on websites, and on websites whose source code is stored on github repositories! This means they must be updated by active maintainers who politely steward the list for the good of the community. As you can imagine, if you have ANY active side projects 😉, these lists can get a little neglected — and are often times fixed only after someone has complained that links are dead, nodes are unresponsive, or requests are timing out. Once this happens, someone (usually 😩) comes from the back of the shop and dusts them off only to return back into obscurity. You’ve normally moved on by then…
Stale Data ⌛
Occasionally, nodes are proven out of sync when they return data that was once correct but is no longer.
In a real-time environment — like blockchains with short consensus cycles — the need for up to date and accurate data is highly pertinent to the smooth functioning of applications. That stated, missing or inconsistent results as a result of old indexed data or out of sync nodes is an occasional nuisance. This is most obvious when you interact with a chain with a short blocktime and ask for the current blockheight, yet receive a blockheight slightly less than expected when compared against explorers or other nodes. For one reason or another, an endpoint may return a result that, though it was once correct, is no longer correct. OH well! On to another endpoint. So much for your dream of smart-contract enabled instantaneous ZK-proofs 😎.
Rate limits! ⏱️
To protect themselves from overuse and abuse, many public RPC endpoints are rate-limited.
Yes — your handy little app is robust and can theoretically process 10,000 transactions per second concurrently while queuing all outgoing requests and caching all incoming data 💪🏾. There’s just one thing you forgot about! RATE LIMITS. These put a hard governor cap on the performance of your application, limiting your ability, nay, your right to use RPC the way that you need. A rate limit says — STOP! you’re going too fast for my node to handle. As a reality, these prevent abuse and over-consumption of essential public goods, but as a nuisance, these obstruct rapid innovation.
Missing/Messy Documentation 🔍
Depending upon your use case, you may not find ample example code of what you’re trying to do.
You wanted to know how things are implemented, right? You wanted a clear and unambiguous single source of truth regarding the interfaces used, didn’t you? More often than not, these things can get a little tricky, especially as a pioneer in the web3 space. Web3 is populated with many young projects with maturing ecosystems; often times, documentation just isn’t keeping up with the rate of technological growth and advancement. At this level of adventure, there are often no maps. Do us all a favor & fully document what you do as you do it ✍🏿. The trail of breadcrumbs you create will help guide future lost explorers.
In Conclusion
The waters are still trepidatious for burgeoning web3 developers. No doubt, much work must and can be done to provide a smoother dev experience in the landscape. It is not reasonable to deal with stale lists, stale data, missing docs, rate limits, and self-custody of infrastructure just to build simple working tools and utilities! The future of web3 requires a solution that enables beginner devs to have seamless experiences devoid of these sorts of issues and limitations. To learn more about how Lava is trying to solve the Web3 RPC problem, check out this article for a breakdown of the protocol.
About the Author🧑🏿💻
KagemniKarimu is current Developer Relations Engineer for Lava Network and former Developer Relations at Skynet Labs. He’s a self-proclaimed Rubyist, new Rust learner, and friendly Web3 enthusiast who entertains all conversations about tech. Follow him on Twitter or say hi to him on Lava’s Discord where he can be found lurking.
About Lava 🌋
Lava is a decentralized network of top-tier API providers, where developers make one subscription to access any blockchain. Providers are rewarded for their quality of service, so your users can fetch data and send transactions with maximum speed, data integrity and uptime. Pairings are randomized, meaning your users can make make queries or transact in privacy.
We help developers build web3-native apps on any chain, while giving users the best possible experience.
