Transaction was fully executed.
HOPR received in this tx.
USDC sent on this tx.
3 Likes
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:
- Support for compiling HOPRd as a native binary on multiple platforms
- Reduction of DB access during packet processing
- Reservation of app tags for internal session and protocol usage
- Overall performance and scalability improvements of the HTTP API
- Offloading of CPU-intensive work and foundations of specialized parallel processing
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.
11 Likes