Blepcoin

Home RSS

Privatix
Internet broadband marketplace

https://privatix.io
lead image

Privatix is an internet broadband marketplace. “Agents” can sell bandwidth based on time, megabyte, or other metric. “Clients” can purchase this bandwidth to deliver data to themselves or others.

Specific use cases for decentralized bandwidth are implemented as plugins. Initial use cases are VPN and proxy services, as the Privatix team has domain expertise as well as 1.7M users in their centralized VPN service. Other potential use cases for a distributed bandwidth network includes 3rd party decentralized VPNs, ProxyMarket, Monetization, Anti-censorship solutions, and content delivery networks (CDNs).

Whitepaper: https://dxw4crzwfgmzw.cloudfront.net/whitepaper/PRIVATIX-WHITEPAPER.pdf

Testnet is live, with a network graph here: https://privatix.network/graph

Market opportunity/Competitive analysis

While Privatix is not a VPN-specific project, the go-to-market strategy is to implement a decentralized VPN on top of the decentralized bandwidth network.

[The] VPN market is expected to reach USD 106 billion by 2022

The biggest competitors for this strategy are existing centralized VPN services. However, this competition may convert into an opportunity to become the infrastructure layer for these competitors, if the cost and performance is comparable to the existing datacenters they use.

The team mentions that 3rd parties could use the network to develop a decentralized CDN in the future. While I do suspect implementations will be complex (to deal with caching), if successful this would be a huge market to enter as well.

The market size of CDN is expected to grow from $4.95 billion in 2015 to $15.73 billion in 2020, and to $70.3 billion by 2025.

Additional potential markets:

Privatix.FAAS: Anti-censorship as a service: basically a built in VPN client for specific apps.

Privatix.Monetize: Replacing ads in apps with a built-in Agent to share bandwidth. Proceeds go to the app developer.

Team/Advisors/Partnerships

The team’s past projects speak for themselves. (note: the team tells me that this picture is now a bit outdated – there are now over 1.7M users on Privatix VPN)

Competitive Advantage

Privatix is an existing company with a VPN product. They have market expertise and 1.7 million users who have already installed their product. The marketing and distribution problem is essentially already solved.

[Privatix for Opera](https://addons.opera.com/en-gb/extensions/details/privatix-for-opera/) addon: 546,000+ downloads, with a 3/5 star rating.

Android: 100,000+ installs, with 4.5/5 star rating.

Privatix Google Chrome extension: 48,000+ downloads, with a 4/5 star rating.

Privatix for Firefox: 3,900 downloads, with a 3.5/5 star rating

Note: Apple doesn’t provide public metrics for iOS App Store. Here’s the US App Store link.

Tokenomics and Token Utility

The tokenomics model is designed as a medium of exchange model, with some mechanisms to capture value from the growth of the underlying network (eg. user base, higher utilization). One of the existing value capture mechanisms is that when Agents register their service offering onto the Ethereum blockchain, they must place a deposit. Similarly, when Clients want to connect to an Agent, they must place a deposit as well.

They are also currently researching token curated registries (TCRs) for ranking/tagging domains, to enable the users to filter out specific content, such as illegal content in specific countries. In this case, the token would be used for voting in the TCR, thus, adding value to the network and reducing circulating supply.

So, is the utility of the token so high that it’s worthwhile for people to overcome the network effects and cognitive overhead of having a new application specific token? There are 3 key ways to increase the chances, and the team is doing all three:

  • Add features to capture value as the network grows (such as the TCR above)
  • Reduce onboarding friction (the team plans to have a fiat onramp ASAP, and utilize EIP865 to allow users to pay PRIX token as transaction fee)
  • Considering an automatic price feed of USD/PRIX in the client side software so users don’t need to have that cognitive overhead.

While there is more friction than just using a chain’s native coin, the team does have more flexibility in increasing token utility without increasing rent seeking.

Markets

There are two markets: PRIX/mb, and PRIX/usd. End users will only care about usd/mb as it provides the least amount of cognitive overhead.

The PRIX/mb market is not an asset market, but an internal service market. In other words, people will use megabytes when they need it; they cannot store megabytes when they are cheap, and sell megabytes when they are expensive. Therefore, even if PRIX/mb is volatile, almost all service users will only be affected by the much more stable, moving average.

The PRIX/usd market is an asset market, and changes in exchange rate will depend on network demand due to the captured network value described below.

Captured Network Value

There are different views on what really impacts marketcap. According to Vitalik Buterin’s equation of exchange:

Market cap = Transaction volume • Holding time of network participants

On the other hand Scott Locklin’s paper (2018) states it’s all about supply and demand and even argues that Vitalk’s equation contains various overt errors and misunderstandings.

Regardless, it all comes down to “network growth value.”

There are a couple mechanisms Privatix has included to capture network value:

  • The network absorbs tokens out of the supply from the time it takes to convert USD to PRIX, send PRIX while service is delivered, and convert PRIX to USD
  • Agents must place deposit when registering a service offering to the Ethereum blockchain
  • Clients must place deposit when starting state channels and connecting to a client
  • A rating system, as explained in detail in this post (already live at https://privatix.network/)
  • The team is also looking into the possibilities of integrating a burning mechanism (economic burning, see BnB as a reference project) in order to capture value from the network growth as a result of the growing user base and therefore utilization of the network

As the team adds more functionality to the token, the network would be able to absort more tokens out of the supply, which means there would be greater demand for lower supply.

In the end, both Buterin’s focus about Token Velocity and Locklin’s focus on supply and demand both are applicable and make sense.

Tech

Architecture

Privatix has many parts, as described in this blog post:

  • Privatix core: responsible for billing and orchestrating service life-cycle
  • Service Plug-in: package that provides or consumes a single service, eg VPN. It automates service provisioning, usage reporting, access to service, and start/stop of service consumption.
    • VPN Agent
    • VPN Client
  • User Interface: a single interface to control all operations
  • Token contract: ERC20 smart contract
  • Service contract: Handles offerings by allowing discovery, aging old offerings, preventing overbidding, etc.

Code

https://github.com/Privatix/privatix

Looking at the README, this repo is all about installing prerequisites, preparing config files, and compiling the code. We don’t need to get too deep into the repo as most of the interesting code will be elsewhere.

https://github.com/Privatix/dappctrl

(1502 commits, 11 contributors)

Starting with main.go’s main() function, we can see the overall logic of dappctrl:

  • Connect to a postgresql database using Reform, an ORM for sql databases. (line 275)

  • Create a new worker (line 308)
  • Create a new queue, attach to worker (line 316)
  • Create a new processor, attached to worker (line 320)
  • Create a new Monitor (line 323)
  • Create UI Server (line 335)
  • Create session server (line 344)
  • If this is a Client installation, create a client billing monitor (line 353)
  • If this is an Agent installation, create an Agent SOMC Server, payment server, and agent billing monitor (line 362).

Pretty straightforward.

Let’s dive into some of the other directories to see how processors, monitors, sessions, and SOMC are implemented. Also, let’s see how agent/client billing monitors differ.

Processors: Looking at processor.go, it looks like a job processor and state machine for all Agent and Client interactions, pretty much as described in this diagram below (from whitepaper):

A lot of business logic is here to handle accounts, agents, clients, and to interface with the Ethereum network. Each of these has a golang file to handle changes, for example for Agents there are functions to handle AgentAfterChannelCreate, AgentAfterUncooperativeCloseRequest, etc. Looks comprehensive!

Monitors: Looking at monitor.go and the readme, it’s clear that this is an Ethereum blockchain monitor. It filters all irrelevant transactions, and generates jobs for the processor.

Sessions: Exposes the API that is used to orchestrate service plug-ins (eg. OpenVPN) incl. authentication, create, start, suspend, ususpend, terminate service actions. There is also some code that pushes Agent’s server configuration to dappctrl and associates server’s IP addresses with geographical location.

SOMC (Service Offering Messaging Channel): The interface through which Clients and Agents share Offerings and connection data. This connection is through Tor.

Agent billing: This utilizes the blockchain monitor and local sql database to verify that the payment matches the service delivered. Also handles cases such as long billing lag, inactive channels, and suspended channels.

Client billing: This makes sure that payment is posted when it’s supposed to, and cleans up the channel if it’s been inactive for too long.

Thoughts:

The git repo was organized nicely, easy to navigate, and comments and readmes where things might have gotten a little confusing without them. In addition, a big portion of the codebase is well tested as shown by how comprehensive each test file is (you can see for yourself all the files that have a _test suffix). This shows that the team has experience and is building for the long run, as code maintenance takes more time than an initial build. If I can get a grasp of where each moving part is in 30 minutes, that means it should be really accessible for the open source community and seamlessly maintainable/upgradable by future team members.

I also like that the team considered privacy factors such as the IP addresses of service providers.

VPN Service Plug-in:

(276 commits, 6 contributors)

Once again, the readme is superb. This repo installs OpenVPN then imports templates to the Privatix core database to allow OpenVPN service to be shared over the Privatix network.

The readme mentions ./scripts/build.sh, which tells us that the important application directories in this repo are at /adapter and /inst.

/adapter: This works by starting OpenVPN and scanning the output as it runs. As OpenVPN outputs data on usage, status, and errors, this adapter handles authentication, connections, monitoring, and sessions with the Privatix core app.

/installer: Copies over Offering templates, Product templates, and other config templates, from the repo to the service adapter directory. (deprecated)

/inst: Custom Privatix adaptation of OpenVPN.

Interesting note about the verification of service:

Privatix Network is a platform for buying and selling various services. Any service that can be measured on seller’s and buyer’s side, using single parameter, might be bought and sold via Privatix Network without 3rd party. There is no escrow party, that can decide, if service was provided or consumed. Instead service is sold and paid in such small portion, that risk for misbehavior considered neglectable.

User Interface:

GUI based on electronjs and redux. Nice but nothing too critical for the network itself.

Smart Contracts:

Token contract: Standard openzeppelin erc20 token implementation.

Service contract: More interesting. Contains all the functionality that the whitepaper touches on, and includes the code to let this smart contract utilize the balances of the token contract. I don’t have experience security-auditing smart contracts so I don’t have additional insights to share.

Overall, I love that their code has clear documentation. It’s clear that this team has run a public-facing open-source project before, and have made considerations in order to reduce as much onboarding friction as possible. For example, the installation guide (https://privatix.atlassian.net/wiki/spaces/BVP/pages/624689306/Install+Privatix+Agent+node+via+CLi+to+DigitalOcean+cloud)

Interesting tidbit: One of the devs, Maxim, also contributes to the Fantom codebase.

Rating system:

Rating system is still not implemented in Agent and Client, but it is implemented as PoC on http://privatix.network. We wanted to test the concept and its performance. Now it is clear, that we can do it on each Agent and Client in decentralized manner and going to do it soon. Code can be found here -> https://github.com/Privatix/privatix/tree/develop/rating

- team (2019. 04. 26.)

Security:

A decentralized VPN faces many of the same weaknesses as Tor, because exit nodes are untrusted and adversaries are motivated to attack from that angle.

This article makes some good points about the tradeoffs in security, privacy, and performance of Tor and VPNs.

Using only Tor, she doesn’t have to trust any single entity. Using a VPN, she has to completely trust her VPN provider.

A user trusts a centralized VPN provider

  • to not keep payment information
  • to not keep logs
  • to not share information with their adversary
  • to be competent at keeping their network and machines secure

With a decentralized VPN utilizing a public blockchain with non-private transactions, all of these vulnerabilities get amplified; users now have to trust not just the one VPN company, but every node providing service.

Malicious entities would be able to host (or hack) some Agent nodes and log all non-ssl traffic and IP connections from non-ssl AND ssl traffic.

The team has mentioned that they may exclude unencrypted http traffic from the network completely, to reduce the attack surface. In addition, the team mentioned adding an option to route DNS traffic through the client’s ISP.

Conclusion

Privatix is impressive in that they’re a real company with over a million users already, giving it great odds in tackling the biggest barrier facing crypto companies today: adoption.

The tokenomics is straightforward, and there are additional features planned that increase network value capture as the network grows.

My only potential concern is with security, if the team decides to not exclude all http traffic by default from the client side. For most VPN users who want to get around geographical blockers or censorship, this is not an issue regardless. And, those who are concerned, can set their devices to only allow https connections. However, the non-tech-savvy user might stumble onto a malicious Agent thinking it’s safe, only to be recorded on every move.

Previous Dec 9, 2018
« Ferrum Network