The Road to RPCh — part 4
Over the past few months, we’ve built a prototype, hosted a hackathon, hired a whole new team, specced out RPCh as a service to give wallets (and users) their first private blockchain gateway, and built a sandbox version to show that it was all feasible.
If that wasn’t enough, now comes the real challenge: a version of RPCh that’s truly live, handling real users’ crypto transactions over the real HOPR network.
We decided this version will be an alpha. Not all the features will be implemented, and first clients and users will have realistic expectations about reliability, bugs, and other gremlins that go with any early code release. But of course it still needs to work.
To get ready for alpha, the team expanded again. Experienced front-end developer Michal was brought over on a shared basis from HOPR’s comm team, and new-hire Martins was recruited to help with RPCh’s growing devops requirements.
Into the Weeds
One of the major gear shifts in developing RPCh alpha was the increased focus on details and testing. It’s fun to talk about privacy in theory and play with prototypes, but a real product needs to survive and thrive in the real world. The world of supply, demand, and razor-thin margins.
RPCh needs to handle live calls made by real users going about their DeFi business. This creates two issues of scale:
- Can RPCh (and the HOPR network underneath it) handle live traffic?
- Can RPCh process large RPC calls?
This isn’t a technical blog, but the second point needs some context.
RPCh is built on top of HOPR, so it needs to use a format HOPR can handle. Calls need to be converted so they can be sent through the mixnet and reassembled at the other end.
This basically means splitting each call into bite-sized chunks.
Or rather 400-byte-sized RPCh segments, since that’s what’s left from a HOPR packet, once you allow for the extra data RPCh needs to add to each packet to function.
Now most RPC calls are small. A few packets tops. And in the initial prototype and hackathon we mostly tested with vanilla transactions, which are simple. But some RPC calls are huge! Testing showed that a single Cowswap transaction could require up to 50 RPCh segments, each taking a different route through the HOPR mixnet.
And if a single one goes missing, the whole call will fail.
Another thing to remember is that wallets make calls even outside of transactions. Just having your wallet active in a browser will see regular calls to check the balance, check the current block number, and more. These are small, but if a lot of users have wallets active at once that traffic quickly adds up. You can see for yourself by using DERP and just leaving your wallet open.
Now our initial partners are smaller privacy-focused wallets — we’re in talks with Metamask, but that’s some way off — but it’s still a lot of users. Hundreds of thousands of calls a day across all their users.
So even in alpha, RPCh needs to handle lots of calls at once, some of them unusually large.
But that’s too vague to be useful. So we needed to really get into the weeds of the actual service RPCh will provide. Not just “send a bunch of RPC calls over HOPR” but “What calls?”, “How many?”, “How big are they?”, “How many at once?” Not just guesses, exact numbers.
So I assigned Diego and Luis to gather the data. They spent hours running wallets from our partner projects, recording what calls got made and their precise size in bytes.
It was dull work, not gonna lie, but essential to know exactly what load RPCh alpha would need to handle.
Will it Work?
It might seem strange to have come this far without working at this level of granularity. What if it just can’t work?
But this is actually a key part of product development, especially when working on something totally new.
“Will it work?” means different things at different stages.
Back in September, when I was coding the first RPCh prototype in Spain, “Will it work?” just meant “Is this even remotely possible?”
During the Hackathon, “Will it work?” meant “Can we integrate this into a real wallet?”
And as we get closer and closer to launch, what it means for RPCh to work gets more and more specific.
It’s not enough for sending transactions privately to be possible. The service has to be reliable. It can’t introduce unacceptable latency. It has to be able to handle the expected throughput of our partner wallets. The UX has to be smooth. It has to use the real HOPR network, not a theoretical sandbox version we spin up locally.
And the realities of business kick in. Because let’s not kid ourselves — wallets care about privacy, but not at any cost. It needs to be easy to use, easy to integrate.
And money talks. Ideally RPCh should be cheaper than competitors, or introduce cost savings elsewhere.
We believe we have a design that achieves all these things, but we still have to put it through its paces.
Testing!
RPCh alpha has now reached the testing stage, and the whole team is working round the clock to ensure we can provide a smooth and reliable service for our first wallet partners. Not everything has gone smoothly — it wouldn’t be software development if it did! But I’m pleased to report that bugs have been found and squashed and everything seems to be on track.
HOPR teamwork
The journey to alpha marked another scaling milestone: the HOPR team itself. I’ve been with HOPR since its inception, even before the HOPR Association was created. At the beginning the vibe was pure startup: everyone pitching in wherever they had expertise. As the project grew, the structure changed, but was still fluid. We had dedicated teams but a lot of overlap.
But the addition of the RPCh team has changed things yet again. Now we have three teams with different goals, deadlines, and requirements. The structure has solidified and it’s now possible to go weeks without interacting with some team members except in our all-hands call.
This has introduced new challenges of coordination and prioritization, especially as each team is spread around the globe. Working towards RPCh alpha has been a real test of teamwork throughout HOPR as a whole, and I’m proud to say we’ve risen to the challenge.
RPCh team has been responsible for building RPCh itself, but the whole HOPR team will have a hand in its success: core team has built the HOPR protocol which RPCh runs on, and comm team are responsible for getting the word out about RPCh and marshalling the community to run HOPR relay nodes and provide a stable network.
The road to RPCh alpha is almost over. It’s been challenging, but extremely rewarding. And of course alpha is only the beginning. There will be more features, more improvements, and more wallets and users to support.
I hope you’ve enjoyed this small insight into what goes into building a web3 product, and hopefully if alpha is a success I’ll be back to share what comes next on our journey to build a truly private web3.
Steven Nonis
RPCh Product Lead
Website: https://rpch.net
Run RPCh Alpha for free: https://access.rpch.net/
Twitter: https://twitter.com/RPC_h_
Discord: https://discord.gg/VRyTQTNBTy
Powered by HOPR: https://hoprnet.org/
