GIP-98: Should GnosisDAO invest in HOPR to kickstart development of GnosisVPN?

Karpatkey · May 10, 2024, 3:03pm

Transaction was fully executed.
HOPR received in this tx.
USDC sent on this tx.

SCBuergel · August 2, 2024, 3:07pm

Intro

This report provides an overview of the work being done as part of the GIP-98 following its approval in 04/2024.

The HOPR team focused on four work streams which have mostly been carried out in parallel:

Finalization, release and support of HOPRd v2.1.x
Implementation of uHTTP (formerly pHTTP)
Design and development of VPN capabilities for HOPRd
Development of HOPRd v2.2.x

Finalization, release and support of HOPRd v2.1.x

The development of v2.1.x had been in full swing since October 2023. Its focus was the replacement of Node.JS as HOPRd’s runtime engine onto become a Rust-native application. This marked the last step of migrating HOPRd from being a Node.JS Typescript-based application to a Rust application. The main benefits coming out of this effort were improved performance, improved stability and better maintainability moving forward. For Gnosis VPN, the improved performance of v2.1.x would already be a welcome side-effect for a better user experience.

The release v2.1.0 changelog (Release HOPR - v2.1.0 · hoprnet/hoprnet · GitHub) includes all details. Notably, the resource consumption of HOPRd went down, making the operation of a HOPRd node more economically viable than before.

Further patch releases up to v2.1.3 most recently fixed minor bugs which HOPRd runners experienced.

With release v2.1.3 we achieved a massive increase in throughput per node. While a HOPRd v2.0.x node was able to handle 2 packets/sec a HOPRd v2.1.3 node can handle 200 packets/sec reliably, a 100x improvement. Below we depict an overview of Grafana charts of a 30min recording of sending messages at a rate of 200 packets per second from one node via a random selection of one out of five intermediate mix nodes back to the same sending node.

Figure 1: Rate of received messages, showing that HOPRd is able to reliably send 200 packets per second.

Figure 2: Success ratio, showing that over the entire 30min recording period the success ratio was over 99.7%, i.e., less than 1 in 300 packets was lost

Figure 3: Message latency quantiles showing that 50% of all packets were received in under 280ms, 90% of all packets were received in under 410ms and 95% of all packets were received in under 440ms.

These results surpassed our original throughput expectations for deliverable 1.5 by a factor of at least 10x.

Additional stress tests which focus on mixer throughput that are run on more powerful consumer laptops have already shown significantly higher throughput than the lab setup results shown above. These can be run by anyone who is interested by following these steps:

Install Nix, the dependency management tool used in HOPRd’s toolchain: Download | Nix & NixOS
Check out HOPRd branch tb/20240731-stress: GitHub - hoprnet/hoprnet at tb/20240731-stress
Run the following command in the checked out sources:

nix develop .#smoke-tests -c make stress-test-local-swarm

Wait, as this will take a while. The results will be shown at the end.

Implementation of uHTTP (formerly pHTTP)

Early on pHTTP was rebranded as u(nlinked)HTTP to signal the most important aspect of unlinking sender and receiver of HTTP requests, thereby protecting the sender’s IP metadata while using web services.

The uHTTP library was developed as FOSS and is available on Github.

To assist dissemination we developed a showcase dApp called MyTokenTracker which highlights the need for uHTTP and shows its effect. The code for MyTokenTracker is open-source as well.

The running dApp can be used at mytokentracker.xyz

We presented uHTTP, MyTokenTracker, as well as a general outlook on Gnosis VPN, at DappCon24 Berlin.

This work completes the deliverables 1.1 and 1.2 of the GIP-98 proposal. Nevertheless, further improvements to uHTTP will be made as we move forward.

Design and development of VPN capabilities for HOPRd

In our original proposal we envisioned the first useful VPN-like functionality to be delivered through a web-browser extension which used uHTTP (see deliverable 1.4 for reference). However, after an initial experimentation phase we discovered that existing web browsers limit web extension functionality too much, making it impossible to design a solution with a good UX. Thus, we pivoted and started focusing on OS-level VPN capabilities, functionality that was originally planned for a later stage.

More specifically, we started designing and implementing the HOPR Session message protocol. This protocol enables HOPRd to expose TCP and UDP ports which can be used to tunnel traffic over TCP and UDP through the HOPR network, both base building blocks to support real VPN functionality in the future.

What does that mean for Gnosis VPN exactly? Firstly, it means the first PoC will act more like existing VPNs from a UX perspective than the original proposal envisioned. This is a welcome change, because user behaviour will not need to change, making Gnosis VPN easier to pick up. Secondly, the first PoC will be closer to the final design, allowing for more time to test and improve performance and reliability as we move forward.

Development of HOPRd v2.2.x

HOPRd v2.2.x is meant as the target release for the Gnosis VPN PoC. As such, it must also provide further performance and stability improvements to cater to VPN-like traffic. Besides the HOPR Session message protocol described in the previous section, we already completed some other notable improvements which we show here in an incomplete list:

Outlook

The focus of the next few months will be on completing the initial implementation of VPN capabilities in HOPRd such that a PoC can be set up and tested. Moreover, work on v2.2.x is planned to complete as well, such that the release can move into an extended testing phase to ensure it sufficiently supports the initial Gnosis VPN PoC.

Thanks for reading. All comments, questions and feedback are appreciated.

SCBuergel · October 18, 2024, 12:35am

Introduction

This quarterly report provides an overview of the work being done as part of GIP-98 as a continuation of the work already described in report #1 above.

The HOPR team focused on the following work streams:

Wireguard-based VPN architecture
Optimizations in HOPR Session protocol
Further development of HOPRd v2.2.x
Smart contract audit

Wireguard-based VPN architecture

The decision to implement the HOPR Session protocol (see the previous report for context) allows us to shift the bulk of the VPN work to the HOPR side, leaving the GnosisVPN client and server lightweight and streamlined. Having completed the initial HOPR Session protocol implementation, we focused on designing an architecture which could leverage that functionality, be as simple as possible, and relied on existing, well-tested technologies where possible. A key component of this decision was choosing a VPN protocol to use on top of the HOPR mixnet.

With these considerations in mind, we opted to leverage Wireguard [1] as the integration point with the operating system.

Using Wireguard as our VPN protocol has multiple advantages:

Wireguard is widely used by vendors like ProtonVPN and Tailscale; as a result it has been optimized and comprehensively tested
Wireguard is available natively on some operating systems as well as in many user-space implementations, giving us plenty of options to choose from
Wireguard speaks plain UDP, which is already supported by the HOPR Session protocol; therefore it’s directly compatible with HOPR itself

The final architecture is simple, with all interaction between client and server happening in a private and secure fashion.

Figure 1: GnosisVPN architecture integrating HOPR and Wireguard VPN protocols. The bold line represents the flow of user traffic and the thin lines are configuration and other control flows.

We will provide more details on the architecture and interaction flows in the next report.

Optimizations in HOPR Session protocol

The HOPR Session protocol allows other clients to use the HOPR network via simple TCP and UDP connections. However, this generic support comes with downsides of having to handle a multitude of combinations of packet sizes and bandwidth. Without optimizations, it would be easy to overload individual nodes or the entire HOPR network. To handle these more reliably, we’ve spent the past months optimizing many parts of the protocol:

UDP stream parallelization: Each CPU core is now used to receive data, reducing back-pressure and potentially dropped packets on the network interface.
Network segment batching: Small network segments are combined into a single HOPR packet. This dramatically reduces the network overhead within the HOPR protocol in such use cases, therefore improving the user experience.
Fast acknowledgment: By prioritizing acknowledgements over other protocol messages, further retransmissions are prevented, further reducing the network overhead.

These are just a few examples of possible improvements As each new use case is tested, we expect to discover further potential optimizations. Each optimization reduces network overhead and improves the user experience of the GnosisVPN PoC. We are aware that while users value privacy, there are limits to the trade-offs they are prepared to accept in terms of latency, stability, etc. Therefore, these optimizations will be a priority for the remainder of the PoC work.

Further development of HOPRd v2.2.x

Besides the aforementioned HOPR Session protocol improvements and many bug fixes, some additional changes made it into the v2.2 release.

The latter changes will allow the HOPR network to move away from 100% ticket winning probability (as currently used within the network) to a much lower value, significantly reducing the number of on-chain interactions HOPR relay nodes need to make to earn rewards. This value can be configured through an on-chain oracle. The lower ticket winning probability is a major enabler for making GnosisVPN viable as it allows users to transmit larger amounts of data over the network in an economical way.

Smart contract audit

Since the HOPRd v2.2 release will be used as the basis for the GnosisVPN PoC, we welcomed the opportunity to get the HOPR smart contracts audited once more, this time by Côme du Crest, Security Researcher at Gnosis.

Côme provided us with a very good report showing that he discovered issues we haven’t been aware of and general improvements. None of the discoveries is critical. Therefore, all feedback was added to the smart contract change scope for HOPRd v3.0 as part of which we will overhaul our smart contracts and can make backwards-incompatible changes. Some changes were already applied to the v3 development branch in Response to audit 20240826 by QYuQianchen · Pull Request #6489 · hoprnet/hoprnet · GitHub

The audit report has been added to our Github repository.

We are thankful to Côme for his efforts.

Outlook

The required work for HOPRd v2.2 is almost complete, with the remainder mostly being bug-fixing and testing and general optimization for VPN usage. HOPRd v2.2 is set to launch before the end of the GIP-98 timeframe. In parallel, work will continue on an end-to-end setup and demonstration of the GnosisVPN PoC, including the GnosisVPN Client, GnosisVPN Server and GnosisVPN Registry components (see Figure 1 above). Thanks to our previous work implementing and optimizing the HOPR Session protocol, completing these final components necessary for the GnosisVPN PoC should be relatively straightforward and is scheduled to be completed within the timeframe given in GIP-98.

Thanks for reading. All comments, questions and feedback are appreciated.