Binance Labs Fellow: HOPR, an Incentivized Privacy Messaging Protocol
Today, we would like to introduce the next Binance Fellow, Dr. Sebastian BĂźrgel from HOPR.
Written by Flora Sun, Director at Binance Labs
HOPR is an incentivized, decentralized mixnet scheme. Using Chaumian 'onion' encryption, HOPR protects both the encrypted message as well as the metadata associated with the message, such as sender/receiver info, the size of the message, the IP address being used, etc. In addition, HOPR believes that mass adoption and scale of a decentralized solution and privacy-preserving infrastructure need economic incentives. Therefore, the relayers in HOPR are compensated with a built-in incentivized mechanism.
Sebastian received his PhD from ETH ZĂźrich. To learn more about him and HOPR, hereâs a Q&A that I did with them earlier:
***
Flora: Can you tell us what is the genesis of HOPR?
Sebastian: We increasingly saw how much of the full decentralized tech stack was missing to build truly decentralized applications. We saw various blockchains for financial applications but the most interesting applications are not financial.
Think about it - which apps are you using more frequently: messengers or mobile banking applications? Upon reviewing the landscape we saw that various projects seemed to be using Ethereumâs Whisper protocol for various things it was not designed for. Beyond application-level use cases such as messaging, we also see the need for privacy at the protocol implementation level. For instance, sending a blockchain-based transaction, management of staking nodes in PoS systems, or payment channel management should happen in a privacy-preserving fashion at the base layer. This is how we realized that there is a big missing puzzle piece in a decentralized and privacy-preserving messaging protocol in the Ethereum space and more generally for decentralized applications towards a web3.0.
Flora: Please describe what HOPR is.
Sebastian: HOPR relays messages from sender to recipient via intermediate hops that thereby provide privacy. Since running a relay node comes with non-zero costs (hardware, energy, traffic and sometimes also costs for legal services), we introduce incentivization for users to become a relay node and participate in the network. The message, funds, and responsibility to deliver a message âhopsâ from one hop to the next downstream node. In technical terms, HOPR is a decentralized mixnet scheme with incentives for relay node operators.
Flora: Why do you call it HOPR?
Sebastian: HOPR is leveraging an onion-routing-based scheme, inspired by Chaumian mixnets such as The Onion Router (TOR). In HOPR, we are relaying a message from sender to recipient, via relay nodes which thereby provide privacy in addition to the more commonly seen end-to-end encryption. These relay nodes are also called âhopsâ - a typical message might get relayed via three hops before it reaches its recipient, therefore the name HOPR is describing what the protocol does at a lower level.
Flora: How is HOPR different from other privacy messaging protocols?
Sebastian: The major difference between other privacy-preserving messaging protocols is that HOPR introduces an incentivization mechanism for relay node operators without destroying the privacy of the message layer. In addition to that it provides:
1. Token / Ledger based accounting scheme between network participants
2. Stronger anonymity guarantees than TOR through the SPHINX packet format https://cypherpunks.ca/~iang/pubs/Sphinx_Oakland09.pdf
3. Full decentralization -- without central points of trust, in contrast to TOR that relies on centralized gatekeepers.
Flora: Please describe the technical architecture of HOPR?
Sebastian: HOPR comprises a message layer (sending the message around) and a payment layer (incentivizing relayers):
1. Message layer:
a. The message gets decrypted, bypassing nodes along the path.
b. Nodes alter the header such that it gets readable for the next node.
c. The next node checks the integrity of header, extracts information and forward it to the next node/hop.
2. Payment layer:
a. Nodes use (customized) payment channels for accounting between each other.
b. The protocol execution between Alice and Bob is completely independent of the one between Bob and Charlie.
c. To earn money, nodes need to prove that theyâve forwarded the packet.
d. Next downstream node accepts packet only if it contains a certain amount of money and a correct header response packet structure, otherwise, itâll drop the message.
e. Nodes follow the âoptimistic fair exchangeâ principle: participants are able to detect misbehavior and make on-chain claims in case such behavior happens.
3. Peer discovery:
a. Decentralized directory service -- nodes use a gossip-like peer discovery protocol inspired by BRAHMS http://webee.technion.ac.il/~idish/ftp/brahms_tr.pdf
b. Nodes use WebRTC with decentralized signaling servers to bypass NATs / firewalls
Flora: What were some design trade-offs youâve made for HOPR?
Sebastian: Generally, we try to BUIDL on the shoulders of giants by using technologies that reduce our time to release, are common in the blockchain ecosystem, and increase usefulness for a variety of other projects. The tech stack for our first implementation that was demoed for the first time at EthCC in Paris we build on top of JavaScript / NodeJS and libp2p which are used by a wealth of projects in the blockchain space.
Sebastian: On a deeper architecture level, we have:
1. Protocol stack:
a. Network -> establish bitstream between nodes
b. Libp2p -> establish overlay network, i.e. determine which protocols the nodes speak/understand, route traffic
c. HOPR -> mixnet, connection to a blockchain that processes the accounting, discovery of possible routes -> also known as relay PKI
d. Synchronization layer: provide chat history, deliver keys, store messages
e. Application layer: e.g. status.im / matrix.org / ratchet scheme âŚ
2. Fixed packet size for better privacy guarantees by ensuring that packages cannot be traced by a strong global passive adversary
3. Depending on the privacy requirements of the application, latency might be low at below one second. For other applications, longer latencies might be acceptable in order to provide even better privacy.
Flora: What are some features that took a lot of longer than you planned and why?
Sebastian: During our design phase we noticed a lot of love and attention on libp2p in the community and chose to build on top of that. However, during the implementation, we discovered an increasing number of Incompatibilities or missing features in libp2p towards which we actively contributed in order to move HOPR ahead. Such discoveries that you make while you code and assume your tech stack is perfect, lead to delays in the overall timeline but are somewhat inevitable in such a young and rapidly progressing ecosystem.
Flora: What are some features that you made available initially and why?
Sebastian: We decided to have a first PoC as soon as possible to find out what is relevant to the community. In the end, HOPR is not useful in and by itself but only if itâs leveraged by as many projects as possible. Therefore we decided on the following MVP requirements:
1. Mixnet functionality
2. Beta version of a relay PKI
3. Payment layer without on-chain dispute resolution
4. CLI chat client
Flora: What kind of help would you need from the developer community?
Sebastian: HOPR is open source today. We would be happy about contributors that write code, review code, test, help us work on the documentation and also tell us where we could be doing a better job. In the end, HOPR is being built for the developer community so early feedback is key for us.
Flora: What kind of help would you need from the non-developer community?
Sebastian: As HOPR is meant to be the missing part between the p2p layer and the synchronization layer, we are looking for decentralized applications/projects that want to give their users additional privacy and use HOPR. We are actively looking for projects that want to build decentralized applications and are interested in privacy even at the network level. Next, we would like to make a more detailed analysis of how HOPR could be integrated into such projects and what we need to develop to get there and integrate HOPR in the most pain-free fashion.
Flora: What do you hope to get out of the Binance Fellowship?
Sebastian: We primarily appreciate the opportunity to present HOPR to the world, specifically interested users, staking providers, projects that want to use HOPR and developers. Finally, this is made for the community and we are hoping for feedback and constructive criticism.
Flora: What do you plan to work on during the Fellowship?
Sebastian: During the 3-month Binance Labs Fellowship, we are working primarily on three milestones:
1. Private Key Infrastructure (PKI) that enhances the reliability of communication in the HOPR network.
2. Architecture for batch dispute resolution mechanism that allows for scalable dispute resolution (e.g., a connected node does not respond).
3. Documentation and testing that makes it easier for external contributors to test HOPR for their own purposes .
Flora: Would you like to share any Interesting stories about HOPR and its community so far?
Sebastian: We were quite positively surprised that after presenting and demo-ing at EthCC we actually had the first external developers checking out HOPR and even contributing code. That probably shows the power of open source development in reality!
***
Thatâs it, folks! If you would like to check out HOPR and contributing to the codebase, you can visit the project Github page. HOPR is crowdfunding their project on Gitcoin and you can support the project along with us here.