Hey Hackers,
Great news—the submission deadline for the #blockchain-api writing contest has been extended to September 27, 2024, giving you 15 extra days to submit your #blockchain-api stories and compete for up to $1,000 in prizes. If you’ve already submitted an entry, you now have more time to draw attention to it or work on a new one to improve your chances of winning.
Start by carefully reviewing the contest’s writing prompts here.
To make the most of this extra time, we hosted an AMA with dRPC, the contest sponsors, where we discussed blockchain APIs, web3 infrastructure, and other key topics a winning entry should cover like reviews of the dRPC platform, popular APIs and RPC nodes, dAPP development, load balancing systems and more.
Let’s get started!
Consta, CEO: In web3 since 2017, leading product, marketing, and business functions. After a stellar time as product lead at P2P Staking, Consta joined dRPC as CEO, building a team of rock stars that have managed to place dRPC as a market leader in little over a year.
Slava, CTO: Decade-old code master with experience in web2 banking and social networks. After a time following up events, Slava became convinced in 2022 of the importance of crypto, and jumped onboard the dRPC rocket ship.
Fito, Brand: Fito leads dRPC's brand efforts in getting to be globally known and recognised in the web3 infra industry as a market innovator and trustworthy partner. Jumped into crypto in 2018 out of love for decentralisation, and motivation to help in the adoption of web3.
Martin, Marketing: Martin has a natural flare for socialising, which has made it easy for him since 2017 to become a Sensei in reaching and engaging end users and online communities. Martin is a crypto native with his finger on the pulse of the industry, and our AMA MC.
The role of blockchain APIs in web3 infrastructure
Data accuracy in blockchain API calls
Benefits of decentralized service providers: affordability, multichain, censorship-resistance
The Blockchain-API Writing Contest
This Slogging thread by Mónica Freitas, Jose Hernandez, Jonh, Martin Kalliola, Asher Umerie and Sheharyar Khan occurred in slogging's official #amas channel, and has been edited for readability.
My name is Constantine, and I’m the CEO of dRPC.org. I started as a tech guy, working as a DBA for several years before gradually moving to the business side. Before entering Web3, I held various roles in large financial and telecom companies, handling high-load systems like billing and antifraud systems. My Web3 journey began in 2015 when I joined Ambisafe, where we built white-label wallets, a semi-decentralized exchange, and other services. It was an exciting time as many well-known crypto companies were just getting started.
After Ambisafe, I joined P2P.org, one of the largest infrastructure and staking companies in Web3. As Head of Product, I was responsible for the Ethereum ecosystem. By 2022, we at P2P were overwhelmed with RPC management. We had over 30 DevOps engineers from different teams managing RPC nodes for dozens of chains, using multiple third-party services because no single service met all our needs. We started building internal tools for RPC management.
During this time, we helped projects like The Graph, Everclear (formerly Connext), and others. Through this, we connected with many infrastructure companies. When we shared what we built, we received numerous requests for access, as many others faced the same RPC challenges. Konstantin Lomashuk, founder of P2P.org, asked me to lead a new company to offer this tool to the public. We brought in Slava, a tech leader from VK and Tinkoff, as our CTO, and that’s how dRPC was born.
Unlike Alchemy or QuickNode, which rely heavily on AWS and in-house DevOps teams to host their RPC nodes, we’ve built a distributed network of RPC providers under an AI-based load-balancing system. Providers handle node maintenance, while we focus on creating reliable load balancing, fault tolerance, quality checks, and UX.You might think our model is similar to POKT, Lava, or BlastAPI, and in some ways, it is. However, they interact with providers through endpoint links, working more like routers without detailed knowledge of each connection.
In our case, each provider sets up a load-balancing proxy that constantly performs checks, collects data about node status, and reports it back to dRPC. This means we have deep insights into connected nodes without guessing their availability or supported methods.We run random auto-checks between providers and block nodes if their responses differ from others. We also offer quorum verification for clients who want to verify every request. This allows us to offer a new generation of RPC services with better distribution, performance, and data quality.
It's important to talk about both security concerns and the general risks of using centralized API providers. With centralized providers, you can’t verify data; you just have to trust them. They usually work with only one type of software client, often GETH, so if there’s an issue with that client, you're stuck.
In our model, we unify dozens of providers using different client types (geth, reth, erigon, etc.), allowing us to quickly identify and address issues. This design helps mitigate risks like bugs in specific software clients, human errors, cloud provider failures, and geographic risks.
For dApps, the best approach is to use at least 2-3 providers simultaneously to minimize risk. While this can be more expensive with providers offering subscription packages, our pay-as-you-go model helps optimize costs by charging only for resources actually used.
We incentivize providers through a reputation system. Providers are rewarded for high performance and penalized for downtime or inaccurate data. Poor-performing providers receive fewer requests or may be permanently removed from the pool if their quality consistently falls short.
In the short term, we plan to keep improving our RPC SaaS by fine-tuning the reliability and performance of our permissioned network of node providers, developing more mechanisms to ensure data accuracy, and expanding into new blockchains with high adoption potential. This will help us grow our market share rapidly.
In the long term, we aim to expand into other data-related products and become a leader in the Web3 data space. Our goal is to build a marketplace where data providers and consumers can easily find and exchange high-quality data at the best price.
We launched this contest with two goals in mind. First, we wanted to see how much non-Web3 experts know about Web3, especially the role of blockchain APIs in dApp performance. Second, we wanted to encourage writers to share their knowledge and insights, helping to make this topic more accessible to others.
Now is the perfect time for this because the industry needs killer dApps to drive adoption and bring Web3 into the mainstream. Performance is key for that to happen, and blockchain APIs play a big role in providing a reliable and engaging user experience.
We’re looking for submissions that educate the general public about blockchain APIs and their practical uses. Submissions that include graphics or videos explaining how blockchain APIs work, especially if they showcase our dRPC platform, will receive bonus points.
Our dRPC YouTube Channel has tutorials on using blockchain APIs to fetch on-chain data, along with showcases of the dRPC solution. Our official docs provide comprehensive information on the platform and its features. The dRPC blog is another great source worth subscribing to.
Focus on clearly explaining what blockchain APIs are, how they work, and using the dRPC platform as an example. Make sure to articulate the benefits of decentralized blockchain APIs versus centralized solutions, including the pros and cons of each approach.
A high-quality submission is clear and concise and explains how everything works, with practical examples from the dRPC platform. A low-quality submission would be unclear, unfocused, or lacking concrete examples.
Yes, a few. One is how decentralized solutions can ensure multichain support and scalability without issues under a centralized architecture. Another is the misconception that running your own node is always more secure, reliable, cost-effective, or data-accurate. It's often better to focus on building your dApp rather than maintaining your own nodes, especially if your dApp supports multiple chains.
First, understand that RPC is critical for providing a user experience that supports accuracy, scalability, and mass adoption. Second, don’t build the infrastructure yourself—it’s time-consuming, costly, and less reliable than using external providers. Finally, centralized infrastructure won’t support Web3’s mass adoption, so look into the benefits of decentralized solutions.
That’s a wrap for this AMA! Thank you dRCP for your time and thoughtful answers. We’re excited to follow your journey from here on out and see what you do next!
To all the writers on HackerNoon, make sure to leverage the valuable insights shared during this conversation when crafting your entries for the**#blockchain-api**writing contest.
We can’t wait to read what you come up with!