Building a Decentralized Value Exchange into a Decentralized VPN

Roberto Vis
Mysterium Network
Published in
8 min readMar 2, 2017

In a world which is rapidly being decentralized — there also needs to be a decentralized way to ensure adequate payment for those who provide us with the infrastructure. We have found a way to get there and now we will present an evolutionary path towards it.

If you are new to Mysterium Network, we suggest you start with our introductory post about Decentralization of VPN.

For the last month we have been examining existing technology and its potential, to perform POC (Proof Of Concept) experiments — with the goal of understanding how to build a decentralized VPN service and how to provide monetization to people running this network — VPN node operators.

We soon found that the issue lies not just in decentralizing a Network of VPN Exit Nodes. This is an elephant in the room. Once we started digging we unveiled much deeper levels. Let me give you an example.

Micropayments — Essential Element of Decentralized Monetization

Let’s say there is a network of VPN exit nodes ready to serve you as a customer. And as a customer you are seeking to connect to a node located somewhere in USA. How would we design such a process?

I. Anonymous Identity

When registering to Mysterium network — you will automatically get an Identity. This doesn’t mean your personal information is stored, just that you are assigned a unique hash acting as your Identifier within the network. When using Mysterium Network you will use this Identity.

In essence Identity is a version of a reputation mechanism, protecting network from user-malicious activities against the network (we will cover this in great detail in our technical documents).

II. Discovery mechanism

When you start searching for a specific node matching your selected criteria — you are communicating with a Discovery mechanism. After choosing a node — you will attempt to open a connection with it.

There will be a quick negotiation process between you and your chosen node, if both agree — a green light to establish a secure connection will be given, with you receiving connection parameters from the node. The moment a secure connection is established — you are officially a customer of this Node, using their service.

III. Payments

At this point another mechanism needs to take place, with the goal of ensuring you and the Exit Node Operator both keep your promises:

  • Node Operator will deliver what they promised You — a VPN service,
  • You will pay for their service according to your usage (e.g. for time and traffic used).

Since this is a continuous process it must be updated frequently. We could create it using Ethereum, but then the cost of transacting would greatly exceed the amount paid to the Node Operator. Thus we need a different mechanism. Micropayments designed by us will use “promise — check — clearing” mechanism, it’s a combination of Ethereum smart contracts backed by internal processes happening inside Server/Node, making sure it’s economically viable to run this process.

Micropayments — are a combination of all 3 elements

We see all 3 elements as essential in making a successful and monetized continuous transaction between 2 unknown entities. And all 3 will make up our CORE.

In Essence — CORE is a decentralized micro payment service operating within range of user to user promises and making sure those promises are delivered.

Building a central server handling micropayments is fairly achievable and has been done many times, it is decentralizing it that is difficult.

After extensive research we believe we found a way to first build a centralized CORE and then decentralize it — providing decentralized value exchange to decentralized network of node operators and their customers.

Let me show you what we found.

Phase I (2017–2019)

Goal of Phase I is to create a completely decentralized VPN service with decentralized node network and decentralized CORE elements.

Phase I is divided into 3 stages.

Stage 1 — Decentralizing VPN Node

The goal is to decentralize the first element of the Network — the VPN Node “dVPN”, and then to create fully functional CORE elements, composed of internal parts built right into a central server and external elements, built as Ethereum Smart Contracts working together with our central server.

Elements created during this stage:

  • VPN Node: able to provide the VPN service upon request, while talking to the CORE.
  • The CORE — acts as an oversight for the whole network. At this stage CORE will be a mixture of centralized servers and decentralized elements built into Ethereum Network;
  • API — for other entities and companies to use this network as their own, in their products;
  • Learning of initial issues, obstacles and fixing them within limits of current setup.

At first we will take existing protocols such as OpenVPN, ShadowSocks, etc .. and build dVPN node using them.

We will learn a great deal during this stage. Here are a few examples: how decentralized network of VPN Nodes acts in reality, what the load balancing challenges of such a network are, what kind of other issues may arise, discover possible attack vectors and weak spots, etc. Central servers will be extremely helpful in this stage of identifying and fixing any issues quickly.

Stage 2 — Starting to Decentralize the CORE

Now that we have a good understanding of the dynamics, we can start decentralizing some of the CORE elements, by embedding first aspects into each Node.

dVPN 2.0 Node is created in this stage.

As shown in the picture Each dVPN Node is made up of 2 elements:

  • Server — a control unit overseeing all actions of the node, such as negotiation with customer, turning Exit Node: on and off, and providing some of the CORE elements.
  • Exit Node — providing encrypted connection to the customer.

In this stage dVPN Node gets a big upgrade — as some of the CORE elements are now accessible via this Node directly.

All CORE functions accessible via Node will be in “Read only” mode, while writing new information will still happen through a central CORE server. Each node will have its own copy of essential data linked to CORE thus getting benefits such as greatly increased speed, and cost of operations.

New elements in this stage:

  • dVPN 2.0, Server — introducing some of the CORE elements into the node, introducing communication between nodes;
  • dVPN2.0, Exit Node — adding additional layers of connection by integrating other VPN protocols, proxy, etc.
  • Central CORE Server — lowering the importance of the central server, as some of the load is transferred to the Node Network.

The goal is preparation for complete decentralization.

Stage 3 — Complete Decentralization

By now we will have enough knowledge to move all CORE elements onto the Nodes communicating with each other and directly cooperating with Ethereum smart contracts.

dVPN 3.0 Node is released.

By now central server is gone, dVPN 3.0 nodes will handle all aspects of the service acting both as the CORE and as VPN service providers.

Once this stage is complete, we will have completely decentralized these elements:

  • Identity management
  • Discovery mechanism
  • Payments
  • Providing of VPN Service

At this point a single point of failure no longer exists, code is open-sourced and accessible to anyone and network is completely decentralized.

Completion of Stage 3 also completes Phase I.

Phase II (2019+)

There are many paths we can take during Phase II, although this is still a debated topic. A few options we see are:

  • Decentralizing Governance modelMelonport decided to go this route for their final phase, we may take a similar approach;
  • Opening up CORE to serve other dAPPs— VPN is not the only dAPP which needs CORE elements to function properly. By this time we will have the necessary know-how and a network of nodes as an asset, which will put us in a great position to create a CORE based on Open Architecture — able to handle not just dVPN, but any kind of dAPP (I could get into greater detail on this topic if you want) as this provides a great opportunity to build something needed by many. Once such a network exists, many dAPP developers will not need to build it themselves anymore and instead will be able to concentrate on their dAPP specific dynamics without needing to build administrative mechanisms, such as secure micropayments and discovery mechanism, as all of it will be supplied via a single integration;
  • Building Mysterium brand targeting end-users. In Phase I — we will be focusing on the service side of things. In Phase I — our goal is not to sell to end users directly, but to build a robust VPN node network, which other companies can use in their products, for example, a regular VPN provider will be able to use a Mysterium node Network instead of building their own server farms all over the world. In Phase II — we could start building our own brand, directly competing with existing brands (your thoughts are welcome if you see this as a wise direction). If we are to choose this path it would include our own apps for all platforms (Windows, iOS, Android, etc.), marketing to users.
  • Improving VPN quality by building our own VPN protocol: untraceable and easy to integrate for companies into their apps. Imagine any app: Facebook, Netflix, Reddit, your email provider with VPN integrated directly into an app. We could design the protocol to make their life a lot easier by providing integration.

Phase II is still not well defined — my mentioned options are just ideas for potential paths to take, and your input is welcome.

Token Sale

In Q2 we will be performing a token sale, with the goal to get the needed resources to create such a network. With this token sale we don’t want to go beyond Stage 3 (Phase I), which means, for now we will be collecting just enough funds to get us to completely decentralized VPN.

A completely separate token sale will take place to fund Phase II sometime in 2018–2019, after we deliver our promises made for Phase I.

Final words

Once we start going on this journey we will uncover the most essential next steps for Phase II. At the moment we can see there are many paths we could take, my questions for you would be:

  • which path would you take for the Phase II? Maybe it’s something new, something I haven’t mentioned in here?
  • How about Phase I — do you see anything you would improve?

Please join discussion on our slack channel, or just comment here.

--

--