The Road to RPCh — Part 3

We returned from Colombia with a new team and a new drive. RPCh would be the first product on top of HOPR — a clear use case for the protocol which didn’t just provide a vague privacy upgrade but which solved an urgent and timely problem in web3. Users were excited, wallets were excited, we were excited.

But now the real work needed to begin, and fast. We’d forged collaborations with half a dozen wallets over the previous month, all keen to provide their users privacy via RPCh through direct integrations into their UI. This was a huge boost for HOPR, but these deals were contingent on a solution being ready in months, not years.

Architectural Digest

The hackathon had produced a great proof of concept, but it was far from being a product, or even a blueprint for one. That version of RPCh required the user to provide everything — the RPC server, the HOPRd node — themselves.

It worked, which was still a huge achievement, but it wasn’t a product or service. With that setup we should be paying the users, not the other way round!

And that was actually the first of many questions which we couldn’t put off any longer. Who would be paying for RPCh? Is this something users would pay for, perhaps as an additional fee on top of gas? Or would wallets pay, and either absorb costs or pass them on to users somehow?

Our internal research showed that users said they would be happy to pay, but this is always the problem with privacy: everyone claims they want it, when it comes to the crunch few are willing to do anything about it.

It was quickly decided that RPCh would be targeted to wallets as an upgrade to their existing RPC solution.

But this already had huge implications: if you’re offering service packages, for example 10 million RPC calls a month, you need a way to assign this quota, track it, and limit the service when it runs out. The architecture for a system like that would be totally different from one where RPCh was paid per transaction. Not to mention the knock-on effects for how RPCh would be communicated and marketed.

And this was just one of many angles to consider, each with its own consequences and constraints on the design.

It can seem like an overwhelming challenge, but one of the most satisfying parts of software design is breaking down a gargantuan problem into increasingly clear and manageable tasks. There’s nothing better than starting with a diagram and a dream and ending up with a roadmap and an ordered list for a packed sprint in GitHub.

For me at least :)

Road to a Roadmap

And as with everything at RPCh this was a team effort. First there were the high level considerations: what would RPCh as a service look like? Who would pay? Who would run RPCh nodes and be rewarded? Would these differ from standard HOPR nodes in their operation and incentivization? How?

This produced an architecture design with various components and their functions and inter-relations. I can’t take credit here: most of the work was completed by the founders and core team, so when I returned to the Zurich office after my holiday in Colombia there was a high level architecture design waiting for me.

As product lead, it was my task to take this plan and turn it into a concrete plan for development. How would the various components be built, and what order would we build them in? How would they be tested? How and when would wallets be given access, via an SDK or otherwise?

And, crucially, who would be assigned to build each part?

Because along with all this design work there was a parallel challenge, although one which was extremely rewarding to tackle. We’d hired Camilo, Diego and Luis — the three Colombians who had performed so well at the hackathon — as members of the new RPCh team. We’d been very impressed by their work and enthusiasm, but they were still relatively junior, particularly when it came to crypto. The development schedule for RPCh meant that most of their onboarding would need to take place on the job. They were also in a completely different time zone to me, which meant they needed to be able to work on tasks unsupervised for a large part of their day.

Like every other HOPR team member, the new recruits went through the standard HOPR onboarding process, from learning our various processes and team-working tools to the awesome hands-on Ethereum sessions from our founder Sebastian (which everyone at HOPR takes, regardless of role or technical expertise).

This is a great way to learn, but it also had profound implications for the roadmap. As with any project, building RPCh has some dependencies — things which have to be built in a certain order because they rely on each other. Then there’s external dependencies: the HOPR protocol is still under development, so we need to work within the roadmap there. We also need to plan how and when to hand RPCh over to our wallet collaborators for the final integration.

There are also dependencies within the team. Everyone has a different skillset and it makes sense for them to work on particular tasks. Luckily for us, the new Colombian recruits arrived as something of a full-stack package: Diego was most experienced at devops and architecture work, Camilo had front-end expertise and Luis was most comfortable building the various Docker images RPCh would rely on.

But most of the prioritization had softer requirements. It made sense to build certain things first because it let us reach minimum viable feature sets faster. This is good for testing and releases, but also for understanding.

I decided we’d build incremental sandbox versions or RPCh, where rudimentary versions of each component would be introduced so the team could really see how everything interacted and how the individual components they were working on would combine. Then we’d move on to alpha, beta, and so on, improving and adding components as we went.

Playing on Hard Mode

One of the most important considerations was to create a smooth difficulty curve for the team.

They were starting roles at a new company working on a new technology, which can be daunting. Although setbacks are inevitable in software development, it was very important for me to create an environment where we felt like we were always making progress. This meant starting with low-hanging fruit where possible, celebrating milestones like first commits and PRs and ramping up the difficulty as we moved through the sprints.

I also learned from my experience in the HOPR core team and was sure to create clear processes from day one, as well as frequent retrospective sessions to celebrate what was working and correct any issues before they became problems.

I don’t want to jinx anything, but so far it seems to have worked. RPCh has hit all its development milestones and the team has more than risen to meet the escalating challenge. It would be a lie to say there have been no setbacks (we’ll get into some of those next time) but careful planning and in-built buffers and redundancies have minimized the impact, and we’re well on track with the timeline agreed with our wallet partners back in October.

This has just scratched the surface of the challenges and considerations that go into planning out even a relatively modest software development project like RPCh, but I hope it’s been interesting to see a side of crypto that’s rarely discussed.

In the final installment, we’ll look at how the RPCh team has expanded further and some of the most important lessons learned over the past few months.

Steven Noni
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/