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

Governance GIPs
24

It’s true that these questions of funding and amount are important, so it could be a further discussion to say what the amount requested might be (a rough range?).

But I understand the desire and interest in making a VPN, especially with the GNOSIS brand.

With its transition, Gnosis wants to offer services and products with real utility and interest for the crypto community.

And I’m totally in line with this philosophy, so I can’t wait to find out more and see if this product can be developed to expand the Gnosis range of services/products

1 Like
25

We deliberately did not ask for a large upfront sum with an upfront full-scale project plan because we do not want to fool GnosisDAO into thinking that such huge projects would ever work according to a non-agile multi-year development plan. Instead, we carefully considered what we are certain we can deliver within 9 months - and maybe we can go beyond that. So a next step depends on exactly how far we get, how the landscape looks like at that point in time and what reasonably makes sense to develop next and which target platforms, user groups and use cases should be tackled. Especially on the commercial questions we are very much looking forward to more discussions and feedback from the community at the time of the second proposal.

Since some questions in this direction came up I find it important to highlight that all work that we undertake at HOPR is free and open source with permissive licenses. As such, even the initial work that is already now ongoing to generalize RPCh to more general purpose usage, is already all in the open. So if HOPR does not deliver, is going over budget or ceases to align with the Gnosis ecosystem, there is absolutely nothing stopping another team from taking over the work that we did.

3 Likes
26

I wanted to also take the opportunity to highlight the decentralized nature of the HOPR network which shows another angle of alignment between HORP and Gnosis and which is a value proposition of onboarding HOPR node runners as Gnosis validators. We created this Dune Dashboard that highlights that there’s only 2 HOPR Safes with more than 10 connected HOPR nodes and only 10 run more than 1 HOPR node.

I think that is a significant difference from many other projects in the ecosystem in that HOPR nodes are operated by individuals and not professional node operating corporations. Many of HOPR nodes are running on DappNodes out of their operators’ homes, thanks to our partnership with and custom branded HOPR DappNode devices.

2 Likes
27

Thank you for your responses. I must express, however, my remaining scepticism.
Upon reviewing the codebase, the associated costs seem unjustifiable. Though I prefer to remain unnamed, I can evaluate this matter accurately.

I propose the following adjustments:

  1. The total cost should be reduced to $500,000
  2. Implement a milestone-based funding model, wherein funds are disbursed upon achieving specified benchmarks

Nevertheless, I anticipate that these suggestions may be overlooked, as this has been my experience with DAOs in the past, sadly.

1 Like
28

Thanks for looking at our code - that’s what FOSS is about and I’d appreciate specific feedback. It would help me to respond to you if you made your criticism explicit. Are you saying “your code looks so poor that it’s not even worth the $1.5m of this first proposal” or “you basically did 90% of the work that’s needed for this first milestone of Gnosis VPN and only have like 3 man months of work left and hence $1.5m is too much”?

As outlined in detail in the OP, I absolutely agree with your notion of milestone-based payouts and that’s exactly what we suggest here in this proposal.

1 Like
29

From my analysis today, it appears that the majority of the tasks associated with GnosisVPN have been successfully completed, with only minor discrepancies remaining.

The remaining objectives include developing the front-end and enhancing the performance of HOPR, which I would argue the former is out of scope, but given Gnosis Ventures initiative, I find it acceptable.

I must apologize if my scrutiny seems excessive. However, I believe the funding requested exceeds the necessary amount. In line with the principles of DAOs and the ethos of cryptocurrency, we should adhere to the maxim: Don’t trust, verify.

Edit: Additionally, can you specify the milestones you are referring to? The proposal seems vague in that aspect. What is the value given to each deliverable? Or is the grant given up-front?

1 Like
30

From my analysis today, it appears that the majority of the tasks associated with GnosisVPN have been successfully completed, with only minor discrepancies remaining.

Thanks again for digging into the code and the proposal this deeply - that’s something I rarely see in DAOs but as you mention, that is extremely valuable to ensure funds are not misappropriated.

As you have mentioned in earlier comment, RPCh is already operational: GitHub - Rpc-h/RPCh: RPCh is the only private RPC provider. Uses HOPR under the hood.

Correct, but that has almost nothing to do with the proposed work here.

Deliverables 1.2 and 1.3 have been met (90% there), given that RPCh encompasses similar functionalities, albeit with different endpoints on the exit-nodes

Generally, the intent of this work is to not just provide short-term gains and PoC, but actually a sustainable product development plan which seeks to bring Gnosis VPN as a viable product to a significant market - in line with the Gnosis 3.0 setup. That is important to understand as, indeed, we could make a quick & dirty first version of pHTTP and Gnosis VPN that would never be rolled out in production. But the goal here is actual product development. RPCh has comparatively tiny payloads compared to what you would typically utilize within the use of a web browsing setup.

Thus, the assumption of deliverables 1.2 and 1.3 being 90% there is incorrect. The current version that is in the repo which you also refer to in your next point is utilizing a relatively simple specific purpose solution built for the Ethereum RPC standard only. For example, the setup cannot handle websockets, additional HTTP header fields or other HTTP verbs. That means the entire architecture of this extremely opinionated and non-optimized form of the protocol needs to be overhauled from the ground up. That is deliverable 1.1 which then gets implemented in deliverable 1.2.

As the entry/exit node behavior changes with these additional requirements, entry and exit nodes also need to be reimplemented. This also needs to be tested wrt performance as I expect some large payloads to not get delivered within a timeout window. Beyond per-resource performance assessments, we also need to consider network-wide load assessments to judge which websites and services are in scope of the allow-listed first version of Gnosis VPN which is in scope of this proposal for the first PoC.

The RPCh code has been relabelled to GitHub - hoprnet/pHTTP-lib: p(rivate)HTTP library, which seems to represent the CORE code in RPCh

To be precise we started extracting and generalizing the core of RPCh which should present the basis for the Gnosis VPN work into a separate library. RPCh will become a user of that library, therefore this isn’t a simple re-branding and presents only the first step before we start re-designing and re-writing this for the much larger capabilities of Gnosis VPN compared to the specific purpose use case of RPCh.

The remaining objectives include developing the front-end and enhancing the performance of HOPR, which I would argue the former is out of scope, but given Gnosis Ventures initiative, I find it acceptable.

I don’t understand why a front-end - without which the proof of concept is entirely unusable for normal users - would be considered out of scope. We normally focus on making tech as approachable for end-users as possible and Gnosis does too.

Edit: Additionally, can you specify the milestones you are referring to?

The deliverables 1.1 - 1.5 culminating with a release of a proof-of-concept version of Gnosis VPN is the first milestone. Further milestones would be subject to an additional Gnosis DAO proposal.

What is the value given to each deliverable? Or is the grant given up-front?

We would prefer upfront payment.

Finally it is important to point out that this proposal is not a grant. Gnosis DAO is not just sponsoring product development work but is receiving a significant value worth of HORP tokens on top of the product development work.

31

As a noob, I would like to know what would be the implications of exit/entry nodes with people using the product with their already KYCed addresses on Gnosis Pay with this product?

I know the PoC is supposed to provide limited access to certain endpoints to help out with privacy. However, as all the people who have signed up for a Gnosis Card provided their KYC info to Fractal, and Gnosis Pay, and most probably Monavate also having access to this info as well, I am curious to get an insight on the implications of what a decentralized VPN network powered by HOPR node runners in terms of prejudicing the user’s privacy (especially if the node runner is using the same credentials/IP/or whatever you wish to call it is known by regulatory bodies or poor opsec by the node runner).

Would it pose a risk to the node runner as being KYCed, would it pose a risk to the user with a KYCed address, would it pose a risk to the entire network due to the failure of either?

EDIT: I do think we need a decentralized VPN solution and this is one of the proposals that got me excited on Gnosis 3.0/consumer product oriented roadmap!

5 Likes
32

That’s a very good - and non-noob - question! Let’s dissect it:

First of all, what are the implications for entry and exit nodes? Entry nodes see the end-to-end encrypted metadata of the traffic. So the entry node which is directly in contact with a user of course sees that user’s IP address and metadata such as the size of requests and reponses they send. The latter can be partially mitigated by sending data via multiple entry nodes. In fact, HOPR is designed to make the switching of routes very efficient, to provide decrease the necessary trust in individual entry nodes.

The exit node, on the other hand, has no way of knowing the user’s metadata, so specifically they don’t see the user’s IP address. But the exit node makes the actual requests and sends back the responses so that webserver sees the websites that are being accessed, but they don’t see from who, so the exit node does not see the IP address or other metadata and is specifically also not able to link individual requests to the same user.

Thus, if you are concerned about your KYC-ed identity being linked to your web-browsing activities, Gnosis VPN should be able to better protect you against de-anonymizing of your traffic than other means. The only exception is of course if the entire chain of nodes all collude (including entry and exit nodes and Gnosis Pay KYC providers) - but there’s really no system that could protect you against that.

I’m very happy to hear that Gnosis VPN makes you excited about the Gnosis 3.0 roadmap - we see the same!

2 Likes
33

This proposal is now live for voting on Snapshot.

3 Likes
34

Enthusiastically voted yes. Let’s do this!

3 Likes
35

@SCBuergel

I haven’t voted on this decision on snapshot yet, but I’d like to know: you say HOPR tokens at -30% discount.

But how many HOPR tokens are you going to sell to the Gnosis Dao at this rate? (Maybe it was mentioned but I must have missed it).

1 Like
36

Hi, happy to clarify the amounts mentioned in the OP. The amount of HOPR tokens sold to Gnosis DAO equals $1.5m / (HoprPrice90dTWAP * 0.7). For the TWAP we created this Dune dashboard. The TWAP will run until end of the Snapshot proposal and will change a little bit - but at current values that would be approximately
1.5m / 0.108 * 0.7 = 19.84m HOPR

2 Likes
37

Thank you very much for this more detailed information!

3 Likes
38

Thank you everyone for the fruitful discussion and for all voters - the proposal has now been voted upon with 99.94% in favor on Snapshot page.

The Dune dashboard for the 90d HOPR TWAP has been updated with the end time of the end of the voting period and the final price is $0.111753491. Thus Gnosis DAO will purchase

1'500'000 / (0.111753491 * 0.7) = 19'174'856 HOPR
3 Likes
39

Congratulations! I’m excited to see how this project progresses.

3 Likes
40

For the record, the OTC deal will be executed through the following DAO address: eth:0x849d52316331967b6ff1198e5e32a0eb168d039d

41

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

3 Likes
42

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.

messages-rate
messages-rate935×494 46.3 KB

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

success-ratio
success-ratio934×497 63.9 KB

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

message-latency-quantiles
message-latency-quantiles939×540 38.5 KB

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:

  1. Install Nix, the dependency management tool used in HOPRd’s toolchain: Download | Nix & NixOS
  2. Check out HOPRd branch tb/20240731-stress: GitHub - hoprnet/hoprnet at tb/20240731-stress
  3. Run the following command in the checked out sources:
nix develop .#smoke-tests -c make stress-test-local-swarm
  1. 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.

11 Likes
43

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.

GnosisVPN-architecture
GnosisVPN-architecture437×572 34 KB

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.

9 Likes