Dima Rusakow
Jul 8 · 8 min read

The Most Important Things You Need To Know about “dVPN” projects

Worldwide attempts to censor the Internet, endless security breaches and the eagerness of companies to collect as much private data as they can, is leading more and more people to adopt VPN services.

Non-tech savvy users see the variety of currently available VPN services as a fast and reliable solution. But the bitter truth is that by using these services, users are just trading in their privacy and security to a single entity, which is non-audited, and free to spy on them whenever it likes.

Moreover, the B2C VPN business has turned into a commodity product. Rapidly decreasing margins are leaving companies looking for opportunities to cut costs and find new ways to monetize user data.


The Blockchain panacea

During the mass euphoria over new opportunities opened up by Blockchain Technology, an ultimate solution to the “VPN-centralization problem” was born — let’s create a Decentralized VPN, the so-called “dVPN”.

The “dVPN” idea was adopted by several teams because it was easy to understand, which saved everyone a lot of time and effort on explanations.

Along with its many features, the killer feature of dVPN has always been the ability to run a node and earn money from the spare internet connection. This was a eureka moment for anyone who realized it and especially for our company, which has been operating a commercial VPN with millions of users for years.


Do we have a “dVPN” now?

When teams working in the ‘dVPN field’ sobered up, they started to think about how they were going to achieve their dreams. It didn’t take them long to realize that it’s much easier and faster to add the letter “d” to the name of well-known software, rather than actually building it.

Moreover, this type of distributed software is obviously quite complex. For this reason, each team arrived at its own definition of a dVPN, according to its ability and desire to develop the product.

Some teams are building software that’s practically the same (if not worse) as, existing VPNs; some are trying to make “shortcuts” with hosted databases, servers, tier-3 blockchains or layer-2 solutions; some are blinding people with technical details and then delivering nothing more than standard centralized VPN software.

The bottom line is, we currently have a fully working dVPN (according to some teams), but on the other hand, probably we don’t have even a good-looking alpha version yet.The cat is dead and alive simultaneously.


The dVPN Quadrilemma

The blockchain trilemma is well known, but let’s extend it to our context. Along with Decentralisation, Scalability, and Security, the dVPN can definitely add a fourth important aspect — SPEED. Most development teams don’t realize the real trade-offs or just don’t want to. The ability to understand this simple, but fundamental idea, is crucial.

1) Decentralization

This term does not have an exact definition, but according to the general consensus can be defined in several areas as follows:

1.1 Technical decentralization — implies no single point of failure (i.e. company servers) or any possibility of network control through the execution or modification of software. If the software is open source software and relying on a popular public blockchain, then this aspect is fully covered.

1.2 Governance is a hot topic right now, but not the most important for dVPN. If a team that maintains open source software tries to abuse the core network software, other developers can execute a “hard fork” and replace it. Even without sophisticated DAO, the project can sustain itself for a long time. The best examples of this are the Bitcoin Core team contributors and Ethereum.

1.3 Regulatory decentralization — the absence of a single jurisdiction that can define the rules and impose a framework on the workings of the network. This aspect is fully covered by native blockchain features.

1.4 Monetary decentralization — means the ability of anyone in the world to execute borderless p2p payments in crypto currency which are freely available on the market. Covered by native blockchain features and by the concept of ERC20 utility tokens in particular.

1.5 Economic decentralization — the lack of a single authority that can influence the decentralized p2p market economy (i.e. set prices for traffic). All economic relations should be built p2p only between network participants. Dedicated smart contracts on a public blockchain (i.e. Ethereum) covering this topic.

“Decentralization, including all of the aspects from 1.1 to 1.5, is an absolutely necessary condition for a reliable dVPN”


2) Scalability

A fast and scalable blockchain is necessary for a reliable dVPN network, because, the paramount goal is to scale up to eventually having millions of people connected online.

Choosing non-scalable blockchains without features like Ethereum state-channels, for example, may cause micro-payments being too slow and expensive. It could be very risky for future stability.

“Scalability is an absolutely necessary condition for a dVPN oriented towards a worldwide mass market”


3) Security

Blockchain security originally referred to a blockchain’s ability to defend itself against attacks from external sources. Much has been written about it. But, with dVPN, we should highlight other security aspects as well.

3.1 Data Encryption — Data transferred through the network should be encrypted and secured. In other words, no one should be able to easily tamper with network participants’ traffic.

3.2 Extreme anonymity -The extra level of anonymity can be implemented on dVPN. The excellent example of such kind of architecture is the TOR. The owner of the Exit node shouldn’t know the IP addresses of other users — the best known solution is relays and multi-hop connections.

3.3 Secured Network topology — The IP addresses of network participants should be secured as tightly as possible. If anyone can gain easy access to these IP addresses, the entire network topology will be totally compromised and become easy to ban or filter.

Aspects 3.1 and 3.3 are absolutely necessary conditions, while the 3.2 (Extreme anonymity), is sufficient but not necessary for dVPN security, due to its strong trade-off with Speed”


4) Speed

We added this important element to the original Trilemma in order to create our Quadrilemma and thereby complete the image of dVPN trade-offs.

In the case of a possible network design when the entities are exit node owners and multi-hop relays, the traffic will bounce through many hops in various places around the world. This will decrease speed significantly and raise a lot of billing questions. Bottlenecks and different network latency will always have a place.

There is no doubt that we have a direct connection and the trade-off between security and speed. The most secure dVPN will probably be very slow and unreliable.

In order being mass adopted not only by people with extreme passion for security, but by the general public worldwide — dVPN should operate at a reliable speed, very close to the original.

A reliable Speed is an absolutely necessary condition for dVPNs oriented towards a mass market worldwide, but a sufficient condition if the dVPN is created for a narrow audience of security-obsessed users”


Analysis

Figure 1: represents the lack of Decentralization, and sacrificing any of the 5 necessary conditions is unacceptable for a reliable dVPN. It will be nothing more than another centralized VPN service.

Figure 2: represents the lack of Scalability. That’s also why choosing the most suitable Blockchain is crucial. Not every public Blockchain satisfies all the necessary conditions for Scalability and Decentralization simultaneously. A non-scalable blockchain means a non-scalable dVPN.

Figure 3: represents a slow, but the extra-anonymous dVPN network that very similar to TOR and would be great for people who are seeking extra anonymity and security for just a certain amount of time. At the same time, this option is definitely not suitable for a regular internet user due to speed limitations.

Relays and Multi-hops functionality is very important in providing extra anonymity, but not as important as providing reliable speed. A dVPN could quite possibly implement this kind of functionality, but there are two main reasons for not doing so:

First, the dVPN crypto-economics assumes payment to bandwidth providers. Creating a decentralized version of TOR and relying on volunteers running relays is not such a good idea. Therefore, someone needs to pay, and every hop/relay in the chain increases the cost of using and dramatically decrease speed.

The second reason is that users with extra anonymity and security requirements may already use TOR, which is a great solution for this kind of purposes. Any attempt to create a new version of TOR-like network is not reasonable.

Figure 4: represents the choice of Speed over Security, but not all the aspects of Security should be sacrificed. Aspect 3.2 only (Extra anonymity), has the biggest trade-off with Speed. Aspects 3.1 and 3.3 of Security are still absolutely necessary.


Conclusions

Based on the analysis, the conclusion is that the first important decision in dVPN development is to choose the most suitable blockchain for the task.

This blockchain should cover all the aspects of Decentralization and Scalability. Unfortunately, the only blockchain currently covering this, in our opinion, is the Ethereum blockchain.

Ethereum is the largest open-source project with the most robust functionality and, considering their development roadmap, has the best chance of finding the right balance in the Trilemma with their Ethereum 2.0 future release.

Using any kind of faster and cheaper blockchain or layer-2 solutions would compromise the most critical aspects of a dVPN — Decentralization and Scalability.

Apart from complex technical challenges, another important task is to keep the right balance between reliable speed and anonymity.

Unfortunately, many teams who are developing dVPNs haven’t realised (or don’t want to realise) the basic underlying trade-offs and developing unreliable solutions.

The examples of the some controversial practices in dVPN development:

  • The lack of available source code
  • Relying in core functionality on tier-2/tier-3 Blockchains or Layer-2 solutions
  • Compromise network topology by allowing anyone to easily extract the IP addresses of all network participants
  • Compromise Decentralization by using own servers/APIs for ANY purpose (except collecting statistics at the testing stage)
  • Compromise Decentralization (Governance) by creating the possibility to execute changes in smart contracts

Disclaimer

The author of this article is affiliated with the Privatix Network. The team is building “dVPN”, but avoid using this term due to the lack of a generally accepted definition.

The team is building an “Internet Bandwidth Marketplace powered by a P2P Network on the Ethereum blockchain”.

The team opinion is that their Core software is at the forefront of what the first versions of reliable dVPN should look like. At the same time, some trade-offs need to be made.

Obvious, that many so-called “dVPN” providers are misusing this concept riding on blockchain-hype and develops centralized solutions, which is the same as the ones available on the market for years or even worse.

privatix

Official Blog :: Privatix Network

Dima Rusakow

Written by

CEO at Privatix Network

privatix

privatix

Official Blog :: Privatix Network

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade