Some time ago we started to explore issues related to Internet, its openness, freedom and safety. We’ve been covering these questions in more details in previous posts. In this post we are going deeper into more technical details. It should help clarify what this project is about and its technical implementation approach.
High Level Architecture
Core Idea of the system is fair exchange of value between network users creating sustainable and decentralized ecosystem. In our case users who want to get anonymity and secure network connections will reward service providers. In its best case the service should fall into DApp architecture (decentralized application) where the application belongs to community and its evolution is encoded into its consensus process.
Proposed Elements of Mysterium DApp node
Full nodes of Mysterium will have integration with Ethereum, supporting financial transactions. To support interactions between Network users a database (DB) will be needed. Such operations like encrypted IP exchange, info about live servers and other information will be stored in the DB. Light weight nodes will not have DB and will be able to connect to full nodes. Mysterium Node Core element will orchestrate the execution of node and interaction between all elements of node and rest of the network. The lowest layer (Local VPN Connection API and drivers) of application is actual VPN implementation and integration into node.
- Ethereum — is a top layer of solution architecture where financial transactions are executed. To start using Mysterium service users will need to deposit coins into Mysterium smart contract. Mysterium smart contract will manage coin transfers between system users (service providers, service users and Mysterium Network).
- Integration between Ethereum and Mysterium data base. Ethereum data changes which are related to Mysterium Contract will be replicated to Mysterium database and vice versa. At the best scenario integrations should be done in a decentralized manner where data is consistent and consent (in proof of concept phase we will use a centralized integration mechanism, while researching ways to decentralize integration).
- MicroPaymets. To prevent abuse of network usage without payment we should do micro payments for small data amounts where those amounts are acceptable by sender and “router”. The size of transferred data chunks for micro transaction will be defined by user parameters and system algorithms. For a better performance micro transactions will be executed off Ethereum blockchain and when the session is closed payment will be executed via Mysterium smart contract. In case of too many sessions and performance issues, payment into user wallet could be done on suppliers request — that would also lower load on smart contract on Ethereum if needed. (More about micro payments in coming blog posts)
- Mysterium Data Base. It is one of the core elements of Mysterium Network node. To keep whole philosophy of Mysterium Network DApp architecture will be applied. It will need a data storage which should be distributed and replicated across network nodes of Mysterium Network. Database solution is not decided yet, but there is few candidates. We still need to do deeper research and compare different solutions on criteria like performance, capacity, need for computing power and etc.
- Client/Server Connector. If system will have a blockchain database on nodes, nodes will be able to discover each other via built in functionalities on it. If a client is lightweight (without Database) then network nodes will be discovered on the network via this module. It is also planned that this module will also contain WEB API interface.
- Mysterium Node Core. It is a front-end library (it is not UI [user interface], but it resides in front layer of DApp) orchestrating all other parts of Mysterium node and having access to DB. It can be called layer between DApp and app. Where app consists of UI/Console and a layer providing or consuming VPN connections.
- GUI/Console. Application will have both graphical user interface and console. It will be built on top of portable Mysterium Node Core library. Application will run in Service provider mode or Client mode.
- Local VPN Connection API. Interface providing connection related functionality for different VPN implementations, like getting configuration for new connection, closing connection, monitoring amounts of data transferred and etc.
- Drivers and Secure connection implementations. At the current vision we are willing to use only open source secure connection solutions like OpenVPN, ShadowSokets or something else which is most reasonable. In some cases it might be needed to adopt those solutions by forking them and modifying to get necessary functionality for Mysterium Network. In initial version we will support one or two of secure connection implementations. For implementing different secure connection solutions community support will play a key role.
Lightweight clients of Mysterium Network without database are also possible. In this case micro transactions will be executed through one or few discoverable nodes of Mysterium Network via API (Application Programing Interface). Lightweight solutions might work well for mobile devices and IoT devices. WEB API and portable Mysterium Network Core library will give a possibility for a community driven implementations of client applications for different devices.
It was a short overview of our solution’s vision where we listed main building blocks of Mysterium Network. In one of the next posts we will cover the workflow and interaction between these building blocks explaining other aspects of solution architecture. Which will bring more clarity how Mysterium Network will work, how it will be built and what kind of challenges and risks we might face.
Vidunas — author of this article is an Architect and lead software developer of Mysterium Network and Co-Founder. During free time he is a family guy, breath-work and meditation coach. and just a dreamer with a feet on the ground — as he likes to say ;) Others might say he is off the ground.