Introducing DEADR: Next Stop, Cover Traffic and Staking
Things have been a little quiet on the tech front, but not because we haven’t been busy — quite the opposite, in fact! Since the HOPR token launched in February, we’ve been all hands on deck working towards our upcoming Eiger release.
We know you’ve all been waiting patiently — and some not so patiently — to begin staking your HOPR tokens, but it’s a delicate balancing act creating an implementation that’s secure, robust and fair, and that’s before you throw privacy into the mix.
One huge hurdle has been weaning the protocol off its reliance on bootstrap servers, which our testnet participants will remember were a major source of instability and downtime. That hurdle has finally been cleared with DEADR, introduced in the upcoming Kiautschou release which should be on its way to you at the end of next week, assuming internal tests go well.
Teething Problems
Even before our token launch, the engineering team at HOPR was working tirelessly to develop the HOPR protocol.
In case you’ve forgotten, we at HOPR are implementing a layer-0 privacy mixnet, allowing anyone to exchange data privately. By now, you have probably already tested our official Jungfrau release, opened a few channels, sent a few messages, and obtained some tickets with wxHOPR to showcase our proof-of-relay concept.
Unfortunately, if you’ve been running Jungfrau, you’ve probably stumbled upon the following screen:
Asking about this in our Telegram, the ambassadors will probably have directed you to our status page. The diagnosis? Our bootstrap server was likely down. The solution? Try again later once the server reboots.
That’s no fun, and it’s been a serious headache when it comes to implementing cover traffic and staking. The beauty of HOPR’s staking model is that it’s integrated right into the privacy protocol: it’s not just an arbitrary way to distribute money to whales, but a fundamental part of incentivizing a mixnet.
But that only works if everyone has a fair shot at accessing the network. Staking is a non-starter while bootstrap issues can randomly lock people out of the HOPR network.
Luckily the next HOPR release completely overhauls the way nodes join the HOPR network and relay data, drastically reducing the reliance on bootstrap servers and paving the way for cover traffic and staking.
To understand how all this works, we need to look at why HOPR was so reliant on bootstrap servers for so long.
So What is a Bootstrap Server Anyway?
Decentralized networks don’t just spring out of thin air. Nodes need to know where to look to start joining a network, and then they need to find other members of that network to exchange data with, even as new nodes go on and offline. That’s hard enough even before you throw privacy into the mix: how do you join and keep track of a network where no-one is supposed to know where anyone is located?
The simplest answer is to use a bootstrap server.
Within a decentralized network, a bootstrap server is like the host of a party that knows everyone invited. It’s one (or more) nodes that host the information about other nodes in the network by being the first entry point, and storing everyone’s address in a data structure called a distributed hash table (DHT). Whenever a HOPR node starts, it looks for a default bootstrap server where it announces itself, for others to find. This is a pretty standard approach. For instance, Golem uses similar strategies to announce parts of their infrastructure to their providers.
Now, for most blockchain applications, this isn’t a problem. First, most clients (e.g., geth, bitcoind) usually require the software to be exposed behind a publicly reachable IP or ask their users to port forward their home setup or use a static IP. Second, whenever a connection is missing and/or other peers fail to announce themselves to other nodes, they can just keep pinging other nodes until they reach enough peers to be taken into consideration. This is perfectly sufficient, as usually you only need to agree on the latest state of a block, and keep track of the latest transactions made by the nodes.
However, this approach is nowhere near good enough for HOPR. Without a stable connection between nodes, the packets shared amongst them can be lost during transmission. This means senders would not receive tickets and thus have no incentive to run their node. Because HOPR cannot function as a mixnet without proper relaying, multiple attacks would be possible against the network, exposing the privacy of HOPR users. Unlike other protocols that can function with just a few reliable nodes, HOPR needs as many peers as possible for it to work properly.
Coming back to our initial problem, using a bootstrap server with this strategy decreases the reliability of the network as a whole. Whenever the server is down, new nodes fail to connect and direct connections cannot relay. In short, it becomes a single point of failure not only for new nodes, which cannot connect, but for existing nodes that use it to relay.
Introducing DEADR, a Strategy to Kill the Bootstrap Server
Since bootstrap servers run the same software as “standard” HOPR nodes, we quickly realized we could increase the reliability of bootstrap servers by not restricting them to the HOPR Association. In short, if we configure HOPR nodes to “announce” themselves whenever they are publicly available (i.e., behind a public IP), they can be used both as bootstrap servers and as normal nodes.
On top of that, we can avoid having to ask for the network DHT from a single bootstrap server if every time a node enters the network we store its address somewhere other than the bootstrap server’s DHT. Since we are already using a blockchain to settle the payments of the nodes, we can also use the blockchain to store this data and fetch it later on. We use the same mechanism to store our payment channels, after all.
Given those ideas, the Decentralized Entry Advertisement & Distributed Relaying strategy (or just DEADR) was born. DEADR defines three fundamental principles at its core:
- Whenever possible, a HOPR node behind a publicly accessible IP should broadcast its address to our HOPR smart contract to be registered as a bootstrap server.
- All servers will have the ability to register themselves as entry nodes to the network using the blockchain, immediately after starting a node.
- Relaying is no longer confined to a single entry bootstrap server, but can be performed by any HOPR node previously registered as an entry node.
DEADR has already been published in our GitHub organization, and the first implementation will go live as part of our Kiautschou release (it was actually part of our Stirling release, but there were some more bugs we wanted to squash before we shared with the public). As always, you can check all this out in our GitHub, along with current progress on all different aspects of HOPR.
FAQ
There are a few questions you may be asking:
Does that mean my node will be used by other node runners to relay traffic? Wouldn’t that leak the privacy of the packets?
If your node is behind a publicly available IP (very likely if you’re using a cloud provider), then your node will probably be used as a relay. However, because HOPR uses the SPHINX packet format, even if your node is used to relay traffic, you will have no ability to inspect any traffic shared between the network.
Will my node being used as a relay affect its performance or memory compared to other nodes?
We haven’t measured this accurately, but analysis of our bootstrap server suggests this is likely. However, if your node is used as a relay, it means it has channels open to other nodes, and is thus more likely to be picked up for cover traffic. So you won’t go unrewarded, which is as it should be.
Next Steps and the Road to Staking
Expect the first implementation of HOPR with DEADR implemented in our next release, Kiautschou, which all being well will be available for community testing by June 18th [UPDATE: Closed community testing has begun, but wider community testing will begin on June 24th]. This isn’t a full public release, but if you’re interested in seeing some of the progress we’ve made it’s a good opportunity to spin up a node and test the network. As always, please don’t put more than 10 wxHOPR onto your node for testing purposes — there’s no benefit to adding more right now.
The implementation of DEADR also finally unblocks the road to cover traffic and staking, the incentivisation mechanism used by HOPR Association to kickstart traffic into the network.
In other exciting news, we’re going to have a community call on June 18th, [UPDATE: this call has been postponed until 4pm CET on June 24th to accommodate a round of closed community testing], where we’ll demo the release and lay out the plans for staking and cover traffic and recap what’s been going on in HOPR over the past few months. More details about this call will be shared next week, but we hope you’ll all join us.
Jose Aguinaga,
HOPR Head of Engineering
Website: https://www.hoprnet.org
Twitter: https://twitter.com/hoprnet
Telegram: https://t.me/hoprnet
Forum: https://forum.hoprnet.org
GitHub: https://github.com/hoprnet/
